塩野義製薬様のAWS統合管理戦略 Organizations設計と運⽤の具体例 菊池 聡規 クラスメソッド株式会社 AWS事業本部

● 氏名：菊池　聡規 ● 所属：クラスメソッド株式会社 ● 2024 Japan AWS Top Engineers(Security) ● 2024 Japan AWS All Certifications Engineers ● ブログ https://dev.classmethod.jp/author/tooti/ ● X https://x.com/tttkkk215 ● 好きな技術 コンテナ、Terraform、Amazon EventBridge、AWS Step Functions ⾃⼰紹介 2

セッションの⽬的と概要 3

課題: 分散管理と属人的な運用体制 1. 複数の部署で独自にAWSアカウントを契約 ● 各部署が独自にAWSアカウントを契約し、管理が分散していた。 ● 組織全体で一貫したガバナンスが確立されていなかった。 2. セキュリティリスクの増大 ● 分散管理により、セキュリティの標準化が困難。 ● 組織全体でのセキュリティポリシーの適用が不十分で、リスクが増大。 3. 属人的な管理体制による運用の非効率 ● 運用が属人化している部分があり、知識が特定の個人に依存。 ● 社内リソースの不足により、運用の効率化が進まない。 塩野義製薬様で発⽣していた課題 4

1. 組織全体での一貫したセキュリティとガバナンスの確立 ● AWS Organizationsを用いた統合管理により、全社的なセキュリティ基準の適用が可能 に。 ● セキュリティリスクの低減とガバナンスの強化。 ● IAM Identity Centerを利用したアカウントと権限の一元管理。 2. 運用効率の向上 ● 属人的な管理から、チームベースでの標準化された運用体制へ移行。 課題解決のために実施したこと 5 AWS環境の統合管理

● 塩野義製薬様での Organizations設計をヒントに、 Organizations活用のための Tipsや具体的な実装方法を理解し、自社の環境に適用するための知見を得るこ と。 ● 運用設計の具体的な方法を理解し、自社の AWS環境の運用に役立てて頂く。 本セッションのゴール 6

AWS Organizationsの設計 7 1. OU設計 2. SCP設計 3. IAM Identity Center設計 4. セキュリティ関連AWSサービスの利⽤

AWS Organizations（以後Organizasions）とは その前にAWS Organizationsの概要 8 ※AWS Organizations terminology and concepts - AWS Organizations より

● AWS Organizations（以後Organizasions）の機能概要のおさらい ○ コスト一括管理 ■ 管理アカウントから全てのアカウントの請求情報にアクセス ○ AWSアカウントの階層的なグループ化 ■ OUという単位でアカウントをグループ化 ■ OU単位でSCPというポリシー制限をかけたり、 CloudFormationStackSetsを実行することが可能 ○ 他のAWSサービスとの統合 ■ Organizations対応しているAWSサービスで組織単位で設定を実施した り、管理することが可能 その前にAWS Organizationsの概要 9

● 先に結論 ○ まずはAWSのOU設計ベストプラクティスに倣ってはじめてみる ○ 最初に決めたOU構成が絶対ではないので運用していく中で改善 する ■ 不要と感じたOUは整理する ■ 統制したいルールが異なる、初期セットアップ方法が異なる等の場合には OU構成の変更を検討 OU設計 10

OU設計 11 ※AWSのマルチアカウント管理で意外と知られていない OU設計の話 より ● AWS推奨のOU構成例

OU設計 12

● 各OUの役割 ○ Security：ログ集約やGuardDuty, SecurityHub等の管理用 ○ Infrastructure：ネットワーク集約等の組織全体の共通インフラ用 ○ Workloads：業務用ワークロードを行うAWSアカウントを配置するOU ○ Suspended：AWSアカウントを廃止するときにいきなり削除するのではなくこの OUに移動ししばらく時間をおいてから削除する ○ Sandbox：ユーザが検証などである程度自由に使えるようにSCP等の権限を一 部緩和しているOU ○ PolicyTest：SCPテスト用のOU OU設計 13

● 塩野義製薬様における SCP設計の設計方針 ○ ControlTower有効化した際の「必須コントロール※1」、「強く推奨されるコント ロール※2」と同等のSCPをつける ○ WorkloadsOU等でのリージョン制限 ○ SCPでは細かい制御はしない ■ SCPはサイズの制限が5120文字、かつ一つのOUにアタッチできるSCP は５つまで ■ そのため条件を細かく指定するようなポリシーを書くとあっという間に上限 に達する SCP設計 14 ※1 https://docs.aws.amazon.com/controltower/latest/controlreference/mandatory-controls.html ※2 https://docs.aws.amazon.com/controltower/latest/controlreference/strongly-recommended-controls.html

● IAM Identity Centerの概要 IAM Identity Center設計 15 ここの部分が 権限設計の要

