【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる~⑥セキュリティ（GuardDuty）の設定をしてみよう~

Last updated at 2025-03-13Posted at 2025-03-13

前回の記事では、ControlTower(Organizatrions)とSecurityHubを統合し、組織全体で「セキュリティ的にこのポリシーは守ってほしいな～」というポリシーの適用、遵守状況の判定が行えるようにしました。
どちらかというと内部向けのセキュリティ、という感じです。
今回はGuardDutyというサービスを組織に統合し、ControlTowerを外部の脅威から守るような設定を行っていきます。
ではやっていきましょう～

【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる

①マルチアカウント管理の利点　
 ②ControlTowerの利点（＆実際かかったコストの画像）
③ひとまず構築しながらControlTowerを理解してみよう（手順付）
④SSOユーザー作成→サインインしてマルチアカウント管理を体感しよう
 ⑤セキュリティ（SecurityHub）の設定をしてみよう
 ⑥セキュリティ（GuardDuty）の設定をしてみよう←本記事はここ
⑦コントロールのざっくり解説＆設定をしてみよう
⑦までやればいったん一通り構築完了です。
ControlTowerだけの構築であれば③だけで完了です。

(+印付きはオプション現在執筆中です)
+ベストプラクティスとはいえ、構築後に実運用に沿って変えた設定集
 +全アカウントのコスト管理を行う
 +アカウント管理者を任命したらやること
 +SecurityHubをもっと詳しく

もし今回の記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです🙌
あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。

※本記事で使用するメールアドレスやアカウント名は一部マスキングしております。
あらかじめご了承ください。

本記事の大まかな流れ

①東京リージョンで組織（AWS Organizations）に対してGuardDutyを有効化＆Auditアカウントに権限を委任する
②Auditアカウントにて再度GuardDutyを有効化＆保護プランを有効化する
③先程の①②の設定をControlTowerの管理対象リージョンごとにそれぞれ設定していく

基本的にはSecurityHubと似たような流れですが、GuardDutyもリージョナルサービスで、たとえOrganizationsと統合したとしてもリージョンごとに設定を入れなければならないようです。
①②自体はそこまで操作に時間がかかりませんが、③の①②の設定を繰り返すというのが明らかにめんどくさそうです……SecurityHubはリージョナルサービスでも中央設定あったのに……
ただControlTowerの一連の導入は、本記事が終われば殆ど全体が終わったようなものです！
もう少し一緒に頑張ってみましょう！

※本記事では以下の２つが完了していることを前提とした作業を行います。
①AWSControlTowerAdminのグループに属するSSOユーザーの作成が終わっていること
②ご自身のAWSアクセスポータルのURLがわかっていること

①,②どちらも前の記事を行った方なら問題ありませんので、お進みください。
また、※ポータルのURLがわからない方は、ご自身の管理者アカウントにてIAMIdentityCenterのダッシュボード、もしくはControlTowerのランディングゾーン設定→設定からアクセスポータルURLを参照してください。

GuardDutyとは

GuardDutyとは、主に外部からの脅威に対する検知を行うサービスとなります。詳細については、他の方の方が細かく書いていただいているため、そちらをご参照ください。

検知、検出というとSecurityHubと混同されがちですが、役割は異なるためどちらも有効化することをお勧めします。

SecurityHub→主にセキュリティ目線で見て、ＡＷＳの環境がベストプラクティスに沿っているかをチェック
GuardDuty→ユーザーの通信や操作ログをモニタリングし、実際に発生した攻撃や、予測される外部の脅威の検知、検出を行う。

また、下記の「保護プラン」を使用してよりセキュリティを高めることが可能です。

①東京リージョンで組織（AWS Organizations）に対してGuardDutyを有効化＆Auditアカウントに権限を委任する

では、前の記事の続きからやっていきます。
AWSアクセスポータルからSSOユーザーにて、 管理者のアカウントに入ります。
権限は「AdministoratorAccess」を一旦使うので、その権限の青字をクリックしてください。

