태그 기반으로 AWS 리소스에 대한 접근 권한 정의하기

태그 기반으로 AWS 리소스에 대한 접근 권한 정의하기 (ABAC 튜토리얼)

ABAC(속성 기반 접근 제어)는 속성에 따라 권한을 정의하는 인가 전략이에요. AWS에서 이러한 속성을 _태그_라고 해요. IAM 리소스(IAM 엔터티, 즉 사용자나 역할 포함)와 AWS 리소스에 태그를 연결할 수 있어요. 정책에서 태그 조건 키를 사용해 프린시펄의 태그에 따라 권한을 부여하도록 정의할 수 있어요. 태그로 AWS 리소스에 대한 접근을 제어하면 팀과 리소스가 성장해도 AWS 정책을 거의 변경하지 않아도 돼요. ABAC 정책은 개별 리소스를 각각 나열해야 하는 기존 AWS 정책보다 더 유연해요. ABAC와 기존 정책에 비해 가지는 장점에 대한 자세한 내용은 "속성 기반 접근 제어(ABAC) 인가로 속성에 따라 권한 정의"를 참고하세요.

참고 – 각 세션 태그에는 단일 값을 전달해야 해요. AWS Security Token Service는 다중 값 세션 태그를 지원하지 않아요.

출처: 문서

본문

이 튜토리얼은 프린시펄 태그가 있는 IAM 역할이 일치하는 태그가 있는 리소스에만 접근할 수 있게 하는 정책을 만들고 테스트하는 방법을 보여줘요. 프린시펄이 AWS에 요청을 하면 프린시펄 태그와 리소스 태그가 일치하는지에 따라 권한이 부여돼요. 이 전략을 사용하면 개인이 작업에 필요한 AWS 리소스만 보거나 편집할 수 있어요.

튜토리얼 개요 (Tutorial overview)

시나리오 (Scenario)

Example Corporation이라는 대기업의 수석 개발자이자 경험 많은 IAM 관리자라고 가정해 볼게요. IAM 사용자, 역할, 정책을 만들고 관리하는 데 익숙해요. 개발 엔지니어와 품질 보증 팀 구성원이 필요한 리소스에 접근할 수 있도록 보장하고 싶어요. 또한 회사가 성장함에 따라 확장되는 전략도 필요해요.

AWS Secrets Manager에서 시작해 태그를 지원하는 서비스에 대해 AWS 리소스 태그와 IAM 역할 프린시펄 태그를 사용해 ABAC 전략을 구현하기로 결정해요. 태그 기반 인가를 지원하는 서비스를 알아보려면 "IAM과 함께 작동하는 AWS 서비스"를 참고하세요. 각 서비스의 작업과 리소스와 함께 정책에서 사용할 수 있는 태그 지정 조건 키를 알아보려면 "AWS 서비스의 작업, 리소스, 조건 키"를 참고하세요. SAML 기반 또는 웹 자격 증명 공급자를 구성해 세션 태그를 AWS에 전달할 수도 있어요. 직원이 AWS에 페더레이션하면 해당 속성이 AWS의 결과 프린시펄에 적용돼요. 그런 다음 ABAC를 사용해 이러한 속성에 따라 권한을 허용하거나 거부할 수 있어요. SAML 페더레이션 ID와 세션 태그를 사용하는 것이 이 튜토리얼과 어떻게 다른지 알아보려면 "IAM 튜토리얼: ABAC에 SAML 세션 태그 사용"을 참고하세요.

Engineering과 Quality Assurance 팀 구성원은 Pegasus 또는 Unicorn 프로젝트에 속해 있어요. 다음 3자리 프로젝트 및 팀 태그 값을 선택해요.

access-project = peg for the Pegasus project
access-project = uni for the Unicorn project
access-team = eng for the Engineering team
access-team = qas for the Quality Assurance team

또한 사용자 지정 AWS 청구 보고서를 활성화하려면 cost-center 비용 할당 태그를 요구하도록 선택해요. 자세한 내용은 _AWS Billing and Cost Management User Guide_의 "비용 할당 태그 사용"을 참고하세요.