● グループの設計の課題 ○ 例えば、同じチーム内に管理者と一般メンバーがいるときチーム単位で IAM Identity Centerのグループ を作ると IAM Identity Center設計 16 ○ 上記の課題点は ■ 同じチームメンバーに一律で同じ権限 がついてしまう ■ チームメンバーによってアクセスさせたい AWSアカウントが異なるケース に対応できない

● グループの設計課題の解決案 ○ グループを<アカウント群 > * <対象アカウント群に対する権限 >の単位で作成 する IAM Identity Center設計 17 ○ チームメンバーごとに異なる権限を与えられるよう になる ○ チームメンバーごとに必要なAWSアカウント群にだけ アクセス

● グループの設計課題の解決案 (アカウント群について ) ○ グループをアカウント単位で作ってしまうとメンバーとグループの紐づけが煩雑 になる ○ そのためグループはアカウント群の単位で作成するのが良い ○ 各アカウント群に名前をつける と管理しやすい ○ アカウント群の命名例 ■ network関連アカウント群：network ■ xxx業務関連アカウント群：xxx-prodとxxx-stgといった形で環境ごとに作成 IAM Identity Center設計 18

● 許可セット ○ 許可セットは対象AWSアカウントを使用する人の役割を意識して設計 IAM Identity Center設計 19 許可セット名 想定メンバー 概要 admin CCoEの全てのメンバ 管理者 super-developer AWSアカウント利用者 NW関連権限とIAMの一部権 限を制限 developer AWSアカウント利用者 NW関連権限とIAMの全権限 を制限 reader AWSアカウント利用者 閲覧のみの権限 billing-reader 請求対応者 請求関連閲覧権限

● IAM関連権限の課題 ○ AWSアカウント利用者にIAMを自由に使える権限を渡してしまうと元の権限を 超える権限 を付与できてしまう IAM Identity Center設計 20

● IAM関連権限の課題の解決案 ○ Permissions boundaryを利用する ○ IAM Identity Center設計 21 ※Permissions boundaries for IAM entities \AWS Identity and Access Management より

● IAM関連権限の課題の解決案 IAM Identity Center設計 22

● IAM関連権限の課題の解決案 ○ 対象AWSアカウントに右記のよう なIAMポリシーを作成 ■ StackSets等で予め作成 ○ 詳細はこちらの記事を参照 ■ ご参考： AWS SSO管理者がユーザー の作成する IAMロールの権限を制限 する方法 \| DevelopersIO IAM Identity Center設計 23 { 全てのアクションを許可 }, { IAM ユーザーと IAM グループの作成、更新、削除を禁止 }, { Permissions boundary を IAM ロールから削除することを禁止 }, { Permissions boundary のポリシーの更新、削除を禁止 }, { "Effect": "Deny", "Action": [ "iam:CreateRole", "iam:AttachRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePolicy", "iam:DeleteRolePolicy", "iam:PutRolePermissionsBoundary" ], "Resource": "*", "Condition": { "StringNotLike": { "iam:PermissionsBoundary": "arn:aws:iam::*:policy/permissions-boundary" } } }

● AWS SecurityHubはOrganizations統 合可能なサービス ○ 委任管理アカウントで設定を行えば アカウント追加時に自動で有効化 ○ 統合するとメンバーアカウントの情報 が一箇所に集約 ○ リージョン集約設定により各リージョ ンの結果も一箇所に セキュリティ関連AWSサービスの利⽤ 24 ※マルチアカウント環境でセキュリティサービスの検出結果を全てSecurity Hubに集約して通知してみた | DevelopersIO より

セキュリティ関連AWSサービスの利⽤ 25 ● GuardDutyもOrganizations統合可能なサービス ○ 委任管理アカウントで設定を行えばアカウント追加時に自動で有効化 ■ S3保護、RDS保護等のオプションはアカウント毎に有効無効を選べる ○ 設定方法は以下のブログを参照 ■ Organizations 環境で Amazon GuardDuty を全リージョンへ簡単セットアッ プしてみる

運⽤設計 26 1. 運⽤メニューの考え⽅ 2. SecurityHub,GuardDutyの運⽤について

課題: 分散管理と属人的な運用体制 1. 複数の部署で独自にAWSアカウントを契約 ● 各部署が独自にAWSアカウントを契約し、管理が分散していた。 ● 組織全体で一貫したガバナンスが確立されていなかった。 2. セキュリティリスクの増大 ● 分散管理により、セキュリティの標準化が困難。 ● 組織全体でのセキュリティポリシーの適用が不十分で、リスクが増大。 3. 属人的な管理体制による運用の非効率 ● 運用が属人化している部分があり 、知識が特定の個人に依存。 ● 社内リソースの不足により、運用の効率化が進まない。 塩野義製薬様で発⽣していた課題（再掲） 27

