企業でAWS Organizationsを動かすための組織設計の考え方

Transcript

1. 企業でAWS Organizationsを 動かすための組織設計の考え方 NRIネットコム TECH AND DESIGN STUDY#107 2026年7月13日 NRIネットコム株式会社 デジタルイノベーション本部 クラウドテクニカルセンター 執行役員 センター長 佐々木拓郎
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 ◼ 2000年 4月 NRIネットコム株式会社入社 ◼ 現在 執行役員 デジタルソリューション事業本部長 クラウドテクニカルセンター センター長 佐々木拓郎 ◼ 執筆
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 本日のテーマ エンタープライズAWSアカウント設計のエッセンスを紹介します • マルチアカウント管理の全体設計（OU・SCP・委任管理） • IAM Identity Center・CloudTrail・AWS Config・コスト管理の実践 • CCoEの立ち上げ方・組織への浸透・ロードマップの作り方 • エンタープライズでの実事例をベースとした設計判断の考え方 エンタープライズAWSアカウント設計 ― 責任境界からの設計書～13章のブループリント NRIネットコム株式会社 発行 ／ 佐々木 拓郎 監修 ハッシュタグ #nncstudy
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 単一アカウントの限界 01 責任境界とOU 02 権限配分 03 統制 04 可視化と組織の責任分界 05
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 1. 単一アカウントの限界
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. あなたの組織でも、こんな状況ありませんか？ • 「ルートユーザーのパスワード、誰も知らない…たぶん退職した方が設定した」 • 「請求書を見ても、どのプロジェクトのコストかまったく分からない」 • 「本番環境と開発環境が同じアカウントの中に混在している」 • 「セキュリティ監査ログはあるけど、どのアカウントにも一貫してない」 ハッシュタグ #nncstudy
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 原因はすべてつながっている これらの問題は バラバラではない 根本原因 すべてが1つのアカウントに集約され 必要な境界を作れない → 課金・セキュリティ・運用・ガバナンスを切り分けられない ハッシュタグ #nncstudy
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. よくある誤解：Organizations は「箱」ではない よくある誤解 Organizations = アカウントをまとめる箱 （≒ フォルダ） → 実態 Organizations = 境界を設計するための インフラ 「箱」という思考から離れると、設計の悩みが整理されていく ハッシュタグ #nncstudy
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. 責任境界とOU
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. AWSアカウント ＝ 責任境界 AWSアカウントは単なる「入れ物」ではない 責任の範囲を区切る境界線である アカウントが変わるごとに、責任の主体も変わる 課金境界 コスト責任の範囲が 明確になる セキュリティ境界 権限・ポリシーの 適用単位になる 運用境界 チームの担当範囲が 決まる ガバナンス境界 監査・統制の 対象単位になる ハッシュタグ #nncstudy
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 責任境界が決まると何が変わるか • 「誰のコストか」が請求書から読める • セキュリティポリシーの適用範囲が明確 • 障害時に「誰が対応するか」が自明 • 監査・コンプライアンスの対象が特定できる ハッシュタグ #nncstudy
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. OU設計の3軸：「何を分けたいか」から始める 環境軸 本番 ／ 開発 ／ 検証 変更管理・リリースフローが 異なる環境を分離 事業軸 事業部 ／ プロダクト ／ チーム コスト・権限の帰属を 組織単位で分離 規制軸 コンプライアンス要件 セキュリティ要件 外部監査スコープの分離 ハッシュタグ #nncstudy
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. OU設計の実例 ※ OU構造は組織の事情を反映する。これは一例 ハッシュタグ #nncstudy
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 「正解のOU構造」は存在しない • 組織の事情が先、AWS の制約が後 • 「他社のベストプラクティス」をそのまま使うと齟齬が生まれる • 1年後の組織変更に耐えられる設計を意識する ◦ 変化に強い設計の指針 ◦ OU は深くしすぎない（3～4階層が目安） ◦ 「機能」ではなく「責任の主体」で分ける ◦ 将来の事業拡大・統廃合を想定しておく ハッシュタグ #nncstudy
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. ここまでのまとめ AWSアカウント = 責任境界（課金 / セキュリティ / 運用 / ガバナンス） OU設計は「何を分けたいか」を組織の言葉で整理することから始まる 「正解」は1つではない。変化に強い設計を目指す ハッシュタグ #nncstudy
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. 権限配分
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 設計の3要素：権限配分・統制・可視化 権限配分 誰が・何を・どこまで できるかを設計する 主なサービス Delegated Admin AWS IAM Identity Center 統制 やってはいけないことを 仕組みで防ぐ 主なサービス SCP AWS IAM Identity Center 可視化 何が起きているかを 見えるようにする 主なサービス AWS CloudTrail AWS Config AWS Cost Explorer ハッシュタグ #nncstudy
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. 権限配分の課題：管理アカウントへの集中 やりがちなアンチパターン 管理アカウントに人が直接ログインして 何でも作業している 何が問題か • 管理アカウントへの影響がOrganizations全体に波 及する • 誰が何をしたか追跡困難（操作の混在） • 最小権限の原則が適用しにくい • セキュリティインシデント時の爆発半径が最大 解決策 委任管理 （Delegated Admin） 管理アカウントを触らずに セキュリティ・ログ等を 専用アカウントで管理する ハッシュタグ #nncstudy
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 委任管理（Delegated Admin）とは ハッシュタグ #nncstudy
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. 何を委任すべきか：判断基準 委任する（推奨） ✓ AWS Security Hub / Amazon GuardDuty / Amazon Inspector ✓ AWS Config / CloudTrail 集約 ✓ Backup 管理 ✓ Firewall Manager ✓ Service Catalog ポートフォリオ → 管理アカウントに残す • Organizations 自体の操作 • SCP の作成・適用 • 管理アカウント専用の請求設定 • ルートの操作（MFA 等） ハッシュタグ #nncstudy
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. 委任管理の落とし穴 • 委任しすぎ：セキュリティアカウントに権限が集中し、同じ問題が再発する • 委任したのに管理アカウントにも同じ設定を残す：二重管理で混乱 • 委任先アカウントのアクセス管理を忘れる：誰でも入れる状態に • 委任先のログが管理アカウントの集約ルールから外れる：盲点が生まれる 委任 = 「問題の移動」ではなく「責任の明確化」 ハッシュタグ #nncstudy
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. 統制
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. SCPとは何か：IAMポリシーとの違い IAMポリシー • IAMユーザー・ロールに「何を許可するか」を定義 • アカウント内で有効 • IDごとに付与・管理 • Allow / Deny を直接記述 vs SCP（サービスコントロールポリシー） • OU・アカウントの「最大許容範囲の上限」を設定 • Organizations 全体またはOU単位で有効 • IAMポリシーの上位に位置する制限 • Deny のみで動作（Allow しても許可にならない） SCPは「やっていいことの上限」を組織レベルで引く仕組み ハッシュタグ #nncstudy
24. 23 Copyright（C） NRI Netcom, Ltd. All rights reserved. SCPの設計：何を禁止するか リージョン制限 許可リージョン以外でのリソース作成を禁止 例: ap-northeast-1 以外は Deny ルートアカウント ルートユーザーへの操作ブロック 例: root による API 呼び出しを Deny 危険なAPI Organizations の設定変更・Leave Organization 検出系サービス（GuardDuty等）の無効化 コスト爆発防止 高コストインスタンスタイプの起動制限 例: GPU インスタンスを開発OUで制限 ハッシュタグ #nncstudy
25. 24 Copyright（C） NRI Netcom, Ltd. All rights reserved. SCPの落とし穴：継承と評価順序 継承 親OUのSCPは子OU・アカウントすべてに継承される → 上位に書いたDenyは下位で解除できない 評価順序 SCP に Allow を書いても「許可」にはならない → IAMポリシーとの AND（両方が許可して初めて実行 可） 管理アカウント適用外 SCPは管理アカウント自身には効かない → 管理アカウントへのアクセスは別途厳格に制御が必要 ハッシュタグ #nncstudy
26. 25 Copyright（C） NRI Netcom, Ltd. All rights reserved. IAM Identity Center：「人の境界」を引く • Single Sign-On（SSO）で複数アカウントに統一ログイ ン • 「誰が」「どのアカウントで」「何の権限で」ログインするかを 一元管理 • 権限セット（Permission Set）でロールを標準化 • ユーザーごとにアカウント × 権限の割り当てを細かく制御 • CloudTrail と連携し「誰がやったか」を追跡可能に ハッシュタグ #nncstudy
27. 26 Copyright（C） NRI Netcom, Ltd. All rights reserved. RCP：リソース単位の統制という新概念 RCP（Resource Control Policy）は 2024年に GA となった比較的新しい機能です • SCPは「IAMプリンシパルが何をできるか」を制限する • RCPは「リソース（S3バケット等）に誰がアクセスできるか」を制限する • 組み合わせることで「人の側」と「リソースの側」の両方から統制できる • 本書で詳しく解説しています → ※ 今日はSCPを主役に。RCPは「SCP の次に学ぶもの」と覚えておいてください ハッシュタグ #nncstudy
28. 27 Copyright（C） NRI Netcom, Ltd. All rights reserved. 統制は「見えること」があってこそ機能する CloudTrail 全APIコールを記録 「誰が・いつ・何をしたか」 の監査ログ AWS Config リソースの設定変更を記録 「どう変わったか」を追跡 コンプライアンス評価 Cost Explorer / CUR コストの可視化 アカウント別・タグ別の 費用分析 Organizations 全体でこれらを集約することで「全体が見える」状態を作る ハッシュタグ #nncstudy
29. 28 Copyright（C） NRI Netcom, Ltd. All rights reserved. ここまでのまとめ 権限配分：委任管理でセキュリティ・ログを専用アカウントへ移す → 管理アカウントは「触らない」を目指す 統制：SCPで「やってはいけないこと」を組織レベルで仕組み化する → IAMポリシーとの積がリアルな許可範囲 可視化：CloudTrail / Config / Cost Explorer を組織全体に集約する → 見えない事象は制御できない ハッシュタグ #nncstudy
30. 29 Copyright（C） NRI Netcom, Ltd. All rights reserved. 5. 可視化と組織の責任分界
31. 30 Copyright（C） NRI Netcom, Ltd. All rights reserved. 技術的な設計が整っても組織が動かない理由 よくある現場の声 「SCPを作ったが、誰が承認・変更するか決まっていなくて止まっている」 「CCoEが設計したが、各チームに浸透していない」 「情シスとCCoEで管轄が重なっていて、どちらに聞けばいいか分からない」 技術の問題ではなく、組織設計の問題 ハッシュタグ #nncstudy
32. 31 Copyright（C） NRI Netcom, Ltd. All rights reserved. CCoEと情シス、何が違うか CCoE クラウド利活用の推進 プラットフォーム基盤の整備 ベストプラクティスの展開 技術標準・ガードレール設計 情シス IT全体のガバナンス 調達・契約・コスト管理 セキュリティポリシー管理 外部監査・コンプライアンス ハッシュタグ #nncstudy
33. 32 Copyright（C） NRI Netcom, Ltd. All rights reserved. 責任分担マトリクス（RACI） R: 実行責任 A: 説明責任 C: 協議先 I: 報告先 ハッシュタグ #nncstudy
34. 33 Copyright（C） NRI Netcom, Ltd. All rights reserved. よくある失敗パターン CCoEが全部やる 推進力はあるが持続しない。CCoEメンバーが離れた瞬間に崩壊する。 情シスに全部任せる ITガバナンスは得意でもクラウド固有の設計知識は蓄積されにくい。 BUが好き勝手にやる 自由度はあるが統制・コスト・セキュリティが分散して管理不能になる。 ハッシュタグ #nncstudy
35. 34 Copyright（C） NRI Netcom, Ltd. All rights reserved. 責任分界は技術ではなく組織設計の問題 • SCPやIAMポリシーを「誰が」「どのプロセスで」変更するか決めておく • 「承認者」と「実行者」を分けて追跡可能にする • 新規アカウント払い出しのフローを事前に設計する（人が増えてからでは遅い） • 定期的なレビューサイクルを組織として回す仕組みを持つ 技術は「設計した通りにしか動かない」。組織が合意してこそ機能する ハッシュタグ #nncstudy
36. 35 Copyright（C） NRI Netcom, Ltd. All rights reserved. 今日の3行まとめ ① AWSアカウント ＝ 責任境界 課金・セキュリティ・運用・ガバナンス。4つの境界を意識してアカウントを設計する ② OU設計は組織の鏡 「何を分けたいか」を組織の言葉で整理する。正解は1つではない ③ 統制は仕組みで担保する SCP・委任管理・Identity Center・可視化ツールを組み合わせ、人に依存しない体制へ ハッシュタグ #nncstudy
37. 36 Copyright（C） NRI Netcom, Ltd. All rights reserved. 本書のご紹介 今日の40分は本書の「序章」です • マルチアカウント管理の全体設計（OU・SCP・委任管理） • IAM Identity Center・CloudTrail・AWS Config・コスト管理の実践 • CCoEの立ち上げ方・組織への浸透・ロードマップの作り方 • エンタープライズでの実事例をベースとした設計判断の考え方 エンタープライズAWSアカウント設計 NRIネットコム株式会社 発行 ／ 佐々木 拓郎 監修 ハッシュタグ #nncstudy NRIネットコムコーポレートサイトより ダウンロードできます https://dsx-marketing.nri- net.com/contact/form/download/2026 0626-01-document- cloud/?utm_source=techstudy&utm_m edium=presentation&utm_campaign= 20260713_tech107
38. 37 Copyright（C） NRI Netcom, Ltd. All rights reserved.