주요 결정 사항 요약 (Summary of key decisions)

직원은 IAM 사용자 자격 증명으로 로그인한 뒤 팀과 프로젝트의 IAM 역할을 맡아요. 회사에 자체 ID 시스템이 있다면 직원이 IAM 사용자 없이 역할을 맡도록 페더레이션을 설정할 수 있어요. 자세한 내용은 "IAM 튜토리얼: ABAC에 SAML 세션 태그 사용"을 참고하세요.
모든 역할에 동일한 정책이 연결돼요. 작업은 태그에 따라 허용되거나 거부돼요.
직원은 역할에 적용된 것과 동일한 태그를 리소스에 연결해야만 새 리소스를 만들 수 있어요. 이렇게 하면 직원이 만든 후 그 리소스를 볼 수 있게 보장돼요. 관리자는 더 이상 새 리소스의 ARN으로 정책을 업데이트할 필요가 없어요.
직원은 프로젝트와 관계없이 팀이 소유한 리소스를 읽을 수 있어요.
직원은 자신의 팀과 프로젝트가 소유한 리소스를 업데이트하고 삭제할 수 있어요.
IAM 관리자는 새 프로젝트에 새 역할을 추가할 수 있어요. 적절한 역할에 대한 접근을 허용하는 새 IAM 사용자를 만들고 태그를 지정할 수 있어요. 관리자가 새 프로젝트나 팀 구성원을 지원하기 위해 정책을 편집할 필요는 없어요.

이 튜토리얼에서는 각 리소스에 태그를 지정하고, 프로젝트 역할에 태그를 지정하며, 앞서 설명한 동작을 허용하는 정책을 역할에 추가해요. 결과 정책은 동일한 프로젝트와 팀 태그로 태그된 리소스에 대해 역할에 Create, Read, Update, Delete 접근을 허용해요. 이 정책은 또한 동일한 팀으로 태그된 리소스에 대한 프로젝트 간 Read 접근도 허용해요.

사전 요구 사항 (Prerequisites)

이 튜토리얼의 단계를 수행하려면 다음이 이미 준비되어 있어야 해요.

관리 권한이 있는 사용자로 로그인할 수 있는 AWS 계정
3단계에서 역할을 만드는 데 사용하는 12자리 계정 ID. AWS Management Console로 AWS 계정 ID 번호를 찾으려면 오른쪽 위 탐색 모음에서 Support를 선택한 뒤 Support Center를 선택해요. 계정 번호(ID)가 왼쪽 탐색 창에 나타나요.
AWS Management Console에서 IAM 사용자, 역할, 정책을 만들고 편집한 경험. 하지만 IAM 관리 프로세스를 기억하는 데 도움이 필요하다면 이 튜토리얼에서 단계별 지침을 볼 수 있는 링크를 제공해요.

1단계: 테스트 사용자 생성 (Step 1: Create test users)

테스트를 위해 동일한 태그가 있는 역할을 맡을 권한이 있는 IAM 사용자 네 명을 만들어요. 이렇게 하면 팀에 사용자를 더 쉽게 추가할 수 있어요. 사용자에 태그를 지정하면 자동으로 올바른 역할을 맡을 접근 권한을 얻게 돼요. 사용자가 한 프로젝트와 팀에서만 작업한다면 역할의 신뢰 정책에 사용자를 추가할 필요가 없어요.

이름이 access-assume-role인 다음 고객 관리형 정책을 만들어요. JSON 정책 생성에 대한 자세한 내용은 "IAM 정책 생성"을 참고하세요.

ABAC 정책: 사용자와 역할 태그가 일치할 때만 모든 ABAC 역할 맡기

다음 정책은 사용자가 계정에서 access- 이름 접두사를 가진 모든 역할을 맡을 수 있게 해요. 역할에도 사용자와 동일한 프로젝트, 팀, 비용 센터 태그가 있어야 해요.

