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