今回、次の記事ではControlTower構築だけじゃもったいない、ということで、SecurityHubやGuardDutyというサービスを組織に統合し、セキュリティを強化していきます。
ではやっていきましょう～
【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる
目次
①マルチアカウント管理の利点
②ControlTowerの利点（＆実際かかったコストの画像）
③ひとまず構築しながらControlTowerを理解してみよう（手順付）
④SSOユーザー作成→サインインしてマルチアカウント管理を体感しよう
⑤セキュリティ（SecurityHub）の設定をしてみよう←本記事はここ
⑥セキュリティ（GuardDuty）の設定をしてみよう
⑦コントロールのざっくり解説＆設定をしてみよう
ControlTowerだけの構築であれば③だけで完了です。
(+印付きはオプション 現在執筆中です)
+ベストプラクティスとはいえ、構築後に実運用に沿って変えた設定集
+全アカウントのコスト管理を行う
+アカウント管理者を任命したらやること
+SecurityHubをもっと詳しく
もし今回の記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです🙌
あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。
※本記事で使用するメールアドレスやアカウント名は一部マスキングしております。
あらかじめご了承ください。
本記事の流れ
本記事の大まかな流れは以下になります。
①組織（AWS Organizations）に対してSecurityHubを有効化＆Auditアカウントに権限を委任する
②ControlTower全体（管理下の全リージョン）に対するセキュリティチェック設定[=中央設定]の、中身を詳しく決める。
自動でセキュリティチェックを行うための設定をこれから行っていきます。また、設定の適用、適用後の初回セキュリティチェックには時間がかかることをご認識おきください。
※本記事では以下の２つが完了していることを前提とした作業を行います。
①AWSControlTowerAdminのグループに属するSSOユーザーの作成が終わっていること
②ご自身のAWSアクセスポータルのURLがわかっていること
①,②どちらも前の記事を行った方なら問題ありませんので、お進みください。
また、※ポータルのURLがわからない方は、ご自身の管理者アカウントにてIAMIdentityCenterのダッシュボード、もしくはControlTowerのランディングゾーン設定→設定からアクセスポータルURLを参照してください。
①組織（AWS Organizations）に対してSecurityHubを有効化＆Auditアカウントに権限を委任する
では前の記事の続きからやっていきます.
AWSアクセスポータルからSSOユーザーにて、管理者のアカウントに入ります。
権限は「AdministoratorAccess」を一旦使うので、その権限の青字をクリックしてください。
左上の検索でSecurityHubを検索し、SecurityHubを開きます。
SecurityHubのダッシュボードが開かれました。右上のリージョンが「アジアパシフィック（東京）」となっていることを確認し、橙色の「SecurityHubに移動」ボタンを押下します。
SecurityHub有効化のページが開かれました。各設定値を見ていきます。
-
AWSConfigの有効化
まず「AWS Config有効化してね、Configで記録したものをもとにセキュリティチェックするよ」と書かれています。ControlTowerを構築した際、Auditアカウントにおいて既にAWS Configが自動で有効化されているため、有効化の対応は不要です。
※AWS Configはリージョナルサービスのため、本来ならばリージョンごとに有効化する必要がありますが、これもControlTower側が構築時に指定した管理下リージョンに対し、自動で有効化してくれています。 -
セキュリティ基準について
セキュリティチェックを行うにあたり、どういう基準でセキュリティチェックしますか、というのを設定する項目になります。 1個目の「AWS 基礎セキュリティのベストプラクティスv1.0.0」を有効にすれば、大体のチェック項目を網羅できるため、とりあえず基本的に有効にしましょう。
セキュリティ基準も後から変更可能です（AWS側で基準適用に時間がかかります……）。
リスク対策の要件的に不足分がありそうであれば、都度追加/削除するようにしましょう。ただ、増やしすぎると管理が煩雑なので今回は一旦これでいいと思います。
※他のセキュリティ基準については別の記事で紹介します。 -
AWS統合&委任された管理者
「いろんなリソースがSecurityHubにチェック内容を送ったり受け取ったりするから、そのあたりのアクセス許可が付与されるよ」ということ、
委任された管理者ではSecurityHubの管理者を別で指定できるよ、ということを言っています。
セキュリティ上、SecurityHubの管理者となったアカウントでしか組織のSecurityHubを見られない（＝チェック項目やチェック結果が見られない）という仕様になっています。
管理アカウントから、委任者のアカウントをどれにするかは後から変更も可能です。
基本的にはセキュリティ専門のAuditアカウントに委任するようにしましょう。
AuditアカウントのIDを入力し、「委任」のボタンを押して委任したことを確認します。
問題なければ、「SecurityHubの有効化」ボタンを押下します。
SecurityHubの有効化をしました。初回チェックは時間がかかるものの、バックグラウンドで設定が進められるため、別の設定を行うことも可能です。
ControlTowerの構築時とは違い、組織にどのくらいアカウント/リソースがあるかで所要時間が変わるため、待つしかありませんが、初回なら1時間行かないくらいで終わると思います。
画面の「セキュリティ基準」のところでは、先程有効にしたセキュリティ基準が表示されています。
検査結果を待つ間、SecurityHubの中央設定を行いましょう。
SecurityHubもリージョナルサービスであるため、今回有効にしたのはSecurityHubの東京リージョン（ホームリージョン）のみで、実は大阪などの別リージョンではSecurityHubは適用されていません
中央設定を行い、先ほど有効にしたセキュリティ基準を全リージョンに適用し、設定をカスタマイズしていきます。
②ControlTower全体（管理下の全リージョン）に対するセキュリティチェック設定[=中央設定]の、中身を詳しく決める。
では、設定を行っていくアカウントに移動します。
先ほど、SecurityHubはその管理者のアカウントでないと組織のSecurityHubを見られないとお伝えしましたが、設定の変更も同様です。
そのため、管理者アカウント/先ほど委任したアカウントでないと中央設定ができません。
現在はAuditアカウントにSecurityHubを委任しているため、SSOユーザーを用いてSecurityHubにサインインします。
目的のアカウントであることを確認し、SecurityHubを開きます。
（なぜか写真だとCIS WAF Benchmarkも検知項目に入ってしまっていますが、後の設定で元に戻ります。）
左タブの「設定」から「中央設定の開始」を押下します
中央設定の編集画面が開きました。リージョンの画面を編集していきます。
ホームリージョンはControlTower構築時のリージョン、
「使用可能なすべてのリージョンをリンク」はチェックを外してください。
この項目のSecurityHubを有効にするリージョンは、ControlTower側で設定した管理リージョンと一致させる必要がありますので、注意してください。
🔵（スキップ可）ここで一致させないと起きてしまうエラー
SecurityHubのセキュリティチェックのリージョンなんだから多いほうが良くない？と考え、すべてのリージョンを検知してしまうと、ControlTower側の管理対象リージョンと設定の齟齬が生まれることになってしまいます。
SecurityHubのAWS SecurityHub 基礎セキュリティのベストプラクティスのチェック項目の一つに、
「[Config.1] AWS Config を有効にする必要があります」
という項目があり、ControlTowerサイドで管理対象のリージョンは自動でConfigを有効化しているためこのチェックはクリアできます。
ただ、管理対象外のリージョンは自動でConfigを有効化していないため、SecurityHubの検知対象のあらゆるリージョンで「Configが有効化されてない」というセキュリティチェック結果が出てしまい、SecurityHubのノイズとなってしまいます。管理対象外とはいえ、個別でConfigを立てるのも、ControlTowerでの管理統制と反してしまい、いろいろなエラーの原因となってしまいます。
（例えば中央設定の適用ができなくなることがある等です。）
どうしてもSecurityHubで全リージョンを検知したければ、ControlTowerの方で全リージョンを管理対象としましょう。
こんな感じでSecurityHubの検知対象のリージョンと管理対象のリージョンを揃えます。
「将来のリージョンのリンクを設定」も、将来AWS側でリージョンが増えた際にControlTower側と齟齬を起こしたくないため、ひとまずオフにしておきます（ここも後から変更可能です。）
設定が正しいことをチェックし、「確認して続行」を押下します。
「組織を首尾よく一元化しました。次に、最初の構成ポリシーを作成します。」と出るので、SecurityHubの詳細設定に入っていきます。
-
設定タイプ
「組織全体で AWS が推奨する Security Hub の設定を使用」を選べばSecurityHubを有効化したときの設定が自動で全体に適用されます。
もし、中央設定をカスタマイズしたい、という場合は真ん中の「Security Hub の設定をカスタマイズ」を選んでください。
- 「実運用に沿うと一部のチェック項目（コントロール）が邪魔」という場合はその項目を無効化（「特定のコントロールを無効化」）
- 特定のコントロールだけを有効化（「特定のコントロールを有効化」）
- 検出対象について一部のアカウントだけセキュリティチェックする
など詳細を変える事が可能です。
変更は後から可能ですが、組織全体への設定の適用に少し時間がかかります。
一旦今回は最初にやったSecurityHubの設定で進めたいので、「組織全体で AWS が推奨する Security Hub の設定を使用」を選んで次へを押下します。
ちなみに今回の設定だと、以下のようになります。
①次の標準を有効化: AWS 基礎セキュリティのベストプラクティス v1.0.0
②有効な規格のすべての新規および既存の統制を有効にする（＝①の全部の項目チェック）
③すべての組織アカウントがこの構成を使用します（＝①②を組織内の全アカウントに適用）
入力した設定が正しいことを確認します。
標準の「AWS Foundational Security Best Practices v1.0.0」は「AWS 基礎セキュリティのベストプラクティス」のことで、頭文字を取ってFSBPと略されます。
Confirmationにチェックを入れ、右下の「ポリシーを作成して適用」を押下します。
以下画像になれば中央設定の設定作成が完了した、ということになります。
なお、現時点では複数のポリシーを中央設定に入れ込むことはできません（2025/2月時点）
そのため、「この基準は組織全体に適用したいけど別の基準はこのアカウントだけに、それでもセキュリティスコアは組織全体で見たい」などの要望は、中央設定で実現することは叶いません。
どうしても上記要望を満たしたい場合は、SecurityHubから該当のアカウントを「セルフマネージド」のポリシーにさせ、中央設定からは抜きつつ個別でセキュリティチェックの運用をしていくしかない状態です。
組織タブを開くと、先ほど作成した中央設定のポリシーが自動で適用されようとしています。
- ポリシーのステータス
「成功」「失敗」「保留中」の三種類あり、「保留中」はポリシーの適用中であること、「失敗」は何らかのエラーがアカウントに発生していることを意味します。
ここが「成功」となるまでまちましょう。
（「失敗」となった場合は、ステータスにあるエラーメッセージなどでエラー解決を目指しましょう。）
組織に対するポリシー適用が完了しました。
配下のアカウントのポリシーステータスがすべて「成功」となっていれば、その上のOUも「成功」となります。
ステータスが管理者アカウント以外の全アカウント、OUで「成功」となっていること、「適用済み」のポリシーが先程指定したものになっていれば問題ありません。
🔵（スキップ可）管理アカウントが「失敗」となる理由
管理アカウントにはConfigを有効化してください、というエラーが出てしまい、ポリシーのステータスは失敗となります。 管理アカウントのポリシーのステータスにカーソルを合わせるとその旨のエラーメッセージが出てきます。
Configが管理アカウントにて有効化されないのは仕様で、AWSサポートにもケース起票して問い合わせましたが、「仕様による表示で、問題はありません」との解答をもらっています。
写真では一番下のアカウントも失敗していますが、すでに停止したアカウントであり、停止したアカウントへのポリシー適用は失敗してしまいます。メッセージ内容は少し違いますが、こちらも問題ありません。
どこかの機会に書ければ書きますが、アカウントを停止する前に、あらかじめ作成した別の削除用OU（SuspnedOU）に入れたのちアカウントを停止すれば、Root直下で停止することなく、削除用OUのトグルの中に入るため、運用的には見やすいかと思います（一応それ以外にもメリットはあります）。
時間が経っていれば、概要ページにセキュリティスコアが表示され、グラフ/図となった検出結果が表示されます。
検出結果のタブでは、どの項目がセキュリティ基準を満たせていないかを確認することが出来ます。
SecurityHubに関する運用や、セキュリティチェックの頻度など、もう少し詳しいところは別記事にて解説します。
おわりに
これで設定はSecurityHubの設定は一旦完了とします。
SecurityHubは細かく取り組もうとすると奥が深く、結構大変だと思います。
最初はSecurityHubの動作を見つつ、重大度が高いものを見ていくようにしていったほうが現実的かな、という感じです。
次回はセキュリティ対策のうち、「外部の脅威から守る」にフォーカスしたGuardDutyの設定を行います。
ではまた～
←前回記事
次回記事→