この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさんこんにちは、杉金です。
Security Hubの自動修復ソリューションの新バージョン(1.4.2)を試してみます。使ったことのない方にも分かるよう、概要から紹介して何が変わったのかを軽く触れつつ、導入方法と使い方を説明します。
Security Hubの自動修復ソリューションとは
Security Hubを利用することで、使っているAWS環境がセキュリティのベストプラクティスに従っているかをチェックしてくれます。チェックに加えてベストプラクティスに沿ったAWS側の設定（修復）も行ってくれるのがこのソリューションです。修復処理は手動もしくは自動で行えます。手動で修復する場合は、Security Hubのコンソールから対象コントロールを選択して実行します。自動で修復させる場合はEventBridgeルールを有効化にします。有効化することで検知とともに修復も行われます。
どのような仕組みで動いているかは下図が参考になります。
– 図: AWS Security Hub Automated Response and Remediation | Implementations | AWS Solutions
管理アカウントとメンバーアカウントのマルチアカウント構成になっており、管理アカウントで検出を集約して、メンバーアカウントでNGを検出したら管理アカウントからメンバーアカウントに対して修復処理を実行します。
バージョンアップ内容
前回記事のバージョン（1.2.0）からの変更点ですが、主な部分としてはService Catalogが不要になり、CloudFormationテンプレートから有効化にする機能の選択が行えるようになりました。あとはPCI-DSS v3.2.1などの修復に対応するコントロールがいくつか増えています。細かな更新内容はGitHubにある更新履歴を見ていただくのが良いかと思います。
PCI-DSS v3.2.1に対応した時のアップデートニュースはこちらです。
やってみる
手順はユーザーガイドをもとに実施します。3つのCloudFormationスタックを実行していきます。
前提条件
事前準備として、以下の前提条件を満たす必要があります。
- 管理アカウントとメンバーアカウントでSecurity Hubを有効にしていること
- 管理アカウントのSecurity Hubからメンバーアカウントを招待していること
導入Step 1. 管理アカウントでCloudFormationスタック展開
まずは管理アカウントのAWSマネジメントコンソールにログインして、ユーザーガイドStep1にある「Launch Solution」をクリックします。
CloudFormationスタックの作成画面に移動します。
デフォルトで選択されているリージョンが「バージニア北部」のため、設定したいリージョンに変更します。今回はアジアパシフィック（東京）に設定しました。
スタックの詳細を設定していきます。まずはスタック名を決めます。CloudFormationのスタック一覧から判別するためのものですので、何用のスタックか分かる名前が良いです。今回は「aws-security-hub-automated-response-and-remediation-master」とします。
次にパラメータを決めます。最初の3つのリストボックスは、各セキュリティ基準用のEventBridgeルールをロードするかの選択です。Security Hubで有効化にしているセキュリティ基準をもとにyes/noを選択する形が良いですが、とりあえず全部yesにして全ルールをロードしてもエラーは起きません。また、後からyes/noを変更可能です。ReuseOrchestratorLogGroupは過去にこのソリューションを導入していたことがあればyesを選択します。今回は新規に導入するためnoを選択します。
(ちなみに上図にあるAFSBP(AWS Foundational Security Best Practices)とはAWS 基礎セキュリティのベストプラクティスのことです)
次へと進み、スタック作成前のレビュー画面で下図のようなメッセージが表示されますので、内容を読んで問題なければチェックを入れて「スタックの作成」を選択します。
スタックの状態が「CREATE_COMPLETE」になるまで待ちます。
導入Step 2. メンバーアカウントで修復用IAMロールを作成
管理アカウント側の設定は完了です。続いてはメンバーアカウントのAWSマネジメントコンソールにログインして、ユーザーガイドStep2にある「Launch Solution」をクリックします。
step1と同様にスタックの作成画面が表示されます。ここでも適切なリージョンを選択して次へと進みます。
スタックの詳細を設定します。スタックの名前は「aws-security-hub-automated-response-and-remediation-role」としました。パラメータには管理アカウントのAWSアカウント番号(12桁)を入力します。
次へと進んでいき、最後の設定レビューにてメッセージが表示されていますので、内容を読んでチェックを入れてスタックの作成を選択します。
導入Step 1と同様にスタックの状態が「CREATE_COMPLETE」になるまで待ちます。
導入Step 3. メンバーアカウントでCloudFormationスタック展開
最後にユーザーガイドStep3にある「Launch Solution」をクリックします。
ここでもリージョンを適切なものに選択します。
スタックの詳細を設定します。スタックの名前は「aws-security-hub-automated-response-and-remediation-member」としました。
次にパラメータを決めます。最初のLogGroup Configurationは、CloudTrail用のCloudWatchロググループ名を指定します。これは、CIS3.1-3.14の修復に使用されます。空欄には設定できないため、CISを使用しない場合は仮の名前を入力します。その次はセキュリティ基準用の修復Playbookをロードするかを選択します。こちらも後からyes/noを変更できます。
SecHubAdminAccountには管理アカウントのAWSアカウント番号(12桁)を入力します。
次へと進んでいき、最後の設定レビューにてメッセージが表示されていますので、内容を読んでチェックを入れてスタックの作成を選択します。
スタックの状態が「CREATE_COMPLETE」になるまで待ちます。これで導入完了です。
修復アクション
導入が完了しましたので修復を行います。今回は例としてAWS 基礎セキュリティのベストプラクティスのEC2.2で試します。EC2.2は次の内容です。
VPCのデフォルトセキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックを許可しないようにする必要があります。
デフォルトのセキュリティグループにルールを入れてみて修復処理をしたらどのようになるか見てみましょう。
手動修復の場合
管理アカウントのSecurity HubコンソールからAWS 基礎セキュリティのベストプラクティス→EC2.2のコントロールを選びます。
チェックをつけてアクションから「Remediate with SHARR」を選択します。
画面上部に「検出結果をAmazon CloudWatchEventsへ正常に送信しました」と表示されます。
修復されたか確認します。リソースを選択するとNGとなっている具体的なセキュリティグループのIDが確認できます。
修復する前に取得したキャプチャですが、defaultのセキュリティグループにルールが設定されています。
修復実行後はルールが0になっていました。
Security Hubのコンソールを確認するとワークフローが「NEW」から「RESOLVED」に変わりました。ステータスが「FAILED」のままですが時間が経つと変化します。Security Hubのチェック間隔は12時間おきですので気長に待ちます。
しばらくするとステータスが「PASSED」に変わりました。
以上が手動修復の方法です。
自動修復の場合
自動修復の場合は、管理アカウントのEventBridgeルールを有効化にします。デフォルトは全て無効になっています。AWSマネジメントコンソールからEventBridgeルールの一覧に移動します。手動修復と同じEC2.2で試します。EC2.2でルールを検索するとAFSPBとPCI-DSSのEC2.2が表示されますのでAFSBPの方を選び「有効にする」を選択します。
（ちなみにAFSBP EC2.2とPCI-DSS EC2.2のコントロールの内容は同じです）
メッセージが表示されるので「有効にする」を選択します。
ステータスが「Disabled」から「Enabled」に変わりました。
デフォルトのセキュリティグループに適当なルールを入れます。翌日になって見てみるとルールが消えていることが確認できました。
Security Hubコンソールからも修復されたことを確認できました。
自動修復の方法としては以上です。管理アカウント側で有効/無効を制御するため、メンバーアカウントごとに自動化を制御できない点に注意しましょう。
補足情報
自動修復ソリューションの導入と使い方は以上となります。ここからは補足情報です。
修復内容を知りたい
今回試したコントロールではセキュリティグループのルールが削除されました。修復内容については以下のページに実行されるPlaybookの情報が記載されています。
AFSBP EC2.2を抜粋すると以下のように記載されています。
アクション：検出の対象であるデフォルトのセキュリティグループのすべてのトラフィックインバウンドおよびアウトバウンドルールを削除します
修復機能に対応していないコントロールもある
全てのコントロールが修復に対応している訳ではありません。例えば、ルートユーザーでハードウェアMFAを有効化にする(AFSBP IAM.6)です。仕組み上、対応していないものもコンソールのアクションから修復を実行できてしまいます。
これを押すとハードウェアMFAデバイスが勝手に購入されて自宅に届くのでしょうか。試しに修復を実行してみましょう。
Amazon CloudWatchEvents（EventBridge）へ正常に送信されちゃいました。行方を追ってみます。送信先であるEventBridgeルールの「Remediate_with_SHARR_CustomAction」のターゲットを見るとStepFunctionsに処理を渡していることが分かります。
該当StepFunctionsの実行ログを見ると「成功」になっています。
詳細を確認すると処理フローが確認できます。対応していないコントロールの場合は「No Remediation for Control」に進み何も処理せずに正常終了します。
何も処理が走らず一安心ですが、修復できないものも修復アクションが実行してしまうと、どのコントロールが修復に対応しているか知りたくなります。修復に対応しているリストは先ほど紹介したPlaybook一覧になります。
自動修復ソリューションのアンインストール方法
ユーザガイドに記載されていますのでリンクを以下に記載します。方法は簡単で導入と逆の順番でCloudFormationスタックを削除する形です。スタック削除後もメンバーアカウントに「SO0111-」で始まる名前のIAMロールが残るため手動で削除します。
最後に
AWSで設定の自動修復と言えばAWS Configがまず思いつきますが、セキュリティのベストプラクティスに沿った自動修復ならこのソリューションを使うべきだと分かりました。気をつけたい点としては、修復動作によって意図しない設定変更となる可能性もあります。事前にテスト環境で動作を確認しておくべきです。 今回は割愛しましたが、メンバーアカウントにロードされる修復用プレイブック(SSMドキュメント）は自動修復のコードとして参考になりますので、カスタマイズにもいずれ挑戦したいなと思います。
2
