セキュリティ基準に違反する設定を簡単に修復

「AWS での自動化されたセキュリティ対応」の活用方法のご紹介

2024-09-03

AWS ソリューション紹介

村上涼

2022 年に builders.flash で「AWS での自動化されたセキュリティ対応」というソリューションのご紹介をしました。
AWS Security Hub は、AWS アカウントにおける様々なリソースをセキュリティのベストプラクティスに照らし合わせて自動的にチェックしたり、Amazon GuardDuty や Amazon Inspector などのセキュリティ関連のサービスの結果を集約して表示することができるサービスです。
Security Hub のチェックによってベストプラクティスに沿っていない (失敗) と評価されたリソースの設定の修復は、基本的には手動で行う必要があります。
本ソリューションは、チェックに失敗したリソースの設定の修復の一部を自動化してくれるものです。

2022 年の記事では、単一の AWS アカウントにおいて本ソリューションをデプロイしチェックに失敗したリソースの自動修復を行うまでの流れをご案内しました。
本記事では最近の AWS Security Hub や本ソリューションのアップデートを踏まえつつ、マルチアカウント・マルチリージョン環境における本ソリューションの活用方法についてご紹介をしていこうと思います。

ご注意

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

*ハンズオン記事およびソースコードにおける免責事項 »

この記事のデモを無料でお試しいただけます »

毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。

今すぐ特典を受け取る »

概要

以下は本ソリューションの概要図です。
マルチアカウントの Security Hub の検出結果を Security Hub 管理用の特定のアカウントに集約し、事前に各アカウントに展開しておいた IAM ロールや SSM Automation Runbook を利用して Security Hub 管理用のアカウントから各アカウントにスイッチロールが行われ、チェックに失敗したリソースの修復が実行されます。

本記事で最終的に目指すのは、管理用の単一のアカウントからマルチアカウント・マルチリージョンの Security Hub の設定および自動修復を統一的に行うことができる環境の構築です。

本題に入る前に、最近 (主に 2023 年以降) の Security Hub および本ソリューションのアップデートについて簡単にご紹介します。2022 年の記事を読まれたことがある方も、ここで Security Hub や本ソリューションの新機能にどのようなものがあるか簡単に把握いただければと思います。

AWS Security Hub

セキュリティ標準の追加

Security Hub では AWS が推奨するベストプラクティスや業界標準の規格にもとづいたセキュリティ標準が用意されています。
サポートされるセキュリティ標準は不定期に追加されており、本記事執筆時点では以下の 7 つのセキュリティ標準を Security Hub で利用することが可能です。

AWS Foundational Security Best Practices (FSBP) standard

CIS AWS Foundations Benchmark v1.2.0

CIS AWS Foundations Benchmark v1.4.0

CIS AWS Foundations Benchmark v3.0.0

National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5

Payment Card Industry Data Security Standard (PCI DSS)

AWS Resource Tagging Standard

コントロールの追加

各セキュリティ標準には複数のコントロールが適用されています。
ベストプラクティスに照らし合わせたリソースのチェックはコントロールを使用して行われます。大半のコントロールは、チェックのために AWS Config の機能のひとつである Config ルールを使用しています。
Security Hub では不定期に新しいコントロールの追加が行われており、本記事執筆時点ではおよそ 400 超のコントロールが利用可能です。

統合されたコントロールの検出結果

2023 年 2 月に、統合されたコントロールの検出結果という機能がリリースされました。
本機能のリリース以前は、あるコントロールが複数のセキュリティ標準に対して適用されている場合に、Security Hub では各セキュリティ標準毎に検出結果を生成していました。
例えばハードウェア MFA デバイスがルートユーザーに対して設定されているかどうかをチェックするコントロール IAM.6 は以下の 5 つのセキュリティ標準に共通して適用されていますが、これら 5 つのセキュリティ標準が有効化されている場合には IAM.6 の検出結果が各セキュリティ標準について合計 5 つ生成されるような動作となっていました。

AWS Foundational Security Best Practices (FSBP) standard
CIS AWS Foundations Benchmark v1.2.0
CIS AWS Foundations Benchmark v1.4.0
National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5
Payment Card Industry Data Security Standard (PCI DSS)

