KMSによる暗号化（キーポリシーとIAMポリシーの関係）難易度 高無料
IAMユーザー bob には kms:Decrypt をすべてのリソース（"Resource": "*"）に許可するIAMポリシーがアタッチされている。しかし bob が特定のCMK（alias/finance-key）を使って Decrypt を呼び出すと AccessDeniedException になる。このCMKのキーポリシーには、デフォルトで含まれる「IAMポリシーによるアカウントルートへの権限委任を有効化する」ステートメント（Enable IAM User Permissionsに相当するもの）が削除されて存在しない状態だった。この状況の説明として最も適切なものを選べ。（単一選択）
- AIAMポリシーで
kms:DecryptをResource: *で許可しているので、キーポリシーの内容に関わらずbobは復号できるはずである。AccessDeniedExceptionの原因は別にある - Bキーポリシーから「IAMポリシーへの権限委任（アカウントルートを許可する既定ステートメント）」が削除されているため、キーポリシー側で
bob（または関連ロール）を明示的に許可しない限り、IAMポリシーのAllowだけではそのCMKにアクセスできない - CSCPが暗黙的にすべてのKMS操作をDenyしているため、キーポリシーやIAMポリシーの内容に関係なく拒否されている
- DCMKに対する
Decryptはキーポリシーでは制御できず、常にIAMポリシーのみで制御される仕様のため、今回の事象は起こり得ない（設定ミスの可能性は無い）
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
KMSのCMKへのアクセス許可は、他のAWSリソースと異なり「キーポリシー」が常に評価に関与するという特殊なモデルを取る。
- CMK作成時のデフォルトのキーポリシーには、通常
{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::<account>:root"},"Action":"kms:*","Resource":"*"}というアカウントルートへの許可ステートメントが含まれる。これがあることで初めて、IAMポリシー側の許可がそのCMKへのアクセスとして「有効」になる （IAMポリシーに実効力を持たせるための“扉”をキーポリシー側が開けている状態）。 - この設問のようにそのステートメントが削除されている場合、IAMポリシーでどれだけ広く
kms:Decryptを許可していても、 キーポリシー側にbob（または彼が引き受けているロール）を明示的に許可するステートメントが無い限りアクセスは拒否される。 - 解決には、キーポリシーに
bob（または関連ロール）を許可するステートメントを追加するか、 削除されたルートへの委任ステートメントを復元してIAMポリシー側の管理に戻す必要がある。
- AKMSはキーポリシーが常に評価に関与する特殊なリソース。「IAMに権限委任する」ステートメントが無いキーポリシーでは、IAMポリシー側のAllowだけでは不十分。
- C設問はSCPの存在に触れておらず、これは論点のすり替え。原因はキーポリシーの権限委任ステートメントの欠如である。
- D事実に反する。CMKはキーポリシーが必ず評価対象になり、キーポリシーの内容次第でIAMポリシーのAllowが無効化されうる。
ひっかけ： 「IAMポリシーでAllowしているのだから使えるはず」という直感（A）が典型的な誤り。KMSはキーポリシーが常に関与する特殊な評価モデルであり、
「IAMに権限委任するステートメント」が無いキーポリシーでは、IAMポリシーだけでは不十分。SCPの話（C）にすり替えるのも本問の論点ではない。
コマンド例と想定される挙動（未実行）
kms:Decrypt on alias/finance-key → AccessDeniedException （IAMポリシーは Allow だが、キーポリシーに Enable IAM User Permissions 相当のステートメントが無く、 かつ bob を明示的に許可するステートメントも無いため拒否される）
公式ドキュメント・関連AWS KMS Developer Guide ― Key policies in AWS KMS↗AWS KMS Developer Guide ― Default key policy↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）