![【Security Hub修復手順】[KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用しないでください](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/f_auto,q_auto/v1790871196/eyecatch/wr309ednrjrbdx9mtsnl.png)
【Security Hub修復手順】[KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用しないでください
かつまたです。
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[KMS.2] IAM プリンシパルは、すべての KMS キーで復号アクションを許可する IAM インラインポリシーを使用しないでください
[KMS.2] IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、IAMユーザー・グループ・ロールに埋め込まれたインラインポリシーが、kms:Decrypt または kms:ReEncryptFrom をすべてのKMSキーに対して許可していないかをチェックします。
Resource に特定のKMSキーのARNを指定すると、このコントロールは成功します。
カスタマー管理ポリシーは [KMS.1] の対象です。KMS.1との大きな違いは、検出結果がポリシーではなくIAMプリンシパル（ユーザー・グループ・ロール）単位で出ることです。
対応が必要な理由
すべてのKMSキーで復号を許可していると、そのプリンシパルは本来扱う必要のないデータまで復号できます。たとえば、アプリケーション用のロールが、別システムのS3バケットにSSE-KMSで保存されたオブジェクトや、Secrets Managerのシークレットを読めてしまいます。認証情報が漏えいしたときに、被害が及ぶ範囲も広がります。
Resource の書き方と評価結果
このコントロールは、インラインポリシーの Resource 要素だけを見て判定します。判定の仕組みはKMS.1と同じです。検証環境で4種類の書き方を試し、AWS Configの評価結果を確認しました。
Resource の書き方 |
評価結果 |
|---|---|
"*" |
NON_COMPLIANT |
"arn:aws:kms:ap-northeast-1:<アカウントID>:key/*" |
NON_COMPLIANT |
"*" に kms:ViaService の条件を追加 |
NON_COMPLIANT |
"arn:aws:kms:ap-northeast-1:<アカウントID>:key/<キーID>" |
COMPLIANT |
リージョンとアカウントまで絞っても、キーIDがワイルドカードなら失敗します。また、Condition 要素は評価されないため、kms:ViaService などの条件で実質的に絞り込んでいても失敗のままです。成功させるには、キーIDまで固定したARNを指定する必要があります。
対応しなくてよいケース
対応するかどうかは、ポリシーの用途や運用負荷を踏まえてご判断ください。たとえば、以下のようなケースでは現状のまま運用する判断もあります。
- 管理者用のロールなど、もともとすべてのキーを扱う前提の権限である
Conditionで実質的に絞り込んでいる（このコントロールは条件を評価しないため、検出結果を抑制して管理します）- 使用するキーが頻繁に増減し、ARNを固定すると運用負荷が大きい
対応する場合は、以下の手順で進めることをご検討ください。
修復手順
1. 使用しているKMSキーを特定する
CloudTrailのイベント履歴で、プリンシパルが実際に使っているKMSキーを確認します。手順はKMS.1と同じです。
- CloudTrailコンソールを開き、左メニューから「イベント履歴」を選択します
- 検索条件で「イベント名」を選択し、
Decryptを入力します - イベントを選択して詳細画面を開き、イベントレコード（JSON）を確認します
確認する箇所は2つです。
userIdentity.sessionContext.sessionIssuer.userName：どのロールの操作か（詳細画面の「ユーザー名」にはセッション名が表示されます）resources：使われたキーのARN（詳細画面の「参照されたリソース」には (0) と表示されますが、JSONには記録されています）
詳しい見方は、KMS.1の記事の「1. 使用しているKMSキーを特定する」で説明しています。
2. インラインポリシーを編集する
Security Hubの検出結果にはポリシー名が含まれません。1つのプリンシパルに複数のインラインポリシーがある場合は、Resource が "*" になっているものを探します。
また、インラインポリシーにはバージョンがありません。編集前の内容を控えておかないと、元に戻せなくなります。
- IAMコンソールを開き、左メニューから「ロール」を選択します（IAMユーザーやグループの場合は、それぞれのメニューを選択します）
- 対象のロールを選択し、「許可」タブを開きます
- タイプが「カスタマーインライン」のポリシーを展開し、
Resourceが"*"になっているものを探します - 「JSON をコピー」を選択し、編集前の内容を控えておきます
- 「編集」を選択し、「JSON」で
Resourceを手順1で特定したキーのARNに変更します - 「次へ」を選択し、確認画面で「変更を保存」を選択します
複数のキーを使っている場合は、配列で指定します。
"Resource": [
"arn:aws:kms:ap-northeast-1:<アカウントID>:key/<キーID1>",
"arn:aws:kms:ap-northeast-1:<アカウントID>:key/<キーID2>"
]
3. 修復確認
ロールの「許可」タブでインラインポリシーを展開し、Resource が変更されていることを確認します。
検証環境では、修復後に指定したキーは引き続き復号でき、指定しなかったキーは AccessDeniedException で拒否されました。
最後に
今回は、KMS.2の修復手順をご紹介しました。
修復の考え方はKMS.1と同じですが、インラインポリシーにはバージョンがないため、編集前のJSONを控えてから作業してください。検出結果がプリンシパル単位で出るため、原因のポリシーを自分で探す必要がある点もKMS.1と異なります。
ご覧いただきありがとうございました。
