問題の発生Secrets Managerからデータベースのパスワードを取得しようとしたり、S3から暗号化された2KBの設定ファイルをダウンロードしようとしたりしているとします。IAMロールにはAdministratorAccessが付与されているにもかかわらず、コードは403エラーでクラッシュします。書類上はすべての権限があるはずなのに、まるで厚い壁にぶつかったような感覚に陥るでしょう。

AccessDeniedException: User: arn:aws:iam::123456789012:role/MyRole is not authorized to perform: kms:Decrypt on resource: arn:aws:kms:ap-northeast-1:123456789012:key/abc-123

原因：「二重ロック」の仕組みAWS KMSは、IAMポリシーだけでは最終的な決定権を持たない数少ないサービスの1つです。これを、2つの異なる鍵を持つ金庫と考えてください。中に入るには、IDチームからの鍵（IAMポリシー）と、金庫管理者からの鍵（キーポリシー）の両方が必要です。

キーポリシーに特定のロールが明示的に記載されていない場合、AWSはデフォルトで「拒否（Deny）」を返します。これは、たとえアカウント管理者であっても同様です。このフェイルセーフ機構により、管理者アカウントが乗っ取られた場合でも、インフラ全体の機密性の高い256ビット暗号化データに即座にアクセスされるのを防いでいます。

ステップバイステップの解決策### ステップ1：キーARNを取得するエラーメッセージをもう一度確認してください。arn:aws:kms...で始まる文字列が、アクセスをブロックしているリソースそのものです。このARNをコピーしてください。何百ものキーの中から特定のキーを見つけるために必要になります。

ステップ2：IAM側の確認IAMロール（MyRole）には、依然としてKMSと通信するための基本的な権限が必要です。IAMコンソールを開き、ポリシーに以下のブロックが含まれていることを確認してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/abc-123"
        }
    ]
}

ステップ3：キーポリシーの修正（本質的な解決策）ほとんどのエラー（約90%）はここで解決します。KMSキーに対して、特定のIAMロールを信頼するように設定する必要があります。

• KMSコンソールを開き、キーabc-123を見つけます。- キーポリシータブをクリックし、編集を押します。- Statement配列の中に以下のステートメントを挿入します：``` { "Sid": "AllowMySpecificRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }

**ヒント：**キーポリシーにおいて、`"Resource": "*"`は「AWS上のすべてのキー」を意味しません。このポリシーがアタッチされている「その特定のキー」のみを指します。
### ステップ4：クロスアカウントアクセスの処理アカウントA（`111122223333`）のLambdaを使用して、アカウントB（`444455556666`）のキーを復号しようとしていませんか？これには「ハンドシェイク」が必要です。アカウントBのキーポリシーの`Principal`に、アカウントAのロールのフルARNを記載する必要があります。この明示的なハンドシェイクがない限り、リクエストは必ず失敗します。
## 修正のテストCI/CDパイプラインの実行を10分も待つ必要はありません。AWS CLIを使用して、数秒で修正を確認しましょう：

キーが表示されるか確認

aws kms describe-key --key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123

模擬復号を試行

aws kms decrypt --key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123 --ciphertext-blob fileb://encrypted_data.bin

`KeyMetadata`を含むJSONレスポンスが正常に返ってくれば、障害を乗り越えたことになります。
## トラブルシューティングのまとめ- **「ルート」ルール：**キーポリシーがアカウントの`root`ユーザーを許可しているか確認してください。許可されている場合、IAMポリシーが通常通り機能します。そのブロックがない場合、キーポリシーにリストされているユーザーのみがそのキーを使用できます。- **サービスロール：**S3やLambdaを使用する場合、個人のIAMユーザーではなく、**実行ロール（Execution Role）**に権限を付与していることを確認してください。- **CloudTrail：**まだ解決しない場合は、CloudTrailログを確認してください。`EventSource: kms.amazonaws.com`でフィルタリングします。ログを確認すれば、IAMとキーポリシーのどちらが`Access Denied`（アクセス拒否）を出しているかが正確に分かります。