이 정책을 사용하려면 _기울임꼴 자리 표시자 텍스트_를 계정 정보로 바꿔요.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::111122223333:role/access-*",
            "Condition": {
                "StringEquals": {
                    "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                    "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                    "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
                }
            }
        }
    ]
}

이 튜토리얼을 많은 수의 사용자로 확장하려면 그룹에 정책을 연결하고 각 사용자를 그룹에 추가할 수 있어요. 자세한 내용은 "IAM 그룹 생성"과 "IAM 그룹의 사용자 편집"을 참고하세요.

다음 IAM 사용자를 만들고 access-assume-role 권한 정책을 연결해요. Provide user access to the AWS Management Console을 선택하고 다음 태그를 추가하세요.

사용자 이름	사용자 태그 키	사용자 태그 값
access-Arnav-peg-eng	access-project access-team cost-center	peg eng 987654
access-Mary-peg-qas	access-project access-team cost-center	peg qas 987654
access-Saanvi-uni-eng	access-project access-team cost-center	uni eng 123456
access-Carlos-uni-qas	access-project access-team cost-center	uni qas 123456

2단계: ABAC 정책 생성 (Step 2: Create the ABAC policy)

이름이 access-same-project-team인 다음 정책을 만들어요. 이 정책을 이후 단계에서 역할에 추가할 거예요. JSON 정책 생성에 대한 자세한 내용은 "IAM 정책 생성"을 참고하세요.

이 튜토리얼에 맞게 조정할 수 있는 추가 정책은 다음 페이지를 참고하세요.

ABAC 정책: 프린시펄과 리소스 태그가 일치할 때만 Secrets Manager 리소스에 접근

다음 정책은 프린시펄이 리소스를 생성, 읽기, 편집, 삭제할 수 있게 하지만, 리소스가 프린시펄과 동일한 키-값 쌍으로 태그된 경우에만 허용해요. 프린시펄이 리소스를 만들 때 프린시펄의 태그와 일치하는 값으로 access-project, access-team, cost-center 태그를 추가해야 해요. 이 정책은 선택적 Name 또는 OwnedBy 태그 추가도 허용해요.

{
 "Version":"2012-10-17",
 "Statement": [
     {
         "Sid": "AllActionsSecretsManagerSameProjectSameTeam",
         "Effect": "Allow",
         "Action": "secretsmanager:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
             },
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "access-project",
                     "access-team",
                     "cost-center",
                     "Name",
                     "OwnedBy"
                 ]
             },
             "StringEqualsIfExists": {
                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
             }
         }
     },
     {
         "Sid": "AllResourcesSecretsManagerNoTags",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:GetRandomPassword",
             "secretsmanager:ListSecrets"
         ],
         "Resource": "*"
     },
     {
         "Sid": "ReadSecretsManagerSameTeam",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:Describe*",
             "secretsmanager:Get*",
             "secretsmanager:List*"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
             }
         }
     },
     {
         "Sid": "DenyUntagSecretsManagerReservedTags",
         "Effect": "Deny",
         "Action": "secretsmanager:UntagResource",
         "Resource": "*",
         "Condition": {
             "ForAnyValue:StringLike": {
                 "aws:TagKeys": "access-*"
             }
         }
     },
     {
         "Sid": "DenyPermissionsManagement",
         "Effect": "Deny",
         "Action": "secretsmanager:*Policy",
         "Resource": "*"
     }
 ]
}

이 정책은 무엇을 하나요?

