ABAC 승인으로 속성 기반 권한 정의하기
ABAC 승인으로 속성 기반 권한 정의하기
속성 기반 접근 제어(Attribute-based access control, ABAC)는 속성(attributes)에 따라 권한을 정의하는 승인 전략이에요. AWS에서는 이 속성을 태그(tag) 라고 불러요. IAM 리소스(IAM 사용자·IAM 역할 같은 IAM 엔터티 포함)와 AWS 리소스에 태그를 연결할 수 있고요. IAM 프린시펄을 위해 단일 ABAC 정책이나 작은 정책 집합을 만들 수 있어요. 프린시펄의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 ABAC 정책을 설계할 수 있죠. ABAC는 높은 사용자 컨텍스트와 세밀한 접근 제어를 모두 제공하는 속성 시스템이에요. 이번 글에서는 ABAC가 무엇이고, 전통적 RBAC 모델과 어떻게 다른지 살펴볼게요.
출처: 문서
본문
ABAC는 속성 기반이므로 데이터나 애플리케이션에 대해 실시간으로 접근을 부여하거나 해지하는 동적 승인을 수행할 수 있어요. ABAC는 확장 중인 환경이나 자격 증명·리소스 정책 관리가 복잡해진 상황에서 유용해요.
예를 들어 access-project 태그 키를 가진 IAM 역할 3개를 만들 수 있어요. 첫 번째 IAM 역할의 태그 값을 Heart, 두 번째를 Star, 세 번째를 Lightning으로 설정해요. 그러면 IAM 역할과 AWS 리소스가 같은 태그 값 access-project를 가질 때 접근을 허용하는 단일 정책을 사용할 수 있어요. AWS에서 ABAC를 사용하는 자세한 튜토리얼은 IAM 튜토리얼: 태그 기반 권한으로 AWS 리소스 접근 정의하기를 참고하고, ABAC를 지원하는 서비스는 IAM과 함께 작동하는 AWS 서비스를 확인하세요.
ABAC와 전통적 RBAC 모델 비교 (Comparison of ABAC to the traditional RBAC model)
IAM에서 사용되는 전통적 승인 모델은 역할 기반 접근 제어(Role-based access control, RBAC)예요. RBAC는 사람의 직무 함수(job function), 즉 역할(role) 에 따라 권한을 정의하며, 여기서 역할은 IAM 역할과는 구별돼요. IAM에는 RBAC 모델에서 권한을 직무 함수에 맞추는 직무 함수용 관리형 정책이 포함돼 있어요.
IAM에서 RBAC를 구현하려면 직무 함수별로 서로 다른 정책을 만든 뒤 자격 증명(IAM 사용자, IAM 그룹, IAM 역할)에 정책을 연결해요. 모범 사례에 따라 직무 함수에 필요한 최소 권한을 부여하는데, 이게 최소 권한(least privilege) 접근이에요. 각 직무 함수 정책은 그 정책을 할당받은 자격 증명이 접근할 수 있는 특정 리소스를 나열해요. 전통적 RBAC 모델의 단점은 사용자나 사용자가 환경에 새 리소스를 추가할 때마다 그 리소스 접근을 허용하도록 정책을 업데이트해야 한다는 거예요.
예를 들어 직원들이 작업하는 Heart, Star, Lightning이라는 프로젝트가 3개 있다고 가정해 볼게요. 각 프로젝트마다 IAM 역할을 만들고, 그 역할을 맡을 수 있는 사람이 접근할 수 있는 리소스를 정의하도록 각 역할에 정책을 연결해요. 직원이 회사 내에서 업무를 바꾸면 다른 IAM 역할에 할당해요. 사람이나 프로그램을 여러 IAM 역할에 할당할 수도 있어요. 그런데 Star 프로젝트에 새 Amazon EC2 컨테이너 같은 추가 리소스가 필요해질 수 있어요. 그 경우 Star IAM 역할에 연결된 정책을 업데이트해 새 컨테이너 리소스를 지정해야 해요. 그렇지 않으면 Star 프로젝트 구성원은 새 컨테이너에 접근할 수 없거든요.
ABAC는 전통적 RBAC 모델에 비해 다음과 같은 장점을 제공해요.
- ABAC 권한은 혁신과 함께 확장돼요. 관리자가 새 리소스 접근을 허용하기 위해 기존 정책을 업데이트할 필요가 없어요. 예를 들어
access-project태그로 ABAC 전략을 설계했다고 해 볼게요. 개발자가access-project=Heart태그가 있는 IAM 역할을 사용해요.Heart프로젝트 직원들이 추가 Amazon EC2 리소스가 필요하면, 개발자가access-project=Heart태그가 있는 새 Amazon EC2 인스턴스를 만들 수 있어요. 그러면 태그 값이 일치하므로Heart프로젝트의 모든 사람이 그 인스턴스를 시작·중지할 수 있어요. - ABAC는 더 적은 정책이 필요해요. 직무 함수마다 다른 정책을 만들 필요가 없으니 정책 수가 줄고, 관리도 쉬워져요.
- ABAC로 팀이 변화와 성장에 동적으로 대응할 수 있어요. 새 리소스에 대한 권한이 속성 기반으로 자동 부여되므로 자격 증명에 정책을 수동으로 할당할 필요가 없어요. 예를 들어 회사가 이미 ABAC로
Heart와Star프로젝트를 지원하고 있다면, 새Lightning프로젝트를 추가하기 쉬워요. IAM 관리자가access-project=Lightning태그를 가진 새 IAM 역할을 만들면 되고, 새 프로젝트를 지원하려고 정책을 바꿀 필요가 없어요. 그 IAM 역할을 맡을 권한이 있는 사람은 누구든access-project=Lightning태그가 달린 인스턴스를 만들고 볼 수 있어요. 또 팀원이Heart프로젝트에서Lightning프로젝트로 이동하는 경우에도, IAM 관리자가 팀원을 다른 IAM 역할에 할당하기만 하면 돼요. 권한 정책을 바꿀 필요가 없어요. - ABAC로 세분화된 권한이 가능해요. 정책을 만들 때는 최소 권한을 부여하는 게 모범 사례예요. 전통적 RBAC에서는 특정 리소스에 대해 접근을 허용하는 정책을 작성해요. 하지만 ABAC를 사용하면 리소스의 태그가 프린시펄의 태그와 일치할 때 모든 리소스에 대한 액션을 허용할 수 있어요.
- 회사 디렉터리의 직원 속성을 ABAC로 사용해요. SAML이나 OIDC 공급자를 구성해 세션 태그(session tags)를 IAM에 전달할 수 있어요. 직원들이 AWS에 페더레이션하면 IAM이 직원의 속성을 결과 프린시펄에 적용해요. 그런 다음 ABAC를 사용해 그 속성에 따라 권한을 허용하거나 거부할 수 있어요.
AWS에서 ABAC를 사용하는 자세한 튜토리얼은 IAM 튜토리얼: 태그 기반 권한으로 AWS 리소스 접근 정의하기를 확인하세요.