ControlTower関連リンクまとめ
・ControlTower①マルチアカウント環境をセットアップする
・ControlTower②環境確認
・ControlTower③SSOの確認・アカウントの追加・削除
・ControlTower④ガードレールの設定
・ControlTower⑤Auditアカウントに作成されるリソースについて
・ControlTower⑥LogArchiveアカウントに作成されるリソースについて
・ControlTower⑦SecurityHubの有効化
・ControlTower⑧GuardDutyの有効化←今ここ
・ControlTower⑨CloudWatchクロスアカウントダッシュボードの設定
・ControlTower⑩LogArchiveアカウント内バケットへのCloudWatchLogs集約
設定する内容の確認
前回の記事では、ControlTower環境でSecurityHubを有効化し、セキュリティチェック結果をAuditアカウントに集約する設定を確認しました。今回は、各アカウントでGuardDutyを有効化し、Auditアカウントに集約する手順を確認します。
ControlTower環境でのGuardDutyの有効化手順
SecurityHub同様、GuardDutyもOrganizationsと統合されるサービスです。
Organizationsと統合されるサービスについては、ユーザーズガイドをご参照ください。GuardDutyをAuditアカウントに集約する為に、まずは管理（root）アカウントでGuardDutyの有効化を行います。
マスターアカウントでGuardDutyを有効化する
管理(root）アカウントにログインし、Organizationsのサービスページに移動します。
左メニューの「サービス」から、サービス一覧を表示します。
GuardDutyはサービス一覧の一番上に表示されています。
サービス名のリンクを押下すると、信頼されたアクセスの設定画面に移動できます。
今回は順を追ってGuardDutyの設定を行う為、「追加のセットアップタスクを実行せずにAmazonGuardDutyの信頼されたアクセスを有効にするオプションを表示します」のチェックボックスにチェックを入れます。
テキストボックスに指定の文字列を入力し、「信頼されたアクセスを有効にする」を押下します。
上部に「Amazon GuardDuty に対する信頼されたアクセスを正常に有効にしました」と表示されることを確認します。次はGuardDutyのサービスページからサービスの有効化、管理の委任設定を行いましょう。
マスターアカウントでGuardDutyの有効化・委任設定を行う
GuardDutyのサービスページに移動します。
トップページに表示されている「今すぐ始める」を押下します。
GuardDutyの設定画面が表示されます。
「委任された管理者」のテキストボックスに、AuditアカウントのアカウントIDを入力し「委任」を押下します。
「委任」ボタンを押下ししばらくすると、「Organization の GuardDuty を代行管理するアカウントの権限が付与されました。」と表示されます。「GuardDutyの有効化」ボタンを押下します。
これで、GuardDutyの有効化が完了しました。
GuardDutyサービスページの左メニューから、「設定」に移動します。
「委任された管理者」としてAuditアカウントが指定されていることが確認できます。
これで管理（root）アカウント側の作業が完了です。
AuditアカウントのGuardDuty画面確認
管理（root）アカウントでの作業が完了したら、AuditアカウントにログインしGuardDutyのサービス画面に移動します。
管理アカウントでGuardDutyの委任設定を行ったため、AuditアカウントのGuardDutyは既に有効化されています。
左メニューから「アカウント」に移動します。
Organizationsに所属するアカウントが一覧表示されていますが、招待を送信していない為まだステータスが「メンバーではありません」となっています。
上部の「このリージョンで Organization の GuardDuty を有効にする」から、「有効化」を押下します。
確認画面が表示されます。「有効化」を押下すると、組織全体でOrganizationsが有効化されます。
上部に「アカウントに対してGuardDutyの有効化が正常に行えた」という旨の通知が表示されることを確認します。各アカウントのステータスは「有効化が進行中」となっています。
ブラウザを更新すると、GuardDutyの有効化が完了しています。
現在は、Organizations配下のアカウントが全てメンバーアカウントとして設定されています。GuardDutyの関連付けを外したいアカウントがあれば対象アカウントのチェックボックスにチェックを入れ、左上の「Actions」から「アカウントの関連付けを解除する」を押下します。
また、S3保護やKubernetesへの保護もここから有効化できます。
メンバーアカウントでのGuardDuty画面確認
LogArchiveアカウントにログインし、GuardDutyのトップページを表示します。
先ほど組織全体でGuardDutyの有効化を行ったため、LogArchiveアカウントでもGuardDutyの有効化が完了しています。
左メニューから「アカウント」に移動します。
LogArchiveアカウントはメンバーアカウントとなるため、Auditアカウントにより管理されていることが確認できます。
Security HubとGuardDutyの統合について
前回～今回の記事で、SecurityHub・GuardDutyの有効化設定が完了しました。
GuarDutyの検出結果はSecurityHubに送信される為、AuditアカウントのSecurityHubコンソールからGuardDutyの検出結果も確認できるようになっています。
GuardDutyとSecurityHubを両方有効化することで、自動的にサービスの統合が完了します。AuditアカウントのSecurityHubから「統合」を確認すると、GuardDutyの検出結果をSecurityHubで受け入れるよう設定が完了していることが分かります。
GuardDuty・Config・SecuryHubの連携は、下記の構成図のようなイメージです。
SecurityHubはConfigルールでセキュリティチェックを実施しています。
また、GuardDutyはSecurityHubに検出結果を連携します。
現在は、SecurityHub・GuardDuty個別に通知を設定していません。
SecurityHubのセキュリティチェックはConfigルールにて実施されるため、Configからの通知によりSecurityHubのルールに違反しているリソースも検出できるようになっています。
しかしGuardDutyの検出結果に対しては通知の設定がされていない為、ControlTower環境にGuardDutyを追加した場合はSecurityHub（GuardDutyと統合）・Configそれぞれに通知を設定する形をご検討ください。
また、GuardDutyのログはデフォルトではS3バケットに出力されません。
GuardDutyのログを出力する場合は、S3バケットを作成した上で結果のエクスポート設定を行う必要があります。
GuardDutyのログを別アカウントに集約する場合の設定方法についてはこちらをご参照ください。
ここまでお読みくださりありがとうございました。
次回は、CloudWatchのクロスアカウントダッシュボードを用いて各アカウントの監視をAuditアカウントに集約させる手順を確認します。