20230829_ccoe_seminar_session_3

Transcript

1. AWS Control Towerから始める組織的AWS統制
   〜主要なサービスの概要と設計の勘所〜
   1
   

   View Slide

2. 2
   自己紹介
   ● 名前：
   芦沢広昭 / あしざわひろあき
   ● 所属・ロール：
   AWS事業本部コンサルティング部
   ソリューションアーキテクト
   ● 業務：
   AWS技術支援・コンサルティング
   ● 好きなAWSサービス：
   ● 趣味：筋トレ(目指せBIG3 350kg)
   AWS Security Lake
   AWS Control Tower
   2023 Japan AWS All Certifications Engineers
   

   View Slide

3. 3
   本日お話しすること
   1. マルチアカウント管理について
   a. なぜマルチアカウント管理が必要なのか？
   b. マルチアカウント管理における課題
   2. AWS Control Towerについて
   a. サービスの全体像
   b. 設計の勘所
   3. まとめ
   

   View Slide

4. 4
   本日話さないこと
   ● 各AWSサービスの詳細な説明
   ● 各AWSサービスの具体的な設定手順
   ● 各AWSサービスの具体的なパラメータ設計について
   

   View Slide

5. 5
   1. マルチアカウント管理について
   

   View Slide

6. 6
   問い
   なぜマルチアカウント管理が必要なのか？
   

   View Slide

7. 7
   答え
   シングルアカウント環境での
   アカウント運用が「難しい」から
   

   View Slide

8. 8
   IAM権限管理の問題
   ● シングルアカウント内に複数環境が存在するアカウントだと、
   環境(本番・開発)の取り違えによるインシデントが起きる可能性が高まる
   ● IAMによる制御も可能だが、管理が煩雑になりがち
   

   View Slide

9. 9
   請求の分割の問題
   ● 原則、利用費請求は1アカウントまとめて管理されるが、
   コスト配分タグを利用したレポート発行によりタグ毎の利用費管理が可能に
   ● ただし、コスト配分タグの付与を徹底する運用は管理が難しい
   

   View Slide

10. 10
    リソース制限の問題
    ● リソースの制限はアカウント単位で設定されている
    ● 複数環境が相乗りする環境だと、開発環境のリソースによって
    本番環境のリソースが立ち上がらず障害発生につながるケースも考えられる
    ● 事前の引き上げは可能だが、想定できない場合もある
    

    View Slide

11. 11
    マルチアカウント環境に変更すると...
    ● セキュリティ境界の明確化と権限移譲
    ○ アカウント自体がIAMの境界、細かいIAM管理が不要に
    ○ 本番以外で強いIAM権限を与えて、開発スピードが向上
    ● 請求の単位
    ○ アカウント(環境) = 請求の単位となる
    ○ 細かいコスト配分タグの運用が不要に
    ● リソース制限
    ○ 環境毎にリソース制限が完全に分離される
    

    View Slide

12. 12
    新しい組織の課題
    マルチアカウント環境にすると出てくる新しい課題
    ● アカウントがたくさんあって全体を把握できていない
    ○ 皆が自由にアカウントを払い出している
    ● アカウントの種類に応じてセキュリティレベルを制御したい
    ○ 本番ワークロードとその他で分けたい
    ● 複数アカウントのIAMの運用負荷が高い、ログインが手間
    ○ アカウントの数だけへ発生するIAM運用作業
    ● アカウントの初期設定にかかる運用作業が手間
    ○ アカウントの初期セットアップ作業に時間がかかっている
    

    View Slide

13. 13
    新しい組織の課題 → 対策
    課題に対する対策
    ● アカウントがたくさんあって全体を把握できていない
    ○ → AWS Organizationsの利用
    ● アカウントの種類に応じてセキュリティレベルを制御したい
    ○ → 予防的・発見的ガードレールの利用
    ● 複数アカウントのIAMの運用負荷が高い、ログインが手間
    ○ → SSO(Single Sign On)の実装
    ● アカウントの初期設定にかかる運用作業が手間
    ○ → アカウントベースラインの実装
    

    View Slide

