기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
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 로그에서 TagResource 또는 UntagResource 항목을 검토하십시오.
정책을 업데이트하지 않고 액세스를 복원하려면 KMS 키의 태그를 변경합니다. 이 조치는 AWS KMS 전반에 걸쳐 효력을 발휘하는 짧은 기간 외에는 최소한의 영향을 미칩니다. 이와 같은 오류를 방지하려면 태그 지정 및 태그 해제 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 태그로 태그 지정 권한을 제한하십시오. 태그를 변경하기 전에 정책을 검색하여 태그에 따라 달라지는 액세스를 감지하고 태그가 있는 모든 리전에서 KMS 키를 가져옵니다. 특정 태그가 변경되면 Amazon CloudWatch 경보를 생성하는 것을 고려할 수 있습니다.
별칭 변경으로 인한 액세스 변경
별칭이 삭제되거나 다른 KMS 키와 연결된 경우 해당 별칭만 기반으로 KMS 키에 액세스할 수 있는 보안 주체는 KMS 키에 대한 액세스가 거부됩니다. 이는 KMS 키와 연결된 별칭이 거부 정책문에 포함된 경우에도 발생할 수 있습니다. KMS 키에 정책 관련 별칭을 추가해도 KMS 키에 대한 액세스가 거부되어야 하는 보안 주체에 액세스가 허용될 수 있습니다.
예를 들어 다음 IAM 정책 문은 kms:ResourceAliases 조건 키를 사용하여 지정된 별칭을 가진 계정의 다른 리전에 있는 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,UpdateAlias 및 DeleteAlias 항목을 검토하십시오.
정책을 업데이트하지 않고 액세스를 복원하려면 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 작업이 완료되고 ListResourceTags 응답에서 태그가 KMS 키에 할당되었음을 확인하지만 보안 주체는 최대 5분 동안 KMS 키에 액세스하지 못할 수 있습니다.
오류를 방지하려면 이 예상 지연을 코드에 빌드하십시오.
별칭 업데이트로 인해 실패한 요청
별칭을 업데이트할 때 기존 별칭을 다른 KMS 키와 연결합니다.
별칭 이름 또는 별칭 ARN을 지정하는 Decrypt 및 ReEncrypt 요청은 이제 암호문을 암호화하지 않은 KMS 키와 별칭이 연결되기 때문에 실패할 수 있습니다. 이 상황은 일반적으로 IncorrectKeyException 또는 NotFoundException을 반환합니다. 또는 요청에 KeyId 또는 DestinationKeyId 파라미터가 없는 경우 호출자가 암호문을 암호화한 KMS 키에 더 이상 액세스할 수 없기 때문에 AccessDenied 예외와 함께 작업이 실패할 수 있습니다.
CreateAlias, UpdateAlias 및 DeleteAlias로그 항목에 대한 CloudTrail 로그를 확인하여 변경 사항을 추적할 수 있습니다. 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 키를 가져옵니다. 별칭 관리 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 별칭으로 별칭 관리 권한을 제한합니다.
