AWS Configのリソースタイプを後から無効化してもAWS Security Hubのコントロールで検出され続ける件

AWS Security Hubのコントロールで検出されたリソースがなんだか多いな

こんにちは、のんピ(@non____97)です。

皆さんはしたいAWS Security Hubのコントロールで検出されたリソースがなんだか多いなと思ったことはありますか? 私はあります。

考えられる原因にSecurity Hubが有効な全リージョンにおいて、グローバルリソースをAWS Configで記録している可能性が考えられます。

Security HubはAWS Config Ruleをベースにセキュリティチェックを行っています。

AWS Security Hub は、サービスにリンクされた AWS Config ルールを使用して、ほとんどのコントロールのセキュリティチェックを実行します。

これらのコントロールをサポートする AWS Config には、 AWS リージョン Security Hub が有効になっている各 で、管理者アカウントとメンバーアカウントの両方を含むすべてのアカウントで を有効にする必要があります。さらに、有効な標準ごとに、有効なコントロールに必要なリソースを記録するように設定 AWS Config する必要があります。

Security Hub 標準を有効にする AWS Config 前に、 でリソース記録を有効にすることをお勧めします。リソース記録が有効になっていないときに Security Hub がセキュリティチェックを実行しようとすると、チェックはエラーを返します。

Security Hub を有効にする前の推奨事項 - AWS Security Hub

全てのリージョンでIAMポリシーやIAMロールなどのグローバルリソースを記録するようにしてしまうと、結果が重複してしまいます。

解決方法として、以下記事では「一つのリージョンでのみグローバルリソースを対象としたコントロールを有効化し、その他のリージョンでは無効化すること」が紹介されています。

AWS Configで特定リージョンでのみグローバルリソースを記録するように変更するだけでは対応として不足しているのでしょうか?

AWS公式ドキュメントを確認してみると、AWS Configでグローバルリソースを対象外としても、コントロールが有効であれば再チェックを行うようです。

一部の はグローバルリソース AWS のサービス をサポートしています。つまり、任意の からリソースにアクセスできます AWS リージョン。のコストを節約するために AWS Config、1 つのリージョンを除くすべてのリージョンでグローバルリソースの記録を無効にすることができます。ただし、これを行った後、Security Hub は引き続きコントロールが有効になっているすべてのリージョンでセキュリティチェックを実行し、リージョンごとにアカウントごとのチェック数に基づいて料金を請求します。したがって、検出結果のノイズを減らし、Security Hub のコストを節約するには、グローバルリソースを記録するリージョンを除くすべてのリージョンで、グローバルリソースを含むコントロールを無効にする必要もあります。

無効にする可能性のある Security Hub コントロール - AWS Security Hub

実際にそのような挙動をするのか確認してみましょう。

いきなりまとめ

• 一度Security Hubで検出されている場合、コスト削減のためにAWS Configで特定リージョンでのみグローバルリソースを記録するように変更するだけでは対応として不足している
  • Security Hubにて一つのリージョンでのみグローバルリソースを対象としたコントロールを有効化し、その他のリージョンでは無効化するのがベター
• AWS Configでリソースタイプを無効化しても、既存のリソースはAWS Config Ruleでは検出され続ける
• Security Hubのコントロールを無効化すると、関連するAWS Config Ruleは削除される
• Security Hubのコントロールを再度有効化すると、関連するAWS Config Ruleが作成される
• 再作成されたAWS Config Ruleでも、リソースタイプ無効化前に検出されていたリソースは再度検出される
• Security Hubは変更によってトリガーされるコントロールであっても、定期的にAWS Configの状態を確認しにいく
  • この動作に課金が発生する

やってみた

AWS ConfigでIAM関連のリソースタイプの記録を無効化

AWS ConfigでIAM関連のリソースタイプの記録を無効化して挙動を確認してみましょう。

無効化前にIAM.1の状態を確認します。59件検出されていますね。

IAM.1はAWS Config Ruleiam-policy-no-statements-with-admin-accessで、AWS::IAM::Policyの状態を確認するようです。

関連する要件： PCI DSS v3.2.1/7.2.1、CIS AWS Foundations Benchmark v1.2.0/1.22、CIS AWS Foundations Benchmark v1.4.0/1.16、NIST.800-53.r5 AC-2、NIST.800-53.r5 AC-2(1)、NIST.800-53.r5 AC-3、NIST.800-53.r5 AC-3(15)、NIST.800-53.r5 AC-3(7)、NIST.800-53.r5 AC-5、NIST.800-53.r5 AC-6、NIST.8000-5 AC-6、NIST. AC-6 AC-68

カテゴリ: 保護 > セキュアなアクセス管理

重要度: 高

リソースタイプ: AWS::IAM::Policy

AWS Config ルール : iam-policy-no-statements-with-admin-access

スケジュールタイプ: 変更がトリガーされた場合

パラメータ:

excludePermissionBoundaryPolicy: true (カスタマイズ不可)

AWS Identity and Access Management コントロール - AWS Security Hub

AWS Config Ruleも確認しましょう。

複数のIAMポリシーが検出されていますね。

また、設定変更が行われたことをトリガーに検出するようです。設定変更が行われたことをトリガーに検出するのであれば、AWS Configで関連するリソースタイプを記録しないようすることで、AWS Config Ruleは動かなくなりそうです。

AWS Configにて記録されたリソースタイプを確認します。

IAM関連のリソースタイプが選択されていますね。

IAM関連のリソースタイプを削除して、保存します。

AWS Config Ruleの手動再評価

この状態でAWS Config Ruleを再評価してみます。

しばらくすると、最後に成功した検出評価が現在の時刻に変更されたことが確認できました。

