はじめに
セッション概要
クラウドガバナンスとは
AWSが推奨するOUの構造
マルチアカウントへの移行
ガバナンスに組み込むAWSセキュリティシステム
Workday社の実践的なヒント
終わりに
参考

はじめに

こんにちは、藤本です。
re:Inventから2カ月経ちましたが、今一度当時の様子を思い出しながら、参加したセッション「Achieving governance at scale(COP383):スケールに応じたガバナンスの実現」の内容をまとめていきたいと思います。

このセッションでは、re:Inventで発表された宣言型ポリシー(Declarative policies)や2024年11月に発表されたリソースコントロールポリシー(RCP)などの最新情報の説明もあり、クラウドガバナンスにおけるサービスの立ち位置や役割がよく分かる内容でした。

aws.amazon.com

セッション概要

タイトル

「Achieving governance at scale(COP383):スケールに応じたガバナンスの実現」

アジェンダ

ガバナンスの核となる要素
マルチアカウントの統合
Workdayでのガバナンスの事例

概要

セッションでは、クラウド運用のスケールに伴い、ポリシーと標準の一貫した統制を行うためのAWSのセキュリティサービスの活用方法やガバナンスを実現する方法が紹介されました。また、AWSサービスを統合することによる、ガバナンスプロセスの自動化、インシデント対応の効率化、AWS環境全体でのセキュリティのベストプラクティスの実施方法が説明されました。
2024年時点で約800アカウントを運用し、2025年には1000アカウントを超える見込み、という大規模なマルチアカウント環境を持つWorkday社から実践的なヒントも共有されました。

セッションの動画(YouTube)

www.youtube.com

セッションのスライド

https://reinvent.awsevents.com/content/dam/reinvent/2024/slides/cop/COP383_Achieving-governance-at-scale.pdf

クラウドガバナンスとは

AWSにおけるクラウドガバナンスは、「組織がベストプラクティスに従うように導く一連のルール、プロセス、レポート」と定義されています。AWSクラウドで所有および運用しているアカウント、インフラストラクチャ、環境に対してガバナンスを確立する必要があります。

aws.amazon.com

ガバナンスには、規制（Regulation）、運用（Operation）、管理（Management）の3つの主要なユースケースが存在します。これらは、組織が効果的に統制を行い、リスクを最小限に抑え、ビジネス目標を達成するために重要な役割を果たします。

規制（Regulation）に関しては、異なる業界、分野、地域ごとに異なるセキュリティフレームワークに対応する必要があります。具体的には、PCIコンプライアンスやHIPAAコンプライアンス、または地域特有のセキュリティ要件に対応することが求められます。これにより、組織は法的要求を遵守し、セキュリティの標準を維持することができます。
運用（Operation）に関しては、M&Aを実行し、異なる環境を既存の環境に統合すること、開発チームの速度と俊敏性を向上させる方法を模索することが重要です。これには、Well-Architectedな構成の構築や、モニタリング機能の強化、チームの活動を可視化するためのツールの導入が含まれます。これにより、運用の効率が向上し、組織全体のパフォーマンスが最適化されます。
管理（Management）に関しては、コスト最適化や効率性の向上が重要な焦点となります。リソースの無駄を減らし、運用コストを最小化することにより、組織はより持続可能な成長を遂げることができます。

これらを実現するには、マルチアカウント環境で実行されているリソースを十分に理解する必要があります。

AWSが推奨するOUの構造

スケーリングの重要な要素は、管理しやすい構造を構築することであると強調されていました。この構造を構築するためにAWS OrganizationsのOU(Organizational Units)単位で環境をカスタマイズする必要があります。
ここでは、AWS セキュリティリファレンスアーキテクチャ(AWS SRA)を参考に、AWSが推奨するOUの構造が紹介されました。

セキュリティOUには、セキュリティチームがセキュリティサービスを管理するためのアカウントを配置します。
例えば、ログアーカイブアカウント、セキュリティツールアカウント、セキュリティサービス読み取り専用アカウントなどが挙げられます。
ログアーカイブアカウントは、CloudTrail、Amazon VPCフローログなどセキュリティ関連の全てのログとバックアップの取り込みとアーカイブを行うアカウントです。
セキュリティツールアカウントは、セキュリティサービスの運用、AWSアカウントのモニタリング、セキュリティアラートとレスポンスの自動化などに特化したアカウントです。

