[アップデート]更にアップデートしたSecurity Hubの自動修復ソリューション(1.5.0)を試してみた

#AWS Security Hub

#AWS

杉金晋

2022.06.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。
AWS Security Hubの自動修復ソリューションがバージョンアップしました！（v1.4.2->1.5.0）
紹介ページは以下のリンクをご覧ください。

改めて概要から紹介して何が変わったのかを触れつつ、導入方法と使い方を説明します。

Security Hubの自動修復ソリューションとは

Security Hubを利用することで、利用中のAWS環境がセキュリティのベストプラクティスに従っているかをチェックしてくれます。チェックNGとして検知したリソースの設定修復を行ってくれるのがこのソリューションです。修復処理は自動もしくは手動で行います。手動で修復する場合は、Security Hubのコンソールから対象コントロールを選択して実行します。自動で修復させる場合はEventBridgeルールを有効化にします。有効化することで検知とともに修復も行われます。

どのような仕組みで動いているかは下図が参考になります。

– 図: AWS Security Hub Automated Response and Remediation | Implementations | AWS Solutions

管理アカウントとメンバーアカウントのマルチアカウント構成になっており、管理アカウントで検出を集約して、メンバーアカウントでNGを検出したら管理アカウントからメンバーアカウントに対して修復処理を実行します。

バージョンアップ内容

前バージョン(1.4.2)からの変更点です。

Added

New remediations - see Implementation Guide

Changed

Improved cross-region remediation using resource region from Resources[0].Id

Added custom resource provider for SSM documents to allow in-place stack upgrades

– 引用: Change Logより抜粋

主には新しい修復機能の追加で、以前のSecurity Hubアップデートで追加されたコントロールに対応したものです。参照先のImplementation Guideのリンクは以下です。（リンク先はpdf）

Implementation Guideを見ても具体的に何が追加されたかのリストが見当たらなかったため、GitHubのソースコードから更新差分を確認しました。以下のコントロールが新しく追加されたもののようです。

AWS 基礎セキュリティのベストプラクティス v1.0.0(AFSBP)
- CloudTrail.4
- CloudTrail.5
- CodeBuild.2
- IAM.3
- S3.4
- S3.5
CIS AWS Foundations Benchmark v1.2.0
- 1.4
PCI DSS v3.2.1
- CodeBuild.2
- EC2.5
- KMS.1
- S3.4
- S3.5

Security Hubアップデートで追加されたコントロールについては以下の記事で一部紹介しています。

新しい修復機能の追加の他に、クロスリージョンの修復改善とSSMドキュメント用のカスタムリソースプロバイダを追加して、CloudFormationスタックのインプレースアップグレードを可能にしました。

やってみる：導入編

導入方法は前バージョン(1.4.2)と同じで、3種類のCloudFormationスタックを作成します。複数のメンバーアカウントに展開する場合はCloudFormation StackSetsを使用します。

シングルアカウント向け手順では、冒頭で紹介した構成図のadminアカウントとmemberアカウントの機能がひとつのアカウント上で構成されます。マルチアカウント向け手順では、ひとつのadminアカウントと複数のmemberアカウントが存在する形です。

前提条件

事前準備として、以下の前提条件を満たす必要があります。

管理アカウントとメンバーアカウントでSecurity Hubを有効にしていること
古いバージョンの自動修復ソリューションを導入済みの場合はアンインストールを行う

導入Step 1. 管理アカウントでCloudFormationスタック展開

まずは管理アカウントのAWSマネジメントコンソールにログインして、ユーザーガイドStep1にある「Launch Solution」をクリックします。

CloudFormationスタックの作成画面に移動します。デフォルトで選択されているリージョンが「バージニア北部」のため、設定したいリージョンに変更します。今回はアジアパシフィック（東京）に設定しました。下図のスタック作成画面は何も変更せず「次へ」進みます。

スタックの詳細を設定していきます。スタックの名前はデフォルトで入力されたものをそのまま使用します。必要に応じて修正ください。続いてその下にあるパラメータを決めます。