肝心なリソースは検出され続けたままですね。AWS公式ドキュメントを確認すると、AWS Configの設定レコーダーをオフにしても、以前のリソースの状態が表示され続ける可能性があると紹介されていました。

設定レコーダがオフになっている場合、削除されたリソースの評価結果を保持することができる

設定レコーダーがオフになっている場合、削除を含むリソースの設定に対する変更を追跡 AWS Config する機能を無効にします。これにより、設定レコーダーをオフにした場合、以前に削除されたリソースの評価結果が表示されることがあります。

設定レコーダーの管理 - AWS Config

記録するリソースタイプから削除しても同様の事象が起きているように思えます。今までの記録結果を削除するのではなく、内部的には情報を持ち続ける動きをするようです。

Security Hubで、IAM.1のコントロールを確認します。

検出されたリソース数は変わらず59で、いずれも更新済みの値が2分前となっています。

Security Hubのコントロールを無効化

リソースタイプの記録を無効化しましたが、一度検出されたリソースは残り続けることが分かりました。

それに連動して検出結果がSecurity Hub上に残っています。気持ち良いものではないので、Security Hubのコントロールを一度無効化して削除できるか確認します。

IAM.1を無効化します。

無効化後の状態は以下のとおりです。

無効にしても検出数は変わりありません。

コントロールに関連するAWS Config Ruleは削除されていました。

Security Hubのコントロールを有効化

IAM.1を有効化します。

有効化をして数分待つと、各検出結果の更新済みが7分前から2分前に変わっていました。

• begfore

• after

　コントロールに関連するAWS Config Ruleを確認すると、最後に成功した検出評価が現在の時刻に変更されていることが確認できました。

コントロールを無効化するだけでは、すでに検出された結果を削除することはできないようです。

21時間後

コントロールに検出され結果は残り続けていますが、対象コントロールが設定変更が行われたことをトリガーに検出するのであれば、AWS Configで関連するリソースタイプを記録しないようすることで、AWS Config Ruleは動かなくなり、Security Hubの料金を抑えることはできそうです。

試しに21時間放置してみました。

すると、一部の検出結果の更新済みが5時間前になっていました。

リソースタイプを無効化したのは21時間前なので、AWS Configでは記録されていないはずです。

AWS Config Ruleの状態を確認すると、最後に成功した検出評価はコントロールを再有効化した時刻から変わっていませんでした。

つまりはAWS Config Ruleは動作していませんが、Security HubがAWS Config Ruleの状態を確認しに行っていることが分かります。

KMS.2というIAMロール、IAMユーザー、IAMグループを確認するコントロールでも同様の事象が発生していました。検出結果の更新済みは5時間前ですが、最後に成功した検出評価は5日前でした。つまりは、AWS Config Rule自体は5日は動作していないことになります。

こちらの挙動はAWS公式ドキュメントにも記載されています。変更によってトリガーされるコントロールであっても、定期的にSecurity HubがAWS Configの状態を見に行くようです。

定期チェック– これらのチェックは、最新の実行後 12 時間または 24 時間以内に自動的に実行されます。Security Hub によって周期が決定され、変更することはできません。定期コントロールは、チェックが実行された時点での評価を反映します。定期コントロールの検出結果のワークフローステータスを更新し、次のチェックで検出結果のコンプライアンスステータスが同じままの場合、ワークフローステータスは変更された状態のままになります。たとえば、KMS.4 - AWS KMS キーのローテーションを有効にする必要があります の検出結果が失敗し、検出結果を修正した場合、Security Hub はワークフローステータスを から に変更しますNEW。 RESOLVED次の定期チェックの前に KMS キーのローテーションを無効にした場合、検出結果のワークフローステータスは のままになりますRESOLVED。

変更によってトリガーされるチェック– これらのチェックは、関連付けられたリソースの状態が変わったときに実行されます。AWS Config では、リソース状態の変化を継続的に記録するか、毎日記録するかを選択できます。毎日記録を選択した場合、リソース状態に変化があれば、AWS Config は 24 時間ごとにリソース設定データを配信します。変化がなければ、データは配信されません。これにより、24 時間が経過するまで Security Hub の検出結果の生成が遅れる場合があります。選択した記録期間に関係なく、Security Hub は 18 時間ごとにチェックを行い、AWS Config からのリソース更新が見逃されていないことを確認します。

セキュリティチェックの実行スケジュール - AWS Security Hub

つまりは、リソースタイプを記録しないようにし、AWS Config Ruleが変更でトリガーされなくとも、既にSecurity Hubで検出されている項目は定期的に確認されることを示しています。

既にSecurity Hubで検出されている項目が多いのであれば、リソースタイプを記録しないようにしても継続してそれなりの課金が発生してしまいます。この記事の冒頭で引用したように、Security Hubにて一つのリージョンでのみグローバルリソースを対象としたコントロールを有効化し、その他のリージョンでは無効化するのがベターのようです。

一度Security Hubで検出されてしまっているのであれば、リソースタイプを無効化するだけではなくコントロールごと無効化しよう

AWS Configのリソースタイプを後から無効化してもAWS Security Hubのコントロールで検出され続ける事象を紹介しました。

一度Security Hubで検出されてしまっているのであれば、リソースタイプを無効化するだけではなくコントロールごと無効化する方が無難と考えます。

グローバルリソース全リージョン重複記録はあるあるだと思います。なんだか検出結果が多いと思った方は、各リージョンのSecurity Hubの検出結果と、AWS Configの設定レコーダーのリソースタイプを確認してみましょう。

グローバルリソースを含む Security Hub コントロールのリストは以下AWS公式ドキュメントにまとまっています。こちらにリストアップされているものについては一リージョンでのみ有効化する形でも良いか

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!