14. 14
    対策の具体例
    ● AWS Organizationsを利用したアカウント管理
    ○ 組織内のアカウントを一括管理できる
    ○ 組織単位(OU)を利用したアカウントのグルーピングも可能
    ● ガードレールによる運用を阻害しないセキュリティ対策
    ○ 予防的ガードレール(SCP)
    ■ 組織レベルのアクセス制御や危険な操作の制限
    ○ 発見的ガードレール(AWS Config, AWS Security Hub)
    ■ セキュリティに問題があるリソースの設定レベルの検出
    ● IAM Identity CenterによるSSOの実装
    ○ アクセス許可設定をセットしたアカウントへのSSOが可能に
    ○ ActiveDirectory、Okta等のIdPと連携できる
    ● AWS Service Catalogを利用したアカウントベースラインの作成
    ○ アカウント作成時に事前定義したCloudFormation StackSetsを
    デプロイ、リソースを自動作成できる
    

    View Slide

15. 15
    参考: アカウントベースラインの運用イメージ
    

    View Slide

16. 16
    先述したサービスを全て入れたアーキテクチャ例
    

    View Slide

17. 17
    ここまでで実現できること
    ● 新規のアカウント払い出しと同時にセキュアな状態で
    アカウントの利用が開始できる状態になっている
    ○ 最低限実施したいセキュリティ設定が自動で設定・構築されてい
    る
    = ランディングゾーン(LandingZone)
    が構築されている状態
    

    View Slide

18. 18
    ランディングゾーンとは？
    ● AWSベストプラクティスに基づいたスケーラブルで安全な
    マルチアカウントAWS環境
    ● アプリケーションを迅速に起動しデプロイするための出発地点
    

    View Slide

19. 19
    ランディングゾーンを楽に構築・運用したい
    ● ランディングゾーンを1から構築する場合、少なくない工数がかかる
    ○ 構築にかかる負荷を減らしたい
    ● アカウントベースラインなどの更新時のアップデートの手間がかか
    る
    ○ 更新の運用にかかる負荷を減らしたい
    → ランディングゾーンをAWSマネージドに実装できる
    サービスがあれば....
    

    View Slide

20. 20
    ランディングゾーンを
    AWSマネージドに実装できるサービス
    ＝ AWS Control Tower
    

    View Slide

21. 21
    2. AWS Control Towerとは？
    

    View Slide

22. 22
    AWS Control Tower
    AWSのベストプラクティスに基づいた
    セキュアでスケーラブルなマルチアカウント環境を
    自動でセットアップできるサービス
    

    View Slide

23. 23
    AWS Control Towerで実装されるアーキテクチャ
    

    View Slide

24. 24
    設定されるリソース一覧
    ● AWS Organizations
    ○ Security OU
    ■ Audit アカウント
    (+ Configアグリゲーター)
    ■ Log Archive アカウント
    (+ ログ集約用S3バケット)
    ○ Sandbox OU
    ● CloudTrail
    ○ 組織のアカウント全体を対象に有効化
    ● Account Factory(Service Catalog)
    ● IAM Identity Center
    など
    

    View Slide

25. 25
    その他設定されるControl Tower独自の機能
    ● Control Towerのガードレール(コントロール)
    ○ 必須コントロール (デフォルト有効化)
    ○ 強く推奨されるコントロール(オプション)
    ○ 選択的コントロール(オプション)
    ● リージョン拒否コントロール(SCP)
    ○ Control Towerが管理するリージョン以外の操作を全面的に禁止するSCP
    ○ デフォルトでは無効化されている
    

    View Slide

26. 26
    問い
    これで安全にAWSを利用していける！
    のでしょうか？
    

    View Slide

27. 27
    答え
    まだ足りません。
    

    View Slide

28. 28
    しかし...
    まずは、Control Towerを有効化するところから始めてください！
    = Control Towerの有効化による
    ランディングゾーンの設定がスタート地点
    

    View Slide

29. 29
    Control Tower有効化前に事前に考慮すべき点
    ● 運用イメージとControl Towerがマッチするか？
    ○ Control Towerの仕様に合わせた運用ができるか？
    ■ 例) CT側でマネージドで作成される範囲について、細かい設定のチューニン
    グができない
    ■ 例) 大阪リージョンを利用する場合に機能に制約が発生する
    ● 既存のリソースをControl Towerで利用するか？
    ○ セキュリティ監査目的のアカウント
    ■ Auditアカウント、Log Archiveアカウント
    ○ IAM Identity Centerディレクトリ
    ■ 既存のものがあれば
    ● 既存リソースを利用しない場合、事前の入念な設計は不要
    ○ 基本的に後から設定変更可能です
    ○ ホームリージョンの設定は後から変更できないため注意
    ■ 原則、組織内で最も頻繁に使うリージョン(東京)でOK
    

    View Slide

