ABAC 권한 부여를 통한 속성 기반 권한 정의 - AWS Identity and Access Management
ABAC와 기존 RBAC 모델 비교

ABAC 권한 부여를 통한 속성 기반 권한 정의

ABAC(속성 기반 액세스 제어)는 속성을 기준으로 권한을 정의하는 권한 부여 전략입니다. AWS에서는 이 속성을 태그라고 합니다. IAM 엔터티(IAM 사용자 또는 IAM 역할)를 포함하는 IAM 리소스와 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 작은 정책 세트를 생성할 수 있습니다. 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 ABAC 정책을 설계할 수 있습니다. ABAC의 속성 시스템은 높은 사용자 컨텍스트와 세분화된 액세스 제어를 모두 제공합니다. ABAC는 속성 기반이므로 실시간으로 액세스 권한을 부여하거나 취소하는 데이터 또는 애플리케이션에 대해 동적 권한 부여를 수행할 수 있습니다. ABAC는 확장 중인 환경과 자격 증명 또는 리소스 정책 관리가 복잡해진 상황에서 유용합니다.

예를 들어, access-project 태그 키를 사용하여 세 개의 IAM 역할을 생성할 수 있습니다. 첫 번째 IAM 역할의 태그 값을 Heart로, 두 번째 역할의 태그 값을 Star로, 세 번째 역할의 태그 값을 Lightning으로 설정합니다. 그런 다음 IAM 역할과 AWS 리소스에 태그 값 access-project가 있을 때 액세스를 허용하는 단일 정책을 사용할 수 있습니다. AWS에서 ABAC를 사용하는 방법을 보여 주는 자세한 자습서는 IAM 튜토리얼: 태그를 기반으로 AWS 리소스에 액세스할 수 있는 권한 정의 섹션을 참조하세요. ABAC를 지원하는 서비스에 대해 알아보려면 AWS IAM으로 작업하는 서비스을 참조하세요.

이 다이어그램은 사용자에게 리소스에 대한 권한을 부여하려면 보안 주체에 적용된 태그가 리소스에 적용된 태그와 일치해야 한다는 것을 보여줍니다. 태그는 IAM 그룹, 리소스 그룹, 개별 사용자 및 개별 리소스에 적용됩니다.

ABAC와 기존 RBAC 모델 비교

IAM에 사용되는 기존 권한 부여 모델은 RBAC(역할 기반 액세스 제어)입니다. RBAC는 IAM 역할과 구별되는 개인의 직무나 역할에 따라 권한을 정의합니다. IAM에는 직무에 관한 관리형 정책이 있어 RBAC 모델의 작업 기능에 대한 사용 권한을 정렬할 수 있습니다.

IAM에서는 다양한 직무에 대해 서로 다른 정책을 생성하여 RBAC를 구현합니다. 그런 다음 정책을 자격 증명(IAM 사용자, IAM 그룹 또는 IAM 역할)에 연결합니다. 가장 좋은 방법은 직무에 필요한 최소 권한을 부여하는 것입니다. 이로 인한 결과가 최소 권한 액세스입니다. 각 직능 정책에는 해당 정책이 할당된 자격 증명이 액세스할 수 있는 특정 리소스가 나열되어 있습니다. 기존 RBAC 모델을 사용하면 사용자가 환경에 새 리소스를 추가할 때 해당 리소스에 액세스할 수 있도록 정책을 업데이트해야 한다는 단점이 있습니다.

예를 들어, 직원이 작업 중인 세 개의 프로젝트 Heart, Star 및 Lightning이 있다고 가정합니다. 각 프로젝트에 대한 IAM 역할을 생성합니다. 그런 다음 각 IAM 역할에 정책을 연결하여 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 프로젝트로 옮기는 경우입니다. 팀원에게 Lightning 프로젝트에 대한 액세스 권한을 부여하기 위해 IAM 관리자는 팀원에게 다른 IAM 역할을 할당합니다. 권한 정책을 변경할 필요가 없습니다.

  • ABAC를 사용하여 세분화된 권한을 사용할 수 있습니다. 정책을 생성할 때는 최소 권한을 부여하는 것이 가장 좋습니다. 기존 RBAC를 사용하는 경우에는 특정 리소스에 대한 액세스를 허용하는 정책을 작성합니다. 그러나 ABAC를 사용하는 경우 리소스의 태그가 보안 주체의 태그와 일치하는 경우에만 모든 리소스에 대한 작업을 허용할 수 있습니다.

  • ABAC를 사용하여 회사 디렉터리의 직원 속성을 사용합니다. 세션 태그를 IAM에 전달하도록 SAML 또는 OIDC 공급자를 구성할 수 있습니다. 직원이 AWS에 페더레이션되면 IAM은 해당 속성을 결과 보안 주체에 적용합니다. 그런 다음 ABAC를 사용하여 이러한 속성에 따라 권한을 허용하거나 거부할 수 있습니다.

AWS에서 ABAC를 사용하는 방법을 보여 주는 자세한 자습서는 IAM 튜토리얼: 태그를 기반으로 AWS 리소스에 액세스할 수 있는 권한 정의 섹션을 참조하세요.