Security Standard Playbooks：各セキュリティ基準用のEventBridgeルールをロードするかの選択です。Security Hubで有効化にしているセキュリティ基準をもとにyes/noを選択する形が良いですが、とりあえず全部yesにして全ルールをロードしてもエラーは起きません。また、後からyes/noを変更可能です。
ReuseOrchestratorLogGroup：過去にこのソリューションを導入していたことがあればyesを選択します。今回は新規に導入するためnoを選択します。

次へ進むと、スタックオプションの設定画面が表示されますので必要に応じて設定ください。今回は特に何も設定しません。

下にスクロールして、次へ進みます。

レビュー画面に移動しますので、設定内容に間違いがないかを確認しながら下にスクロールします。

画面最下部に下図のようなメッセージが表示されていますので、内容を読んで問題なければチェックを入れて「スタックの作成」を選択します。

スタックの作成が開始されました。「イベント」タブから進捗状況の詳細が確認できます。右側に更新ボタンがありますので、適宜押してください。

「スタックの情報」タブにあるステータスが「CREATE_COMPLETE」になったらスタックの作成完了です。

導入Step 2. メンバーアカウントで修復用IAMロールを作成

管理アカウント側の設定は完了です。続いてはメンバーアカウントのAWSマネジメントコンソールにログインして、ユーザーガイドStep2にある「Launch Solution」をクリックします。
複数のメンバーアカウントに展開する場合は、CloudFormationテンプレートをStackSetsで展開します。以下に記載する手順はシングルアカウントで展開する場合の手順です。

step1と同様にスタックの作成画面が表示されます。ここでも適切なリージョンに切り替えた上で次へと進みます。

スタックの詳細を設定します。スタックの名前はデフォルトのままとしました。パラメータには管理アカウントのAWSアカウント番号(12桁)を入力します。

次へ進むと、スタックオプション画面に移動します。特に設定せず進みます。

下にスクロールして、次へ進みます。

レビュー画面に移動しますので、設定内容に間違いがないかを確認しながら下にスクロールします。

画面最下部に下図のようなメッセージが表示されていますので、内容を読んで問題なければチェックを入れて「スタックの作成」を選択します。

導入Step 1と同様にスタックの状態が「CREATE_COMPLETE」になるまで待ちます。

導入Step 3. メンバーアカウントでCloudFormationスタック展開

ユーザーガイドStep3にある「Launch Solution」をクリックします。複数のメンバーアカウントに展開する場合は、CloudFormationテンプレートをStackSetsで展開します。以下に記載する手順はシングルアカウントで展開する場合の手順です。

スタックの作成画面が表示されます。ここでも適切なリージョンに切り替えた上で次へと進みます。

スタックの詳細を設定します。スタックの名前はデフォルトのままとしました。下にスクロールしてパラメータを設定します。

次にパラメータを決めます。

LogGroup Configuration：CloudTrail用のCloudWatchロググループ名を指定します。これは、CIS3.1-3.14の修復に使用されます。空欄には設定できないため、CISを使用しない場合は仮の名前を入力します。
Playbooks：セキュリティ基準用の修復Playbookをロードするかを選択します。こちらも後からyes/noを変更できます。
Create S3 Bucket For Redshift Audit Logging：AFSBP RedShift.4修復用のS3バケットを作成するかどうかを選択します。
Sec Hub Admin Account：管理アカウントのAWSアカウント番号(12桁)を入力します。

次へ進むと、スタックオプション画面に移動します。特に設定せず進みます。

下にスクロールして、次へ進みます。

レビュー画面に移動しますので、設定内容に間違いがないかを確認しながら下にスクロールします。

画面最下部に下図のようなメッセージが表示されていますので、内容を読んで問題なければチェックを入れて「スタックの作成」を選択します。

「スタックの情報」タブにあるステータスが「CREATE_COMPLETE」になったらスタックの作成完了です。全部の機能をyesにしていると15〜20分ほどかかりました。気長に待ちましょう。

以上で導入完了です。

やってみる：修復アクション編