本機能を有効化すると、Security Hub は特定のセキュリティ標準に関連付けられない、コントロール毎に単一の検出結果を生成するようになります。
同一の内容の検出結果が複数存在することによるノイズの削減のため、本機能を有効化することが推奨されています。
本機能がリリースされた 2023 年 2 月 23 日よりも以前に Security Hub を有効化していたアカウントでは本機能は無効化されているため、手動で本機能を有効化する必要があります。2023 年 2 月 23 日以降に Security Hub を有効化したアカウントでは、本機能は自動的に有効化されます。
なお、Security Hub はリージョン毎のサービスのため、本機能の有効化は各リージョンで実施する必要があります。

自動化ルール

2023 年 6 月に、自動化ルール という機能がリリースされました。
自動化ルールを利用することで、事前に定義しておいた条件に合致する検出結果に対してさまざまなフィールドの自動的な更新を行うことができます。
後ほど改めて触れますが、本機能は Security Hub と Amazon EventBridge を連携して利用している場面において強力な効果を発揮します。

中央設定

2023 年 11 月に、中央設定 という機能がリリースされました。
中央設定は、Security Hub と AWS Organizations を統合したマルチアカウント・マルチリージョンの組織における一元的な管理を従来よりも大幅に簡潔にするものです。

本機能を使用することで、Security Hub の管理用に指定された特定のアカウントの特定のリージョンからの操作によってマルチアカウント・マルチリージョンの Security Hub の設定を簡易に行うことが可能となります。

Automated Security Response on AWS

Security Hub だけではなく、本ソリューション自身も継続的にアップデートが行われています。
アップデートの詳細については GitHub の Change Log に詳しくまとまっています。自動修復をサポートしているコントロールの追加やあるいは問題の修正などが継続的に進められていることがわかります。

自動修復をサポートしているコントロール

本記事執筆時点における最新バージョンの Automated Security Response on AWS バージョン 2.1.2 では以下のコントロールの自動修復をサポートしています。

AutoScaling.1
CloudFormation.1
CloudFront.1, CloudFront.12
CloudTrail.1, CloudTrail.2, CloudTrail.3, CloudTrail.4, CloudTrail.5, CloudTrail.6, CloudTrail.7
CloudWatch.1, CloudWatch.2, CloudWatch.3, CloudWatch.4, CloudWatch.5, CloudWatch.6, CloudWatch.7, CloudWatch.8, CloudWatch.9, CloudWatch.10, CloudWatch.11, CloudWatch.12, CloudWatch.13, CloudWatch.14
CodeBuild.2, CodeBuild.5
Config.1
EC2.1, EC2.2, EC2.4, EC2.6, EC2.7, EC2.8, EC2.13, EC2.14, EC2.15, EC2.18, EC2.19, EC2.23
IAM.3, IAM.7, IAM.8, IAM.11, IAM.12, IAM.13, IAM.14, IAM.15, IAM.16, IAM.17, IAM.18, IAM.22
KMS.4
Lambda.1
RDS.1, RDS.2, RDS.4, RDS.5, RDS.6, RDS.7, RDS.8, RDS.13, RDS.16
Redshift.1, Redshift.3, Redshift.4, Redshift.6
S3.1, S3.2, S3.3, S3.4, S3.5, S3.6, S3.8, S3.9, S3.11, S3.13
SecretsManager.1, SecretsManager.3, SecretsManager.4
SNS.1, SNS.2
SQS.1
SSM.4

統合されたコントロールの検出結果のサポート

本ソリューションのバージョン 2.0.0 では、統合されたコントロールの検出結果を有効化されたアカウントにおける自動修復をサポートしています。
統合されたコントロールの検出結果機能のリリースからおよそ 1 か月で本ソリューションもそれに追随してアップデートされており、活発に開発されている様子が伺えます。

本題

ソリューションのデプロイ

今回は例として以下のような 3 つのアカウント・3 つのリージョンにおいて本ソリューションを活用できる環境を構築してみます。

アカウント

アカウント A：Organizations 管理アカウント
アカウント B：Organizations メンバーアカウント (Security Hub 委任管理アカウントとして指定)
アカウント C：Organizations メンバーアカウント

Security Hub と Organizations を統合したマルチアカウント管理においては、Organizations 管理アカウントから特定のメンバーアカウントを Security Hub 委任管理アカウントとして指定し、Security Hub 委任管理アカウントでメンバーアカウントの Security Hub の管理を行います。

リージョン

東京リージョン
バージニア北部リージョン
パリリージョン

Security Hub では特定のリージョンにその他のリージョンの検出結果を集約するリージョン集約という機能があります。その他のリージョンの検出結果が集約されるリージョンを集約リージョンと呼びます。
今回は、東京リージョンを集約リージョンに指定しバージニア北部リージョンおよびパリリージョンの検出結果を集約するような構成をとります。

