個人で企業再現：AWSマルチアカウント運用基盤の設計と構築

Transcript

1. 個人で企業再現： AWSマルチアカウント運用基盤の 設計と構築 せい(@shirodo_rider) 2026.03.16 JAWS-UG初心者支部 NW再入門！NW-JAWSコラボLT回
2. 目次 1. 自己紹介 2. 背景 3. 目的と概要 4. Organizations設計 5. 運用設計 6. 今後やりたいこと 7. まとめと感想 2
3. １. 自己紹介 3 ・名前：古谷 成康 (ふるや せいこう) ・所属：株式会社エスワイシステム ・AWS歴：11ヶ月くらい ・好きなAWSサービス：AWS Organizations ・趣味：減量、筋トレ せい(@shirodo_rider) (8月から婚活開始予定)
4. ２. 背景 4 ◆資格の勉強をしているとマルチアカウントの話はよく出てくる …が、自分で触ってみないといまいち実感が湧かない 個人で試すには ・アカウントの数だけメールアドレスが必要… ・組織を横断した権限設計やサービス設定がややこしい… ⇒ 試しにくいからこそガチでやってみたくなった！
5. ２. 背景 5
6. ３. 目的と概要 6 ✓公式推奨のベストプラクティスをベースにする ✓企業レベルのガバナンスを意識した設計 ✓混同しやすいサービスは違いや役割分担を明確にしながら進める ✓迷った時は「実際の企業だったらどうするか？」を考える × Control Towerは使わない → まずは自分で手を動かして理解する × 大規模組織向けサービスは使わない(Security Lake / CloudTrail Lake 等) → コストが高く、個人規模では過剰なため 目的：企業のマルチアカウント運用基盤を個人規模で再現すること
7. ３. 目的と概要 7 複数のAWSアカウントを一元管理し、統制を実現するためのサービス。 組織単位(OU)によるアカウントのグループ化と階層構造の機能を持つ。 各種ポリシーを活用して一元的なアクセス管理・設定ができる。 AWS Organizations Account Organizational Unit Management Account Account Account Organizational Unit Root Organizational Unit Organizational Unit Account SCP SCP RCP Organizations構成例 ◆AWS Organizationsとは
8. ３.目的と概要 8 Organizationsを利用したマルチアカウント環境を迅速に立ち上げるサービス。 ベストプラクティスに基づいた構成を自動で展開・設定できる。 AWS CloudFormation AWS Config AWS CloudTrail AWS Organizations AWS IAM Identity Center Stack AWS Control Tower ➢Organizations → 独自の要件に合わせて柔軟にきめ細かく設計・制御したい場合 ➢Control Tower → 標準化された公式推奨の構成を迅速に導入・運用したい場合 ◆AWS Control Towerとは
9. 目次 1. 自己紹介 2. 背景 3. 目的と概要 4. Organizations設計 5. 運用設計 6. 今後やりたいこと 7. まとめと感想 9
10. Organizations設計 ①OU設計 ②Identity Center設定 ③SCP 10
11. ４-➀. OU設計 11 ◆AWS公式推奨構成 (AWSホワイトペーパー：https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws- environment/organizing-your-aws-environment.html) セキュリティ統制・監査・ログ集約・脅威検知 共有基盤など全アカウント共通のインフラ 本番・非本番を含む業務ワークロードを配置 検証・実験・学習用 通常運用に収まらない用途向けの例外OU 大規模組織での特定用途向けOU Foundational OUs Root Security OU Infrastructure OU Workloads OU Application OUs Experimental OUs Sandbox OU Procedural OUs Advanced OUs Exceptions OU Transitional OU Suspended OU Policy Staging OU Deployments OU Business Continuity OU Individual Business Users OU Management Account
12. ４-➀. OU設計 12 ◆拡張性を残しつつ個人用に再設計 Foundational OUs Root Security OU Infrastructure OU Workloads OU Application OUs Experimental OUs Sandbox OU Procedural OUs Advanced OUs Exceptions OU Transitional OU Suspended OU Policy Staging OU Deployments OU Business Continuity OU Individual Business Users OU Management Account ←中間レイヤーを入れる必要性が薄い ←例外運用OUと大規模用OUは不要
13. ４-➀. OU設計 13 Security Audit Account Log Archive Account Identity Account Workloads-shared Account Sandbox Account Root Management Account Foundational OUs Security OU Infrastructure OU Workloads OU Sandbox OU Suspended OU ➀ 管理アカウント 組織管理・請求・全体統制 ➁ セキュリティアカウント セキュリティ統合・監査 ➂ ログアカウント CloudTrailとConfigのログ集約 ➃ Identityアカウント Identity Center管理 ➄ 汎用ワークロードアカウント 汎用ワークロード ⑥ 検証アカウント 検証・実験・学習用
14. ４-➁. Identity Center設計 14 ◆IAM Identity Centerとは ✓複数アカウントへのアクセスをSSOで一元管理 ✓一時クレデンシャルのみ発行（長期キー不要） ✓「人×場所×権限」の組み合わせで細かい制御が可能 AWS IAM Identity Center マルチアカウント環境における認証・認可管理のAWS公式推奨サービス ➢IAMユーザーが非推奨な理由 × アカウントごとの個別管理が必要なため管理コストが大きい × 長期クレデンシャル（アクセスキー）漏洩のリスクが常に伴う × マルチアカウント環境での「誰がどこに入れるか」の全体把握が困難
15. ４-➁. Identity Center設計 15 ◆許可セット×グループ(ユーザー)×OU(アカウント)の割り当て Organizations = オフィスビル OU・アカウント =フロアや区画・部屋 「場所」の単位 ユーザー・グループ =組織の構成員・部署 「人」の単位 許可セット =入館証の券種 「権限」の単位
16. ４-➁. Identity Center設計 16 ◆許可セット×グループ(ユーザー)×OU(アカウント)の割り当て 割り当ては「入れる区画を設定した入館証をグループごとに配布する」こと ➢グループ(人)と許可セット(権限)は1対1にしておくと見通しが良い → なるべく職能ごとに管理すると運用時に混乱しにくい
17. ４-➂. SCP設計 17 (オフィスビル内の特定の場所を物理的に施錠して立ち入り禁止にする) ➢許可セットで権限の管理はしつつ、多重に制御する ◆Service Control Policy(SCP)とは ✓Organizationsのポリシーの一種 ✓組織全体のアカウントやOUに適用できる最強のガードレール ✓明示的なDenyで「誰であっても絶対にできない」ことを設定する
18. 運用設計 ①通知 ②セキュリティ ③料金監視 ④ログ 18
19. ５-➀. 通知設計 19 ➢複数のアカウントを作成するためのメールアドレスの用意 ただし通知先のメールアドレスは1つに集約したい ➢Route53で独自ドメインを取得 Amazon Route 53 @ludwiq-org.comを購入(1年 $15.00)
20. ５-➀. 通知設計 20 ➢購入したドメインを使ったメールアドレスでアカウント作成 ➢各アドレスで受信したメールをSESで一度S3バケットに保存 → Lambdaが起動し、自分のアドレスに転送 Amazon Simple Email Service (Amazon SES) Email AWS Lambda Amazon Simple Storage Service (Amazon S3) Email
21. ５-➁. セキュリティ設計 21 Amazon GuardDuty 機械学習による分析やAWS各種ログ解析を活用した脅威検出サービス 「今まさに起きている脅威」をリアルタイムで検知できる AWS Security Hub 複数のセキュリティサービスの検知結果を一元集約し、可視化するサービス 組織全体のセキュリティ状態を業界標準に照らしてスコア化して評価できる AWS Config AWSリソースの設定を継続的に記録し、評価するサービス 定義されたルールによる静的な設定違反を検出することができる
22. ５-➁. セキュリティ設計 22 サイバー攻撃や不正操作に対するリアルタイム検知 発報したら緊急事態のためすぐに確認が必要 複数のセキュリティサービスを一元集約して可視化する 組織全体のセキュリティ状態をチェック 各設定の「あるべき状態」からの逸脱を検知する 静的な設定違反のチェック AWS Config Amazon GuardDuty AWS Security Hub ◆使い分けと役割比較 火災報知器 防災センター 消防法違反検知
23. ５-➂. コスト異常検知設計 23 ➢セキュリティ的に問題なくても料金爆発したら死ぬ Cost Anomaly Detection (AWS Cost Explorer) 機械学習により、普段の利用傾向から外れた異常値を検知する機能 突発的なコスト急増をすぐに発見して対応することが可能 AWS Budgets あらかじめ設定した予算に対して、閾値を超えた場合に通知する 突発的なコスト増の「点」ではなく、予算超過の「線」を捉えられる インシデント発生時の初動対応が極めて重要！
24. ５-➂. コスト異常検知設計 24 AWS Lambda Amazon CloudWatch Alarm 普段の料金パターンを学習して急なコスト増大を検知 「相対的な急増」を発見する仕組み 毎朝9:30に前日の料金を取得してSlack通知を行う 日々の料金を毎日確認する仕組み 設定した絶対値での閾値を超えた時に別途通知を行う 「絶対値ベースの監視」を行う仕組み ◆使い分けと役割比較 異常値検知 日次料金通知 Cost Anomaly Detection 閾値での監視
25. ５-➃. ログ設計 25 ➢組織のログは専用のアカウントに集約 ログ保管バケットにはコンプライアンスモードのObject Lockをかける 設定後は誰も保持期間中のオブジェクトを削除・変更できなくなる → 初期設定時にミスるとアカウントごと削除するしかなくなる… AWS Config AWS CloudTrail Amazon S3 S3 Object Lock Logs Log Archive Account Logs 完全な改竄防止！
26. 26 ６. 今後やりたいこと ◆CloudFormationを使ってリソース配布したい AWS CloudFormation Stack ◆いろんな人の話を聞きたい ◆社内アカウントの運用改善をしたい
27. 27 ７. まとめと感想 ◆企業再現を目標に個人でマルチアカウント基盤を設 計・構築した ◆10分で話す内容じゃない… ◆設計を考えるのが楽しかった！ →マイクラで初めてトラップタワーを作った時を思い出した ◆組織統制は奥が深い
28. ご清聴ありがとうございました！ 28