# ABAC 권한 부여를 통한 속성 기반 권한 정의
<a name="introduction_attribute-based-access-control"></a>

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 리소스에 액세스할 수 있는 권한 정의](tutorial_attribute-based-access-control.md) 섹션을 참조하세요. ABAC를 지원하는 서비스에 대해 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)을 참조하세요.

![\[이 다이어그램은 사용자에게 리소스에 대한 권한을 부여하려면 보안 주체에 적용된 태그가 리소스에 적용된 태그와 일치해야 한다는 것을 보여줍니다. 태그는 IAM 그룹, 리소스 그룹, 개별 사용자 및 개별 리소스에 적용됩니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/tutorial-abac-concept-23.png)


## ABAC와 기존 RBAC 모델 비교
<a name="introduction_attribute-based-access-control_compare-rbac"></a>

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

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

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

![\[이 다이어그램은 역할 기반 액세스 제어를 위해서는 각 자격 증명에 특정 직무 기반 정책을 할당해야 서로 다른 리소스에 액세스할 수 있음을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/tutorial-abac-rbac-concept-23.png)


**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를 사용하여 세분화된 권한을 사용할 수 있습니다.** 정책을 생성할 때는 [최소 권한을 부여](best-practices.md#grant-least-privilege)하는 것이 가장 좋습니다. 기존 RBAC를 사용하는 경우에는 특정 리소스에 대한 액세스를 허용하는 정책을 작성합니다. 그러나 ABAC를 사용하는 경우 리소스의 태그가 보안 주체의 태그와 일치하는 경우에만 모든 리소스에 대한 작업을 허용할 수 있습니다.
+ **ABAC를 사용하여 회사 디렉터리의 직원 속성을 사용합니다.** 세션 태그를 IAM에 전달하도록 SAML 또는 OIDC 공급자를 구성할 수 있습니다. 직원이 AWS에 페더레이션되면 IAM은 해당 속성을 결과 보안 주체에 적용합니다. 그런 다음 ABAC를 사용하여 이러한 속성에 따라 권한을 허용하거나 거부할 수 있습니다.

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