20230829_ccoe_seminar_session_3

Transcript

1. AWS Control Towerから始める組織的AWS統制 〜主要なサービスの概要と設計の勘所〜 1
2. 2 自己紹介 • 名前： 芦沢広昭 / あしざわひろあき • 所属・ロール： AWS事業本部コンサルティング部 ソリューションアーキテクト • 業務： AWS技術支援・コンサルティング • 好きなAWSサービス： • 趣味：筋トレ(目指せBIG3 350kg) AWS Security Lake AWS Control Tower 2023 Japan AWS All Certifications Engineers
3. 3 本日お話しすること 1. マルチアカウント管理について a. なぜマルチアカウント管理が必要なのか？ b. マルチアカウント管理における課題 2. AWS Control Towerについて a. サービスの全体像 b. 設計の勘所 3. まとめ
4. 4 本日話さないこと • 各AWSサービスの詳細な説明 • 各AWSサービスの具体的な設定手順 • 各AWSサービスの具体的なパラメータ設計について
5. 5 1. マルチアカウント管理について
6. 6 問い なぜマルチアカウント管理が必要なのか？
7. 7 答え シングルアカウント環境での アカウント運用が「難しい」から
8. 8 IAM権限管理の問題 • シングルアカウント内に複数環境が存在するアカウントだと、 環境(本番・開発)の取り違えによるインシデントが起きる可能性が高まる • IAMによる制御も可能だが、管理が煩雑になりがち
9. 9 請求の分割の問題 • 原則、利用費請求は1アカウントまとめて管理されるが、 コスト配分タグを利用したレポート発行によりタグ毎の利用費管理が可能に • ただし、コスト配分タグの付与を徹底する運用は管理が難しい
10. 10 リソース制限の問題 • リソースの制限はアカウント単位で設定されている • 複数環境が相乗りする環境だと、開発環境のリソースによって 本番環境のリソースが立ち上がらず障害発生につながるケースも考えられる • 事前の引き上げは可能だが、想定できない場合もある
11. 11 マルチアカウント環境に変更すると... • セキュリティ境界の明確化と権限移譲 ◦ アカウント自体がIAMの境界、細かいIAM管理が不要に ◦ 本番以外で強いIAM権限を与えて、開発スピードが向上 • 請求の単位 ◦ アカウント(環境) = 請求の単位となる ◦ 細かいコスト配分タグの運用が不要に • リソース制限 ◦ 環境毎にリソース制限が完全に分離される
12. 12 新しい組織の課題 マルチアカウント環境にすると出てくる新しい課題 • アカウントがたくさんあって全体を把握できていない ◦ 皆が自由にアカウントを払い出している • アカウントの種類に応じてセキュリティレベルを制御したい ◦ 本番ワークロードとその他で分けたい • 複数アカウントのIAMの運用負荷が高い、ログインが手間 ◦ アカウントの数だけへ発生するIAM運用作業 • アカウントの初期設定にかかる運用作業が手間 ◦ アカウントの初期セットアップ作業に時間がかかっている
13. 13 新しい組織の課題 → 対策 課題に対する対策 • アカウントがたくさんあって全体を把握できていない ◦ → AWS Organizationsの利用 • アカウントの種類に応じてセキュリティレベルを制御したい ◦ → 予防的・発見的ガードレールの利用 • 複数アカウントのIAMの運用負荷が高い、ログインが手間 ◦ → SSO(Single Sign On)の実装 • アカウントの初期設定にかかる運用作業が手間 ◦ → アカウントベースラインの実装
14. 14 対策の具体例 • AWS Organizationsを利用したアカウント管理 ◦ 組織内のアカウントを一括管理できる ◦ 組織単位(OU)を利用したアカウントのグルーピングも可能 • ガードレールによる運用を阻害しないセキュリティ対策 ◦ 予防的ガードレール(SCP) ▪ 組織レベルのアクセス制御や危険な操作の制限 ◦ 発見的ガードレール(AWS Config, AWS Security Hub) ▪ セキュリティに問題があるリソースの設定レベルの検出 • IAM Identity CenterによるSSOの実装 ◦ アクセス許可設定をセットしたアカウントへのSSOが可能に ◦ ActiveDirectory、Okta等のIdPと連携できる • AWS Service Catalogを利用したアカウントベースラインの作成 ◦ アカウント作成時に事前定義したCloudFormation StackSetsを デプロイ、リソースを自動作成できる
15. 15 参考: アカウントベースラインの運用イメージ
16. 16 先述したサービスを全て入れたアーキテクチャ例
17. 17 ここまでで実現できること • 新規のアカウント払い出しと同時にセキュアな状態で アカウントの利用が開始できる状態になっている ◦ 最低限実施したいセキュリティ設定が自動で設定・構築されてい る = ランディングゾーン(LandingZone) が構築されている状態
18. 18 ランディングゾーンとは？ • AWSベストプラクティスに基づいたスケーラブルで安全な マルチアカウントAWS環境 • アプリケーションを迅速に起動しデプロイするための出発地点
19. 19 ランディングゾーンを楽に構築・運用したい • ランディングゾーンを1から構築する場合、少なくない工数がかかる ◦ 構築にかかる負荷を減らしたい • アカウントベースラインなどの更新時のアップデートの手間がかか る ◦ 更新の運用にかかる負荷を減らしたい → ランディングゾーンをAWSマネージドに実装できる サービスがあれば....
20. 20 ランディングゾーンを AWSマネージドに実装できるサービス ＝ AWS Control Tower
21. 21 2. AWS Control Towerとは？
22. 22 AWS Control Tower AWSのベストプラクティスに基づいた セキュアでスケーラブルなマルチアカウント環境を 自動でセットアップできるサービス
23. 23 AWS Control Towerで実装されるアーキテクチャ
24. 24 設定されるリソース一覧 • AWS Organizations ◦ Security OU ▪ Audit アカウント (+ Configアグリゲーター) ▪ Log Archive アカウント (+ ログ集約用S3バケット) ◦ Sandbox OU • CloudTrail ◦ 組織のアカウント全体を対象に有効化 • Account Factory(Service Catalog) • IAM Identity Center など
25. 25 その他設定されるControl Tower独自の機能 • Control Towerのガードレール(コントロール) ◦ 必須コントロール (デフォルト有効化) ◦ 強く推奨されるコントロール(オプション) ◦ 選択的コントロール(オプション) • リージョン拒否コントロール(SCP) ◦ Control Towerが管理するリージョン以外の操作を全面的に禁止するSCP ◦ デフォルトでは無効化されている
26. 26 問い これで安全にAWSを利用していける！ のでしょうか？
27. 27 答え まだ足りません。
28. 28 しかし... まずは、Control Towerを有効化するところから始めてください！ = Control Towerの有効化による ランディングゾーンの設定がスタート地点
29. 29 Control Tower有効化前に事前に考慮すべき点 • 運用イメージとControl Towerがマッチするか？ ◦ Control Towerの仕様に合わせた運用ができるか？ ▪ 例) CT側でマネージドで作成される範囲について、細かい設定のチューニン グができない ▪ 例) 大阪リージョンを利用する場合に機能に制約が発生する • 既存のリソースをControl Towerで利用するか？ ◦ セキュリティ監査目的のアカウント ▪ Auditアカウント、Log Archiveアカウント ◦ IAM Identity Centerディレクトリ ▪ 既存のものがあれば • 既存リソースを利用しない場合、事前の入念な設計は不要 ◦ 基本的に後から設定変更可能です ◦ ホームリージョンの設定は後から変更できないため注意 ▪ 原則、組織内で最も頻繁に使うリージョン(東京)でOK
30. 30 Control Tower有効化後、+αでやること • ガードレールの方針を決める ◦ ゆるく統制する ▪ 必須コントロールのみ + Security Hub ◦ 強く統制する ▪ Control Towerのコントロールを可能な限り設定 ▪ Security Hub + カスタムConfigルールによる追加の実装 • 追加の検出的ガードレールの実装 ◦ AWS Security Hub、Amazon GuardDutyの有効化・通知設定 ◦ Control Towerの追加コントロール(強く推奨/選択的)の実装 • 追加のOU設計 ◦ 本番ワークロードを動作させるOUが必要
31. 31 ざっくり説明 ・AWS Security Hub AWS環境内のリソースに関する セキュリティベストプラクティスのチェックを 行い、アラートを集約するCSPMサービス。 例) S3のパブリック公開をアラート検出 ・Amazon GuardDuty AWSアカウント内のセキュリティログを分 析・処理して、AWS環境上の脅威検出を可 能にするセキュリティモニタリングサービ ス。 例) IAMアクセスキーの不正利用の検出
32. 32 Security Hub、GuardDutyの設計の勘所 • 両サービス共通 ◦ Organizations統合機能を利用して各アカウントに自動展開 ◦ 各アカウントのControl Towerの管理リージョンすべてで有効化 ◦ サービスの委任管理者の設定 ▪ 例) Audit(監査)アカウントに管理者権限を委任 • AWS Security Hub ◦ 「AWS基礎セキュリティベストプラクティス」を有効化 ◦ 特定のリージョンに検出結果を集約 ◦ 検出時にメール、Slack、Teamsなどにアラートを通知する • Amazon GuardDuty ◦ 検出結果をSecurity Hubに集約
33. 33 参考: Security Hub通知の実装イメージ 参考: 【CloudFormation】Security Hubに集約した検出結果を整形して通知する仕組みを実装してみた | DevelopersIO
34. 34 追加のセキュリティ設定に関する参考資料
35. • セキュアアカウントのアーキテクチャを参考に、 AWS Control Towerで管理するセキュリティベースラインを設計しました 35 参考: AWS Control Tower実装に関する事例
36. 36 追加のOU設計 • Control Towerの初期OU設定では、本番ワークロードを 動作させるOUが存在しない ◦ 別途作成する必要がある • 上記含め、組織全体のOU設計は必須 ◦ 各資料を参考に設計しましょう
37. 37 参考: Classmethod Cloud Guidebook(CCG) - 組織管理ガイド
38. 38 参考: Classmethod Cloud Guidebook(CCG)について メンバーズのお客様に無料提供しているAWSのナレッジ集です。 クラウドジャーニーを手助けするガイドブックとして活用できます。 現在のコンテンツは以下の4つ • 組織管理ガイド • AWS利用ガイドラインサンプル • AWS Security Hubガイド • マイグレーションガイド まずはデモサイトをご覧ください →→→→→
39. 39 参考: AWS Security Reference Architecture(SRA) リンク: The AWS Security Reference Architecture | AWS Document
40. 40 3. まとめ
41. 41 まとめ: 設計の勘所 • はじめにControl Towerを有効化しましょう ◦ まずはここから始めましょう • 追加のセキュリティ設定として以下を実施します ◦ ガードレールの設計方針を決める(ゆるい制限 or 強い制限) ◦ Security Hub、GuardDutyを有効化し、通知の設定を行う ◦ 全体のOU設計を検討し、実装する • 設計・実装にあたり様々なナレッジを参考にする ◦ Classmethod CloudGuidebook(CCG) ◦ AWSドキュメント ◦ DevelopersIOブログ
42. 42 最後に... クラスメソッドはAWS Control Towerに関する サービスデリバリープログラム(SDP)の認定を国内のパートナーでは初 めて取得しました。 マルチアカウント運用、AWS Control Towerについて、なんでも ご相談ください。