30. 30
    Control Tower有効化後、+αでやること
    ● ガードレールの方針を決める
    ○ ゆるく統制する
    ■ 必須コントロールのみ + Security Hub
    ○ 強く統制する
    ■ Control Towerのコントロールを可能な限り設定
    ■ Security Hub + カスタムConfigルールによる追加の実装
    ● 追加の検出的ガードレールの実装
    ○ AWS Security Hub、Amazon GuardDutyの有効化・通知設定
    ○ Control Towerの追加コントロール(強く推奨/選択的)の実装
    ● 追加のOU設計
    ○ 本番ワークロードを動作させるOUが必要
    

    View Slide

31. 31
    ざっくり説明
    ・AWS Security Hub
    AWS環境内のリソースに関する
    セキュリティベストプラクティスのチェックを
    行い、アラートを集約するCSPMサービス。
    例) S3のパブリック公開をアラート検出
    ・Amazon GuardDuty
    AWSアカウント内のセキュリティログを分
    析・処理して、AWS環境上の脅威検出を可
    能にするセキュリティモニタリングサービ
    ス。
    例) IAMアクセスキーの不正利用の検出
    

    View Slide

32. 32
    Security Hub、GuardDutyの設計の勘所
    ● 両サービス共通
    ○ Organizations統合機能を利用して各アカウントに自動展開
    ○ 各アカウントのControl Towerの管理リージョンすべてで有効化
    ○ サービスの委任管理者の設定
    ■ 例) Audit(監査)アカウントに管理者権限を委任
    ● AWS Security Hub
    ○ 「AWS基礎セキュリティベストプラクティス」を有効化
    ○ 特定のリージョンに検出結果を集約
    ○ 検出時にメール、Slack、Teamsなどにアラートを通知する
    ● Amazon GuardDuty
    ○ 検出結果をSecurity Hubに集約
    

    View Slide

33. 33
    参考: Security Hub通知の実装イメージ
    参考: 【CloudFormation】Security Hubに集約した検出結果を整形して通知する仕組みを実装してみた | DevelopersIO
    

    View Slide

34. 34
    追加のセキュリティ設定に関する参考資料
    

    View Slide

35. ● セキュアアカウントのアーキテクチャを参考に、
    AWS Control Towerで管理するセキュリティベースラインを設計しました
    35
    参考: AWS Control Tower実装に関する事例
    

    View Slide

36. 36
    追加のOU設計
    ● Control Towerの初期OU設定では、本番ワークロードを
    動作させるOUが存在しない
    ○ 別途作成する必要がある
    ● 上記含め、組織全体のOU設計は必須
    ○ 各資料を参考に設計しましょう
    

    View Slide

37. 37
    参考: Classmethod Cloud Guidebook(CCG) - 組織管理ガイド
    

    View Slide

38. 38
    参考: Classmethod Cloud Guidebook(CCG)について
    メンバーズのお客様に無料提供しているAWSのナレッジ集です。
    クラウドジャーニーを手助けするガイドブックとして活用できます。
    現在のコンテンツは以下の4つ
    ● 組織管理ガイド
    ● AWS利用ガイドラインサンプル
    ● AWS Security Hubガイド
    ● マイグレーションガイド
    まずはデモサイトをご覧ください →→→→→
    

    View Slide

39. 39
    参考: AWS Security Reference Architecture(SRA)
    リンク: The AWS Security Reference Architecture | AWS Document
    

    View Slide

40. 40
    3. まとめ
    

    View Slide

41. 41
    まとめ: 設計の勘所
    ● はじめにControl Towerを有効化しましょう
    ○ まずはここから始めましょう
    ● 追加のセキュリティ設定として以下を実施します
    ○ ガードレールの設計方針を決める(ゆるい制限 or 強い制限)
    ○ Security Hub、GuardDutyを有効化し、通知の設定を行う
    ○ 全体のOU設計を検討し、実装する
    ● 設計・実装にあたり様々なナレッジを参考にする
    ○ Classmethod CloudGuidebook(CCG)
    ○ AWSドキュメント
    ○ DevelopersIOブログ
    

    View Slide

42. 42
    最後に...
    クラスメソッドはAWS Control Towerに関する
    サービスデリバリープログラム(SDP)の認定を国内のパートナーでは初
    めて取得しました。
    マルチアカウント運用、AWS Control Towerについて、なんでも
    ご相談ください。
    

    View Slide

43. View Slide