翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS KMS の ABAC トラブルシューティング
タグとエイリアスに基づいて KMS キーへのアクセスを制御することは、便利で強力です。ただし、いくつかの予測可能なエラーが発生しやすいため、予防する必要があります。
タグの変更によりアクセスが変更される
タグが削除されるかその値が変更されると、そのタグのみに基づいて KMS キーにアクセスするプリンシパルは、KMS キーへのアクセスを拒否されます。これは、拒否ポリシーステートメントに含まれるタグが KMS キーに追加された場合にも発生します。ポリシー関連のタグを KMS キーに追加すると、KMS キーへのアクセスを拒否されるプリンシパルにアクセスを許可できます。
例えば、プリンシパルに、Project=Alpha タグに基づく KMS キーへのアクセス許可 (以下の例の、IAM ポリシーステートメントによって付与されるアクセス許可など) があるとします。
{ "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 サービスのデータを読み取る、または書き込む際に明らかになります。タグの変更を追跡するには、TagResource または UntagResource entries の CloudTrail ログを確認します。
ポリシーを更新せずにアクセスを復元するには、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 キーに関連付けられたエイリアスを変更します。各エイリアスは、アカウントおよびリージョン内の 1 つの KMS キーのみにしか関連付けできないため、エイリアスの管理は、タグの管理よりも若干難しくなります。ある KMS キーの一部のプリンシパルへのアクセスを復元すると、異なる KMS キーの同じプリンシパルまたは他のプリンシパルへのアクセスが拒否されることがあります。
このエラーを防ぐには、エイリアス管理許可を必要なプリンシパルのみに付与し、エイリアス管理許可の制限を管理する必要があるエイリアスに制限します。エイリアスを更新または削除する前に、ポリシーを検索してエイリアスに依存するアクセスを検出し、エイリアスに関連付けられているすべてのリージョンで KMS キーを検索します。
エイリアスクォータによりアクセスが拒否された
kms:ResourceAliases 条件によって KMS キーの使用を認可されているユーザーには、KMS キーがそのアカウントまたはリージョンの、デフォルトのKMS キーあたりのエイリアスクォータを超えた場合、AccessDenied の例外が適用されます。
アクセスを復元するには、KMS キーに関連付けられたエイリアスを削除して、クォータに適合させます。または、別のメカニズムを使用して、ユーザーに KMS キーへのアクセスを許可します。
認可変更の遅延
タグとエイリアスを変更すると、KMS キーの認可に影響を及ぼすまでに最大 5 分かかる場合があります。結果として、タグやエイリアスの変更が認可に影響を与える前に、API オペレーションからのレスポンスに反映される可能性があります。この遅延はほとんどの場合、結果整合性の短い遅延よりも長くなる可能性があり、AWS KMS オペレーションに最も大きく影響します。
例えば、特定のプリンシパルに "Purpose"="Test" タグで KMS キーの使用を許可する IAM ポリシーなどです。次に、"Purpose"="Test"タグを KMS キーに追加します。TagResource オペレーションが完了し、ListResourceTags レスポンスによって、タグが KMS キーに割り当てられていることが確認されても、プリンシパルは KMS キーに最大 5 分間アクセスできない場合があります。
エラーを防ぐには、この予想される遅延をコードに組み込みます。
エイリアスの更新によるリクエストの失敗
エイリアスを更新するときは、既存のエイリアスを別の KMS キーに関連付けます。
エイリアス名またはエイリアス ARN を指定する Decrypt および ReEncrypt リクエストは、エイリアスが暗号文を暗号化していない KMS キーに関連付けられたため、失敗することがあります。この状況は通常、IncorrectKeyException または NotFoundException を返します。または、リクエストに KeyId または DestinationKeyId パラメータがない場合、発信者が暗号文を暗号化した KMS キーにアクセスできなくなったため、AccessDenied の例外により、オペレーションは失敗する可能性があります。
CloudTrail ログで CreateAlias、UpdateAlias、DeleteAlias ログエントリを探して、変更を追跡できます。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 キーを取得します。エイリアス管理許可を、必要とするプリンシパルにのみ付与し、エイリアス管理許可の制限を、管理する必要があるエイリアスに設定します。