左上の検索でGuardDutyを検索し、GuardDutyを開きます。

Guard Dutyのダッシュボードが開かれました。右上のリージョンが「アジアパシフィック（東京）」となっていることを確認し、橙色の「今すぐ始める」ボタンを押下します。

GuardDuty有効化のページが開かれました。各設定値を見ていきます。

サービスのアクセス権限について、一通りのログに対するアクセス許可を求められます。
先程もお伝えしましたが、GuardDutyは主にログを確認して脅威の検知を行うため、ここは許可する前提で進めます。
保護プランについては、複数のユースケースに応じた監視設定をカスタマイズ可能です。

後からでも設定変更は可能なので、今回はデフォルト通りの設定を有効化します（S3 のランタイムモニタリングと Malware Protection を除くすべての GuardDuty 保護プラン）。

保護プランの詳細は以下の通りです。

AWＳ公式ドキュメント -GuardDutyとは-より

例えば、「EC2の方で個別にエージェント監視のソフトウェアを入れているため干渉してしまう可能性がある」など、そういった際に個別に無効化する場合もあります。

SecurityHubと同じく、委任された管理者にAuditアカウントのIDを入れ、「委任」を押下します。
今回、保護プランのデフォルトの設定だと「Malware Protection」が有効になっていないため、許可もオフのままにします。

管理者が委任できたことを確認したら、「GuardDutyを有効にする」を押下。
するとこんな画面になります。

SecurityHubの時と同様、GuardDutyもすでにAuditアカウントに管理権限が移っているため、SSOユーザーでAuditにサインインします。

GuardDutyを検索し、アカウントタブに移るとこのような画面になります。

これでAuditアカウントへの委任は完了しました。

②Auditアカウントにて再度GuardDutyを有効化＆保護プランを有効化する

管理者アカウントにてGuardDutyを有効化しましたが、何故かその他のアカウントでは有効になっていません。
管理権限の委任を行ったAuditアカウントでさえ、GuardDutyの有効化がされていないのがよくわかりませんが、仕方ないので組織内の他アカウントにもGuardRutyを有効化していきます。
先程の画像の青色の通知の、「このリージョンでOrganizationsのGuardDutyを有効にする」の「有効にする」をクリック、ガイドに沿って有効化してください。
画像のように上部に「〇個のアカウントを正常に有効になっている GuardDutyしました」となっていれば設定適用が開始します。

ここについては10分くらいでステータスが「有効」になります。

保護プランも有効化されていないため、左上のページアカウントの「新しいアカウントの自動有効化」の右隣りの「編集」を押下し、再度設定します。設定は先程の通り、「S3 のランタイムモニタリング」と「Malware Protection 」を除くすべての GuardDuty 保護プラン、自動有効化設定にチェックを入れます）。
その後、「変更の保存」を押下します。

ここまで行ったら、緑の帯で「優先設定は正常に保存されました」と表示されます。
保護プランの変更は非常に時間がかかるため、この確認を待つよりは別の作業をしてしまった方が良いと思います。

これで東京リージョンにおける設定は完了です。

③先程の①②の設定をControlTowerの管理対象リージョンごとにそれぞれ設定していく

先程もお伝えしたとおり、非常に手間ですが、GuardDutyはここまでの一連の流れをリージョンごとに設定する必要があります。

これが終われば、「ControlTowetrを軸にしたマルチアカウント管理」の初期設定がほぼ終わったようなものなので、もう少しだけやってみましょう。

まず、SSOユーザーで再度管理者アカウントにサインインします。
Auditアカウントでリージョンをそれぞれ変えてGuardDutyを有効化するよりは、当初やった手順に沿って、
1.毎リージョンで管理者アカウントとしてGuardDutyを有効化＆Auditアカウントに委任
2.Auditアカウントで保護プラン有効化
3.確認

とするのが設定のプロセス的にはおすすめです