事前準備

本ソリューションの構築にあたっては、いくつかの AWS CloudFormation テンプレートを使用して各アカウント・リージョンにスタックをデプロイします。
ソリューションを使用するためには事前に AWS Config および Security Hub を各アカウント・リージョンで有効化しておく必要があります。
マルチアカウント・マルチリージョンにおける各サービスの有効化の方法を見ていきましょう。

AWS Config の有効化

Security Hub の有効化に先立ち、各アカウント・リージョンで AWS Config を有効化しておきます。
CloudFormation の StackSets を使用してデプロイを行うのが簡単です。
ドキュメントで案内されている CloudFormation StackSets のサンプルテンプレートなどが活用できます。

AWS Config はリージョン毎のサービスですが、グローバル IAM リソース (IAM ユーザー・IAM ロール・IAM ユーザーグループ・IAM ポリシー) については各リージョンで設定を記録することが可能です。同一のリソースの設定が複数のリージョンで記録されることによる重複したコストの発生を回避するために、グローバル IAM リソースの記録は特定のリージョンのみで行うことをベストプラクティスとして推奨しています。

後述する中央設定を使用して構築した Security Hub 環境では集約リージョンにおいてのみグローバル IAM リソースに関するチェックが行われます。そのため、今回は東京リージョンの AWS Config においてのみグローバル IAM リソースを記録するように設定します。

上で案内したサンプルテンプレートではデプロイ時にパラメータとしてグローバル IAM リソースを記録するかどうかを選択できるため、東京リージョンにデプロイする StackSets ではグローバル IAM リソースを記録するように指定し、バージニア北部リージョンおよびパリリージョンにデプロイする StackSets ではグローバル IAM リソースを記録しないように設定しておきます。

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 を利用してデプロイを行うのが簡単です。

本スタックにはネストされたスタックが含まれているため、サービスマネージド型の 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' には 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 コンソールから随時確認することができます。
アカウント B の東京リージョンの Step Functions コンソールで SO0111-SHARR-Orchestrator という名前のステートマシンを選択し、実行のフローチャートを「グラフビュー」で表示できます。
現在処理は順調に進んでおり、Wait for Remediation というステップにいることから、修復処理の待機中であることが読み取れます。

クリックすると拡大します

しばらく待つと、自動修復が無事完了しました。

クリックすると拡大します

上のように自動修復の実行の様子のフローチャートを確認することで、仮に何らかの理由で自動修復が失敗した場合にも、どのステップにおいて処理が失敗したかを簡単に絞り込むことができます。

アカウント 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 ルールを事前に有効化しておきます。
例えば、S3.5 に対応する EventBridge ルールの名前は SC_2.0.0_S3.5_AutoTrigger となっています。

{
  "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"]
      }
    }
  }
}

クリックすると拡大します

Security Hub のコントロールは定期的にチェックを行い、チェックの結果がイベントとして EventBridge に送信されます。
コントロールのタイプによって定期的なチェックの周期は異なりますが、コントロールに対応する EventBridge ルールが有効化されていれば、少なくとも 24 時間に 1 回は自動的に自動修復が開始されます。
いち早くリソースの修復を行いたい場合は手動で開始、そこまで急ぎではない場合は EventBridge ルールを有効化しておく、といった使い分けができるでしょう。

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 も日々機能の追加などが行われているため、今後はさらに本ソリューションが活躍できる場面が増えていくのではないかと個人的に期待もしています。

本記事の内容がマルチアカウント環境におけるセキュリティ統制を向上させるうえでお役に立てば幸いです。

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

メンバー特典を受け取る »

筆者プロフィール

村上涼
アマゾンウェブサービスジャパン合同会社
クラウドサポートエンジニア

クラウドサポートエンジニアとして、主に Security Hub、GuardDuty などセキュリティサービスに関連する技術的なお問い合わせへの対応を行っています。
前職はセキュリティベンダーで、マルウェア解析や脆弱性診断などの業務に携わっていました。
好きな AWS サービスは Security Hub です。
最近の楽しみは会社の同僚と将棋の団体戦に出ることです。

ツイート »

はてブ »

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫

5 ステップでアカウント作成できます

無料サインアップ ≫

ご不明な点がおありですか?

日本担当チームへ相談する

「AWS での自動化されたセキュリティ対応」の活用方法のご紹介

ツイート »

シェア »

はてブ »

この記事のデモを無料でお試しいただけます »

概要

AWS Security Hub

Automated Security Response on AWS