AllActionsSecretsManagerSameProjectSameTeam 문은 이 서비스의 모든 작업을 관련 리소스 전부에 대해 허용하지만, 리소스 태그가 프린시펄 태그와 일치하는 경우에만 허용해요. 정책에 "Action": "secretsmanager:*"를 추가하면 Secrets Manager가 성장함에 따라 정책도 성장해요. Secrets Manager가 새 API 작업을 추가하면 문에 해당 작업을 추가할 필요가 없어요. 이 문은 세 개의 조건 블록을 사용해 ABAC를 구현해요. 세 블록이 모두 true를 반환할 때만 요청이 허용돼요.
- 이 문의 첫 번째 조건 블록은 지정된 태그 키가 리소스에 있고 해당 값이 프린시펄의 태그와 일치하면 true를 반환해요. 이 블록은 태그가 일치하지 않거나 리소스 태그 지정을 지원하지 않는 작업에 대해서는 false를 반환해요. 이 블록이 허용하지 않는 작업을 알아보려면 "AWS Secrets Manager의 작업, 리소스, 조건 키"를 참고하세요. 해당 페이지는 ****Secret 리소스 유형에서 수행되는 작업이 secretsmanager:ResourceTag/tag-key 조건 키를 지원한다는 것을 보여줘요. GetRandomPassword와 ListSecrets를 포함해 일부 Secrets Manager 작업은 해당 리소스 유형을 지원하지 않아요. 이러한 작업을 허용하려면 추가 문을 만들어야 해요.
- 두 번째 조건 블록은 요청에 전달된 모든 태그 키가 지정된 목록에 포함되면 true를 반환해요. 이는 ForAllValues와 StringEquals 조건 연산자를 사용해 수행돼요. 키가 전달되지 않거나 키의 부분 집합이 전달되면 조건은 true를 반환해요. 이렇게 하면 요청에 태그 전달을 허용하지 않는 Get* 작업이 허용돼요. 요청자가 목록에 없는 태그 키를 포함하면 조건은 false를 반환해요. 요청에 전달되는 모든 태그 키는 이 목록의 구성원과 일치해야 해요. 자세한 내용은 "다중값 컨텍스트 키의 집합 연산자"를 참고하세요.
- 세 번째 조건 블록은 요청이 태그 전달을 지원하고, 세 태그가 모두 존재하며, 프린시펄 태그 값과 일치하면 true를 반환해요. 이 블록은 요청이 태그 전달을 지원하지 않으면 true를 반환해요. 이는 조건 연산자의 ...IfExists 덕분이에요. 이 블록은 태그 전달을 지원하는 작업 중 태그가 전달되지 않거나 태그 키·값이 일치하지 않으면 false를 반환해요.
AllResourcesSecretsManagerNoTags 문은 첫 번째 문이 허용하지 않는 GetRandomPassword와 ListSecrets 작업을 허용해요.
ReadSecretsManagerSameTeam 문은 프린시펄이 리소스와 동일한 access-team 태그로 태그된 경우 읽기 전용 작업을 허용해요. 프로젝트나 비용 센터 태그와 관계없이 허용돼요.
DenyUntagSecretsManagerReservedTags 문은 Secrets Manager에서 "access-"로 시작하는 키가 있는 태그를 제거하는 요청을 거부해요. 이러한 태그는 리소스에 대한 접근을 제어하는 데 사용되므로 태그를 제거하면 권한이 제거될 수 있어요.
DenyPermissionsManagement 문은 Secrets Manager 리소스 기반 정책을 생성, 편집, 삭제하는 접근을 거부해요. 이러한 정책은 비밀의 권한을 변경하는 데 사용될 수 있어요.

중요 – 이 정책은 서비스의 모든 작업을 허용하되 권한 변경 작업을 명시적으로 거부하는 전략을 사용해요. 작업 거부는 프린시펄이 해당 작업을 수행하도록 허용하는 다른 정책을 모두 재정의해요. 이는 의도하지 않은 결과를 초래할 수 있어요. 모범 사례에 따라 해당 작업을 허용해야 할 상황이 전혀 없을 때만 명시적 거부를 사용하세요. 그렇지 않으면 개별 작업 목록을 허용하고 원치 않는 작업은 기본적으로 거부하는 것이 좋아요.

3단계: 역할 생성 (Step 3: Create roles)

다음 IAM 역할을 만들고 이전 단계에서 만든 access-same-project-team 정책을 연결해요. IAM 역할 생성에 대한 자세한 내용은 "IAM 사용자에게 권한을 부여할 역할 생성"을 참고하세요. IAM 사용자와 역할 대신 페더레이션을 사용하기로 선택했다면 "IAM 튜토리얼: ABAC에 SAML 세션 태그 사용"을 참고하세요.