● AWS運用をする際の一般的タスク 運⽤メニューの考え⽅ 28 種別 タスク名 概要 監視 障害検知 障害を検知する 通知 障害発生を通知する 障害対応 一次対処 障害が発生した際に実施する定型的な 手順（エスカレーションも含む） エスカレーション 一次対処で対処できないときに適切な宛 先にエスカレーションする 原因調査 障害原因の調査 根本対策提案 原因に基づき対策を提案

● AWS運用をする際の一般的タスク ● 運⽤メニューの考え⽅ 29 種別 タスク名 概要 運用代行（パッチ適用等 の障害時以外で発生する 作業を想定） 定型作業 手順書化されている作業 手順書メンテナンス 手順書の改善や修正等 非定型作業 手順書がない作業、突発的な作業や一 度きりの作業を想定 報告 レポート作成・定期報告会 運用状況やコストに関するレポートの作 成とその報告

運⽤メニューの考え⽅ 30 ● 運用を行う対象の明確化 ○ 提供するサービスの観点 ■ アカウント提供サービス ：AWSアカウント上のシステムの運用等も含め利用 者にAWSアカウントをほぼ丸ごとお渡しする形態 ■ AWS運用サービス ：EC2やRDS等の構築まで実施し、利用者にはOSより上 の層を提供するイメージの形態 ○ サービス提供基盤（インフラ）の観点 ■ 共通基盤：Organizations関連AWSサービスや共通ネットワーク部分に対す る運用 この３つを大項目としてそれぞれに含まれる作業・要素を洗い出した

運⽤メニューの考え⽅ 31 ● 運用を行う対象の明確化（ 中項目の洗い出し ） ○ アカウント提供サービスに含まれる要素・作業の例 ■ アカウント払い出し ■ アカウントクローズ ○ AWS運用サービスに含まれる要素・作業の例 ■ EC2の構築 ■ EC2の設定変更、アップデート ■ EC2のバックアップ・リストア ○ 共通基盤に関しては共通基盤を構成する AWSサービスを洗い出した ■ Organizations(SCP等) ■ IAM Identity Center ■ TransitGateway

運⽤メニューの考え⽅ 32 ● 運用メニューの作成、各メニュー実現のためのタスク化 ○ 運用を行う対象 × AWS運用をする際の一般的タスク ■ この掛け合わせで運用メニュー実現のための準備を進めていった 運用を行う対象（大項目） 運用を行う対象（中項目） AWS運用をする際の 一般的タスク 運用メニュー実現のためのタスク 共通基盤 ネットワーク管理(VPC) 運用代行 VPC IPレンジ発行・管理手順作成 VPC設定変更手順作成 監視 VPCの監視メトリクスの準備 障害検知時の通知先、エスカレーション フローの検討 障害対応 障害検知時の一次対処手順についての検 討 障害検知時の一次対処後に何をするかを 検討 ※実際のタスクの例

SecurityHub,GuardDutyの運⽤について ● 何を通知するか ○ SecurityHub,GuardDutyは共通基盤の中では特に通知が多くなる部分 ○ 通知内容をフィルタリングしないと運用する側が疲弊してしまう ■ もちろん見れるならフィルタリングせずに全て確認するのがベスト ■ しかし通知が多すぎて監視が形骸化するくらいならまずは重要なものだけしっ かり確認するというアプローチもアリ ○ SecurityHubについては以下のような方針のもとフィルタリングを進めた ■ 弊社クラスメソッドが提供するclassmethod Cloud Guidebook（以下CCG）の 推奨対応に従い、有効コントロールを決定 ■ 重要度でフィルタリング ○ GuardDutyについても重要度でフィルタリング、検知した際には利用者の確認の 上、抑制ルールを作成するかどうかを検討 33

SecurityHub,GuardDutyの運⽤について 34 ※CCG推奨対応の例

SecurityHub,GuardDutyの運⽤について ● SecurityHubの定期通知対策 ○ SecurityHubではコントロールによって は定期的にチェックが実行される ○ チェックの度にイベントが発行される。 イベントを契機にメール等に通知を行 うので、既に通知されている内容が何 度も通知されることとなる ○ 特に大量のアカウントを対象に運用し ているとこの通知の数は無視できない レベル ○ そのため右記のような仕組みを実装し ている 35 ※AWS Security Hub の検出結果を自動で「通知済み」にする | DevelopersIO より

まとめ ● AWS Organizationsの設計 ○ OU設計はAWS推奨構成からはじめよう ○ IAM Identity Centerはグループの設計に注意。実際の組織に模した形ではなく、 アカウント群 * 対象アカウント群に対する権限で作成 ○ SecurityHub等はOrganizations統合を積極的に活用しよう ● AWS Organizations下での運用設計 ○ 運用メニューは運用を行う対象 と AWS運用の一般的な要素のかけ合わせで考え てみるのも一つの手 36

37