[アップデート]Security Hub 自動修復のソリューションを Organizations 組織全体に展開してみる

はじめに

大阪オフィスの川原です。

2020/08/12 に Security Hub で自動修復可能なソリューションが一般提供されました。

Security Hub を使った自動修復の仕組みは CloudWatch Eventルールと Lambda(or Systems Manager オートメーション) を組み合わせて実現できます。 が、 結構な作り込みが必要です。

今回提供されたソリューションにより上記作り込みの手間が省けます。 AWS提供の Service Catalog 製品を展開して、すぐに利用できます。

また マルチアカウントにも対応しており、Security Hubマスターアカウントからメンバーアカウントに対して 修復を実施できます。

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

現段階(2020/08/12) では CISセキュリティ標準の一部のセキュリティチェック項目に対して、 修復の仕組みが提供されています。

すでに以下検証ブログがあります。

本ブログでは マルチアカウント(Organizations)環境 でこのソリューションを展開して、動作を確かめてみました。

展開してみる

ソリューションのページとデプロイ方法のドキュメントは以下にあります。

「デプロイ方法のドキュメント通りに行う」、「すでに検証ブログで手順が丁寧に説明されている」ことなので、 マルチアカウント展開部分のみ焦点を当てて、他は簡素に説明します。

以下 手順通りに進めます。

• Step 1. Launch the stack
• Step 2. Configure service catalog portfolio permissions
• Step 3. Deploy the playbook(s)
• Step 4. Deploy the solution permissions

Step.1,2,3 はシングルアカウント環境と実施内容一緒です。Security Hubマスターアカウント上で進めていきます。 Step.4 のみマルチアカウント環境の場合、考慮する点/追加作業があります。

前提

• Security Hub マスターアカウント/メンバーアカウントの関係を構築済み

Step 1. Launch the stack

Security Hubのマスターアカウント(東京リージョン) で実施していきます。

デプロイ方法のドキュメントから提供されている CloudFormationスタックを作成します。

※ 右上のリージョンが 東京 になっていること確認しましょう。

パラメータの指定は無いのでこのまま展開しましょう。

Step 2. Configure service catalog portfolio permissions

スタックの [リソース] から SCPlaybooks を選択して Service Catalog のページに行きましょう。

このポートフォリオを扱えるIAMグループ/ロール/ユーザーを追加します。 ポートフォリオの [グループ、ロール、およびユーザー] から追加しましょう。 (自分自身のIAMロールを追加しました)

Step 3: Deploy the playbook(s)

Service Catalog の [製品] ページに移動します。

CIS 項目があるはずです。 [製品の起動] をしましょう。

名前を適当に ( CIS-v-1-2-0 など)　決めて、パラメータはひとまず全て DISABLED にして、 起動しましょう。

利用可能 になれば OKです。

Step 4. Deploy the solution permissions

修復の実行権限を作成します。事前にデプロイ方法のドキュメントからテンプレートをダウンロードしておきましょう。

テンプレートの中身は 「Security Hub マスターアカウントから各メンバーアカウントへ修復アクションを行う際に必要な IAMロール」です。

組織内全アカウントに必要なIAMロールです。以下手順で展開します。

• Organizations マスターアカウント からスタックセット展開
• Organizations マスターアカウント にスタック展開

▼ Organizations マスターアカウントからスタックセット展開

[スタックセットの作成] へ進み、先程保存したテンプレートをアップロードします。

パラメータは Security Hubのマスターアカウント AWSアカウントIDを入力します。

[サービスマネージドアクセス許可] で展開します。 [組織へのデプロイ] を選択します。自動デプロイ、アカウント削除の操作は環境に合わせて、適宜変更してください。

東京リージョンに指定して、展開しましょう。

組織内全アカウントへの展開が完了するまで待ちます。

▼ Organizations マスターアカウントにスタック展開

同じパラメータで Organizationsマスターアカウントにスタック展開しましょう。

これで (Organizationsマスターアカウント含む)組織内全アカウントに IAMロールの展開が完了しました。

修復してみる

現時点で可能な修復は以下のとおり。

• CIS1.3, 1.4: 90日を超えた未使用IAMキーの削除
• CIS1.5, 1.11: パスワードポリシーを強固にする
• CIS2.2: CloudTrail ログのファイル検証を有効にする
• CIS2.3: CloudTrail ログバケットをプライベートにする
• CIS2.4: CloudTrailの CloudWatch Logs を有効化する
• CIS2.6: CloudTrail ログバケットのアクセスロギングを有効化する
• CIS2.8: CMKのキーローテーションを有効にする
• CIS2.9: すべてのVPCのフローログを有効化する
• CIS4.1, 4.2: SSH, RDP のインバウンド全許可を取り消す
• CIS4.3: デフォルトセキュリティグループから全てのルールを消す

今回は CISのセキュリティ標準の 1項目、 「[CIS4.3]すべてのVPCのデフォルトセキュリティグループがすべてのトラフィックを制限していることを確認する」 で修復(カスタムアクション手動選択)を試してみます。

メンバーアカウントで非準拠リソース作成

メンバーアカウントでデフォルトのセキュリティグループのルールを編集してみます。 以下のようにインバウンド・アウトバウンドルールを入れました。

マスターアカウントで修復

しばらくすると Security Hub マスターアカウントで非準拠リソースとして上がって来ます。 対象の検出結果をクリックして、カスタムアクションから CIS 4.3 を選択しましょう。

「検出結果を Amazon CloudWatchEvents へ正常に送信しました」表示を確認します。

カスタムアクションのCloudWatchイベントが送信され、それをトリガーにした修復アクションが実施されます。

確認

カスタムアクション実施後に、メンバーアカウントのセキュリティグループを見てみると、ルールが全て消えていました。

実行のログは Security Group マスターアカウントのロググループ(今回は /aws/lambda/CIS43_lambda ) で確認できます。

マルチアカウントの修復 実行ログが Security Hub マスターアカウントに集約されています。

おわりに

Security Hub 自動修復のソリューションを Organizations 組織全体に展開してみました。 Service Catalog 自体ははじめて触りましたが、公式ドキュメントのデプロイ方法のとおりに展開するだけで、 問題なくセットできました。

今までは Security Hubの自動修復の仕組みは作り込みが必要なため、 別途 Configルール + 修復アクションで対応していたケースがあったと思います。 (こちらは Configのコンソール上で簡単に設定できます)

Configルール + 修復アクション をマルチアカウント展開する場合、全アカウントに それぞれ Configルール + 修復アクションを作る必要が ありました。

今回の Security Hub 自動修復のソリューションはマスターアカウントからメンバーアカウントへ、 クロスアカウントアクセスで修復を行います。実行ログもマスターアカウントに集約されます。 より統率のとれる、良い構成だと思いました。

この記事が少しでもどなたかのお役に立てば幸いです。