ControlTower構築後、第4回でSSOの仕組みを体験し、第5回、第6回で内部と外部のセキュリティを高める設定を行いました。
今回はControlTower本来の機能に戻り、今設定されているコントロールの確認、コントロールの追加ということで、少し後回しにしていた「コントロール」についてフォーカスしていくような内容です。
ではやっていきましょう～
【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる
目次
①マルチアカウント管理の利点
②ControlTowerの利点（＆実際かかったコストの画像）
③ひとまず構築しながらControlTowerを理解してみよう（手順付）
④SSOユーザー作成→サインインしてマルチアカウント管理を体感しよう
⑤セキュリティ（SecurityHub）の設定をしてみよう
⑥セキュリティ（GuardDuty）の設定をしてみよう
⑦コントロールのざっくり解説＆設定をしてみよう←本記事はここ
⑦までやればいったん一通り構築完了です。
ControlTowerだけの構築であれば③だけで完了です。
(+印付きはオプション 現在執筆中です)
+ベストプラクティスとはいえ、構築後に実運用に沿って変えた設定集
+全アカウントのコスト管理を行う
+アカウント管理者を任命したらやること
+SecurityHubをもっと詳しく
もし今回までの記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです🙌
あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。
※本記事で使用するメールアドレスやアカウント名は一部マスキングしております。
あらかじめご了承ください。
本記事の流れ
本記事の大まかな流れは以下になります。
①現在ControlTowerで設定済みの統制のルール（コントロール）を確認する
（おまけ）ControlTower統制の仕組み (コントロールについてざっくり解説）
②追加でコントロールを有効化してみる
今回は上記の流れで行きます。もしコントロールについて調べてみたけどよくわからん！という方は①において途中のおまけトグル（ControlTower統制の仕組み）でちょっぴり解説しています。（スキップ可能です）
ControlTowerを立てたものの、その特徴であるコントロールについてはあまり触れてきませんでした。
これまで、「ひとまず初回構築をしてその中で理解をしてもらう」ように記事を書いていたためです。人によりますが、私は「やってみて理解」が一番自分に合っている気がするので、実はそんな感じで書いてます。
コントロールは最初からガチガチに決めるよりは、ある程度決めつつ途中途中で実運用に沿ってカスタマイズしていくほうが現実的だと思います。
一通り構築が終わった今回は、今設定済みのコントロールの確認、その後「ある程度決める」の部分をやっていきます。
「ある程度決める」の部分では、以下のように見てください。
「ご自身で確認されたうえで設定済みのものだけでいいや」という人はご自由にスキップください。
「一応推奨されてる追加設定があるなら、いったんそれもやっちゃおう」という人は読んでみてください。
①現在ControlTowerで設定済みの統制のルール（コントロール）を確認する
では、始めていきましょう。
コントロールはContolTowerの管理者しか詳細を確認できないため、ControlTowerの管理者アカウントにサインインします。SSOユーザー/IAMユーザーで入ります。
※一応ベストプラクティス的には管理者がなんかやるときは管理権限もつSSOユーザーでやってねとは言われてます。
サインインしたらControlTowerを開きます。
左タブで「コントロールライブラリ」をクリックし、コントロールライブラリを開きます。
コントロールの設定を後回しにしていたのは、このコントロールが539個あり(2025/2/11時点)、非常に多いため、この設計を考えるところで心が折れてほしくないなと思ったからです。
細かいコントロールの解説はいろいろなところでなされているため、今回はおまけの方でざっくりとした解説にとどめます。飛ばしても問題ありません。
ControlTowerの統制の仕組み (以下トグル)
（スキップ可）🔵ControlTowerの統制の仕組み
そもそもControlTowerでは、大まかに3つの形で統制を取っています。
（これは私の個人的な、めちゃくちゃざっくりとした言い換えなので、もし相違あればご指摘ください。特にプロアクティブは分かりづらいので、公式ドキュメントも併せてみることを推奨します。）
そしてそれぞれの統制に対応するように、以下のコントロールが設けられています。
これらはコントロールライブラリの「動作」列でフィルタリングすると、それぞれのコントロールに何があるかを確認できます。
また、それぞれのコントロールの中にも、
- 「この予防コントロールは必須だろう（必須）」
- 「この予防コントロールは権限強いし、実運用で欲しい人だけ選択してもらおう（選択的）」
- 「この検出コントロールは強く推奨されてるから基本適用しよう。一部は別の方法で検知するから無効化しよう（強く推奨）」
みたいなレベルがあります。以下のとおりです。
デフォルトではこの「必須」や「選択的」が表示されないため、右上の歯車マークから「ガイダンス」をオンにしてみましょう。
「動作」列＆「ガイダンス」列でフィルタリングするとこんな感じです
よりコントロールを詳しく知りたい人は、このあたりとかはわかりやすく書いてくださっているため、おすすめです。
https://note.shiftinc.jp/n/n6d107f32edcc
もちろん、公式ドキュメントも詳しく載っています。
業界によっては、有志の方がコントロールと業界基準のアーキテクチャの対応表を書いてくださっていたりします。
例 金融 FISC 安全対策基準 実務基準 (2023/11/13時点)
ただ、コントロールの内容はそ
こそこの頻度でアップデートされますので、最新版はご自身で確認する必要があります。更新のタイミングは例えばですが、
例 S3バケットの暗号化がデフォルトで行われるようになる、という仕様変更
→S3バケットに対するガードレールが追加、およびガイダンスが「必須」→「選択的」になる
https://dev.classmethod.jp/articles/update-aws-control-tower-logarchive-guardrail/
s3がデフォルトで暗号化されることによって、[Athena.1][Athena.1] Athena ワークグループは、保管中に暗号化する必要がありますのコントロールが廃止される。
https://dev.classmethod.jp/articles/20240316-remove-security-hub-controls/
などなど……
そのため、具体的に1個1個見ていくよりは、下にあげたようなアプローチを取って、関係各所に説明していくのがよいと思います。
- 「必須」に加えて、一旦AWS側で「強く推奨」されているものを有効にしました。
- 業界基準のアーキテクチャに対応したものを有効にしました。
- 「この統制目標を達成したい！(”統制目標”でフィルタリング)」というところと「でも有効化して予防/検出すると業務に支障でるかも（”ガイダンス”でフィルタリング）」の折り合いをつけて検討しました。
など
統制目標は「コントロールライブラリ」のカテゴリで確認可能です。
今回はひとまず「コントロールの有効化」のガイダンスも兼ねて、②の手順では「強く推奨」されているコントロールを有効化していきます。
ということで、その検討をする前に一旦現時点で設定されているコントロールを確認してみましょう。
コントロールライブラリで「ガイダンス＝必須」のフィルターを掛けてみます。
「必須」となっているものは23個（2025/2/11時点）で、その全てがControlTower構築時に自動で有効化されているものです。
※当初の設定の方で「管理リージョン以外のリージョンを拒否する」という設定をControlTowerに設定していた場合は、予防・選択的のコントロール[AWS-GR_REGION_DENY] リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否するが追加され、必須・予防と合わせ計24個になっています。
基本的には必須コントロールは「ControlTowerやそれが作成したリソースに対する変更/削除をしないでください」という旨が多く，別プロジェクトの妨げになるようなものは必須にはありません。
ただ、必須コントロールは無効化出来ないため、必須・予防コントロールで禁止されているようにControlTowerのリソースを自在にカスタマイズできる、というわけではないことも知っておいてほしいです。
これらコントロールはControlTowerに新しく追加されたアカウントにも等しく適用されます。
SecurityOUに現在適用されているコントロールを確認しましょう。
左の「組織」タブからSecurityOUをクリックし、下にスクロールします。
（フィルターがかかっていますが、写真撮り忘れて後から撮っただけなので無視してください。）
SecurityOUは必須コントロールがそのまま23個入っていますね。
では、同じようにSandBoxOUもみてみましょう。
SandBoxOUの方は15個しかありません。
なぜかというと、残りの必須コントロール8個はSecurityOU専門だからです。
というより、
SecurityOUが特別なOUのため、一部のセキュリティに必要なコントロールはSecurityOUにしかつかず、逆にSecurityOUにだけはつかないコントロールもあるからです。
特に「検出」のコントロールに多いですが、例えば先程SandBoxOUにはなかった8個のうち、以下の検出・必須コントロールなどはSecurityOU以外にあっても役割を果たしません。
[AWS-GR_AUDIT_BUCKET_PUBLIC_WRITE_PROHIBITED] ログアーカイブのパブリック書き込みアクセス設定を検出する
ログアーカイブ、監査アカウントのいるSecurityOUにしか出来ない仕事があるわけです。
②追加でコントロールを有効化してみる
では実際に「強く推奨」のコントロールを有効化してみましょう。
コントロールライブラリで「ガイダンス＝強く推奨」のフィルターを掛けてみます。
「強く推奨」は14個で、そのうち動作「検出」のものが12個、動作「予防」のものが2個です。
「予防」とはちがい、「強く推奨」「選択的」のものはまだ現時点ではControlTowerに適用されていません。また、その２つはControlTowerのどのOUに適用するかを選ぶことが出来ます。
※先ほどのように、一部SecurityOU専用のコントロール/逆にSecurityOUには適用できないコントロールがあります。
基本的には「検出」なのでやってまずいことはないと思いますが、「予防」はアクションができなくなってしまいますので、有効化する際は注意してください。
例えば [AWS-GR_RESTRICT_ROOT_USER] ルートユーザーとしてのアクションを許可しない は強く推奨かつ予防ですが、これを設定すると、アカウントのrootのアクションができなくなります。MFA設定なども例に漏れず出来ないため、もし行う人はここらへんや他にも漏れがないかを確認しましょう。
仮に忘れたまま有効化した場合は、一旦該当のOUアカウントからコントロールを無効化する形になります。
さて確認できたら有効化ですが、左のチェックボックスを選んで14/14（全量/選択数）となっていることを確認します。
右上の「コントロールアクション」を押下し、「有効にする」を押下します。
一応「選択したコントロール」を開き、間違いのないことを確認したら、適用する組織単位を選んでいきます。
今回は「SecurityOU」、「SandBox」を選択します。
選択できたら、設定に間違いのないことを確認し、「コントロールを有効化」を押下します。
押下したら、「コントロールアクションが進行中です」と出ます。
ちなみにコントロールアクションが進行中に別のコントロールアクション（例えば有効化中に無効化など）を行うとエラーとなってしまうので気をつけてください。
左タブの「最近の業務」から、現在進行中のコントロールオペレーションを確認できます。
ちなみにコントロールオペレーションが先ほど設定されたものより多いのは、Controltower構築時に必須コントロールを有効化したオペレーションが履歴に残っているからです。
オペレーションステータスが「有効」となりました。
確認のため、先ほどと同じようにSecurityOU、SandBoxOUのコントロールを見てみます。
「ガイダンス＝強く推奨」でフィルタリングをかければ、ともに14個のコントロールが有効になっていることを確認できると思います。
以上でControlTowerのコントロール設定を終わります。
コントロールはたくさんあり、更新頻度もそこそこあり、きっちり運用していくと工数を使いますので、ある程度ゆるめに見ていきましょう。ただ、予防コントロールを安易にやると開発側でできることがだいぶ制限されてしまいます。予防コントロールにはきちんと向き合い、要件とよく相談しましょう。
これでControlTowerの初期構築は終了です。大変お疲れ様でした。
これから運用というフェーズに入り、不足部分の構築の中で、
なるべく他の人の手間や間違ってしまいそうなことをControltowerで無くしていければ良いなと思います。
ひとまずここまで頑張って作り上げたご自身を褒めてあげてください。
今回の記事「【マルチアカウント管理】AWSのベストプラクティスを実現できるControlTowerに取り組んでみる」としては一旦区切りですが、この後はオプションとして運用Tipsを書いていきます。
上記興味があれば、ぜひ見ていただけると嬉しいです。
改めてですが、今回の記事が参考になったり、いいなと思ったら、よろしければストックやいいねしていただけると非常に嬉しいです。あなたのいいねがとっても励みになり、記事を書くモチベになります。
コメントもぜひ、お待ちしております。
ではまた～
←前回記事
次回記事→