직무	역할 이름	역할 태그	역할 설명
Project Pegasus Engineering	access-peg-engineering	access-project = peg access-team = eng cost-center = 987654	엔지니어가 모든 엔지니어링 리소스를 읽고 Pegasus 엔지니어링 리소스를 만들고 관리할 수 있게 허용해요.
Project Pegasus Quality Assurance	access-peg-quality-assurance	access-project = peg access-team = qas cost-center = 987654	QA 팀이 모든 QA 리소스를 읽고 모든 Pegasus QA 리소스를 만들고 관리할 수 있게 허용해요.
Project Unicorn Engineering	access-uni-engineering	access-project= uni access-team = eng cost-center = 123456	엔지니어가 모든 엔지니어링 리소스를 읽고 Unicorn 엔지니어링 리소스를 만들고 관리할 수 있게 허용해요.
Project Unicorn Quality Assurance	access-uni-quality-assurance	access-project = uni access-team = qas cost-center = 123456	QA 팀이 모든 QA 리소스를 읽고 모든 Unicorn QA 리소스를 만들고 관리할 수 있게 허용해요.

4단계: 비밀 생성 테스트 (Step 4: Test creating secrets)

역할에 연결된 권한 정책은 직원이 비밀을 만들 수 있게 해요. 비밀이 프로젝트, 팀, 비용 센터로 태그된 경우에만 허용돼요. 사용자로 로그인하고 올바른 역할을 맡은 뒤 Secrets Manager에서 활동을 테스트해 권한이 예상대로 작동하는지 확인해요.

필수 태그가 있거나 없는 비밀 생성을 테스트하려면

기본 브라우저 창에서 관리자 사용자로 로그인한 상태를 유지해 IAM에서 사용자, 역할, 정책을 검토할 수 있게 해요. 테스트에는 브라우저 시크릿 창이나 별도 브라우저를 사용해요. 거기서 access-Arnav-peg-eng IAM 사용자로 로그인하고 https://console.aws.amazon.com/secretsmanager/ 에서 Secrets Manager 콘솔을 열어요.
access-uni-engineering 역할로 전환을 시도해요. 이 작업은 access-Arnav-peg-eng 사용자와 access-uni-engineering 역할의 access-project와 cost-center 태그 값이 일치하지 않으므로 실패해요. AWS Management Console에서 역할 전환에 대한 자세한 내용은 "사용자에서 IAM 역할로 전환(콘솔)"을 참고하세요.
access-peg-engineering 역할로 전환해요.
다음 정보로 새 비밀을 저장해요. 비밀 저장 방법을 알아보려면 _AWS Secrets Manager User Guide_의 "기본 비밀 생성"을 참고하세요.
- 중요 – Secrets Manager는 Secrets Manager와 함께 작동하는 추가 AWS 서비스에 대한 권한이 없다는 경고를 표시해요. 예를 들어 Amazon RDS 데이터베이스의 자격 증명을 만들려면 RDS 인스턴스, RDS 클러스터, Amazon Redshift 클러스터를 설명할 권한이 있어야 해요. 이 튜토리얼에서 이러한 특정 AWS 서비스를 사용하지 않으므로 이러한 경고는 무시해도 돼요.
- Select secret type 섹션에서 Other type of secrets를 선택해요. 두 텍스트 상자에 test-access-key와 test-access-secret을 입력해요.
- Secret name 필드에 test-access-peg-eng을 입력해요.
- 다음 표에서 다양한 태그 조합을 추가하고 예상 동작을 확인해요.
- Store를 선택해 비밀 생성을 시도해요. 저장이 실패하면 이전 Secrets Manager 콘솔 페이지로 돌아가 다음 표의 다음 태그 세트를 사용해요. 마지막 태그 세트는 허용되며 비밀이 성공적으로 생성돼요.

test-access-peg-eng 역할에 대한 ABAC 태그 조합은 다음 표와 같아요.

