はじめに
こんにちは。クラウドサポートエンジニアの村上 涼です。
2022 年に builders.flash で 「AWS での自動化されたセキュリティ対応」というソリューションのご紹介 をしました。
AWS Security Hub は、AWS アカウントにおける様々なリソースをセキュリティのベストプラクティスに照らし合わせて自動的にチェックしたり、Amazon GuardDuty や Amazon Inspector などのセキュリティ関連のサービスの結果を集約して表示することができるサービスです。
Security Hub のチェックによってベストプラクティスに沿っていない (失敗) と評価されたリソースの設定の修復は、基本的には手動で行う必要があります。
本ソリューションは、チェックに失敗したリソースの設定の修復の一部を自動化してくれるものです。
2022 年の記事では、単一の AWS アカウントにおいて本ソリューションをデプロイしチェックに失敗したリソースの自動修復を行うまでの流れをご案内しました。
本記事では最近の AWS Security Hub や本ソリューションのアップデートを踏まえつつ、マルチアカウント・マルチリージョン環境における本ソリューションの活用方法についてご紹介をしていこうと思います。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
builders.flash メールメンバー登録
概要
以下は本ソリューションの概要図です。
マルチアカウントの Security Hub の検出結果を Security Hub 管理用の特定のアカウントに集約し、事前に各アカウントに展開しておいた IAM ロールや SSM Automation Runbook を利用して Security Hub 管理用のアカウントから各アカウントにスイッチロールが行われ、チェックに失敗したリソースの修復が実行されます。
本記事で最終的に目指すのは、管理用の単一のアカウントからマルチアカウント・マルチリージョンの Security Hub の設定および自動修復を統一的に行うことができる環境の構築です。
本題に入る前に、最近 (主に 2023 年以降) の Security Hub および本ソリューションのアップデートについて簡単にご紹介します。2022 年の記事を読まれたことがある方も、ここで Security Hub や本ソリューションの新機能にどのようなものがあるか簡単に把握いただければと思います。
概略図
AWS Security Hub
セキュリティ標準の追加
Automated Security Response on AWS
本題
ソリューションのデプロイ
事前準備
Security Hub の有効化
先ほど紹介した中央設定を使用し、3 アカウント 3 リージョンで Security Hub を有効化していきます。※以降のスクリーンショットでは、アカウント ID などの情報を一部マスクしています。
1) アカウント A (Organizations 管理アカウント) の東京リージョンの Security Hub コンソール [一般] からアカウント B を Security Hub 委任管理アカウントとして指定します。
中央設定を開始
2) アカウント B (Security Hub 委任管理アカウント) の東京リージョンの Security Hub コンソール [設定] から「中央設定を開始」を選択します。
リージョン選択
3) ホームリージョンとして東京リージョン、リンクされたリージョンとしてバージニア北部リージョンおよびパリリージョンを選択し、「確認して続行」を選択します。
中央設定では、Security Hub 委任管理アカウントのホームリージョンからメンバーアカウントのホームリージョンおよびリンクされたリージョンの Security Hub の設定を行うことができます。
設定ポリシー作成
4) 設定ポリシーを作成し適用します。デフォルトで選択されている設定タイプのまま、「次へ」を選択します。
中央設定では、設定ポリシー というリソースを用いてメンバーアカウントの Security Hub の設定を行います。
設定ポリシーは、以下のような Security Hub の設定に関する情報を含んでいます。
Security Hub の有効化・無効化
セキュリティ標準の有効化・無効化
コントロールの有効化・無効化
コントロールのパラメータのカスタマイズ (一部コントロールのみ)
設定ポリシーをメンバーアカウントに関連付けることで、メンバーアカウントのホームリージョンおよびリンクされたリージョンにおいて設定ポリシーの内容にもとづいた Security Hub の設定が自動的に行われます。
設定ポリシーは独自の要件にもとづいて細かく設定することも可能ですが、今回は中央設定を開始する際にデフォルトで表示される、「セキュリティ標準 AWS 基礎セキュリティのベストプラクティス v1.0.0 (AWS Foundational Security Best Practices (FSBP) standard) をすべてのアカウントに対して有効化する」設定ポリシーをそのまま選択することにします。
ポリシーを作成して適用
5) これから適用する設定ポリシーについて確認画面が表示されます。「ポリシーを作成して適用」を選択します。
設定ポリシーの適用完了
6) 設定ポリシーの適用が開始されるとステータスが「保留中」となり、無事適用が成功するとステータスが「成功」と表示されます。
裏側の処理について
この手順までを実施すると、実は裏側では以下の処理が自動的に行われています。
アカウント A, B, C の東京リージョン、バージニア北部リージョン、パリリージョンにおける Security Hub およびセキュリティ標準 AWS Foundational Security Best Practices (FSBP) standard の有効化
バージニア北部リージョンおよびパリリージョンにおけるアカウント B の Security Hub 委任管理アカウントとしての指定
東京リージョン、バージニア北部リージョン、パリリージョンにおけるアカウント A, C のメンバーアカウントとしての関連付け
東京リージョンを集約リージョン、リンクされたリージョンをバージニア北部リージョンおよびパリリージョンとするリージョン集約の設定
これにより、アカウント B の東京リージョンの Security Hub にはアカウント A, B, C の東京リージョン、バージニア北部リージョン、パリリージョンの検出結果が表示される状態となっています。
統合されたコントロールの検出結果を有効化
7) アカウント B の東京リージョン、バージニア北部リージョン、パリリージョンで統合されたコントロールの検出結果を有効化します。
CloudFormation テンプレートによるソリューションのデプロイ
各アカウント・リージョンで AWS Config および Security Hub の有効化ができたところで、CloudFormation テンプレートを用いて以下の 3 種類のスタックをデプロイしていきます。
今回の構成における Security Hub 管理アカウントは Security Hub 委任管理アカウントであるアカウント B です。
メンバーアカウントは自動修復を行いたい対象のアカウントを指します。今回はすべてのアカウントで自動修復が実行できる環境の構築を目指すため、メンバーアカウントはアカウント A, B, C すべてとなります。
各アカウント・リージョンに最終的にデプロイされるスタックは以下の図のようになります。
デプロイされるスタック
Security Hub 管理アカウント用のスタック
Security Hub 管理アカウント用のスタックは、本ソリューションのコアとなるリソースを Security Hub 管理アカウントに作成するためのものです。
本スタックのデプロイにより、Security Hub で検出結果が生成・更新された際に EventBridge に送信されるイベントを受け取る EventBridge ルールやそのターゲットとなる AWS Step Functions ステートマシンなどのリソースが作成されます。
本スタックは、Security Hub 管理アカウントの集約リージョンにのみデプロイします。今回の構成では、アカウント B の東京リージョンが該当します。
ドキュメントでリンクされている Amazon S3 URL をテンプレートとして指定し、デプロイを行います。
スタックの詳細を指定
スタックのパラメータの設定画面では、‘Consolidated Control Findings Playbook’ と ‘Security Standard Playbooks’ という 2 種類の Playbook が表示されます。統合されたコントロールの検出結果を有効化している場合は ‘LoadSCAdminStack’ を yes 、無効化している場合は有効化する予定のセキュリティ標準に対応する Stack を yes に選択します。今回は AWS が推奨している通り統合されたコントロールの検出結果を有効化するため ‘LoadSCAdminStack’ を yes に選択します。
メンバーアカウント用のスタック
メンバーアカウント用のスタックは、リソースの修復を行うために必要となる Systems Manager Automation runbook などのリソースをメンバーアカウントに作成するためのものです。
本スタックは、自動修復を行いたいすべてのアカウント・リージョンにデプロイする必要があります。このような要件においては、StackSets を利用してデプロイを行うのが簡単です。
IAM ロールを作成
本スタックにはネストされたスタックが含まれているため、サービスマネージド型の StackSets ではデプロイができません。そのため、事前に各アカウントに必須となる IAM ロール AWSCloudFormationStackSetExecutionRole を作成しておき、さらにセルフマネージド型の StackSets でスタックのデプロイを行うアカウント（どのアカウントでも構いません）に IAM ロール AWSCloudFormationStackSetAdministrationRole を作成しておく必要があります。
各 IAM ロールは以下のスタックをデプロイすることで作成できます。
筆者が環境構築を行う際は、Organizations 管理アカウントであるアカウント A からサービスマネージド型の StackSets を利用して AWSCloudFormationStackSetExecutionRole のスタックをアカウント B, C にデプロイし、その後アカウント A 自身に AWSCloudFormationStackSetExecutionRole および AWSCloudFormationStackSetAdministrationRole のスタックをデプロイしました。この場合、セルフマネージド型の StackSets を利用したデプロイはアカウント A から行うことになります。
スタックのパラメータを指定
さて、セルフマネージド型の StackSets を利用してデプロイを行う準備が整ったところで StackSets を使用してメンバーアカウント用のスタックをデプロイしていきます。
スタックをデプロイする際にはいくつかパラメータを指定します。
'LogGroup Configuration' には CloudTrail 証跡で配信先に指定している CloudWatch Logs ロググループの名前を入力します。これは、CloudWatch 関連のコントロール（CloudWatch.1 から CloudWatch.14）の修復のために必要となるパラメータです。
筆者の環境では 'aws-cloudtrail-logs' という名前のロググループに証跡から CloudTrail イベントを配信するように設定していたため、この名前を入力しました。CloudWatch 関連のコントロールの自動修復を行う予定が無い場合は、適当な名前を入力して操作を進めて問題ありません。
'Consolidated control finding Playbook' および 'Security Standard Playbooks' では、Security Hub 管理アカウント用のスタックをデプロイしたときと同様に 'LoadSCAdminStack' を yes 、その他を no に選択します。
'SecHubAdminAccount' には Security Hub 委任管理アカウントであるアカウント B のアカウント ID を入力します。
スタックをデプロイ
東京リージョン、バージニア北部リージョン、パリリージョンを選択し、スタックをデプロイします。
メンバーアカウントの IAM ロール用のスタック
メンバーアカウントの IAM ロール用のスタックは、自動修復を実行するために必要となる権限が付与された IAM ロールを各アカウントに作成するためのものです。本スタックは自動修復を行いたいすべてのアカウントにデプロイする必要があります。
テンプレートを選択
本スタックによって作成されるリソースは IAM ロールのみのため、各アカウントでは任意のひとつのリージョンにおいてのみデプロイを行えば良いです。わかりやすさの観点から、Security Hub の集約リージョンにおいてデプロイを行うことが推奨されています。
筆者が環境構築を行う際は、メンバーアカウント用のスタックをデプロイした際と同様にアカウント A からセルフマネージド型の StackSets を利用してスタックのデプロイを行いました。
パラメータ 'SecHubAdminAccount' の設定
パラメータ 'SecHubAdminAccount' には Security Hub 委任管理アカウントであるアカウント B のアカウント ID を入力します。
実践
AWS Config と Security Hub の有効化および本ソリューションのデプロイが各アカウント・リージョンで完了しました。さっそくリソースの自動修復を試していきましょう。
まずは S3 バケットへのアクセス時に SSL を使用するように要求しているかどうかをチェックするコントロール S3.5 の自動修復を手動で開始してみます。
リソースの検出結果を確認
アカウント C のバージニア北部リージョンに S3 バケット builders-flash-sharr-2024 を作成します（当該 S3 バケットは現在は削除済みです）。
S3.5 では特定の要件を満たすバケットポリシーが設定されているかどうかをチェックしています。作成直後の S3 バケットには特にバケットポリシーが設定されていないため、チェックに失敗します。
しばらく待つと、以下のようにアカウント B の東京リージョンの Security Hub コンソールに S3 バケット builders-flash-sharr-2024 が S3.5 で FAILED と評価されている検出結果が表示されます。
自動修復を開始
検出結果にチェックを入れ「アクション」から Remediate with ASR を選択します。自動修復が開始された旨のメッセージがコンソール上部に表示されます。
Step Functions コンソールで経過確認
自動修復が行われている際の経過は Step Functions コンソールから随時確認することができます。
アカウント B の東京リージョンの Step Functions コンソールで SO0111-SHARR-Orchestrator という名前のステートマシンを選択し、実行のフローチャートを「グラフビュー」で表示できます。
現在処理は順調に進んでおり、Wait for Remediation というステップにいることから、修復処理の待機中であることが読み取れます。
自動修復完了
しばらく待つと、自動修復が無事完了しました。
このように自動修復の実行の様子のフローチャートを確認することで、仮に何らかの理由で自動修復が失敗した場合にも、どのステップにおいて処理が失敗したかを簡単に絞り込むことができます。
S3 バケット builders-flash-sharr-2024 を確認
アカウント C に作成した S3 バケット builders-flash-sharr-2024 を確認すると、このように SSL が使用されていない場合にはアクセスを拒否するようなバケットポリシーが設定されています。
バケットポリシー
以下のようなアクセスを拒否するバケットポリシーが設定されています。
{
"Version": "2012-10-17",
"Id": "BucketPolicy",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::builders-flash-sharr-2024",
"arn:aws:s3:::builders-flash-sharr-2024/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}検出結果を確認
FAILED と評価されていた検出結果も PASSED に変わりました。
EventBridge ルールを有効化
今回は手動で自動修復を行いましたが、これを自動的に開始したい場合は各コントロールに対応する EventBridge ルールを事前に有効化しておきます。
例えば、S3.5 に対応する EventBridge ルールの名前は SC_2.0.0_S3.5_AutoTrigger となっています。
Security Hub のコントロールは定期的にチェックを行い、チェックの結果がイベントとして EventBridge に送信されます。
コントロールのタイプによって定期的なチェックの周期は異なりますが、コントロールに対応する EventBridge ルールが有効化されていれば、少なくとも 24 時間に 1 回は自動的に自動修復が開始されます。
いち早くリソースの修復を行いたい場合は手動で開始、そこまで急ぎではない場合は EventBridge ルールを有効化しておく、といった使い分けができるでしょう。
EventBridge ルール
イベントパターンの内容
{
"detail-type": ["Security Hub Findings - Imported"],
"source": ["aws.securityhub"],
"detail": {
"findings": {
"Compliance": {
"Status": ["FAILED", "WARNING"]
},
"GeneratorId": ["security-control/S3.5"],
"RecordState": ["ACTIVE"],
"Workflow": {
"Status": ["NEW"]
}
}
}
}対象リソースの検出結果のワークフローステータスを変更
EventBridge ルール SC_2.0.0_S3.5_AutoTrigger のイベントパターンは S3.5 のチェックで FAILED あるいは WARNING と評価された場合に送信されるイベントに合致するものとなっており、これに合致するイベントを受信するとイベントがターゲットの Step Functions ステートマシンに渡され、自動修復が開始されます。
なお、運用上の事情などから一部のリソースについては意図的にコントロールに準拠しないような設定にしている場合もあるかと思います。
そのような場合には、対象リソースの検出結果のワークフローステータスを SUPPRESSED に変更するとよいです。
イベントパターンはワークフローステータスが NEW のイベントのみに合致するように設定されているため、ワークフローステータスを SUPPRESSED に設定されたリソースについては自動修復は行われません。
自動化ルールを作成
次に、自動化ルールを使用して特定の条件に当てはまるリソースのワークフローステータスを自動的に SUPPRESSED に変更し、自動修復の対象外とする方法をご紹介します。
ここでは、特定のポートに対してインバウンドルールで無制限のアクセスが許可されていないことをチェックするコントロール EC2.19 を題材とします。
はじめに、次のように「EC2.19 のチェックで FAILED と評価されており、なおかつ automated-response: no というタグがセキュリティグループに付与されている場合には検出結果のワークフローステータスを SUPPRESSED に変更する」ような自動化ルールをアカウント B の東京リージョンで作成します。
無制限のインバウンドアクセスを許可するセキュリティグループを作成
さらに、EC2.19 に対応する EventBridge ルール SC_2.0.0_EC2.19_AutoTrigger を有効化し、自動修復が自動的に開始される状態にしておきます。
さて、アカウント A, B, C いずれかの東京リージョンでポート 22 番に対して無制限のインバウンドアクセスを許可するようなセキュリティグループを作成してみましょう。作成時に、automated-response: no というタグをセキュリティグループに付与しておきます。
検出結果を確認
しばらく待つと、検出結果が生成されます。先ほど作成した自動化ルールの作用により、ワークフローステータスはデフォルトの NEW ではなく SUPPRESSED となっています。
ワークフローステータスが NEW ではないため、チェック時に Security Hub から EventBridge に送信されたイベントは EventBridge ルール SC_2.0.0_EC2.19_AutoTrigger のイベントパターンに合致せず、この検出結果のもととなったセキュリティグループに対する自動修復は行われません。
もし automated-response: no というタグが付与されていないセキュリティグループが EC2.19 のチェックで FAILED と評価された場合には、原因となっているインバウンドルールが自動修復によって削除される動作となります。
運用上の理由から修復が不要なリソースに関連する検出結果のワークフローステータスを都度 SUPPRESSED に変更することは作業の負荷が高く、また抜け漏れが生じる可能性もあると思います。自動化ルールでは事前に定義した様々な条件にもとづいて自動的に検出結果のフィールドを更新することが可能なため、ぜひ運用の効率化に活用してみてください。
なお、自動化ルールは作成されたリージョンの検出結果に対してのみ作用するため、すべてのリージョンの検出結果に対して作用させたい場合はすべてのリージョンでのルールの作成が必要となります。
まとめ
本記事では、マルチアカウント・マルチリージョンにおいて Automated Security Response on AWS をデプロイし統一的な Security Hub の管理やリソースの自動修復を行うまでの流れをご紹介しました。
StackSets を使用した本ソリューションのデプロイと中央設定、自動化ルールなどを使用した Security Hub のマルチアカウント管理を組み合わせることで、Organizations 組織内における一貫した統制が簡潔に実現できることがお分かりいただけたと思います。
本ソリューションはオープンに開発が継続されており、また Security Hub も日々機能の追加などが行われているため、今後はさらに本ソリューションが活躍できる場面が増えていくのではないかと個人的に期待もしています。
本記事の内容がマルチアカウント環境におけるセキュリティ統制を向上させるうえでお役に立てば幸いです。
村上 涼
前職はセキュリティベンダーで、マルウェア解析や脆弱性診断などの業務に携わっていました。
好きな AWS サービスは Security Hub です。
最近の楽しみは会社の同僚と将棋の団体戦に出ることです。
