AWS에서는 RBAC(Role base access control)의 접근 제어와 ABAC(Attribute Base access control)을 제공 합니다.
이중 ABAC는 속성 즉 태그 기반의 접근 제어 기능을 제공 합니다.
이번 포스트에서는 ABAC를 알아 보겠습니다.
테스트를 위해 동일한 태그를 사용하여 역할을 맡을 권한이 있는 IAM 사용자 4명을 생성합니다. 이렇게 하면 팀에 사용자를 더 쉽게 추가할 수 있습니다. 사용자에게 태그를 지정하면 올바른 역할을 맡을 수 있는 액세스 권한이 자동으로 부여됩니다. 사용자가 하나의 프로젝트와 팀에서만 작업하는 경우 역할의 신뢰 정책에 사용자를 추가할 필요가 없습니다.
1. 다음과 같이 access-assume-role이라는 고객 관리형 정책을 생성하고 사용자 id를 account-ID-without-hyphens 부분에 입력 합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::account-ID-without-hyphens: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}"
}
}
}
]
}
2. 다음 IAM 사용자를 생성하고, access-assume-role 권한 정책을 연결합니다. AWS Management Console에 대한 사용자 액세스 제공을 선택하고 다음 태그를 추가해야 합니다.
3. 다음과 같이 access-same-project-team이라는 정책을 생성합니다. 이후 단계에서 이 정책을 역할에 추가합니다.
다음 정책은 보안 주체와 동일한 키-값 페어로 리소스에 태그가 지정된 경우에만 보안 주체가 리소스를 생성, 읽기, 편집 및 삭제할 수 있도록 허용합니다. 보안 주체가 리소스를 생성할 때 보안 주체의 태그와 일치하는 값을 가진 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를 반환
합니다. 여기서는 비밀 리소스 유형에 대해 수행된 작업이 secretsmanager:ResourceTag/tag-key 조건 키를
지원한다는 것을 보여 줍니다. 일부 Secrets Manager 작업에서는 GetRandomPassword 및 ListSecrets를 포함하여
해당 해당 리소스 유형을 지원하지 않습니다. 이러한 작업을 허용하려면 추가 문을 생성해야 합니다.
- 두 번째 조건 블록은 요청에 전달된 모든 태그 키가 지정된 목록에 포함된 경우 true를 반환합니다.
이 작업은 StringEquals 조건 연산자와 함께 ForAllValues를 사용하여 수행됩니다. 키 또는 키 세트의 일부가
전달되지 않으면 조건이 true를 반환합니다. 이 경우 요청에서 태그 전달을 허용하지 않는 Get* 작업을 사용할 수
있습니다. 요청자가 목록에 없는 태그 키를 포함하는 경우 조건은 false를 반환합니다.
요청에 전달되는 모든 태그 키가 이 목록의 멤버와 일치해야 합니다.
- 세 번째 조건 블록은 요청이 태그 전달을 지원하고, 세 개의 태그가 모두 존재하고, 보안 주체 태그 값과 일치하는
경우 true를 반환합니다. 요청이 태그 전달을 지원하지 않는 경우에도 이 블록은 true를 반환합니다.
그 이유는 조건 연산자의 ...IfExists 때문입니다. 지원하는 작업 중에 전달된 태그가 없거나 태그 키 및 값이
일치하지 않으면 블록이 false를 반환합니다.
- AllResourcesSecretsManagerNoTags 문은 첫 번째 문에서 허용되지 않는 GetRandomPassword 및 ListSecrets 작업을 허용합니다.
- ReadSecretsManagerSameTeam 문은 보안 주체가 리소스와 동일한 액세스 팀 태그로 태그가 지정된 경우 읽기 전용 작업을 허용합니다. 이는 프로젝트 또는 비용 센터 태그와 관계없이 허용됩니다.
- DenyUntagSecretsManagerReservedTags 문은 Secrets Manager에서 “access-”로 시작하는 키가 있는 태그를 제거하라는 요청을 거부합니다. 이러한 태그는 리소스에 대한 액세스를 제어하는 데 사용되므로 태그를 제거하면 권한이 제거될 수 있습니다.
- DenyPermissionsManagement 문은 Secrets Manager 리소스 기반 정책을 생성, 편집 또는 삭제할 수 있는 권한을 거부합니다. 이러한 정책을 사용하여 비밀의 권한을 변경할 수 있습니다
Job Function Role-name Role-tag Role-describtion
| Project Pegasus Engineering | access-peg-engineering | access-project = peg access-team = eng cost-center = 987654 |
Allows engineers to read all engineering resources and create and manage Pegasus engineering resources. |
| Project Pegasus Quality Assurance | access-peg-quality-assurance | access-project = peg access-team = qas cost-center = 987654 |
Allows the QA team to read all QA resources and create and manage all Pegasus QA resources. |
| Project Unicorn Engineering | access-uni-engineering | access-project = uni access-team = eng cost-center = 123456 |
Allows engineers to read all engineering resources and create and manage Unicorn engineering resources. |
| Project Unicorn Quality Assurance | access-uni-quality-assurance | access-project = uni access-team = qas cost-center = 123456 |
Allows the QA team to read all QA resources and create and manage all |
4. secret 생성 테스트 시험
역할에 연결된 권한 정책을 통해 직원이 비밀을 생성할 수 있습니다. 이 작업은 비밀에 프로젝트, 팀 및 비용 센터 태그가 지정된 경우에만 허용됩니다. Secrets Manager에서 사용자로 로그인하고, 올바른 역할을 맡고, 활동을 테스트하여 권한이 예상대로 작동하는지 확인합니다.
- 비밀 유형 선택 섹션에서 다른 유형의 비밀을 선택합니다. 두 텍스트 상자에 test-access-key 및
test-access-secret를 입력합니다.
- 비밀 이름 필드에 test-access-peg-eng를 입력합니다.
- 다음 표에서 다양한 태그 조합을 추가하고 예상되는 동작을 확인합니다.
- Store(저장)를 선택하여 비밀을 생성합니다. 스토리지에 장애가 발생하면 이전 Secrets Manager 콘솔 페이지로
돌아가서 아래 표에 있는 다음 태그 세트를 사용합니다. 마지막 태그 세트가 허용되고 비밀이 성공적으로 생성됩니다.
6) 로그아웃하고 다음 역할 및 태그 값 각각에 대해 이 절차의 처음 세 단계를 반복합니다. 이 절차의 네 번째 단계에서는 선택한 누락된 태그, 선택적 태그, 허용되지 않는 태그 및 잘못된 태그 값 세트를 테스트합니다. 그런 다음 필수 태그를 사용하여 다음 태그와 이름으로 비밀을 생성합니다.
각 역할에 연결된 정책을 통해 직원은 프로젝트와 관계없이 팀 이름으로 태그가 지정된 모든 비밀을 볼 수 있습니다. Secrets Manager에서 역할을 테스트하여 권한이 예상대로 작동하는지 확인합니다.
- access-Arnav-peg-eng
- access-Mary-peg-qas
- access-Saanvi-uni-eng
- access-Carlos-uni-qas
2)일치하는 역할로 전환합니다.AWS Management Console에서의 역할 전환에 대한 자세한 내용은 역할로 전환(콘솔) 단원을 참조하십시오.
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-uni-quality-assurance
3)왼쪽의 탐색 창에서 메뉴 아이콘을 선택하여 메뉴를 확장한 다음 비밀을 선택합니다.
4)현재 역할과 관계없이 표에 네 가지 비밀이 모두 표시됩니다. 이는 access-same-project-team이라는 정책이 모든 리소스에 대해 secretsmanager:ListSecrets 작업을 허용하기 때문입니다.
5)비밀 중 하나의 이름을 선택합니다.
6)비밀에 대한 세부 정보 페이지에서 역할의 태그에 따라 페이지 콘텐츠를 볼 수 있는지 여부가 결정됩니다. 역할의 이름을 비밀의 이름과 비교합니다. 동일한 팀 이름을 공유하는 경우 access-team 태그가 일치합니다. 일치하지 않으면 액세스가 거부됩니다.
7) 페이지 상단의 이동 경로에서 비밀을 선택하여 비밀 목록으로 돌아갑니다. 다른 역할을 사용하여 이 절차의 단계를 반복하여 각 암호를 볼 수 있는지 여부를 테스트합니다.
6. 테스트 확장하기
RBAC(역할 기반 액세스 제어)를 통해 ABAC(속성 기반 액세스 제어)를 사용하는 중요한 이유는 확장성입니다. 회사에서 새 프로젝트, 팀 또는 인력을 AWS에 추가할 때 ABAC 기반 정책을 업데이트할 필요가 없습니다. 예를 들어, Example Company가 코드명이 Centaur인 새로운 프로젝트에 자금을 조달하고 있다고 가정합니다. Saanvi Sarkar라는 엔지니어는 Unicorn 프로젝트에서 계속 작업하면서 Centaur의 수석 엔지니어도 겸할 예정입니다. Saanvi는 Peg 프로젝트의 작업도 검토할 것입니다. 또한 Nikhil Jayashankar를 포함하여 Centaur 프로젝트에서만 작업하기 위해 몇 명의 엔지니어가 새로 고용되었습니다.
1)IAM 관리자로 로그인하여 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
2)왼쪽 탐색 창에서 역할(Roles)을 선택한 후 access-cen-engineering이라는 IAM 역할을 추가합니다. 역할에 access-same-project-team 권한 정책을 연결하고 다음 역할 태그 추가:
- access-project = cen
- access-team = eng
- cost-center = 101010
3)왼쪽에 있는 탐색 창에서 Users(사용자)를 선택합니다.
4) access-Nikhil-cen-eng라는 새 사용자를 추가하고, access-assume-role이라는 정책을 연결하고, 다음 사용자 태그를 추가합니다.
- access-project = cen
- access-team = eng
- cost-center = 101010
5)4단계: 비밀 생성 테스트 및 5단계: 비밀 보기 테스트의 절차를 사용합니다. 다른 브라우저 창에서 Nikhil이 Centaur 엔지니어링 비밀만 만들 수 있는지와 모든 엔지니어링 비밀을 볼 수 있는지를 테스트합니다.
6)관리자로 로그인한 기본 브라우저 창에서 사용자 access-Saanvi-uni-eng를 선택합니다.
7)권한 탭에서 access-assume-role 권한 정책을 제거합니다.
8)access-assume-specific-roles라는 다음 인라인 정책을 추가합니다. 인라인 정책을 사용자에게 추가하는 방법에 대한 자세한 내용은 사용자 또는 역할의 인라인 정책을 포함하려면(콘솔) 단원을 참조하십시오.ABAC 정책: 특정 역할만 수임이 정책을 통해 Saanvi는 Pegasus 또는 Centaur 프로젝트의 엔지니어링 역할을 맡을 수 있습니다. IAM에서는 다중 값 태그를 지원하지 않으므로 이 사용자 지정 정책을 생성해야 합니다. Saanvi의 사용자에게 access-project = peg 및 access-project = cen 태그를 지정할 수 없습니다. 또한 AWS 권한 부여 모델은 두 값과 모두 일치할 수 없습니다. 자세한 내용은 IAM 및 AWS STS의 태그 지정 규칙 섹션을 참조하세요. 대신 Saanvi가 맡을 수 있는 두 역할을 수동으로 지정해야 합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "TutorialAssumeSpecificRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
"arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
]
}
]
}9)이 정책을 사용하려면 기울임꼴 자리 표시자 텍스트를 계정 정보로 바꿉니다.
10)4단계: 비밀 생성 테스트 및 5단계: 비밀 보기 테스트의 절차를 사용합니다. 다른 브라우저 창에서 Saanvi가 두 역할을 모두 맡을 수 있는지 확인합니다. 역할의 태그에 따라 프로젝트, 팀 및 비용 센터에 대해서만 비밀을 생성할 수 있는지 확인합니다. 또한 Saanvi가 방금 생성한 비밀을 포함하여 엔지니어링 팀이 소유한 비밀에 대한 세부 정보를 볼 수 있는지 확인합니다.
역할에 연결된 access-same-project-team 정책을 통해 직원은 프로젝트, 팀 및 비용 센터로 태그가 지정된 모든 비밀을 업데이트하고 삭제할 수 있습니다. Secrets Manager에서 역할을 테스트하여 권한이 예상대로 작동하는지 확인합니다.
1)다음 IAM 사용자 중 한 명으로 로그인합니다.
- access-Arnav-peg-eng
- access-Mary-peg-qas
- access-Saanvi-uni-eng
- access-Carlos-uni-qas
- access-Nikhil-cen-eng
2)일치하는 역할로 전환합니다.
- access-peg-engineering
- access-peg-quality-assurance
- access-uni-engineering
- access-peg-quality-assurance
- access-cen-engineering
3)각 역할에 대해 비밀 설명을 업데이트하고 다음 비밀을 삭제해봅니다.
| 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 | 허용 |
이제 속성 기반 액세스 제어(ABAC)에 태그를 사용하는 데 필요한 모든 단계를 마쳤습니다.