access-project 태그 값	access-team 태그 값	cost-center 태그 값	추가 태그	예상 동작
(없음)	(없음)	(없음)	(없음)	access-project 태그 값이 역할의 peg 값과 일치하지 않으므로 거부됨
uni	eng	987654	(없음)	access-project 태그 값이 역할의 peg 값과 일치하지 않으므로 거부됨
peg	qas	987654	(없음)	access-team 태그 값이 역할의 eng 값과 일치하지 않으므로 거부됨
peg	eng	123456	(없음)	cost-center 태그 값이 역할의 987654 값과 일치하지 않으므로 거부됨
peg	eng	987654	Owner = Jane	세 필수 태그가 모두 존재하고 그 값이 역할의 값과 일치하지만 추가 태그 owner가 정책에서 허용되지 않으므로 거부됨
peg	eng	987654	Name = Jane	세 필수 태그가 모두 존재하고 그 값이 역할의 값과 일치하므로 허용됨. 선택적 Name 태그도 포함할 수 있음

로그아웃한 뒤 다음 각 역할과 태그 값에 대해 이 절차의 처음 세 단계를 반복해요. 이 절차의 네 번째 단계에서는 원하는 누락 태그, 선택적 태그, 허용되지 않는 태그, 잘못된 태그 값 조합을 테스트해요. 그런 다음 필수 태그를 사용해 다음 태그와 이름으로 비밀을 만들어요.

사용자 이름	역할 이름	비밀 이름	비밀 태그
access-Mary-peg-qas	access-peg-quality-assurance	test-access-peg-qas	access-project = peg access-team = qas cost-center = 987654
access-Saanvi-uni-eng	access-uni-engineering	test-access-uni-eng	access-project = uni access-team = eng cost-center = 123456
access-Carlos-uni-qas	access-uni-quality-assurance	test-access-uni-qas	access-project = uni access-team = qas cost-center = 123456

5단계: 비밀 보기 테스트 (Step 5: Test viewing secrets)

각 역할에 연결한 정책은 직원이 프로젝트와 관계없이 팀 이름으로 태그된 모든 비밀을 볼 수 있게 해요. Secrets Manager에서 역할을 테스트해 권한이 예상대로 작동하는지 확인해요.

필수 태그가 있거나 없는 비밀 보기를 테스트하려면

다음 IAM 사용자 중 하나로 로그인해요: access-Arnav-peg-eng, access-Mary-peg-qas, access-Saanvi-uni-eng, access-Carlos-uni-qas
일치하는 역할로 전환해요: access-peg-engineering, access-peg-quality-assurance, access-uni-engineering, access-uni-quality-assurance. AWS Management Console에서 역할 전환에 대한 자세한 내용은 "사용자에서 IAM 역할로 전환(콘솔)"을 참고하세요.
왼쪽 탐색 창에서 메뉴 아이콘을 선택해 메뉴를 확장한 뒤 Secrets를 선택해요.
현재 역할과 관계없이 표에 네 개의 비밀 모두가 표시되는 것을 볼 수 있어요. 이는 예상된 동작이에요. access-same-project-team 정책이 모든 리소스에 대해 secretsmanager:ListSecrets 작업을 허용하기 때문이에요.
비밀 중 하나의 이름을 선택해요.
비밀의 상세 페이지에서 역할의 태그에 따라 페이지 내용을 볼 수 있는지가 결정돼요. 역할의 이름과 비밀의 이름을 비교해요. 같은 팀 이름을 공유하면 access-team 태그가 일치해요. 일치하지 않으면 접근이 거부돼요.

다음 표는 각 역할에 대한 ABAC 비밀 보기 동작을 보여줘요.

역할 이름	비밀 이름	예상 동작
access-peg-engineering	test-access-peg-eng	허용됨
	test-access-peg-qas	거부됨
	test-access-uni-eng	허용됨
	test-access-uni-qas	거부됨
access-peg-quality-assurance	test-access-peg-eng	거부됨
	test-access-peg-qas	허용됨
	test-access-uni-eng	거부됨
	test-access-uni-qas	허용됨