導入が完了しましたので修復を行います。今回は例としてAWS 基礎セキュリティのベストプラクティスS3.5で試します。S3.5は次の内容です。

S3 バケットでは、Secure Socket Layer を使用するためのリクエストの要求が必要です

– 引用: AWS Foundational Security Best Practices コントロール#S3.5

適当なS3バケットを作成してみて修復処理をしたらどのように設定変更されるか見てみましょう。

手動修復の場合

管理アカウントのSecurity HubコンソールからAWS 基礎セキュリティのベストプラクティス→S3.5のコントロールを選びます。

チェックをつけてアクションから「Remediate with SHARR」を選択します。

画面上部に「検出結果をAmazon CloudWatchEventsへ正常に送信しました」と表示されます。

対象S3バケットポリシーを見てみます。空のバケットポリシーに内容が記載されていました。

画像だと分かりにくいと思いますのでバケットポリシーを以下に記載します。

{
    "Version": "2012-10-17",
    "Id": "BucketPolicy",
    "Statement": [
        {
            "Sid": "AllowSSLRequestsOnly",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::sugi-test-bucket-20220615",
                "arn:aws:s3:::sugi-test-bucket-20220615/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

SecureTransportがfalseの場合はアクセスを拒否する内容が入っていますね。
Security Hubのコンソールを確認するとワークフローが「NEW」から「RESOLVED」に変わりました。ステータスが「FAILED」のままですが時間が経つと変化します。Security Hubのチェック間隔は12時間おきですので気長に待ちます。

しばらくするとステータスが「PASSED」に変わりました。

以上が手動修復の方法です。

自動修復の場合

自動修復の場合は、管理アカウントのEventBridgeルールを有効化にします。AWSマネジメントコンソールからEventBridgeルールの一覧に移動します(イベントバスはデフォルト)。手動修復と同じS3.5で試します。S3.5で検索して「AFSBP_S3.5_AutoTrigger」を選び「有効化」を選択します。

ステータスが「Enabled」に変わりました。

手動修復ではS3のバケットポリシーが空の状態で試しましたが、既に何らかのポリシーがあった場合にどうなるか見てみましょう。一旦以下のようなバケットポリシーを入れてみます。これでどうなるか。

{
    "Version": "2012-10-17",
    "Id": "BucketPolicy",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/test-user"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::sugi-test-bucket-20220615"
        },
        {
            "Sid": "Statement2",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/test-user"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sugi-test-bucket-20220615/*"
        }
    ]
}

バケットポリシーを上記内容に変更して15分とかからず修復されていました。結果を見てみます。

画像だと分かりにくいため、更新されたバケットポリシーを記載します。以下のようにいい感じに追記してくれました。すごいですね！

{
    "Version": "2012-10-17",
    "Id": "BucketPolicy",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/test-user"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::sugi-test-bucket-20220615"
        },
        {
            "Sid": "Statement2",
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/test-user"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sugi-test-bucket-20220615/*"
        },
        {
            "Sid": "AllowSSLRequestsOnly",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::sugi-test-bucket-20220615",
                "arn:aws:s3:::sugi-test-bucket-20220615/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

自動修復の方法としては以上です。管理アカウント側で有効/無効を制御するため、メンバーアカウントごとに自動化を制御できない点に注意しましょう。

補足情報

修復プレイブック一覧

Security Hubのすべてのコントロールで修復に対応しているわけではありません。修復に対応しているものは以下のリストから確認できます。修復動作によって意図しない設定変更となる可能性もありますので、事前の内容確認やテスト環境での動作確認を行っておくとよいでしょう。

最後に

バージョンアップしたSecurity Hubの自動修復ソリューションを試してみました。新しいコントロールに対応してくれて待望のアップデートでした。導入方法は前バージョンと同じ3つのCloudFormationスタックを実行するだけで簡単です。以前のバージョンだとCloudFormationのスタック名が空欄で名前を何にしようかなと悩んだ記憶がありますので、名前が既に入力されているのは小さな変更ながらありがたいです。今後より活用されるケースが増えることを願ってます！