インフラストラクチャOUには、ネットワークサービスや環境全体で共有されるサービス用のアカウントを配置します。
例えば、共有サービスアカウントやネットワークアカウントを配置します。
共有サービスアカウントは、複数のアプリケーションやチームが目標を達成するために使用するサービスをサポートします。ここでは、ディレクトリ (Active Directory)、メッセージング、メタデータを取り扱うAWS Systems Manager,AWS Managed Microsoft AD,IAMIdentity Center 等を活用します。
ネットワークアカウントは、アプリケーションとインターネット間の双方向インターフェイスを保護することを目的に、ゲートウェイを管理します。

Sandbox OUには、開発者がAWSサービスの検証を行うアカウントを配置します。SandboxOUでは、予算制限を設けてリソースの管理を行い、開発者が本番環境に影響を与えることなく新しいソリューションを試せるようにポリシーを少なめに設定します。

ワークロードOUには、アプリケーションを実行および運用するためのインフラストラクチャをホストするアカウントを配置します。新しいアプリケーションやプロジェクトのために環境が拡大する場合は、新しいアカウントを追加して、開発・ステージング・本番環境を分けるためのサブOUを設けます。

マルチアカウントへの移行

マルチアカウントへ移行する場合、気を付けるべき5つの観点が紹介されました。

①管理アカウントでワークロードを持たない

組織内にアカウントが少数しかなく、管理アカウントにレガシーなワークロードを含む場合は、管理アカウントとワークロードを分離して運用するように変更します。
解決策として、組織外に新しいアカウントを作成し、そのアカウントで組織を作り、既存の全アカウントをメンバーアカウントとしてその組織に移行します。これによって、管理アカウントは管理目的のみに使用され、すべてのユーザー・開発者・ワークロードは別の場所に配置されるようになります。
これは、スケーリングの重要な要素である構造作りに役立ちます。

②ワークロードを始めるときは新しいアカウントで始める

新規のアプリケーションを構築する際には、単一のレガシーアカウント内で追加のアプリケーションやサービスを構築するのではなく、新規でアカウントを作成し、アプリケーションを構築します。アカウントを作成することで自然な分離境界が生まれ、互いに影響を及ぼさない独自のスペースを確保できるようになります。

③管理アカウントとなるユーザーの数を制限する

管理アカウントのベストプラクティスで「管理アカウントにアクセスできるユーザーを制限する」とされているように、管理アカウントは、アカウント管理、ポリシー、他の AWS サービスとの統合、一括請求など重要タスクを担うため、管理者ユーザー(Admin権限)のみに制限する必要があります。

④AWS Resource Access Manager(RAM)などのリソース共有機能を利用する

AWS Resource Access Manager(RAM)を用いることで、他のアカウントと簡単にリソースの共有を行うことができます。大規模なレガシーアカウントが存在する場合もそれに手を加えることなく、複数のアカウントを効果的に活用することができます。

⑤単一のプロダクション組織を利用する

ガバナンスは組織レベルで行われるため、AWS Organizationsでは単一のプロダクション組織を持つことが推奨されています。複数の組織にまたがってシステムを運用すると、組織自体が強力なセキュリティ境界となるため、ポリシーを効果的に管理したり、セキュリティ上のインベントリを一元的に把握したりする能力が失われてしまいます。

ガバナンスに組み込むAWSセキュリティシステム

ガバナンスを効かせる環境においてセキュリティサービスを組み込む方法が紹介されました。
紹介されたセキュリティサービスを各ドメインごとにまとめました。
本記事ではサービスの基本的な説明は割愛します。

アクセス管理

AWS IAM Identity Center
IAMのRoot Access Management

AWS Identity and Access Management (IAM) でルートアクセスを一元管理 - AWS

AWS IAM Access Analyzer

私が以前執筆したAWS IAM Access Analyzerについてのブログがあるので、よかったら見てみてください!

tech.nri-net.com

可視性とモニタリング

AWS CloudTrail
AWS Security Hub
AWS GuardDuty

コントロール

Config Rules
宣言型ポリシー(Declarative policies)
サービスコントロールポリシー(SCP)
リソースコントロールポリシー(RCP)
AWS Control Tower

インベントリ管理

