AWS KMS: キーポリシーが許さない限り、IAM ポリシーで kms:Decrypt を付けても使えない
KMS のキーは、他の多くの AWS リソースと違って「リソース側のポリシー（キーポリシー）が先に効く」仕組みになっている。マルチアカウントで暗号化キーを共有するときに詰まりやすいのはここ。
仕組み
- キーの利用可否は、まずキーポリシーで決まる。キーポリシーに書かれていない主体は、IAM ポリシーで
kms:Decryptなどを持っていても使えない - IAM ポリシーを効かせたいときは、キーポリシーに「このアカウント（
arn:aws:iam::<account-id>:root）にkms:*を許可する」文を入れておく。コンソールで作ったキーの既定ポリシーにある「Enable IAM User Permissions」がこれで、これがあって初めて同じアカウント内の IAM ポリシーで権限を配れる - つまり「キーポリシーが権限の上限（境界）を決め、IAM ポリシーはその内側で配る」と考えるとわかりやすい
別アカウントにキーを使わせるとき
両方の許可が必要になる。
- キーを持つアカウント側: キーポリシーで相手アカウント（またはその中の特定ロール）に必要な操作（
kms:Decrypt、kms:GenerateDataKeyなど）を許可する - 使う側のアカウント: そのロールの IAM ポリシーで、相手のキー ARN に対する同じ操作を許可する
どちらか片方だけだと AccessDenied になる。S3 の SSE-KMS で別アカウントのオブジェクトを読めないときは、バケットポリシーだけでなくキーポリシーも確認する。
注意点
- キーポリシーからアカウントの root 許可を外すと、IAM で権限を配れなくなる。管理者まで締め出すと AWS サポートに頼むことになるので、変更前に必ず確認する
- グラント（
CreateGrant）でも一時的に権限を渡せる。サービス連携ではこちらが使われることもある - 投稿は要点のメモ。正確な評価ロジックは AWS KMS の「キーポリシー」ドキュメントで確認する
関連
- AWS IAM: 評価は「明示 Deny → 明示 Allow → 暗黙 Deny」
- AWS 設計の定石メモ: 人は Identity Center・システムは IAM ロール／VPC エンドポイント／Route 53 Resolver