この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
大阪オフィスの川原です。
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 自動修復のソリューションはマスターアカウントからメンバーアカウントへ、 クロスアカウントアクセスで修復を行います。実行ログもマスターアカウントに集約されます。 より統率のとれる、良い構成だと思いました。
この記事が少しでもどなたかのお役に立てば幸いです。
2
