Devocean을 통해 정책엔진인 OPA에 대해 소개한 적이있다.(https://devocean.sk.com/blog/techBoardDetail.do?ID=163522) 이를 적용하기 위해 다양한 스터디를 진행하고 있다. 때마침 OPA Slack(https://slack.openpolicyagent.org/)에 ‘OPA를 사용해 Attribute Based Access Control (ABAC)구현하는 방법’ (https://dev.to/permit_io/how-to-implement-attribute-based-access-control-abac-using-open-policy-agent-opa-3ek4)이라는 글이 소개되어 이를 번역하고자 한다.
인증을 구성하는 것은 복잡하고 노력이 많이 필요한 일이 될수 있다. 인증을 구성하는 다양한 모델들과 방법이 존재하지만, 최종적 목표는 우리가 적합한 사용자에게 적합한 권한을 부여하는 것이다. 이러한 이유로 우리는 몇가지 인증모델(ABAC, RBAC)을 살펴보고 OPA를 통해 어떻게 구현할 것인가를 설명할 것이다.
ABAC과 RBAC은 가장 기본적이고 일반적으로 사용되는 두가지 권한부여 모듈이고 대부분의 복잡하거나 특화된 시스템의 기준선을 제공한다.
역할 기반 접근제어는 미리 정의된 역할을 기반으로 접근 제어를 결정하는 권한 부여 모델이다. 권한은 역할(예: Admin, User...)에 할당되고 역할은 관리자가 사용자에게 할당한다. 이 구조를 통해 누가 어디에 접근했는지 쉽게 인지할 수 있다.
사용자(어떤 사용자가), 자원(어떤 자원에), 작업(어떤 일을 수행할지)- 세가지의 조합을 ‘정책’이라 한다 .
속성 기반 접근제어는 역할이 아닌 속성 이라는 특징의 집합을 기반으로 접근을 결정한다. 속성에는 사용자 역할, 보안 허가, 액세스 시간, 현재 시간, 데이터 위치, 현재 조직의 위협 수준, 리소스 생성 날짜 또는 소유권, 데이터 민감도 등에 대한 값들이 포함된다.
ABAC에서는 사용자뿐만 아니라 접근하려는 자원이나 전체시스템 및 이 상황와 관련된 기타 모든 것에 대한 속성을 확인하는 것에 유의하자.
사용자(어떤 사용자가), 자원(어떤 자원에), 작업(어떤 일을 수행할지), 상황(이 동작이 수행되기 위해 필요한 환경) - 네가지의 조합을 기반으로 ABAC ‘정책’이 만들어진다.
조직의 요구사항에 따라 RBAC와 ABAC 중 선택하게 된다.
RBAC는 권한 부여를 결정하기 위한 다소 간단한 솔루션을 제공한다. RBAC에서 확장된 ABAC는 무단접근를 방지를 위한보다 심층적인 접근 방식을 제공한다. 더 많은 처리 능력과 시간이 필요하지만, ABAC는 훨씬 더 많은 수의 변수를 포함하는 더 복잡하고 상세한 인증이 가능하다.
많은 경우에 RBAC 및 ABAC는 함께 계층적으로 사용할 수 있다(RBAC에 의한 광범위한 접근제어와 ABAC에 의한 보다 복잡한 접근제어). 즉, 조직의 요구 사항에 맞는 적절한(너무 단순하지도 복잡하지도 않는) 인증 방법을 선택하는 것이 중요하다.
이 글의 목적상 ABAC을 선택했다고 가정한다.
ABAC를 사용하여 정책을 설정하기로 결정했다면, 다음과 같은 문제를 만나게 될 것이다.
각 개별 서비스에 대한 정책 집합은 서비스 내부에 수동으로 설정되어야 한다. 정책, 사용자 및 서비스의 양이 증가함에 따라 각 관련 서비스에서 변경은 매우 지루하고 시간 소모적 작업이 된다. 그뿐만 아니라 정책이 시시각각 변하기 때문에 최소한의 유동성을 가져야 한다. 또 다른 문제는 인증 계층의 코드가 애플리케이션 자체의 코드와 혼합되어 있을 때 발생할 수 있다. 이로 인해 서로 다른 마이크로서비스 간에 복제되는 코드를 업그레이드하고, 기능을 추가하고, 모니터링하는 데 어려움을 겪는 상황이 발생한다. 횔용하는 마이크로 서비스가 개발됨에 따라 서로 더 멀리 확산되고, 각 변경사항은 많은 코드 영역의 리팩토링을 요구한다.