기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AWS KMS의 ABAC
속성 기반 액세스 제어(ABAC)는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. AWS KMS는 KMS 키와 연결된 태그 및 별칭을 기반으로 고객 관리 키에 대한 액세스를 제어할 수 있도록 하여 ABAC를 지원합니다. AWS KMS에서 ABAC를 활성화하는 태그 및 별칭 조건 키는 정책을 편집하거나 권한 부여를 관리하지 않고도 보안 주체가 KMS 키를 사용할 수 있도록 권한을 부여하는 강력하고 유연한 방법을 제공합니다. 그러나 보안 주체에 실수로 액세스가 허용되거나 거부되지 않도록 이러한 기능을 주의해서 사용해야 합니다.
ABAC를 사용하는 경우 태그 및 별칭 관리 권한이 이제 액세스 제어 권한이라는 점에 유의하십시오. 태그 또는 별칭에 따라 달라지는 정책을 배포하기 전에 모든 KMS 키의 기존 태그와 별칭을 알고 있어야 합니다. 별칭을 추가, 삭제 및 업데이트하거나 키에 태그를 지정하고 태그를 해제할 때 합리적인 예방 조치를 취해야 합니다. 태그와 별칭을 관리할 수 있는 권한을 필요한 보안 주체에게만 부여하고 관리할 수 있는 태그와 별칭을 제한합니다.
참고
AWS KMS에 ABAC를 사용하는 경우 보안 주체에게 태그 및 별칭을 관리할 수 있는 권한을 부여하는 데 주의해야 합니다. 태그 또는 별칭을 변경하면 KMS 키에 대한 사용 권한을 허용하거나 거부할 수 있습니다. 키 정책을 변경하거나 권한 부여를 생성할 권한이 없는 키 관리자는 태그 또는 별칭을 관리할 권한이 있는 경우 KMS 키에 대한 액세스를 제어할 수 있습니다.
태그 및 별칭 변경으로 KMS 키 인증에 영향을 미치는 데 최대 5분이 소요될 수 있습니다. 최근 변경 사항은 권한 부여에 영향을 미치기 전에 API 작업에서 볼 수 있습니다.
별칭을 기반으로 KMS 키에 대한 액세스를 제어하려면 조건 키를 사용해야 합니다. 별칭을 사용하여 정책문의 Resource 요소에서 KMS 키를 나타낼 수 없습니다. 별칭이 Resource 요소에 나타나면 정책문이 연결된 KMS 키가 아니라 별칭에 적용됩니다.
자세히 알아보기
-
예를 포함하여 ABAC에 대한 AWS KMS 지원에 대한 자세한 내용은 별칭을 사용하여 KMS 키에 대한 액세스 제어 및 태그를 사용하여 KMS 키에 대한 액세스 제어 단원을 참조하십시오.
-
태그를 사용하여 AWS 리소스에 대한 액세스를 제어하는 방법에 대한 일반적인 정보는 AWS의 ABAC란 무엇입니까?와 IAM 사용 설명서의 리소스 태그를 사용하여 AWS 리소스에 대한 액세스 제어를 참조하십시오.
AWS KMS에 대한 ABAC 조건 키
태그 및 별칭을 기반으로 KMS 키에 대한 액세스 권한을 부여하려면 키 정책 또는 IAM 정책에서 다음 조건 키를 사용합니다.
| ABAC 조건 키 | 설명 | 정책 유형 | AWS KMS 작업 |
|---|---|---|---|
| 법칙: ResourceTag | KMS 키의 태그(키 및 값)가 정책의 태그 (키 및 값) 또는 태그 패턴과 일치합니다. | IAM 정책만 | KMS 키 리소스 작업 2 |
| aws:RequestTag/태그 키 | 요청의 태그(키 및 값)가 정책의 태그(키 및 값) 또는 태그 패턴과 일치합니다. | 주요 정책 및 IAM 정책1 | TagResource, UntagResource |
| AWS: TagKeys | 요청의 태그 키가 정책의 태그 키와 일치합니다. | 주요 정책 및 IAM 정책1 | TagResource, UntagResource |
| kms: ResourceAliases | KMS 키와 연결된 별칭은 정책의 별칭 또는 별칭 패턴과 일치합니다. | IAM 정책만 | KMS 키 리소스 작업 2 |
| kms: RequestAlias | 요청의 KMS 키를 나타내는 별칭은 정책의 별칭 또는 별칭 패턴과 일치합니다. | 주요 정책 및 IAM 정책1 | 암호화 작업, DescribeKeyGetPublicKey |
1키 정책에서 사용할 수 있는 모든 조건 키는 IAM 정책에서도 사용할 수 있지만 키 정책에서 허용하는 경우에만 가능합니다.
2KMS 키 리소스 작업은 특정 KMS 키에 대해 권한이 부여된 작업입니다. KMS 키 리소스 작업을 식별하려면 AWS KMS 권한 테이블에서 작업의 Resources 열에서 KMS 키 값을 찾습니다.
예를 들어 이러한 조건 키를 사용하여 다음 정책을 생성할 수 있습니다.
-
특정 별칭 또는 별칭 패턴이 있는 KMS 키를 사용할 수 있는 권한을 허용하는
kms:ResourceAliases가 포함된 IAM 정책. 이는 태그에 의존하는 정책과 약간 다릅니다. 정책에서 별칭 패턴을 사용할 수 있지만 각 별칭은 AWS 계정 및 리전에서 고유해야 합니다. 이렇게 하면 정책 설명에 KMS 키의 키 ARN을 나열하지 않고 선택한 KMS 키 집합에 정책을 적용할 수 있습니다. 집합에서 KMS 키를 추가하거나 제거하려면 KMS 키의 별칭을 변경합니다. -
보안 주체가
Encrypt작업에서 KMS 키를 사용하도록 허용하지만Encrypt요청이 해당 별칭을 사용하여 KMS 키를 식별하는 경우에만 허용하는kms:RequestAlias가 포함된 키 정책. -
특정 태그 키 및 태그 값과 함께 KMS 키를 사용할 수 있는 권한을 거부하는
aws:ResourceTag/tag-key가 포함된 IAM 정책. 이렇게 하면 정책문에 KMS 키의 키 ARN을 나열하지 않고 선택한 KMS 키 집합에 정책을 적용할 수 있습니다. KMS 키를 집합에서 추가하거나 제거하려면 KMS 키에 태그를 지정하거나 태그를 해제합니다. -
보안 주체가
"Purpose"="Test"KMS 키 태그만 삭제할 수 있도록 허용하는aws:RequestTag/tag-key가 포함된 IAM 정책. -
Restricted태그 키로 KMS 키에 태그를 지정하거나 태그를 해제할 수 있는 권한을 거부하는aws:TagKeys가 포함된 IAM 정책.
ABAC는 액세스 관리를 유연하고 확장 가능하게 합니다. 예를 들어 aws:ResourceTag/tag-key 조건 키를 사용하여 KMS 키에 Purpose=Test 태그가 있는 경우에만 보안 주체가 지정된 작업에 KMS 키를 사용하도록 허용하는 IAM 정책을 생성할 수 있습니다. 이 정책은 AWS 계정의 모든 리전에 있는 모든 KMS 키에 적용됩니다.
사용자 또는 역할에 연결된 경우 다음 IAM 정책은 보안 주체가 지정된 작업에 대해 Purpose=Test 태그가 있는 모든 기존 KMS 키를 사용할 수 있도록 허용합니다. 새 KMS 키 또는 기존 KMS 키에 대한 액세스를 제공하기 위해 정책을 변경할 필요가 없습니다. Purpose=Test 태그를 KMS 키에 지정하기만 하면 됩니다. 마찬가지로 Purpose=Test 태그가 있는 KMS 키에서 이 액세스 권한을 제거하려면 태그를 편집하거나 삭제합니다.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Purpose": "Test" } } } ] }
그러나 이 기능을 사용하는 경우 태그와 별칭을 관리할 때는 주의해야 합니다. 태그 또는 별칭을 추가, 변경 또는 삭제하면 실수로 KMS 키에 대한 액세스를 허용하거나 거부할 수 있습니다. 키 정책을 변경하거나 권한 부여를 생성할 권한이 없는 키 관리자는 태그 및 별칭을 관리할 권한이 있는 경우 KMS 키에 대한 액세스를 제어할 수 있습니다. 이 위험을 완화하기 위해 별칭과 태그 관리 권한을 제한하는 것이 좋습니다. 예를 들어, 선택된 보안 주체만 Purpose=Test 태그를 관리하도록 허용할 수 있습니다. 자세한 내용은 별칭을 사용하여 KMS 키에 대한 액세스 제어 및 태그를 사용하여 KMS 키에 대한 액세스 제어 섹션을 참조하세요.
태그 또는 별칭?
AWS KMS는 태그 및 별칭이 있는 ABAC를 지원합니다. 두 옵션 모두 유연하고 확장 가능한 액세스 제어 전략을 제공하지만 서로 약간 다릅니다.
특정 AWS 사용 패턴에 따라 태그를 사용하거나 별칭을 사용하기로 결정할 수 있습니다. 예를 들어 대부분의 관리자에게 이미 태그 사용 권한을 부여한 경우 별칭을 기반으로 권한 부여 전략을 제어하는 것이 더 쉬울 수 있습니다. 또는 KMS 키당 별칭 할당량에 근접한 경우 태그 기반 권한 부여 전략을 선호할 수 있습니다.
일반적으로 다음과 같은 이점이 있습니다.
태그 기반 액세스 제어의 이점
-
다른 유형의 AWS 리소스에 대해 동일한 권한 부여 메커니즘있습니다.
동일한 태그 또는 태그 키를 사용하여 Amazon Relational Database Service(RDS) 클러스터, Amazon Elastic Block Store(Amazon EBS) 볼륨 및 KMS 키와 같은 여러 리소스 유형에 대한 액세스를 제어할 수 있습니다. 이 기능을 사용하면 기존의 역할 기반 액세스 제어보다 유연한 여러 가지 권한 부여 모델을 사용할 수 있습니다.
-
KMS 키 그룹에 대한 액세스 권한을 부여합니다.
태그를 사용하여 동일한 AWS 계정 및 리전의 KMS 키 그룹에 대한 액세스를 관리할 수 있습니다. 선택한 KMS 키에 동일한 태그 또는 태그 키를 할당합니다. 그런 다음 태그 또는 태그 키를 기반으로 하는 간단한 easy-to-maintain 정책 설명을 생성합니다. 인증 그룹에서 KMS 키를 추가하거나 제거하려면 태그를 추가하거나 제거하십시오. 정책을 편집할 필요가 없습니다.
별칭 기반 액세스 제어의 이점
-
별칭을 기반으로 암호화 작업에 대한 액세스 권한을 부여합니다.
aws:RequestTag/tag-key를 비롯한 속성에 대한 대부분의 요청 기반 정책 조건은 속성을 추가, 편집 또는 삭제하는 작업에만 영향을 줍니다. 하지만 kms: RequestAlias 조건 키는 요청에서 KMS 키를 식별하는 데 사용된 별칭을 기반으로 암호화 작업에 대한 액세스를 제어합니다. 예를 들어 보안 주체에게
Encrypt작업에서 KMS 키를 사용할 수 있는 권한을 부여할 수 있지만KeyId매개 변수의 값이alias/restricted-key-1인 경우에만 가능합니다. 이 조건을 충족하려면 다음 사항이 모두 필요합니다.-
KMS 키는 해당 별칭과 연결되어 있어야 합니다.
-
요청은 별칭을 사용하여 KMS 키를 식별해야 합니다.
-
보안 주체는
kms:RequestAlias조건에 따라 KMS 키를 사용할 수 있는 권한이 있어야 합니다.
이는 애플리케이션에서 일반적으로 별칭 이름이나 별칭 ARN을 사용하여 KMS 키를 참조하는 경우에 특히 유용합니다.
-
-
매우 제한된 권한을 제공합니다.
별칭은 AWS 계정 및 리전에 고유해야 합니다. 따라서 보안 주체에 별칭을 기반으로 KMS 키에 대한 액세스 권한을 부여하는 것이 태그를 기반으로 액세스 권한을 부여하는 것보다 훨씬 더 제한적일 수 있습니다. 별칭과 달리 동일한 계정 및 리전에 있는 여러 KMS 키에 태그를 할당할 수 있습니다. 원하는 경우
alias/test*와 같은 별칭 패턴을 사용하여 보안 주체에게 동일한 계정 및 리전의 KMS 키 그룹에 대한 액세스 권한을 부여할 수 있습니다. 그러나 특정 별칭에 대한 액세스를 허용하거나 거부하면 KMS 키에 대한 매우 엄격한 제어가 가능합니다.
AWS KMS의 ABAC 문제 해결
태그 및 별칭을 기반으로 KMS 키에 대한 액세스를 제어하는 것은 편리하고 강력합니다. 그러나 몇 가지 예측 가능한 오류가 발생하기 쉽습니다.
태그 변경으로 인해 액세스 변경
태그가 삭제되거나 해당 값이 변경되면 해당 태그만 기반으로 KMS 키에 액세스할 수 있는 보안 주체는 KMS 키에 대한 액세스가 거부됩니다. 거부 정책문에 포함된 태그가 KMS 키에 추가되는 경우에도 이 문제가 발생할 수 있습니다. KMS 키에 정책 관련 태그를 추가하면 KMS 키에 대한 액세스가 거부되어야 하는 보안 주체에 액세스가 허용될 수 있습니다.
예를 들어 보안 주체가 다음 예제 IAM 정책문에서 제공하는 권한과 같이 Project=Alpha 태그를 기반으로 KMS 키에 액세스할 수 있다고 가정합니다.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] }
해당 KMS 키에서 태그가 삭제되거나 태그 값이 변경되면 보안 주체는 지정된 작업에 KMS 키를 사용할 수 있는 권한을 더 이상 갖지 않습니다. 이는 보안 주체가 고객 관리 키를 사용하는 AWS 서비스에서 데이터를 읽거나 쓰려고 할 때 분명해질 수 있습니다. 태그 변경을 추적하려면 로그 또는 항목을 검토하십시오 CloudTrail. TagResourceUntagResource
정책을 업데이트하지 않고 액세스를 복원하려면 KMS 키의 태그를 변경합니다. 이 조치는 AWS KMS 전반에 걸쳐 효력을 발휘하는 짧은 기간 외에는 최소한의 영향을 미칩니다. 이와 같은 오류를 방지하려면 태그 지정 및 태그 해제 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 태그로 태그 지정 권한을 제한하십시오. 태그를 변경하기 전에 정책을 검색하여 태그에 따라 달라지는 액세스를 감지하고 태그가 있는 모든 리전에서 KMS 키를 가져옵니다. 특정 태그가 변경되면 Amazon CloudWatch 경보를 생성하는 것을 고려할 수 있습니다.
별칭 변경으로 인한 액세스 변경
별칭이 삭제되거나 다른 KMS 키와 연결된 경우 해당 별칭만 기반으로 KMS 키에 액세스할 수 있는 보안 주체는 KMS 키에 대한 액세스가 거부됩니다. 이는 KMS 키와 연결된 별칭이 거부 정책문에 포함된 경우에도 발생할 수 있습니다. KMS 키에 정책 관련 별칭을 추가해도 KMS 키에 대한 액세스가 거부되어야 하는 보안 주체에 액세스가 허용될 수 있습니다.
예를 들어 다음 IAM 정책 설명에서는 kms: ResourceAliases condition 키를 사용하여 지정된 별칭으로 계정의 여러 지역에 있는 KMS 키에 액세스할 수 있도록 허용합니다.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:List*", "kms:Describe*", "kms:Decrypt" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "ForAnyValue:StringEquals": { "kms:ResourceAliases": [ "alias/ProjectAlpha", "alias/ProjectAlpha_Test", "alias/ProjectAlpha_Dev" ] } } } ] }
별칭 변경을 추적하려면, 및 항목에 대한 CloudTrail CreateAlias로그를 검토하십시오. UpdateAliasDeleteAlias
정책을 업데이트하지 않고 액세스를 복원하려면 KMS 키와 연결된 별칭을 변경합니다. 각 별칭은 계정 및 리전에서 하나의 KMS 키에만 연결될 수 있으므로 별칭 관리는 태그를 관리하는 것보다 조금 더 어렵습니다. 하나의 KMS 키에서 일부 보안 주체에 액세스 권한을 복원하면 다른 KMS 키에 대한 동일 또는 다른 보안 주체의 액세스가 거부될 수 있습니다.
이 오류를 방지하려면 별칭 관리 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 별칭으로 별칭 관리 권한을 제한합니다. 별칭을 업데이트하거나 삭제하기 전에 정책을 검색하여 별칭에 종속된 액세스를 검색하고 별칭과 연결된 모든 리전에서 KMS 키를 찾습니다.
별칭 할당량으로 인한 액세스 거부
kms: ResourceAliases 조건에 따라 KMS 키를 사용할 수 있는 권한을 부여받은 사용자는 KMS 키가 해당 계정 및 지역의 KMS 키 할당량당 기본 별칭을 초과하는 경우 AccessDenied 예외가 발생합니다.
액세스를 복원하려면 할당량을 준수하도록 KMS 키와 연결된 별칭을 삭제합니다. 또는 대체 메커니즘을 사용하여 사용자에게 KMS 키에 대한 액세스 권한을 부여합니다.
지연된 권한 부여 변경 사항
태그 및 별칭을 변경하면 KMS 키 인증에 영향을 미치는 데 최대 5분이 소요될 수 있습니다. 따라서 권한 부여에 영향을 미치기 전에 API 작업의 응답에 태그 또는 별칭 변경이 반영될 수 있습니다. 이 지연은 대부분의 AWS KMS 작업에 영향을 미치는 짧은 최종 일관성 지연보다 길 수 있습니다.
예를 들어 특정 보안 주체가 "Purpose"="Test" 태그가 있는 모든 KMS 키를 사용하도록 허용하는 IAM 정책이 있을 수 있습니다. 그런 다음 KMS 키에 "Purpose"="Test" 태그를 추가합니다. TagResource작업이 완료되고 KMS 키에 태그가 할당되었다는 ListResourceTags응답이 확인되더라도 보안 주체는 최대 5분 동안 KMS 키에 액세스하지 못할 수 있습니다.
오류를 방지하려면 이 예상 지연을 코드에 빌드하십시오.
별칭 업데이트로 인해 실패한 요청
별칭을 업데이트할 때 기존 별칭을 다른 KMS 키와 연결합니다.
별칭이 이제 암호문을 암호화하지 않은 KMS 키와 연결되므로 별칭 이름 또는 별칭 ARN을 지정하는 ReEncrypt요청 복호화가 실패할 수 있습니다. 이 상황은 일반적으로 IncorrectKeyException 또는 NotFoundException을 반환합니다. 또는 요청에 KeyId 또는 DestinationKeyId 파라미터가 없는 경우 호출자가 암호문을 암호화한 KMS 키에 더 이상 액세스할 수 없기 때문에 AccessDenied 예외와 함께 작업이 실패할 수 있습니다.
, 및 로그 항목의 로그를 보면 변경 사항을 추적할 수 있습니다. CloudTrail CreateAliasUpdateAliasDeleteAlias ListAliases응답의 LastUpdatedDate 필드 값을 사용하여 변경 사항을 감지할 수도 있습니다.
예를 들어, 다음 ListAliases예제 응답은 kms:ResourceAliases 조건의 ProjectAlpha_Test 별칭이 업데이트되었음을 보여줍니다. 따라서 별칭을 기반으로 액세스 권한이 있는 보안 주체는 이전에 연결된 KMS 키에 대한 액세스 권한을 잃게 됩니다. 대신 새로 연결된 KMS 키에 액세스할 수 있습니다.
$aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]'{ "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] }
이 변경에 대한 해결책은 간단하지 않습니다. 별칭을 다시 업데이트하여 원래 KMS 키와 연결할 수 있습니다. 그러나 작업을 수행하기 전에 해당 변경 사항이 현재 연결된 KMS 키에 미치는 영향을 고려해야 합니다. 보안 주체가 암호화 작업에 후자의 KMS 키를 사용한 경우 보안 주체에 계속 액세스해야 할 수 있습니다. 이 경우 보안 주체가 두 KMS 키를 모두 사용할 수 있는 권한을 갖도록 정책을 업데이트할 수 있습니다.
이와 같은 오류는 다음과 같이 방지할 수 있습니다. 별칭을 업데이트하기 전에 별칭에 의존하는 액세스를 감지하는 정책을 검색하십시오. 그런 다음 별칭과 연결된 모든 리전의 KMS 키를 가져옵니다. 별칭 관리 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 별칭으로 별칭 관리 권한을 제한합니다.
