Security Hub CSPMのコントロール修復を自動化・半自動化したい
こんにちは、まるとです。
みなさんSecurity Hub CSPMは有効にしていますか？
AWSリソースのセキュリティ向上のために有効化されている方も多いと思います。
全て必ず対応しないといけない、というわけではないですが、推奨事項が多いため対応が大変...と感じている方もいらっしゃるのではないでしょうか。
今回はAWS公式ドキュメントでも記載がありますが、自動化を行ってみたので備忘録として紹介します。
この記事でできること
- Security Hub 管理者アカウントからメンバーアカウントへの招待
- Security Hub コントロールの修復半自動化・自動化
前提条件
- AWS Config、AWS Security Hubが各アカウントで有効になっていること
- AWS ConfigはIAMなどグローバルリソースに関連する検出に必要となります。
ざっくり手順
- Security Hub 管理アカウントで管理者スタックをデプロイ
- メンバーアカウントで修復用ロールをデプロイ
- メンバーアカウント用スタックをデプロイ
実際にやってみる（準備）
では実際に必要なスタックをデプロイして、準備を行なっていきます。
Security Hub 管理者アカウントからメンバーアカウントの登録・招待
まず、Security Hub 管理者アカウントからメンバーアカウントの登録招待を行います。
Security hub CSPM コンソール サイドバーにある「設定」から招待を行います。
設定を開いたら、Add accountsを選択します。
続いて、メンバーアカウント側のAWSアカウントIDを入力して、Addボタンを選択します。
すると、Accounts to addの欄に入力したAWSアカウントIDが表示されるため、Nextボタンを選択します。
その後、追加したメンバーアカウントに対してStatueがCreatedとなるため、横にあるinviteをクリックすれば、メンバーアカウントへの招待は完了です。
続いて、メンバーアカウント側にログインします。
ログイン後、同様にSecurity Hub CSPMの設定を開くと、Administrator accountの欄に先ほど送信した招待が表示されます。
Security Hub 管理者アカウントのアカウントIDであることを確認して、Acceptのトグルスイッチをオンに変更、Accept invitationを選択することで招待を許可します。
再度、Security Hub 管理者アカウントにログインし、Statusの部分がEnabledに変わっていれば、メンバーアカウントの招待・登録は完了となります。
Security Hub 管理アカウントで管理者スタックをデプロイ
続いて、Security Hub 管理アカウントで管理者スタックをデプロイします。
デプロイにはAWS公式ドキュメントにリンクがあるCloudFormationテンプレートを使用します。
テンプレートは以下のLaunch solutionボタンにあります。
Launch solutionボタン押下直後はバージニア北部（us-east-1）でスタックを作成しようとするため、必要に応じてリージョンを変更してください。
（リージョンごとに大きな変化はありませんが、本記事ではアジアパシフィック (東京) （ap-northeast-1）で検証を行います。）
最初のステップでは、必要事項が全て入力されているので、何も変こせずに次へを選択します。
次に、スタックの詳細を指定ページでパラメータなどを設定します。
今回の検証では、AWS 基礎セキュリティのベストプラクティス v1.0.0のコントロールに対して検証を行います。
任意のスタック名を入力し、パラメータは以下を参考に設定していきます。
| パラメータ名 | 備考 | 本記事での設定値 |
|---|---|---|
| LoadSCAdminStack | コントロール自動修復用のコンポーネントのインストール | yes |
| LoadAFSBPAdminStack | AWS 基礎セキュリティのベストプラクティス v1.0.0向け自動修復コンポーネントのインストール | yes |
| LoadCIS120AdminStack | CIS AWS Foundations Benchmark v1.2.0向け自動修復コンポーネントのインストール | no |
| LoadCIS140AdminStack | CIS AWS Foundations Benchmark v1.4.0向け自動修復コンポーネントのインストール | no |
| LoadCIS300AdminStack | CIS AWS Foundations Benchmark v3.0.0向け自動修復コンポーネントのインストール | no |
| LoadNIST80053AdminStack | NIST Special Publication 800-53 Revision 5向け自動修復コンポーネントのインストール | no |
| LoadPCI321AdminStack | PCI DSS v3.2.1向け自動修復コンポーネントのインストール | no |
| ReuseOrchestratorLogGroup | 既存のOrchestrator Log Groupの使用有無 ※初めてのデプロイの場合はno |
no |
| ShouldDeployWebUI | Security Hubとは別にWebUIによるダッシュボードの有効化有無 | no |
| AdminUserEmail | WebUIダッシュボードの管理者メールアドレス ※WebUIダッシュボードが無効の場合は空欄でOK |
空欄 |
| UseCloudWatchMetrics | 自動修復に関連するリソースのモニタリング有無 | no |
| UseCloudWatchMetricsAlarms | 自動修復に関連するリソースのCloudWatch Alarmの有無 | no |
| EnableEnhancedCloudWatchMetrics | コントロールID個別にCloudWatch メトリクスの作成有無 | no |
| RemediationFailureAlarmThreshold | コントロールIDごとの失敗数の閾値 | デフォルト値 (5) |
| TicketGenFunctionName | チケット管理システムとの統合を行う場合は、Lambda関数名 本記事では割愛します。 |
空欄 |
パラメータ入力後は特に設定をいじらず進めていきます。
途中、IAMリソースや機能の要求が入ることを確認されるため、チェックを入れた上でCloudFormationスタックのデプロイまで進めてください。
エラーが発生せず、CloudFormation スタックのステータスがCREATE_COMPLETEとなれば、本作業は完了です。
メンバーアカウントで修復用ロールをデプロイ
続いて、管理者アカウントからメンバーアカウントにアカウントを跨いでAPIコールができる様に、必要なロールをデプロイします。
先ほどと同様に、AWS公式ドキュメントにテンプレートへのリンクがあります。（リージョン変更をお忘れなく）
設定すべきパラメータは以下の2つです。
| パラメータ名 | 備考 | 本記事での設定値 |
|---|---|---|
| Namespace | IAMロールのサフィックス ※最大9文字の英数字である必要あり |
shtest |
| SecHubAdminAccount | Security Hub 管理者AWSアカウントID | <AWSアカウントID> |
他は設定を変えずにCloudFormation スタックをデプロイします。
メンバーアカウント用スタックをデプロイ
最後にメンバーアカウントに自動修復を実行するためのリソースをデプロイします。
以下のリンクにあるLaunch solutionをクリックしてデプロイします。（リージョン変更をお忘れなく）
パラメータとしては、管理者アカウント向けと似ているものがあります。
| パラメータ名 | 備考 | 本記事での設定値 |
|---|---|---|
| LoadSCMemberStack | コントロール自動修復用のコンポーネントのインストール | yes |
| LoadAFSBPAdminStack | AWS 基礎セキュリティのベストプラクティス v1.0.0向け自動修復コンポーネントのインストール | yes |
| LoadCIS120AdminStack | CIS AWS Foundations Benchmark v1.2.0向け自動修復コンポーネントのインストール | no |
| LoadCIS140AdminStack | CIS AWS Foundations Benchmark v1.4.0向け自動修復コンポーネントのインストール | no |
| LoadCIS300AdminStack | CIS AWS Foundations Benchmark v3.0.0向け自動修復コンポーネントのインストール | no |
| LoadNIST80053AdminStack | NIST Special Publication 800-53 Revision 5向け自動修復コンポーネントのインストール | no |
| LoadPCI321AdminStack | PCI DSS v3.2.1向け自動修復コンポーネントのインストール | no |
| CreateS3BucketForRedshiftAuditLogging | AWS 基礎セキュリティのベストプラクティス v1.0.0のRedshift.4を修復するためのS3バケット作成有無 | no |
| SecHubAdminAccount | Security Hub 管理者AWSアカウントID | <AWSアカウントID> |
| Namespace | メンバーアカウントで修復用ロールをデプロイ時に設定したNamespace | shtest |
| EnableCloudTrailForASRActionLog | CloudWatchダッシュボードの仕組みより生成される管理イベントのモニタリング有無 ※AWS Organization必須 |
no |
以上でデプロイを進めます。デプロイが完了したら事前準備は完了となります。
実際にやってみる（修復）
一通り準備が整ったため、試しにSecurity Hubのコントロールに失敗するリソースを作成・設定した上で半自動修復を行います。
わかりやすいものとして、EC2.2 VPCのデフォルトセキュリティでインバウンド/アウトバウンドトラフィックを許可しない、というものがあるので、これを例に検証を行います。
早速、コントロールが失敗する様に0.0.0.0/0から全てのポート。プロトコルに対してアクセスを許可するルールをデフォルトセキュリティグループに追加してみました。
しばらくすると、EC2.2のコントロールが失敗することを確認できました。
それでは実際に自動修復を実行します。
修復を行うには、ステータスがFAILEDになっているリソース横のチェックボックスを選択した上で、アクション > Remediate with ASRを選択します。
すると、「検出結果を Amazon EventBridge に正常に送信しました」というメッセージが表示されて、EventBridge経由でリソース修復要求が行われます。
しばらくして、再度セキュリティグループを確認すると、インバウンド・アウトバウンドトラフィックが全て削除されて、コントロールに沿って修正されていました。
なお、裏ではStep Functionsの「SO0111-ASR-Orchestrator」で実際の動作状況などを確認できます。
コントロール失敗を元に自動修復を有効にする
今回は、手動でSecurity Hubから自動修正を要求しましたが、コントロール失敗を監視して自動修正も行うことができます。
本機能を有効にするには、Security Hub 管理者アカウント内のDynamoDBを変更する必要があります。
DynamoDBのテーブル名はSecurity Hub 管理者用CloudFormation スタックの出力RemediationConfigurationDynamoDBTableに記載があります。
記載のテーブルを確認すると、controlIdに対してautomatedRemediationEnabledでtrue/falseが設定されています。（デフォルトは全てfalse）
自動化したいコントロールIDに対して、automatedRemediationEnabledをtrueにすることで自動化を有効化できます。
終わりに
今回はSecurity Hub CSPMのコントロール修復自動化を触れてみました。
いくつか設定はあるものの、より簡単に推奨される状態に戻すことができるためぜひお試しいただくのが良いのではないでしょうか。
以上、まるとでした。
