今日からはじめるAWSマルチアカウント戦略（登壇資料）

2025年11月19日 Classmethod社 Showcaseイベント（ガバナンス編）にて「今日からはじめるAWSマルチアカウント戦略」という題で登壇した資料です

Transcript

1. 今日からはじめる AWS マルチアカウント戦略 クラスメソッド株式会社 クラウド事業本部 コンサルティング部 荒平 祐次
2. 荒平 祐次 (Arahira Yuji) クラスメソッド株式会社 クラウド事業本部 コンサルティング部 VMware vExpert 2021-2025, Japan AWS Top Engineer 2025, AWS Community Builder (Serverless) 2
3. • マルチアカウント戦略とは ◦ AWS OrganizationsとAWS Control Tower • Service Control Policy (SCP) 紹介 ◦ オススメSCPをいくつかピックアップ • ⽣成AIの統制管理（2025年末版） • ランサムウェアから組織を守る Agenda 3
4. マルチアカウント戦略とは
5. 単⼀、もしくは複数アカウントに跨り乱雑な状態に対して 基準（戦略）を設け管理しやすいアカウント単位にすること AWSにおけるマルチアカウント戦略 5 ⼤量のシステムが所属 環境やネットワークは⼀纏め ⼤規模 AWSアカウント 権限やログもバラバラ システムA- 本番環境 システムA- ステージ環境 システムX- 開発環境 サンドボックス 環境 環境‧システムごとに分離 組織のポリシーに沿った設定 セキュリティと利便性の調和 管理しやすい
6. 環境‧システムごとにアカウントを分離するメリット - 権限分離を⾏いやすい - 本番環境を操作できる⼈数を減らすことで、内部犯⾏の防⽌ マルチアカウントの必要性 6 本番 AWSアカウント 開発 AWSアカウント 社外メンバーなど
7. 環境‧システムごとにアカウントを分離するメリット - 制限内容の柔軟性 - 後に紹介する Service Control Policy (SCP)を変えられ、柔軟性がある マルチアカウントの必要性 7 システムA- 本番環境 システムA- ステージ環境 システムX- 開発環境 サンドボックス 環境 厳しい 緩い
8. 環境‧システムごとにアカウントを分離するメリット - ログの追跡がしやすい（トレーサビリティ） - 有事の際に何があったのかを追いかける⼿間を省⼒化 マルチアカウントの必要性 8 環境‧システムがごちゃごちゃ クエリ対象データが多い （料⾦が⾼くなる） 環境‧システムが整理されている ⽬的のデータをすぐ発⾒
9. 環境‧システムごとにアカウントを分離するメリット - 爆発半径（Blast radius）の極⼩化 - セキュリティ侵害にあった場合の影響範囲を⼩さくできる マルチアカウントの必要性 9 インシデント発⽣
10. AWS Organizations バラバラになったアカウントを中央管理 マルチアカウント管理を実現する機能 10 AWSアカウント AWS Organizations AWSアカウント AWSアカウント AWSアカウント AWSアカウント 複数の アカウントを管理 統合サービスの例 AWS Security Hub Amazon GuardDuty AWS Backup AWS Transit Gateway (via RAM)
11. Service Control Policy (SCP) 制限する内容を記述する（拒否リスト）⽅式を採⽤することが多い マルチアカウント管理を実現する機能 11 引⽤：AWS再⼊⾨2023 Organizations SCP編 https://dev.classmethod.jp/articles/re-introduction-2023-aws-organizations-scp/
12. AWS Control Tower Organizations組織内のアカウントをポリシーに沿わせる マルチアカウント管理を実現する機能 12 AWS Control Tower 定義に沿って統制 組織‧管理者定義の ポリシー AWSアカウント 新AWSアカウント AWSアカウント ポリシーがOU/アカウントに 対して適⽤ AWS Organizations
13. Service Control Policy (SCP) 紹介
14. 実装⽅法を検討 そして導⼊を進める Organizations SCP、 RCP、Control Tower どうやって実現するのか ⾃組織に必要な 制限内容を⼀覧化する （どこに、何を） ※As-Isも⼤事だが To-Beベース 環境調査を⾏い ⾃組織にあるアカウントの 共通項（ベースライン） を発⾒する （個⼈的にベストだと思う）基本的な考え⽅ 組織内へのポリシー適⽤の進め⽅ 14
15. 知っておきたい基本のSCPたち - 利⽤できるリージョンの制限 - ⾼額サービスの利⽤禁⽌ - 証跡（CloudTrail）の変更禁⽌ - インターネットアクセスの禁⽌ - EBSのデフォルト暗号化を強制 - IMDSv1を禁⽌ - S3のブロックパブリックアクセスを禁⽌ Service Control Policy (SCP) 紹介 15
16. リージョン制限を実施することで得られる効果 - 攻撃対象領域（Attack Surface）の極⼩化 - シャドーITの抑制、GDPRの対応 - セキュリティサービスのコストダウン など 利⽤できるリージョンの制限 16 ap-northeast-1 ap-northeast-3 us-east-1 us-west-1 ap-south-1 ca-central-1 eu-central-1 利⽤しないリージョンを無効化
17. ポリシーのサンプル 利⽤できるリージョンの制限 17 グローバルサービスを対象外に （実際はもっとある）
18. ⼀般的に⾼額なサービス（AWS Shield Advancedなど）や EC2, RDSのハイコストインスタンスを禁⽌することが可能 ⾼額サービスの利⽤禁⽌ 18 記載したインスタンス以外は 起動できない
19. 監査などのために操作証跡を変更する権限はしっかり奪っておく 証跡（CloudTrail）の変更禁⽌ 19 CloudTrail名を指定する
20. 完全にクローズドな環境で維持したい場合に インターネットアクセスの禁⽌ 20 IGW, VPC Peeringの作成を禁⽌
21. EBSのデフォルト暗号化を無効にできないポリシー EBSのデフォルト暗号化を強制 21
22. インスタンスメタデータサービスv1 （IMDSv1）を通じたSSRF攻撃から 守るために禁⽌しておきます。 IMDSv1を禁⽌ 22 参考： [待望のアプデ]EC2インスタンスメタデータサービスv2がリ リースされてSSRF脆弱性等への攻撃に対するセキュリティが強 化されました！ https://dev.classmethod.jp/articles/ec2-imdsv2-release/
23. S3をパブリックアクセス可能な状態にするアクションを禁じる S3のブロックパブリックアクセスを禁⽌ 23
24. 紹介した⼀部SCPはControl Towerで似た制御も可能 - 利⽤できるリージョンの制限 [CT.MULTISERVICE.PV.1] - ⾼額サービスの利⽤禁⽌ - 証跡（CloudTrail）の変更禁⽌ [AWS-GR_CLOUDTRAIL_ENABLED] - インターネットアクセスの禁⽌ [AWS-GR_DISALLOW_VPC_INTERNET_ACCESS] - EBSのデフォルト暗号化を強制 [AWS-GR_ENCRYPTED_VOLUMES] - IMDSv1を禁⽌ [SH.EC2.8] - S3のブロックパブリックアクセスを禁⽌ [CT.S3.PR.12] ※ 厳密には紹介の⽂脈と異なる動作をするものもあるため要確認 補⾜ 24
25. ⼀部は aws-samples の GitHub を参考にしました。是⾮ご覧ください https://github.com/aws-samples/service-control-policy-examples 補⾜ 25
26. 生成AIの統制管理（ 2025年末版）
27. ⽇々お客さまからいただく声 ⽣成AI時代の新しい課題 27 従業員みんな 使っているツールや モデルがバラバラ 組織内に（AIに関する） ルールなど存在しない 情報漏洩のリスクがある
28. ⽇々お客さまからいただく声 ⽣成AI時代の新しい課題 28 従業員みんな 使っているツールや モデルがバラバラ 情報漏洩のリスクがある ツールなど⾃由なところは⾃由に 寄せるべきところはしっかり寄せる 利便性とセキュアの天秤
29. ある程度AWSに寄せるとしたら、以下の課題がありそう • どのモデルを使ってもらうか（開発者向け） ◦ 組織で利⽤できるモデルの制限 • 統制とのバッティング（インフラ担当向け） ◦ リージョン制限 • 有害なコンテンツのブロック（利⽤者向け） ◦ Guardrails for Amazon Bedrock ⽣成AI時代の新しい課題 29
30. AWS上で統制するなら、モデル単位で利⽤を制限することが可能 組織で利⽤できるモデルの制限 30 Claude 4.5 Sonnet のみok
31. ⼀部のモデルと前述のリージョン制限は相性が悪い場合があります リージョン制限とBedrock 31 ap-northeast-1 Amazon Bedrock コール元 （利⽤者‧端末など） ap-southeast-2 Amazon Bedrock モデルごとに設定された プロファイル ap-northeast-1 Source Region （APIリクエストを処理） Destination Region (実際の推論処理を実⾏) Pre-defined Inference Profiles (事前定義推論プロファイル)
32. という話を資料にまとめていました https://dev.classmethod.jp/articles/ ccoe-7-arap-bedrock-crossregion/ リージョン制限とBedrock 32
33. が、最新のモデルでは⽇本限定プロファイルが出現しています これを利⽤しましょう！ ※ 今後のモデルでも出るかは不明ではある リージョン制限とBedrock 33
34. ユーザーとBedrock間のやりとりに有害な⾔葉、機密情報や個⼈情報 などが含まれることを防ぐ仕組み Guardrails for Amazon Bedrock 34 業務上必要な 強度にする
35. ワードフィルターや個⼈情報フィルターにも対応 Guardrails for Amazon Bedrock 35 正規表現で定義 https://dev.classmethod.jp/articles/guardrails-for- amazon-bedrock-general-availability/
36. ランサムウェアから組織を守る
37. 対策の区分として⼤まかには４つに分けて考えます AWSレイヤーのランサムウェア対策 37 攻撃対象領域 (Attack Surface) の減少 不審挙動の検知 脅威からの防御 復旧準備
38. 対策の区分として⼤まかには４つに分けて考えます AWSレイヤーのランサムウェア対策 38 攻撃対象領域 (Attack Surface) の減少 不審挙動の検知 脅威からの防御 復旧準備 ‧AWS Backup ‧AWS Elastic Disaster Recovery ‧AWS Shield ‧AWS WAF ‧Amazon GuardDuty ‧Amazon Detective ‧AWS CloudTrail ‧Amazon CloudWatch ‧AWS Organizations ‧AWS Control Tower ‧AWS Security Hub CSPM ‧Amazon Inspector ‧AWS Network Firewall ‧AWS Direct Connect
39. まずは脅威に晒されないことが何よりも重要 - 組織として統制が取れている状況か？ - AWS Organizations, Control Tower統合機能を利⽤して確認する - 攻撃者から⾒て⼿薄になっている設定はないか？ - AWS Security Hub CSPMの「AWS Foundational Secuirty Best Practices」を⽤いて横断的にチェックをする - AWS Configのカスタムルールを活⽤する 攻撃対象領域(Attack Surface)の減少 39
40. まずは脅威に晒されないことが何よりも重要 - 通信経路の⾒直し - インターネット経由でのアクセスが必須か？ - 通信集約、専⽤線敷設など⾒直しを⾏う - SSL-VPNの脆弱性対応は素早くできているか？ - ネットワークが環境ごとに分離されているか （感染速度の違い） 攻撃対象領域(Attack Surface)の減少 40
41. AWSレイヤーで不審な挙動はキャッチできる仕組みを構築しましょう - 検知が有効になっているからOK？ - 管理者への通知、アクションまで結び付けなければ効果がない - 適切な量のアラートを通知できるようにする - 全量のアラート流すと誰もオーナーシップを持って⾒ない - メールボックスやチャットチャンネルにて重要度分けをする - フォレンジックのために操作証跡は残るようにしておく - アカウント内、または集約アカウントのS3に残していく - オブジェクトロックも有効な⼿段 不審挙動の検知 41
42. 常に攻撃を受ける可能性を考えた防御⼿段を取る - ⼀般的にはEDR製品などが有効とされる - AWSネイティブにはないので Marketplace などから調達 - インターネットに晒しているWEBアプリケーションは特に注意 - 侵⼊経路になるため、WAFやEDR導⼊、OS領域を持たないなど - データの保全‧改ざん対策をする - 書き換え不可(non-rewritable)ストレージで保管＆暗号化を⾏う - Amazon S3 Object Lock, AWS Backup Vault Lock FSx for NetApp ONTAP SnapLock 脅威からの防御 42
43. 有事の際に戻せるような備えを - バックアップを必ず取得する - 平均潜伏期間は24⽇、⻑い場合は2ヶ⽉との情報も - 数⽇‧数世代程度では感染中のデータしか残らないため、ある 程度⻑期バックアップを取るよう設定する - Organizationsでバックアップポリシーを適⽤することも可能 - 別リージョン‧別アカウントへ保全する - クロスアカウントでスタンバイを確保することも可能 - 停⽌時間が許容できないシステムがある場合に検討する 復旧準備 43
44. 気になる⽅は 44 https://dev.classmethod.jp/articles/aws-elastic- disaster-recovery-ec2-replicate/ https://dev.classmethod.jp/articles/aws-reinforce-organizations- multi-party-approval/
45. さいごに
46. • 統制管理は昨今のランサムウェア被害から注⽬度UP • マルチアカウント化は早ければ早いほど移⾏コストが低い • ⽣成AIの統制をどうやって整えるかが急務 無償のSA相談会もございます ご相談、お待ちしております！ さいごに 46