기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 에 대한 ABAC 문제 해결 AWS KMS
태그 및 별칭을 기반으로 KMS 키에 대한 액세스를 제어하는 것은 편리하고 강력합니다. 그러나 몇 가지 예측 가능한 오류가 발생하기 쉽습니다.
## 태그 변경으로 인해 액세스 변경
태그가 삭제되거나 해당 값이 변경되면 해당 태그만 기반으로 KMS 키에 액세스할 수 있는 보안 주체는 KMS 키에 대한 액세스가 거부됩니다. 거부 정책문에 포함된 태그가 KMS 키에 추가되는 경우에도 이 문제가 발생할 수 있습니다. KMS 키에 정책 관련 태그를 추가하면 KMS 키에 대한 액세스가 거부되어야 하는 보안 주체에 액세스가 허용될 수 있습니다.
예를 들어 보안 주체가 다음 예제 IAM 정책문에서 제공하는 권한과 같이 `Project=Alpha` 태그를 기반으로 KMS 키에 액세스할 수 있다고 가정합니다.
------
#### [ JSON ]
****
```
{
"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](ct-tagresource.md) 또는 [UntagResource 항목을](ct-untagresource.md) 검토합니다.
정책을 업데이트하지 않고 액세스를 복원하려면 KMS 키의 태그를 변경합니다. 이 조치는 AWS KMS전반에 걸쳐 효력을 발휘하는 짧은 기간 외에는 최소한의 영향을 미칩니다. 이와 같은 오류를 방지하려면 태그 지정 및 태그 해제 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 태그로 [태그 지정 권한을 제한](tag-permissions.md#tag-permissions-conditions)하십시오. 태그를 변경하기 전에 정책을 검색하여 태그에 따라 달라지는 액세스를 감지하고 태그가 있는 모든 리전에서 KMS 키를 가져옵니다. 특정 태그가 변경되면 Amazon CloudWatch 경보를 생성하는 것을 고려할 수 있습니다.
## 별칭 변경으로 인한 액세스 변경
별칭이 삭제되거나 다른 KMS 키와 연결된 경우 해당 별칭만 기반으로 KMS 키에 액세스할 수 있는 보안 주체는 KMS 키에 대한 액세스가 거부됩니다. 이는 KMS 키와 연결된 별칭이 거부 정책문에 포함된 경우에도 발생할 수 있습니다. KMS 키에 정책 관련 별칭을 추가해도 KMS 키에 대한 액세스가 거부되어야 하는 보안 주체에 액세스가 허용될 수 있습니다.
예를 들어 다음 IAM 정책 문은 [kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 조건 키를 사용하여 지정된 별칭을 가진 계정의 다른 리전에 있는 KMS 키에 대한 액세스를 허용합니다.
------
#### [ JSON ]
****
```
{
"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](ct-createalias.md),[UpdateAlias](ct-updatealias.md) 및 [DeleteAlias](ct-deletealias.md) 항목을 검토하십시오.
정책을 업데이트하지 않고 액세스를 복원하려면 KMS 키와 연결된 별칭을 변경합니다. 각 별칭은 계정 및 리전에서 하나의 KMS 키에만 연결될 수 있으므로 별칭 관리는 태그를 관리하는 것보다 조금 더 어렵습니다. 하나의 KMS 키에서 일부 보안 주체에 액세스 권한을 복원하면 다른 KMS 키에 대한 동일 또는 다른 보안 주체의 액세스가 거부될 수 있습니다.
이 오류를 방지하려면 별칭 관리 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 별칭으로 [별칭 관리 권한을 제한](alias-access.md#alias-access-limiting)합니다. 별칭을 업데이트하거나 삭제하기 전에 정책을 검색하여 별칭에 종속된 액세스를 검색하고 별칭과 연결된 모든 리전에서 KMS 키를 찾습니다.
## 별칭 할당량으로 인한 액세스 거부
[kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 조건에 따라 KMS 키를 사용하도록 권한이 부여된 사용자는 KMS 키가 해당 계정 및 리전에 대한 [KMS 키당 별칭](resource-limits.md#aliases-per-key)의 기본 할당량을 초과하는 경우 `AccessDenied` 예외를 수신합니다.
액세스를 복원하려면 할당량을 준수하도록 KMS 키와 연결된 별칭을 삭제합니다. 또는 대체 메커니즘을 사용하여 사용자에게 KMS 키에 대한 액세스 권한을 부여합니다.
## 지연된 권한 부여 변경 사항
태그 및 별칭을 변경하면 KMS 키 인증에 영향을 미치는 데 최대 5분이 소요될 수 있습니다. 따라서 권한 부여에 영향을 미치기 전에 API 작업의 응답에 태그 또는 별칭 변경이 반영될 수 있습니다. 이 지연은 대부분의 AWS KMS 작업에 영향을 미치는 짧은 최종 일관성 지연보다 길 수 있습니다.
예를 들어 특정 보안 주체가 `"Purpose"="Test"` 태그가 있는 모든 KMS 키를 사용하도록 허용하는 IAM 정책이 있을 수 있습니다. 그런 다음 KMS 키에 `"Purpose"="Test"` 태그를 추가합니다. [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html) 작업이 완료되고 [ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html) 응답에서 태그가 KMS 키에 할당되었음을 확인하지만 보안 주체는 최대 5분 동안 KMS 키에 액세스하지 못할 수 있습니다.
오류를 방지하려면 이 예상 지연을 코드에 빌드하십시오.
## 별칭 업데이트로 인해 실패한 요청
별칭을 업데이트할 때 기존 별칭을 다른 KMS 키와 연결합니다.
[별칭 이름](concepts.md#key-id-alias-name) 또는 [별칭 ARN](concepts.md#key-id-alias-ARN)을 지정하는 [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) 및 [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html) 요청은 이제 암호문을 암호화하지 않은 KMS 키와 별칭이 연결되기 때문에 실패할 수 있습니다. 이 상황은 일반적으로 `IncorrectKeyException` 또는 `NotFoundException`을 반환합니다. 또는 요청에 `KeyId` 또는 `DestinationKeyId` 파라미터가 없는 경우 호출자가 암호문을 암호화한 KMS 키에 더 이상 액세스할 수 없기 때문에 `AccessDenied` 예외와 함께 작업이 실패할 수 있습니다.
[CreateAlias](ct-createalias.md), [UpdateAlias](ct-updatealias.md) 및 [DeleteAlias](ct-deletealias.md)로그 항목에 대한 CloudTrail 로그를 확인하여 변경 사항을 추적할 수 있습니다. [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html) 응답의 `LastUpdatedDate` 필드 값을 사용하여 변경 사항을 감지할 수도 있습니다.
예를 들어 다음 [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html) 예제 응답은 `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 키를 가져옵니다. 별칭 관리 권한을 필요한 보안 주체에게만 부여하고 관리해야 하는 별칭으로 [별칭 관리 권한을 제한](alias-access.md#alias-access-limiting)합니다.