access-uni-engineering	test-access-peg-eng	허용됨
	test-access-peg-qas	거부됨
	test-access-uni-eng	허용됨
	test-access-uni-qas	거부됨
access-uni-quality-assurance	test-access-peg-eng	거부됨
	test-access-peg-qas	허용됨
	test-access-uni-eng	거부됨
	test-access-uni-qas	허용됨

페이지 상단의 이동 경로에서 Secrets를 선택해 비밀 목록으로 돌아가요. 서로 다른 역할을 사용해 각 비밀을 볼 수 있는지 테스트하려면 이 절차의 단계를 반복해요.

6단계: 확장성 테스트 (Step 6: Test scalability)

역할 기반 접근 제어(RBAC)보다 ABAC(속성 기반 접근 제어)를 사용하는 중요한 이유는 확장성이에요. 회사가 AWS에 새 프로젝트, 팀, 인력을 추가할 때 ABAC 기반 정책을 업데이트할 필요가 없어요. 예를 들어 Example Company가 Centaur라는 코드명의 새 프로젝트에 자금을 지원한다고 가정해 볼게요. Centaur의 수석 엔지니어로 Saanvi Sarkar가 임명되면서 Unicorn 프로젝트에서 계속 작업해요. Saanvi는 Peg 프로젝트의 작업도 검토할 거예요. 또한 Centaur 프로젝트에서만 작업할 Nikhil Jayashankar를 포함해 새로 고용된 엔지니어도 몇 명 있어요.

새 프로젝트를 AWS에 추가하려면

IAM 관리자 사용자로 로그인하고 https://console.aws.amazon.com/iam/ 에서 IAM 콘솔을 열어요.
왼쪽 탐색 창에서 Roles를 선택하고 access-cen-engineering이라는 IAM 역할을 추가해요. access-same-project-team 권한 정책을 역할에 연결하고 다음 역할 태그를 추가해요.
- access-project = cen
- access-team = eng
- cost-center = 101010
왼쪽 탐색 창에서 Users를 선택해요.
access-Nikhil-cen-eng이라는 새 사용자를 추가하고 access-assume-role이라는 정책을 연결한 뒤 다음 사용자 태그를 추가해요.
- access-project = cen
- access-team = eng
- cost-center = 101010
"4단계: 비밀 생성 테스트"와 "5단계: 비밀 보기 테스트"의 절차를 사용해요. 다른 브라우저 창에서 Nikhil이 Centaur 엔지니어링 비밀만 만들 수 있고 모든 엔지니어링 비밀을 볼 수 있는지 테스트해요.
관리자로 로그인한 기본 브라우저 창에서 access-Saanvi-uni-eng 사용자를 선택해요.
Permissions 탭에서 access-assume-role 권한 정책을 제거해요.
access-assume-specific-roles라는 다음 인라인 정책을 추가해요. 사용자에 인라인 정책을 추가하는 방법에 대한 자세한 내용은 "사용자 또는 역할에 인라인 정책을 포함하려면(콘솔)"을 참고하세요.

ABAC 정책: 특정 역할만 맡기

이 정책은 Saanvi가 Pegasus와 Centaur 프로젝트의 엔지니어링 역할을 맡을 수 있게 해요. IAM이 다중값 태그를 지원하지 않으므로 이 사용자 지정 정책을 만드는 것이 필요해요. Saanvi의 사용자에 access-project = peg와 access-project = cen으로 태그를 지정할 수 없어요. 또한 AWS 인가 모델이 두 값을 모두 일치시킬 수 없어요. 자세한 내용은 "IAM과 AWS STS의 태그 지정 규칙"을 참고하세요. 대신 맡을 수 있는 두 역할을 직접 지정해야 해요.

이 정책을 사용하려면 _기울임꼴 자리 표시자 텍스트_를 계정 정보로 바꿔요.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "TutorialAssumeSpecificRoles",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::111122223333:role/access-peg-engineering",
                "arn:aws:iam::111122223333:role/access-cen-engineering"
            ]
        }
    ]
}

