【Security Hub修復手順】[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーの復号アクションを許可しないでください

かつまたです。

本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。

本記事の対象コントロール

[KMS.1] IAM カスタマー管理ポリシーでは、すべての KMS キーの復号アクションを許可しないでください

[KMS.1] IAM customer managed policies should not allow decryption actions on all KMS keys

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/kms-controls.html#kms-1

前提条件

本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。

https://dev.classmethod.jp/articles/lets-learn-aws-security-hub/

https://dev.classmethod.jp/articles/aws-security-operation-with-securityhub-2021/

対象コントロールの説明

このコントロールは、IAMのカスタマー管理ポリシーが kms:Decrypt または kms:ReEncryptFrom を、すべてのKMSキーに対して許可していないかをチェックします。
Resource に特定のKMSキーのARNを指定すると、このコントロールは成功します。

評価対象はカスタマー管理ポリシーのデフォルトバージョンです。どのIAMプリンシパルにもアタッチされていないポリシーも評価されます。インラインポリシーは [KMS.2] の対象で、AWS管理ポリシーはどちらのコントロールでも評価されません。

対応が必要な理由

すべてのKMSキーで復号を許可していると、そのプリンシパルは本来扱う必要のないデータまで復号できます。たとえば、アプリケーション用のロールが、別システムのS3バケットにSSE-KMSで保存されたオブジェクトや、Secrets Managerのシークレットを読めてしまいます。認証情報が漏えいしたときに、被害が及ぶ範囲も広がります。

KMSキーへのアクセスは、キーポリシーとIAMポリシーの組み合わせで決まります。キーポリシーがIAMポリシーに判断を委ねている場合（デフォルトのキーポリシーがこの形です）、IAMポリシー側で範囲を絞らない限り、アカウント内のすべてのキーが復号の対象になります。

Resource の書き方と評価結果

このコントロールは、ポリシーの Resource 要素だけを見て判定します。検証環境で4種類のポリシーを作成し、AWS Configの評価結果を確認しました。

リージョンとアカウントまで絞っても、キーIDがワイルドカードなら失敗します。また、Condition 要素は評価されないため、kms:ViaService などの条件で実質的に絞り込んでいても失敗のままです。成功させるには、キーIDまで固定したARNを指定する必要があります。

対応しなくてよいケース

対応するかどうかは、ポリシーの用途や運用負荷を踏まえてご判断ください。たとえば、以下のようなケースでは現状のまま運用する判断もあります。

• 管理者用のポリシーなど、もともとすべてのキーを扱う前提の権限である
• Condition で実質的に絞り込んでいる（このコントロールは条件を評価しないため、検出結果を抑制して管理します）
• 使用するキーが頻繁に増減し、ARNを固定すると運用負荷が大きい

対応する場合は、以下の手順で進めることをご検討ください。

修復手順

1. 使用しているKMSキーを特定する

CloudTrailのイベント履歴で、プリンシパルが実際に使っているKMSキーを確認します。イベント履歴で確認できるのは過去90日分です。

1. CloudTrailコンソールを開き、左メニューから「イベント履歴」を選択します
2. 検索条件で「イベント名」を選択し、Decrypt を入力します
3. イベントを選択して詳細画面を開きます

詳細画面の「参照されたリソース」には (0) と表示されますが、使われたキーは記録されています。イベントレコード（JSON）を下までスクロールすると、resources にキーのARNがあります。

どのロールの操作かは、イベントレコードの userIdentity.sessionContext.sessionIssuer.userName で確認します。詳細画面の「ユーザー名」にはロール名ではなくセッション名が表示されるため、注意してください。

"sessionIssuer": {
    "type": "Role",
    "userName": "sh-test-kms-1-role"
},
...
"resources": [
    {
        "accountId": "<アカウントID>",
        "type": "AWS::KMS::Key",
        "ARN": "arn:aws:kms:ap-northeast-1:<アカウントID>:key/9e1d55ff-..."
    }
]

なお、暗号文にキーの情報が含まれているため、Decrypt のリクエストパラメータ（requestParameters）にはキーIDが記録されません。キーの特定には resources を使います。

ポリシーで kms:Encrypt や kms:GenerateDataKey も許可している場合は、同じ方法でこれらのイベントも確認してください。同じステートメントに書かれていれば、Resource を絞ったときにこれらのアクションも一緒に絞られます。

2. ポリシーを編集する

1. IAMコンソールを開き、左メニューから「ポリシー」を選択します
2. 対象のポリシーを選択し、「編集」を選択します

3. 「JSON」を選択し、Resource を手順1で特定したキーのARNに変更します
4. 「次へ」を選択し、確認画面で「変更を保存」を選択します

複数のキーを使っている場合は、配列で指定します。

"Resource": [
    "arn:aws:kms:ap-northeast-1:<アカウントID>:key/<キーID1>",
    "arn:aws:kms:ap-northeast-1:<アカウントID>:key/<キーID2>"
]

3. 修復確認

ポリシー詳細画面の「ポリシーのバージョン」タブを開き、新しいバージョンが「デフォルト」になっていることを確認します。

検証環境では、修復後に指定したキーは引き続き復号でき、指定しなかったキーは次のエラーで拒否されました。

An error occurred (AccessDeniedException) when calling the Decrypt operation: User: arn:aws:sts::<アカウントID>:assumed-role/sh-test-kms-1-role/sh-test is not authorized to perform: kms:Decrypt on resource: arn:aws:kms:ap-northeast-1:<アカウントID>:key/9e1d55ff-... because no identity-based policy allows the kms:Decrypt action

最後に

今回は、KMS.1の修復手順をご紹介しました。

Resource にワイルドカードを使わず、キーIDまで固定したARNを指定する必要がある点が、このコントロールの注意点です。使用しているキーはCloudTrailのイベント履歴で特定できますが、キーのARNはイベントレコードのJSONにしか表示されないため、見落とさないようにしてください。

インラインポリシーを対象とする [KMS.2] の修復手順は、こちらの記事でご紹介しています。

https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-kms-2/

ご覧いただきありがとうございました。