「AWS Control Towerを利用したマルチアカウント管理とセキュリティ統制」JAWS DAYS 2021登壇資料 #jawsug #jawsdays #jawsdays2021 #jawsdays2021_C

こんにちは、臼田です。

みなさん、JAWS-UG楽しんでますか？(挨拶

今回は年に1回のJAWS最大のお祭りであるJAWS DAYS 2021に登壇したのでその資料を共有しつつ解説とかしていきます。

動画

資料

解説

コンセプト

最近AWS Control Towerについて取り組むことが増えてきたのと、活用できるようになってきたので、ガンガンアピールしたいのでテーマにしました。

概要

マルチアカウント戦略のための基本的な情報を抑えつつControl TowerにDeep Diveできるように以下の観点でまとめました。

• AWSの利用が進むとマルチアカウント管理が避けて通れない道
• マルチアカウント管理のベストプラクティスと選択肢の提示
• AWS Control Towerを利用した手法を詳細に解説

セッションの対象者

上級者向けセッションのカテゴリですが、つまるところAWSに関わる人みんなに届いてほしいですね。

過去セッション

JAWS DAYS 2018 / 2019 / 2020の資料です。AWSセキュリティの基礎・運用・マネジメント&ガバナンスの強化にご利用ください。本セッションではある程度基礎がある前提で話しています。

アジェンダ

1. AWSマルチアカウント戦略とマネジメント & ガバナンス
2. Landing Zoneに必要な要素
3. Control Towerの展開と運用

1. AWSマルチアカウント戦略とマネジメント & ガバナンス

まず基本的な話。

むかしむかし…、AWS上では1つのVPCにいろんな環境をいれて使っていました(そういう人もいた、というたとえです)

ネットワークの境界線がなくて、良くないですよね。というわけでVPCを分けます。

ネットワークレイヤーの環境分離はできました。でもIAMはどうでしょう？というわけでAWSアカウントも分けます。

AWSレイヤーも環境分離できました。これで一件落着、とは行かないですよね。

AWSアカウントの管理が問題になってきます。この管理手法をだいたいAWSマルチアカウント戦略って呼びます。だいたいです。

以下のブログは鉄板なので見たことない人は見ておきましょう。

AWSマルチアカウント戦略をどうやって行くかですが、たくさんのAWSマネジメント & ガバナンスサービスなどで補うことが可能です。

• AWS Organizations
• AWS Config
  • Config Rules
  • Config Aggregator
• Systems Manager
• CloudFormation
  • StackSets
• Trusted Advisor
• Well-Architected Framework
• AWS SSO
• RAM
• などなど

いっぱいありすぎてキャッチアップも大変だけど、便利です。細かい紹介をしない代わりに、ざっくりだけ紹介します。

AWS Organizationsはマルチアカウント戦略の主力ですね。まさにマルチアカウントを管理する仕組みなので。OUを定義してアカウントをその配下にまとめます。OUやアカウントにはSCP(Service Control Policy)を適用して強制的なアクセス制御ができます。詳しくは以下もどうぞ。

SCPは強制的にポリシーが適用されるので、絶対にやっていけないことを定義しておきます。これを予防的ガードレールといいます。やってはならないことをできないように。

でも一律で止めづらいものもあります。条件が色々ある場合、例外として許容する場合など。そういうときは発見的ガードレールで見つけることができるようにします。

AWS Configでは各種AWSの設定値を管理し、Config Rulesにより定義した設定から逸脱したものを検知できます。場合によっては自動修復までやります。

例えば以下のように、SSHをうっかり開放したら3分で自動修復されます。

AWS Systems ManagerはEC2に関する様々な機能がありますが、リージョン・アカウントをまたがって情報を収集・可視化できるExplorere機能などもあります。

こういった機能を駆使して、自分たちに合わせたAWSマルチアカウント戦略をやっていきます。実際のやり方、使い方は十人十色ですし、AWS以外の機能も合わせて使っていくこともあるでしょう。

こういう機能を作っていくことを、ここではLanding Zoneを作っていくと言えます。

いきなりLanding Zoneという言葉を出しました。次の章で説明します。

2. Landing Zoneに必要な要素

というわけでLanding Zoneの話。Landing Zoneはマルチアカウント管理のベストプラクティスに従がった構成の考え方です。

考え方なので、特定のパターンはありません。が、イメージのために図を貼っておきます。

これが1つのパターンです。図の内容はともかく、Landing Zoneの構成要素について説明します。だいたい、大きく以下の4つの機能を持っています。

• ID管理: SSOなど各アカウントに対するアクセス管理
• ガードレール: SCPやConfig Rulesなどでポリシーに反する操作をさせない or してもすぐ検知する
• ベースラインの展開: CloudTrailやConfigなどの仕組みを展開する(Vending Machine)
• ログ管理・監視: 必要なログを保全したり、健全な状態か監視する

おまけにOrganizationsのベストプラクティスもおいておきますので見てください。

そして先程図に出した実装例はAWSが直接提供しているLanding Zoneの実装の1つである「AWS Landing Zoneソリューション」です。

CloudFormationで展開し、AWS OrganizationsでのAWSアカウント管理とSCP展開を始め、AWS SSOでIDの管理、ベースラインはCloudFornationなどでログ管理などと一緒に展開するなどで各種機能を実現しています。

ただしこのソリューションは現在延長サポート中で、追加の機能は提供されません。

代わりに、AWS Control TowerがLanding Zoneを展開するマネージドサービスとして提供されています。Control Towerはだいたい以下のような構成になります。

ところどころAWS Landing Zoneソリューションとは違います。Control Towerの詳細の説明は後にとっておきます。

ここで重要なのは、Landing Zoneの実現はControl Towerを使うしか無いのか？あるいはOrganizationsを使うしか無いのか、というところです。

私としては、Organizationsが使えるなら、使ったほうがいいと100%答えます。ただ色んな事情によりOrganizationsが利用できないことがあります。その場合でもLanding Zoneの実装は諦めなくてもいいです。前述したLanding Zoneに必要な機能は、なにもOrganizationsが無いと成り立たないわけではありません。

ここではOrganizationsを利用しなくても実現できる手法も含め、Landing Zoneの4つの機能の実現手法を紹介します。

ID管理

• AWS SSO
  • Organizationsと連携して利用します
  • Control Towerでもこれを採用しています
  • AWSアカウントに対してSSOする場合は向いています
  • ADなどのIdPとの連携も可能です
• OktaやOneLoginなどのIdPサービス
  • OrganizationsやAWS SSOを利用しなくても直接AWSアカウントにSSOできます
  • AWSアカウント以外にもSSOできるので、各クラウドサービスにも利用できます
• IAM管理AWSアカウントへのIAM User集約
  • Organizationsが無くてもできる枯れた手法です
  • IAM Userはすべて1つのアカウントに集約して、Switch Roleで各アカウントへアクセスします
  • 各アカウントへのアクセス権限管理をAWSだけで一元管理できます

ガードレール

• SCP(予防的ガードレール)
  • Organizationsを使ってOU/アカウント全体に強制的に適用するポリシーです
  • 展開したガードレールやベースラインを削除できないようにしたりできます
• Config Rules(発見的ガードレール)
  • ポリシーに違反する設定を検知・自動修復できます
  • Organizationsが無くても利用できます
  • OrganizationsがあってもSCPと一緒に使います
  • Aggregatorによりマルチアカウントの集約ができます
• Dome9/Prisma Cloudなどサードパーティ
  • いわゆるPosture Management系のサービス
  • Config Rulesの代わりに、より設定しやすかったりテンプレートが豊富だったり、管理機能が充実している
  • AWS以外のチェックもできる

ベースラインサービス一例

• CloudTrail
• Config
• GuardDuty
• Security Hub
• IAM Access Analyzer
• Detective

上記は全部展開すべきサービス。Organizationsで集約しやすいものもある。

Security Hubを利用したセキュリティチェックは、今ではAWSを利用する上で当たり前のように行う運用の1つなので、以下は要チェック

Detectiveはセキュリティインシデントの調査に最適なサービスなのでめっちゃおすすめ

ベースライン展開

• CloudFormation StackSets
  • Organizationsと連携して各OUにまとめて展開できます
  • Organizationsが無くてもIAM Roleを作成して利用できます
  • 一括で展開するのに活用します
  • CloudFormation特有の制約が細かいハマりどころ
    • 機能がリリースされてもCloudFormationでサポートされていないと利用できないなど
• Control Tower
  • ベースラインの展開は結構楽になります
• Terraform
  • 宣言型のOSS構成管理ツール
  • CloudFormationに依存しないのでCloudFormationでできないことができることもある
  • 逆に新機能の対応がOSSなのでケースバイケースだったりするのでそれに付き合う気持ちがだいじ
• CodePipeline
  • 構成をコードで管理して展開する
  • CloudFormationとかTerraformとかその他諸々と連携する

以下は実際にControl Tower以外のLanding Zone実装の事例の1つです。非常に参考になると思います。

ログ管理

• Control Tower
  • どちらかというとベースライン展開の役割です
  • CloudTrailとConfigを展開してログを集約します
• S3
  • 基本的に集約先のS3に送る形の実装をすればおっけーです
• SIEM
  • 集約したS3のデータを取り込んで分析します
  • 以下のような仕組みを展開するのにもS3に集約されているといい感じですね

ここまでLanding Zoneの機能についていろんなパターンを紹介しました。何を組み合わせてどう管理するかは担当者や部署の好きなもの・得意なもの・うまく仕組み化できるものをベースに考えていくことになるでしょう。

そしてControl Towerもその選択肢の1つです。

3. Control Towerの展開と運用

ようやく本題ですが、Landing Zoneを展開・運用していく上でControl Towerを利用した場合の詳細な話です。

仕組み

まず仕組みから。もう一回図を載せておきます。

上記の図の通り、大きく4つのアカウントの役割があります。

• マネジメント
  • Control Towerを管理するアカウント
  • Organizationsのマネジメントアカウントにもなります
  • AWS SSOやService Catalogなどの機能が展開されます
  • AWS SSOはADなどと連携が可能です
  • CloudFormationのStackSetsでアカウントのベースラインをもっていて各アカウントへ展開します
• Audit
  • CoreOU配下でControl Tower管理下のアカウントを監査するアカウント
  • Configの情報が集約されるので各アカウントの状況をチェックしたり是正したりします
  • アカウントのベースラインが適用されます
• Log Archive
  • CoreOU配下でログを集約するアカウント
  • CloudTrail / Configのログが集約されます
  • アカウントのベースラインが適用されます
• Custom(任意)
  • Control Tower配下で一般利用のためにアカウントを発行します
  • アカウントファクトリーという機能を使います
  • 任意のOUを作成してその配下に追加できます
  • アカウントのベースラインの他に、ネットワークのベースラインも展開されます

使い方

• セットアップ
  • ポチッと有効化できます
  • 60分待てばLanding Zoneの出来上がり
  • 簡単に上記の環境が展開できるのでいいですね
  • 雰囲気は以下も見てみてください

• ガードレール
  • SCPとConfig Rulesの仕組みが用意されています
  • そのうち、必須で適用されるものと、任意で選択できるものがあります
  • CoreOUには専用のものが適用されます
  • 任意のガードレールはOU毎に選択して適用できるので、その範囲を考えてOUを分けるといいです
  • 展開されるガードレールの一覧はここでは割愛しますのでユーザーガイドか資料をご確認ください
• アカウントファクトリー
  • 新規のAWSアカウントを発行する仕組みです
  • 作られたアカウントにはService Catalogから仕組みが展開されます
  • デフォルトではネットワークベースラインとしてVPCとともにNAT Gatewayが展開されるため、初手この設定でVPCの作成を無効化するのが私のオススメです
• AWS SSOでアクセス
  • 作成したAWSアカウントにはAWS SSOからアクセスできるようにします

具体的な実装と運用

• 管理外リージョン対応

Control Towerは現状対応しているリージョンにのみ仕組みが展開されます。気をつける部分はガードレールです。

ガードレールはSCPとConfig Rulesが展開されますが、SCPが全体に適用されるのに対し、Config Rulesはリージョナルサービスのため、デフォルトではConfig RulesがControl Towerに対応していないリージョンに展開されません。

しかし心配はいりません。Control Towerを拡張し非対応のリージョンに対してもConfig Rulesを展開するソリューションがAWSから提供されています。現状ではこの仕組を使うことで東京リージョンに対しても適切にガードレールを展開できます。詳細は以下もご確認ください。

• セキュリティ機能の展開

Control Towerでは現状セキュリティ機能としてCloudTrailとConfigが展開されます。ただ、他のセキュリティ機能も活用していく必要があります。具体的には以下は別途設定していく必要があります。

• GuardDuty
• Security Hub
• IAM Access Analyzer
• Detective

Detective以外はOrganizationsと連携して展開できます。Auditアカウントに委任して展開・管理するといいです。

• OU/SCP追加

OUやSCPの設計は、Control Tower利用時もただOrganizationsを利用しているときと同じように必要です。SCPはどこまでやるかは難しい課題ですが、縛りすぎないほうがいいことが多いです。以下のようなものをよく追加します。

• 追加ガードレール(GuardDuty等)変更禁止
• テストOUでインスタンスタイプ制限
• リージョン制限

こちらのユーザーガイドも参考になります。

SCPは止めようと思ったものと一緒に止めたくないものも止めがちです。SCP検証用のOUを用意したり、一時的な作業用のSCPがあまり適用されていないOUがあるといいです。

• バージョンアップ

Control Towerはマネージドサービスですが、アカウントの状態にも関わってくるので仕組みが更新されるときはバージョンアップが発生し、利用者が実行する必要があります。

これまであったバージョンアップは、リージョンが追加されたり、子アカウントへの追加設定などで、都度Control TowerのコンソールからバージョンアップやOUへの適用が必要でした。

手間でもありますが、機能追加が半自動でされると考えるとマネージドサービスである良さと感じられるかもしれません。

バージョンアップの検証のためにControl Towerを検証する別のセットを用意するのもありです。

細かいハマりどころ

• アカウント受け入れ時

Control Towerでは新規アカウントの作成だけでなく、既存のアカウントの受け入れも可能です。注意事項がいくつかあります。

例えば一部のリージョンでSTSを無効化していると受け入れプロセスが途中で失敗します。場合によっては手動でロールバックも必要になります。STS以外にもSCPによる失敗もあるので要注意です。これも作業前にユーザーガイドで詳細にチェックしてください。

• SIEMの仕組みをAuditに展開する

CoreOUのSCPは厳し目で、S3周りの扱いは特に気をつける必要があります。SIEM on Amazon ESの仕組みをAuditアカウントで展開しようとすると、できることがかなり限定的になります。役割的にはAuditに任せたいところですが、別OUに同等の仕組みを作るほうがいいです。

Landing ZoneにControl Towerを採用するメリット・デメリット

ここまでいろいろ説明しましたがまとめていきます。

• メリット
  • (操作的に)簡単にLanding Zoneをセットアップできる
  • ガードレールが自動で設定・展開される
  • 任意のガードレールを簡単に設定・解除できる
  • アカウント一覧とコンプライアンス状況が1機能で簡単に管理できる
  • ガードレールや管理の仕組みがマネージドで提供され、(比較的)簡単にバージョンアップできる
• デメリット
  • Landing Zoneの柔軟性がない
    • 独自のガードレール追加は簡単ではない
    • 必須ガードレールを外せない
    • CoreOUの機能を変更できない
    • 料金コストを抑えられない -> リージョンを外すのは2.6で対応
  • 孫OUに対応していない
  • SCP設定数が通常より1-2個制限される
  • 対応リージョンが限られる
    • 管理外リージョンの管理に手間がかかる(2重管理)
  • セキュリティ機能を別で管理する必要がある
  • 東京リージョンに対応していない
  • バージョンアップ時に負荷がかかる

書いていくとデメリットの数が多くなっていますが、実際直接Landing Zoneを構築していくのもつらみがあるところは変わらないので、Control Towerを選ばなければ楽なわけではないので気をつけましょう。

そして、Control Towerはマネージドサービスですから、どんどん良くなります。私も上記の内容などはフィードバックしていますし、Control Towerのアップデートを眺めながら利用するタイミングを見極めてもいいでしょう。

Control Towerを使うか判断する基準

上記メリット・デメリットをみてもどうするか悩む気がするので、私なりの現状の基準も用意しました。参考にしてください。

• 早く簡単にLanding Zoneを構築したいか
• Landing Zoneの構成がある程度固定されていて問題ないか
• 料金コストより構築・運用管理コストを削減したいか
• 現状の必須/任意ガードレールを許容できるか
• AWS SSOを利用したアクセスが問題ないか
• 現状東京リージョンが対応していなくて問題ないか
• 東京リージョンに対応したい時にControl Towerを構築し直す覚悟があるか(そうしたい場合)

書き出しておいてなんですが、つまり東京リージョンに来たときがいいタイミングだと思います。

まとめ

• とにかくマルチアカウント管理をやっていくことを前提に仕組みを考えましょう
• Landing Zoneは十人十色なので、順番に合うものを確認しながらやっていくといいでしょう
  • まずはIAMをまとめるところから、というのは始めやすいです
• 手っ取り早く統制を効かせるならControl Towerはおすすめです
  • 今から検証しておくとControl TowerやLanding Zoneの理解が深まります
  • 東京リージョンの対応に備えましょう

さいごに

登壇当日は最後少し駆け足になったので、Control Towerの魅力を伝えるにはもっと時間が必要だなと感じました。

引き続き推していきたいので、みなさんもチェックしていってください！