AWS용 ABAC란 무엇입니까? - AWS Identity and Access Management
ABAC와 기존 RBAC 모델 비교

AWS용 ABAC란 무엇입니까?

ABAC(속성 기반 액세스 제어)는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. AWS에서는 이러한 속성을 태그라고 합니다. IAM 엔터티(사용자 또는 역할)와 AWS 리소스에 태그를 연결할 수 있습니다. IAM 보안 주체에 대해 단일 ABAC 정책 또는 작은 정책 세트를 생성할 수 있습니다. 이러한 ABAC 정책은 보안 주체의 태그가 리소스 태그와 일치할 때 작업을 허용하도록 설계될 수 있습니다. ABAC는 빠르게 성장하는 환경에서 유용하며 정책 관리가 번거로운 상황에 도움이 됩니다.

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

ABAC 모델

ABAC와 기존 RBAC 모델 비교

IAM에 사용되는 기존 권한 부여 모델을 역할 기반 액세스 제어(RBAC)라고 합니다. RBAC는 AWS 외부에서 역할로 알려진 개인의 직무에 따라 권한을 정의합니다. AWS 내에서 역할은 일반적으로 사용자가 수임할 수 있는 IAM의 자격 증명인 IAM 역할을 나타냅니다. IAM에는 직무에 관한 관리형 정책이 있어 RBAC 모델의 작업 기능에 대한 사용 권한을 정렬할 수 있습니다.

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

예를 들어, 직원이 작업 중인 세 개의 프로젝트 Heart, Star 및 Lightning이 있다고 가정합니다. 각 프로젝트에 대한 IAM 역할을 생성합니다. 그런 다음 각 IAM 역할에 정책을 연결하여 역할을 맡을 수 있는 모든 사람이 액세스할 수 있는 리소스를 정의합니다. 직원이 회사 내에서 직무를 변경하는 경우 다른 IAM 역할에 해당 직무를 할당합니다. 사람이나 프로그램은 둘 이상의 역할에 할당될 수 있습니다. 그러나 Star 프로젝트에 새 Amazon EC2 컨테이너와 같은 추가 리소스가 필요할 수 있습니다. 이 경우 Star 역할에 연결된 정책을 업데이트하여 새 컨테이너 리소스를 지정해야 합니다. 그렇지 않으면 Star 프로젝트 멤버가 새 컨테이너에 액세스할 수 없습니다.

RBAC 모델
ABAC는 전통적인 RBAC 모델에 비해 다음과 같은 이점을 제공합니다.

  • ABAC 권한은 혁신적으로 확장됩니다. 관리자가 새 리소스에 액세스할 수 있도록 기존 정책을 업데이트할 필요가 없습니다. 예를 들어, access-project 태그로 ABAC 전략을 설계했다고 가정합니다. 개발자는 access-project = Heart 태그와 함께 역할을 사용합니다. Heart 사용자에게 추가 Amazon EC2 리소스가 필요한 경우 개발자는 access-project = Heart 태그를 사용하여 새 Amazon EC2 인스턴스를 생성할 수 있습니다. 그러면 Heart 프로젝트의 모든 사용자가 태그 값이 일치하기 때문에 해당 인스턴스를 시작하고 중지할 수 있습니다.

  • ABAC를 사용하면 필요한 정책 수가 적어집니다. 각 직무에 대해 서로 다른 정책을 생성할 필요가 없기 때문에 생성해야 하는 정책이 더 적습니다. 그러므로 정책을 관리하기가 더 쉽습니다.

  • ABAC를 사용하여 팀은 빠르게 변화하고 성장할 수 있습니다. 새 리소스에 대한 권한이 속성에 따라 자동으로 부여되기 때문입니다. 예를 들어, 회사에서 이미 ABAC를 사용하여 Heart 및 Star 프로젝트를 지원하는 경우 새 Lightning 프로젝트를 쉽게 추가할 수 있습니다. IAM 관리자는 access-project = Lightning 태그를 사용하여 새 역할을 생성합니다. 새 프로젝트를 지원하기 위해 정책을 변경할 필요는 없습니다. 역할을 맡을 권한이 있는 모든 사용자는 access-project = Lightning 태그가 지정된 인스턴스를 생성하고 볼 수 있습니다. 또한 팀 멤버가 Heart 프로젝트에서 Lightning 프로젝트로 이동할 수 있습니다. IAM 관리자는 사용자를 다른 IAM 역할에 할당합니다. 권한 정책을 변경할 필요가 없습니다.

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

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

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