RBAC 와 ABAC

클라우드 환경에서 접근 제어에 대한 두가지의 접근 모델을 알아본다.

RBAC(Role-Based Access Control) : 역할기반 제어

정의 : 사용자의 역할에 따라 접근 가능한 리소스를 결정.

특징

• 역할이 잘 정의되어 있을 때 직관적이고 사용하기 쉽다.
• 사용자에게 역할을 할당하면 해당 역할에 고정된 권한 집합이 부여된다.
  

클라우드 환경에서 왜 RBAC가 유용한가?

• 최소 권한 원칙(PoLP) : 사용자는 필요한 최소한의 권한만 부여받아 계정이 해킹당했을 때 피해 범위 최소화 가능
• 운영 효율성 : 사용자별로 권한을 할당하는 대신 역할 수준에서 권한을 관리합니다. 새로운 사용자를 추가할 때는 해당 사용자에게 적합한 역할을 할당하기만 하면 됨
• 확장성 : 소규모 개발팀을 운영하든 글로벌 기업을 운영하든 동일하게 작동
• 중앙 집중식 관리 : 역할 기능을 통해 누가 어떤 권한에 접근할 수 있는지 한눈에 확인하고 조정 가능.
• 규정 준수 및 감사 : HIPAA, GDPR, SOX와 같은 표준은 접근 제어에 대한 입증을 요구합니다. RBAC는 접근 권한을 명확하게 정의된 역할에 연결함으로써 감사를 간소화
• 내부자 위협 완화 : 권한 강화는 우발적이거나 악의적인 데이터 노출 가능성을 줄여줌.
• 서비스 간 권한 부여 : 마이크로서비스 중심의 환경에서 RBAC는 서비스 간 통신 방식을 제한가능.

클라우드 환경에서 왜 RBAC의 한계

RBAC가 완벽했더라면 ABAC는 필요없었을 것이다.
알려진 RBAC의 한계는 다음과 같다.

• 역할 확산 : 프로덕션 환경에서는 개발자에게 읽기 전용 스토리지 권한을, 스테이징 환경에서는 개발자에게 쓰기 권한을, 운영팀에게는 전체 액세스 권한을, 지원팀에게는 읽기 전용 EC2 인스턴스 권한을 부여하는 등 거의 동일한 역할이 수십 개씩 생성되는 경우가 발생함.

• 상황 인식의 부족 : RBAC는 태그, 사용자 속성, 시간이나 IP 주소와 같은 조건을 고려하지 않음, 특정 역할에서 허용된 작업은 모든 환경에서 허용됨

  ABAC(Attribute-Based Access Control) : 속성기반 제어

정의 :사용자의 역할뿐 아니라 사용자 및 리소스의 속성에 따라 세부적인 접근 권한을 제어.

특징

• 접근 권한을 부여하기 전에 사용자, 리소스, 그리고 경우에 따라 환경의 속성을 평가하는 더욱 심층적인 접근 제어 방식이다.
• 역할만으로는 확장이 어려운 복잡하고 다중 테넌트 환경 또는 동적인 환경에서 더 큰 유연성을 제공한다.

예시

개발자 역할은 버킷에 쓰기 권한을 가집니다" 라고 명시하는 대신 , "버킷의 env=dev 속성이 있고 호출자의 팀 태그가 engineering인 경우에만 쓰기 권한을 허용합니다" 라고 지정.

ABAC는 어떤 환경, 어떤 리소스, 그리고 어떤 조건에서 해당 권한을 실제로 사용할 수 있는지에 대한 정확성을 강화한다.

구성요소

• 속성 : 사용자, 자원 또는 환경의 특성. 여기에는 사용자 속성(예: 부서, 직책), 자원 속성(예: 문서 유형, 분류) 및 환경 속성(예: 시간, 위치)이 포함될 수 있다.
• 정책 : 속성을 사용하여 접근 권한을 부여하거나 거부하는 방법을 정의하는 규칙이다.
• 요청 : 사용자가 리소스에 접근하려는 시도이며, 속성을 사용하여 정책에 따라 평가된다.

RBAC와 비교하였을 때 정책 관리 복잡, 초기 설계 비용 증가한다는 단점이 존재한다.
기본적으로 RBAC 환경에서 고위험·동적 환경에 ABAC을 결합한 혼합형 접근 통제(RBAC+ABAC) 방식도 존재한다.

https://www.firefly.ai/academy/rbac-vs-abac#:~:text=RBAC%20(Role%2DBased%20Access%20Control)%20grants%20permissions%20based%20on,is%20dynamic%20and%20context%2Ddriven.