Managed Service Provider(MSP)によるマルチOrganizations管理の裏側（Security JAWS 第24回発表資料）

© 2022 NTT DATA Corporation
[Security JAWS 第24回]
Managed Service Provider(MSP)による
マルチOrganizations管理の裏側
2022年2月28日
株式会社NTTデータ奥村康晃

© 2022 NTT DATA Corporation 2
１．自己紹介
氏名：奥村康晃
所属：NTTデータビジネスソリューション事業本部
データセンタ＆クラウドサービス事業部
役割：
- クラウド分野における技術リード
- 先進技術のソリューション取り込み
好きなAWSサービス：
- Organizations

1.会社紹介/組織紹介
2.なぜマルチOrganizations？
3.Organizations管理の課題とその解決方法
4.まとめ
Agenda

4.まとめ
Agenda

会社紹介 | NTTデータ
様々な業界のお客様のニーズ・課題を踏まえた最適なシステムを
ご提案するNTTグループの会社です

組織紹介
公共分野
のお客様
金融分野
のお客様
ヘルスケア分野
のお客様
多岐にわたる業態のお客様への対応があるため、全社で一つのCCoEを作るのではなく、
2レイヤーでのCCoEによって、お客様のシステム構築/運用を実施
・・・・
1層CCoE
AWSアカウントの管理[払い出し/解約]、1st line support、請求処理等
(MSPとして守らなければならない対応を実施）
2層CCoE 2層CCoE 2層CCoE
政府統一基準対応
FISC対応
PCI/DSS対応
医療情報システムの
安全管理
ガイドライン対応本日は
この組織のお話し

組織紹介 | 1層CCoEの体制と管理対象規模
• 体制
• 社員：2～3名
• パートナー：2～3名
• 管理対象数
• AWSアカウント：約2000
小規模な体制でかなり大規模なAWSアカウントの管理を実施

4.まとめ
Agenda

２．なぜマルチOrganizations？ | AWS Organizationsとは？
• 複数のAWSアカウントを管理するための仕組み
• 使用例
• Organizations配下のすべてのAWSアカウントの一括請求
• 複数のAWSアカウントへの一括権限制御(=SCP)
• CloudTrailなど他のAWSサービスの統合管理
マルチアカウントが一般的となっている現在のAWSでは
利用が強く推奨されるサービス

２．なぜマルチOrganizations？ | 理由
論理的な境界の作成のため
①請求データが見れる範囲の限定
②Organizations連携サービスの利用要望(AWS SSO/Control Tower等)
AWS Organizations
Account
Account
Account
顧客A
AWS Organizations
Account
Account
Account
顧客B
Account
Account
Account
顧客C
AWS Organizations
AWS Single Sign-On
AWS Control Tower

２．なぜマルチOrganizations？ | 理由
論理的な境界の作成のため
①請求データが見れる範囲の限定
②Organizations連携サービスの利用要望(AWS SSO/Control Tower等)
AWS Organizations
Account
Account
Account
顧客A
AWS Organizations
Account
Account
Account
顧客B
Account
Account
Account
顧客C
AWS Organizations
AWS Single Sign-On
AWS Control Tower
100近くのOrganizationsが存在する状況に・・・

4.まとめ
Agenda

３．Organizations管理の課題
本日は下記3つの課題と対策についてご紹介
① 構成管理
② 既存AWSアカウントへのSCP適用
③ Organizations連携サービスの開放

３．Organizations管理の課題 | ①構成管理
多くのOrganizationsを管理するとなると、それぞれがどのような設定となっ
ているかの構成管理が必要になってくる
• どんなOU構成にしたか？
• どんなSCP構成にしているのか？などなど
しかし・・・・
OUやSCPといったOrganizationsレイヤーのAWSリソースが
CloudFormation未対応で、IaCによる構成管理ができない
• https://docs.aws.amazon.com/en_us/AWSCloudFormation/latest/UserGuide/a
ws-template-resource-type-ref.html
ちなみにTerraformは対応済み
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/organizations_
organization

３．Organizations管理の課題 | ①構成管理の解決方法
＜背景＞
• Terraformの維持コスト等を考えて、AWS純正のサービスである
CloudFormationが対応するのを待つべきと判断した
• しかし、CloudFormationが対応するまで何らかの対策が必要・・・
1層CCoEとしてコントロールするスコープにおいては、すべての
Organizationsを、原則同一構成とし、構成管理の負担を軽減する
解決策

1層CCoEとしてコントロールする主な要件（≒MSPとして守らなければならない最低限の
事項）が下記4点
1. Organizations(Payerアカウント配下)からの自由な離脱や参加の禁止
2. サポートプランの自由な変更の禁止
3. 請求情報をメンバーアカウントからの参照を禁止(どうしても必須の場合を除く)
4. 特定のIAMロール以外のサポートケースの起票を禁止(IAMユーザからのサポートケー
ス起票禁止)
※2層CCoEがもつガードレールの仕組みとバッティングしないように最低限に限定

1層CCoEとしてコントロールする主な要件（≒MSPとして守らなければならない最低限の
事項）が下記4点
1. Organizations(Payerアカウント配下)からの自由な離脱や参加の禁止
2. サポートプランの自由な変更の禁止
3. 請求情報をメンバーアカウントからの参照を禁止(どうしても必須の場合を除く)
4. 特定のIAMロール以外のサポートケースの起票を禁止(IAMユーザからのサポートケー
ス起票禁止)
Organizations管理アカウント(＝Payerアカウント)で権限を渡さない
メンバーアカウントでRootユーザーを渡さない
SCPで実現する
SCPおよびCloudFormation Stacksetsで実現する
※2層CCoEがもつガードレールの仕組みとバッティングしないように最低限に限定

Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
Stack
A. 特定名のIAMロール
B. 上記IAMロール用ポリシー
C. AのIAMロールへAssume Role可能な権限
を付与したIAMグループ
等を作成
SCP
・Stacksetsで作成したIAMリソースの変
更/削除をDeny
・Billing情報の変更をDeny
・特定名IAMロール以外のサポートケース
起票をDeny
SCP ・Billing情報の参照をDeny
実現する要件
・請求情報をメンバーアカウントからの参照を原則禁止
・特定IAMロール以外のサポートケース起票の禁止
OU
凡例

Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
Stack
A. 特定名のIAMロール
B. 上記IAMロール用ポリシー
C. AのIAMロールへAssume Role可能な権限
を付与したIAMグループ
等を作成
SCP
・Stacksetsで作成したIAMリソースの変
更/削除をDeny
・Billing情報の変更をDeny
・特定名IAMロール以外のサポートケース
起票をDeny
SCP ・Billing情報の参照をDeny
ポイント①
最上位OUにStacksetsを
適用し、OU移動による
IAMリソース削除を防ぐ
ポイント②
PitinOUにを用意し
想定外のメンテにも
対応可能
ポイント③
OU/SCPをネスト構成とし、
利用者要望に対応可能
実現する要件
・請求情報をメンバーアカウントからの参照を原則禁止
・特定IAMロール以外のサポートケース起票の禁止

３．Organizations管理の課題 | ②既存AWSアカウントへのSCP適用
＜背景＞
• 前スライドの通りのOU/SCP/StackSetsの基本構成で管理を行うこと
にしたが、既存AWSアカウントに対してSCPを適用してしまうと、業務に
影響を与えてしまう可能性が高い状況
既存AWSアカウント向けのOU/SCP/StackSetsの構成を作成し、
利用者に運用変更を行うための準備期間を用意できるようにした
解決策

３．Organizations管理の課題 | ②既存AWSアカウントへのSCP適用の解決方法
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Billing_Restrict
_Users
Account Account
先ほどの基本構成に加えて、既存利用者向けのOUを作成

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Billing_Restrict
_Users
Account Account
先ほどの基本構成に加えて、既存利用者向けのOUを作成

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Billing_Restrict
_Users
Account Account
IAM関連リソースの作成(StackSets)を実施

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Account Account
Billing_Restrict
_Users
Account Account
Stackで作成したIAMリソースの削除/変更禁止
SCP

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Billing_Restrict
_Users
Account Account
特定のIAMロール以外のサポートケース起票禁止(Tempは対象外)
SCP
SCP

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Account Account
Billing_Restrict
_Users
Account Account
特定のIAMロール以外のサポートケース起票禁止(Tempは対象外)
SCP
SCP
既存運用に最も影響が大きそうなサポートケース起票に関しては
並行期間を持てるように移行期間のみ所属するOUを用意

既存利用者
新規利用者
Account
Root
All
Users
Billing_Restrict
_Users
Pitin
Account
All_Previous
Previous_Users
Temp_Previous
_Users
Billing_Restrict
_Users
Pitin
Account Account
Billing_Restrict
_Users
十分な準備期間をとったのちに、SCP適用されているOUへ移動
SCP
SCP

３．Organizations管理の課題 | ③Organizations連携サービスの開放
• Organizations連携サービスは大きく分けて、①管理アカウントのみでしか利用できないものと②
委任アカウントを指定してメンバーアカウントで自由に利用できるものの2種類がある
• https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_integrate_services_li
st.html
• 厄介なのが①管理アカウントのみでしか利用できないもの（下記で委任管理者をサポートが
「いいえ」となっているサービス）

３．マルチOrganizationsの課題 | ③Organizations連携サービスの開放
管理アカウントでしか利用できないOrganizations連携サービス
• AWS Artifact
• AWS Backup
• AWS CloudTrail
• AWS Compute Optimizer
• AWS Control Tower
• AWS Directory Service
• AWS Health
• AWS Marketplace
• AWS Resource Access Manager
• Service Quotas
• AWS Single Sign-On
• タグポリシー
• AWS Trusted Advisor
これらのサービスを利用してもらうには、
管理アカウントにIAMリソースの払い出しが必要

３．Organizations管理の課題 | ③Organizations連携サービスの開放の
解決策
＜背景＞
• 管理アカウントはAWS料金をはじめとしたMSPにとってはセンシティブな
情報が多く含まれるため、利用者に自由に開放するわけにはいかない
• 管理アカウントはSCPが適用されないため、IAMを利用したアクセス制
御が必要
• Organizations連携のAWSサービスは、AWSマネージドのIAMポリシーもないことがほ
とんどのため、CloudTrailのログなどから、一つ一つAction単位で手探りで最小権限を
見つけ、利用者へ付与
• サービスアップデートが行われるため、一度決めればよいというわけではなく、何度も見直
しが必要。現在は週に1度週刊AWSやWhat’s Newなどを参照しながら、定期的に最
小権限の見直しや影響確認を実施
解決策

3.マルチOrganizationsの課題とその解決方法
4.まとめ
Agenda

まとめ
• マルチAWSアカウント環境の管理としてOrganizationsを利用すること
が増え続けており、MSPでは『マルチOrganizations』の時代に突入
• まだまだ知見の少ないOrganizationsの運用では多くの課題が出てき
つつある
1. 構成管理
2. 既存AWS環境へのSCP適用
3. Organizations連携サービスの開放
• 試行錯誤しながら、一つ一つ対応しているものの、そろそろこのレイヤーを
カバー可能なマネージドサービスが出てくることも期待

https://www.nttdata.com/jp/ja/recruit/careers/
We are hiring!

Managed Service Provider(MSP)によるマルチOrganizations管理の裏側（Security JAWS 第24回発表資料）

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Managed Service Provider(MSP)によるマルチOrganizations管理の裏側（Security JAWS 第24回発表資料）

Ähnlich wie Managed Service Provider(MSP)によるマルチOrganizations管理の裏側（Security JAWS 第24回発表資料） (20)

Mehr von NTT DATA Technology & Innovation

Mehr von NTT DATA Technology & Innovation (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)