"4단계: 비밀 생성 테스트"와 "5단계: 비밀 보기 테스트"의 절차를 사용해요. 다른 브라우저 창에서 Saanvi가 두 역할을 모두 맡을 수 있는지 확인해요. 역할의 태그에 따라 자신의 프로젝트, 팀, 비용 센터에 대한 비밀만 만들 수 있는지 확인해요. 또한 방금 만든 비밀을 포함해 엔지니어링 팀이 소유한 모든 비밀의 세부 정보를 볼 수 있는지 확인해요.

7단계: 비밀 업데이트 및 삭제 테스트 (Step 7: Test updating and deleting secrets)

역할에 연결된 access-same-project-team 정책은 직원이 프로젝트, 팀, 비용 센터로 태그된 모든 비밀을 업데이트하고 삭제할 수 있게 해요. Secrets Manager에서 역할을 테스트해 권한이 예상대로 작동하는지 확인해요.

필수 태그가 있거나 없는 비밀 업데이트·삭제를 테스트하려면

다음 IAM 사용자 중 하나로 로그인해요: access-Arnav-peg-eng, access-Mary-peg-qas, access-Saanvi-uni-eng, access-Carlos-uni-qas, access-Nikhil-cen-eng
일치하는 역할로 전환해요: access-peg-engineering, access-peg-quality-assurance, access-uni-engineering, access-peg-quality-assurance, access-cen-engineering. AWS Management Console에서 역할 전환에 대한 자세한 내용은 "사용자에서 IAM 역할로 전환(콘솔)"을 참고하세요.
각 역할에 대해 비밀 설명을 업데이트한 다음 다음 비밀을 삭제해 보세요. 자세한 내용은 _AWS Secrets Manager User Guide_의 "비밀 수정"과 "비밀 삭제 및 복원"을 참고하세요.

다음 표는 각 역할에 대한 ABAC 비밀 업데이트·삭제 동작을 보여줘요.

역할 이름	비밀 이름	예상 동작
access-peg-engineering	test-access-peg-eng	허용됨
	test-access-uni-eng	거부됨
	test-access-uni-qas	거부됨
access-peg-quality-assurance	test-access-peg-qas	허용됨
	test-access-uni-eng	거부됨
access-uni-engineering	test-access-uni-eng	허용됨
	test-access-uni-qas	거부됨
access-peg-quality-assurance	test-access-uni-qas	허용됨

요약 (Summary)

이제 태그를 속성 기반 접근 제어(ABAC)에 사용하는 데 필요한 모든 단계를 성공적으로 완료했어요. 태그 지정 전략을 정의하는 방법을 배우고 그 전략을 프린시펄과 리소스에 적용했어요. Secrets Manager에 대해 그 전략을 적용하는 정책을 만들고 적용했어요. 또한 새 프로젝트와 팀 구성원을 추가할 때 ABAC가 쉽게 확장된다는 것도 배웠어요. 그 결과 테스트 역할로 IAM 콘솔에 로그인해 AWS에서 태그를 ABAC에 사용하는 방법을 경험할 수 있게 됐어요.

참고 – 특정 조건 아래에서만 작업을 허용하는 정책을 추가했어요. 사용자나 역할에 더 넓은 권한이 있는 다른 정책을 적용하면 작업이 태그 지정을 요구하도록 제한되지 않을 수 있어요. 예를 들어 AdministratorAccess AWS 관리형 정책으로 사용자에게 전체 관리 권한을 부여하면 이러한 정책이 그 접근을 제한하지 않아요. 여러 정책이 관련될 때 권한이 어떻게 결정되는지에 대한 자세한 내용은 "AWS 시행 코드 로직이 요청을 평가해 접근을 허용하거나 거부하는 방법"을 참고하세요.

관련 정보는 다음 리소스를 참고하세요.

계정의 태그를 모니터링하는 방법을 알아보려면 서버리스 워크플로와 Amazon CloudWatch Events로 AWS 리소스의 태그 변경 모니터링을 참고하세요.

태그 기반으로 AWS 리소스에 대한 접근 권한 정의하기