AWS Resource Explorer
AWS Config

コスト管理

Cost and Usage ReportとAmazon QuickSightを使用した自動インサイト付きのコストダッシュボード
AWS Compute Optimizer
Amazon S3 Storage Lens
AWS Cost Optimization Hub

Workday社の実践的なヒント

財務管理、人事、分析のためのクラウドベースのエンタープライズアプリケーションを提供するWorkday社から実際に約800アカウントを運用するガバナンスの事例が共有されました。
全て紹介することはできないので、個人的に気になったトピックをピックアップしました。

AWS CloudTrail

CloudTrailで証跡の設定を行う場合、各リージョンでの管理イベントの最初のコピーは無料で提供されますが、同じ管理イベントに対して追加のトレイルを作成すると、CloudTrailのコストが発生します。例えば、バージニア北部(us-east-1)と東京(ap-northeast-1)の 2 つの単一リージョンの証跡がある場合、各リージョンには証跡ログイベントが 1 つずつしかないため、 CloudTrail 料金は発生しません。
Amazon S3の読み取りと書き込みイベントについて、GetObject、DeleteObject、PutObject のAPIコールに注意が必要になります。 S3を頻繁に利用するチームでは、CloudTrailの支出が大きくなる可能性があります。 s3:PutObject、s3:GetObject、s3:DeleteObjectの使用率が高いS3バケットは、これらのタイプのイベントの証跡のアクティビティを監視・抑制する必要があります。
カスタマー管理の暗号化キーを使用した暗号化に関して、中央のS3バケットでCloudTrailログを使用する場合、メンバーアカウントはローカルで90日間のアクティビティにしかアクセスできません。メンバーアカウントが90日間以上の期間でCloudTrailイベントにアクセスする場合、特にCloudTrailイベントに基づいてIAMポリシーを生成する場合は、クロスアカウントアクセスのためにKMSリソースポリシーを変更できるカスタマー管理の暗号化キーを使用するように設定します。

AWS Control Tower

すべての変更はControl Towerを通じて行う必要があります。 Control Towerを通じて操作を行わないと、ランディングゾーンがドリフトを検出し、修復されるまで機能しなくなります。
ランディングゾーンについて計画する際は、アカウントやOUの構造を十分に検討した上で、セットアップを行います。具体的なランディングゾーンの設定に関しては、AWS Control Towerのランディングゾーン向けのAWSマルチアカウント戦略で紹介されています。
Control Towerには事前に構築された多くのガードレールがあるので有効化にする前に、組織内での影響を慎重に検討する必要があります。

AWS IAM

アカウントの帰属関係を把握し、正確にデータベースインベントリを維持することが重要です。アカウントの管理者、支出の承認者、アラートの送信先を明確にし、アカウントのプロビジョニングとオフボーディング時にデータベースが動的に更新されるようにします。
「The confused deputy problem（混乱した代理人問題）」に注意する必要があります。「The confused deputy problem（混乱した代理人問題）」は、権限管理に関する問題の一つで、アクションを実行する権限を持たないエンティティが、より権限のあるエンティティにアクションを実行するように強制できるセキュリティ問題のことです。これはアイデンティティベースのポリシーとリソースベースのポリシーの両方に影響を与える可能性のある脆弱性で、クロスアカウントやクロスサービスのロールで発生する可能性があります。

ロールの信頼ポリシーで設定する外部 ID(sts:ExternalId)を条件(Condition)として含めることで、「The confused deputy problem（混乱した代理人問題）」に対処することができます。

docs.aws.amazon.com

終わりに

今回は、re:Inventで参加したセッション「スケールに応じたガバナンスの実現」の内容をまとめてみました。
スケールに応じたガバナンスを実現するためには、統制しやすい構造を構築することが重要であり、そのためにAWS OrganizationsのOU構造を見直す必要があることが分かりました。基本的原則に基づいた構造を構築した上で、AWS Control TowerやSCP、RCPの予防的ガードレールを設定することが重要です。これらを運用していく中で、制御と管理負荷はトレードオフの関係にあるため、クラウドガバナンスにおける「Simplexity」を考慮しつつ、統制を効かせていきたいと思います。本セッションの内容を踏まえ、管理しているマルチアカウント環境を基本的原則に従って見直し、現状の構造の改善点を模索していきたいと思います。