CI部 佐竹です。
本日は、AWSのホワイトペーパー（白書）を読みながら、AWS Organizations の OU に関するベストプラクティスを学びたいと思います。
- はじめに
- Organizations のホワイトペーパー
- Recommended OUs
- Security OU
- Infrastructure OU
- Sandbox OU
- Workloads OU
- Policy Staging OU
- Suspended OU
- Individual Business Users OU
- Exceptions OU
- Deployments OU
- Transitional OU
- 2024年6月13日 追記 Business Continuity OU
- 余談
- まとめ
はじめに
まずは AWS Organizations に関する用語をご紹介します。
Organization (組織)
Organization は Root を頂点にしたツリー構造となる1つの組織です。Root の単位が Organization の単位になり、それぞれの組織には一意となるIDが割り振られます。
SCP (サービスコントロールポリシー)
- IAM Policy のように動作するポリシーです
- SCP は各エンティティにそれぞれ複数個付与が可能になっています（最大5つ）
エンティティ
エンティティは、以下の3つ（Root, OU, Account）です。
Root
- ルートはその組織内部で 1 つのみ（1つのAWSアカウントのみ）持つことができます
- Root は OU のように動作するため、Root に直接 SCP をアタッチすることが可能です
OU (organizational unit)
- AWSアカウントはいずれかの OU に配置されるか、もしくは Root 直接に配置されます
- OU は他の OU に所属させることが可能で、階層構造を持つことが可能です(最大5階層)
アカウント
- 個別のAWSアカウント1つを指します
- AWSアカウントもエンティティであるため、直接 SCP をアタッチすることが可能です
- Management Account（管理アカウント） は Organization 内に1つ存在し Payer（支払者）として動作します
- Management Account は Member Account（メンバーアカウント） と呼ばれるAWSアカウントを払い出すことが可能です
構成図
以下が簡易的な Organizations の構成図です。
Root を頂点に各 OU が配置され、各 OU に AWS アカウントが配置されます。Management Account は Root に直接配置されており、現時点では Management Account = Root と考えて頂いて問題ありません。
Management Account はその役割から「親アカウント」と呼ばれることがあります。Member Accountは「子アカウント」と呼ばれることがあります。
Organizations における悩み
AWS Organizations の構築において悩みの種となるのは、「どの単位で OU を分けるのか」につきます。Organizations において OU の役割は非常に重要です。それは以下の理由があげられます。
- SCP は OU 単位でアタッチ可能であり、アタッチされた SCP はその配下のエンティティに継承される
- CloudFormation StackSets は OU 単位で実行することが可能
つまり OU の単位で機能制限や統制をかけることになるため、適切に OU を設計することが適切な運用につながります。
そこで、今回は AWS 公式のホワイトペーパーから OU に関するベストプラクティスを学びたいと考えています。
Organizations のホワイトペーパー
以下のブログで紹介されている通り、2021年6月2日に Organizations のホワイトペーパーがアナウンスされました。
以下がそのホワイトペーパーになります。現時点では英語のみで閲覧可能です。
この中にある「Recommended OUs」が今回ご紹介するページとなります。
補足ですが、この内容は2020年7月21日に以下のブログでアナウンスされた内容と基本的に同じものとなっています。
それでは、ホワイトペーパーを翻訳しながらベストプラクティスをご紹介します。
なお「補足：」から始まる文章は私が補足説明のために追記した文章であり、原文には存在しません。
Recommended OUs
お客様の要件によっては、推奨されるすべてのOUを設定する必要がない場合もあります。AWSを導入し、ニーズをより深く知ることで、OUの全体的なセットを拡張することができます。AWSアカウントを整理する方法の例については、「AWSアカウントを組織するパターン」を参照してください。
推奨されるOUは一般的なユースケースに合わせて設定されていますが、ニーズに合わせて独自のOU構造を定義することも可能です。このガイダンスは、ほとんどのお客様のニーズを満たすことを目的としています。ただし、すべてのユースケースに対応するものではありません。
推奨されるOUは以下の構成から成ります：
- Security OU
- Infrastructure OU
- Sandbox OU
- Workloads OU
- Policy Staging OU
- Suspended OU
- Individual Business Users OU
- Exceptions OU
- Deployments OU
- Transitional OU
当社は、セキュリティOUとインフラストラクチャOUを基礎的 (foundational) なものとして分類しています。foundational OU には、アカウント、ワークロード、その他のAWSリソースが含まれ、AWS環境全体を安全にサポートするための共通のセキュリティおよびインフラストラクチャ機能を提供します。
foundational OU に存在する「アカウント、ワークロード、およびデータ」は、通常「セキュリティチーム、インフラストラクチャチーム、およびオペレーションチーム」からなるクロスファンクショナルな代表者で構成されるクラウドプラットフォーム、もしくはクラウドエンジニアリングチームによって管理/所有されます。
お客様のアカウントの大部分は、その他のOUに含まれており、それらのOUはお客様のビジネス関連のワークロードを格納することを目的としています。また、お客様のビジネス関連のサービスやデータのライフサイクル全体をサポートするツールやサービスも含まれています。
Security OU
Security OU は基本となる OU です。セキュリティ組織は、この OU を子OU および関連するアカウントとともに所有・管理する必要があります。Security OUには、以下のアカウントを作成することを推奨します。
- ログアーカイブ：Log archive
- セキュリティ ツーリング：Security tooling
- セキュリティの読み取り専用アクセス：Security read-only access
- セキュリティ ブレークグラス：Security break-glass
初期の要件によっては、これらのアカウントのすべてを作成する必要はないかもしれません。AWS導入の初期段階でよく使われる OU とアカウントのセット例については、Patterns for organizing your AWS accountsを参照してください。
補足：ブレークグラスとは、火災報知器を鳴らすためにガラスを割ることから名づけられたもので、特定の情報へのアクセス権限を持たない人が、必要なときに素早くアクセスできる手段のことを言います。ようは、緊急事態には権限の壁を突破できるということです
Log archive account
ログアーカイブは、組織内のすべてのアカウントから収集されるログデータの集約ポイントとして機能するアカウントで、主にセキュリティ、運用、監査、コンプライアンスの各チームが利用します。
例えば、AWS CloudTrail に記録されたAWS APIアクセスログや、AWS Config に記録されたAWSリソースへの変更ログなど、セキュリティに関わるログをこのアカウントに集約することを推奨します。また、アカウント間で VPC ピアリングを利用しているのであれば、VPCフローログのデータをこのアカウントに集約するのも効果的です。
この統合されたログデータをSIEM（Security Information and Event Management）ソリューションと統合するのは一般的な方法です。
AWS Control Tower を使ってAWS環境全体を管理しているのであれば、各アカウントで CloudTrail が自動的に有効になり、CloudTrail のログは Log archive アカウントの Amazon S3 バケットに集約されます。
運用ログデータ
インフラストラクチャ、オペレーション、及びワークロードを所有する各チームによって使用される運用ログデータは、セキュリティ、監査、コンプライアンスチームによって使用されるログデータと重複することがよくあります。
そのため、運用ログデータをログアーカイブアカウントに統合することを推奨します。セキュリティやガバナンスの要件に応じて、このアカウントに保存された運用ログデータをフィルタリングする必要があるかもしれません。また、ログアーカイブアカウントに保存された運用ログデータにアクセスできる人を制限することや、閲覧できる内容を制限する必要もあります。
不変的なログデータ
ログアーカイブ アカウントに保存されたログデータは、変更されることがない不変のものとして見なされます。
このアカウントへのアクセスの管理
このアカウントには、ログデータのみを収容し、ログデータを操作するようなワークロードを含めないことを強く推奨します。そうすることで、このアカウントへのアクセスを大幅に限定することができます。
統合されたログデータを消費（活用）する必要のあるワークロードやツールは、通常、他のアカウントに収容され、IAM ロールを介してアカウント横断的なアクセス（クロスアカウントアクセス）を与えられ、読み取り専用の最小特権でログデータにアクセスします。
Security tooling accounts
セキュリティサービス、ツール、およびサポートデータの形で広く適用可能なセキュリティ指向のワークロードを格納するために、1つ以上のセキュリティツーリングアカウントを使用することを推奨します。使用するセキュリティツーリングアカウントの数は、AWSアカウントを整理するための設計原則を考慮して決定してください。
AWSサービスの一般的な例
セキュリティツーリングアカウントで一元的にアクセス・管理できるセキュリティ機能やAWSサービスの一般的な例としては、以下のようなものがあります。
Detection
- AWS Security Hub：AWS組織内のすべてのアカウントでAWS Security Hubを有効にすることを推奨します。セキュリティツーリングアカウントの1つを、Security Hubの委任された管理者として指定できます。
- Amazon GuardDuty：AWS組織内のすべてのアカウントで、Amazon GuardDutyを有効にすることを推奨します。セキュリティツーリングアカウントの1つを、GuardDutyの委任管理者として指定できます。
- AWS Config：AWSリソース、AWS Configルール、AWSリソースのコンプライアンス状態を集約して見ることができるように、セキュリティツーリングアカウントの1つにAWS Configアグリゲータを設定することを推奨します。
Identity and Access Management
- IAM Access Analyzer：IAM Access Analyzerは、AWS組織全体を信頼ゾーンとして設定して使用することを推奨します。これにより、リソースポリシーを素早く確認し、意図しないパブリックアクセスやクロスアカウントアクセスを持つリソースを特定することが容易になります。このアナライザは、セキュリティツーリングアカウントの1つに設定することを推奨します。
Incident Response
- Amazon Detective：セキュリティツーリングアカウントの1つを、Amazon Detective、Amazon GuardDuty、およびAWS Security Hubの委任管理者として指定することを推奨します。そうすることで、これらのサービス間の統合を利用することができます。
Data Protection
- Amazon Macie：AWS組織全体でAmazon Macieを使用する場合は、セキュリティツーリングアカウントの1つをMacieの委任管理者として指定することを推奨します。
Infrastructure Protection
- AWS Firewall Manager：AWS Firewall ManagerをAWS組織全体で使用する予定の場合、セキュリティツーリングアカウントの1つをFirewall Managerの委任管理者として指定することを推奨します。
サードパーティのクラウドセキュリティ監視ツール
サードパーティのクラウドセキュリティ監視サービスやツールを、セキュリティツーリングアカウントに収容することもできます。例えば、これらのアカウントには、通常、セキュリティ情報およびイベント管理（SIEM）ツールや脆弱性スキャナーが含まれています。
自動検知・対応ワークフロー
これらのサービスで収集されたデータに基づいて動作する自動検出および応答ワークフローは、通常、セキュリティツーリングアカウントに含まれています。
インシデント対応（IR）サポート
手動のインシデント対応（IR）手順をサポートするツールは、通常、セキュリティツーリングアカウントに含まれています。
詳細については、『AWS Security Incident Response Guide』を参照してください。
セキュリティチームのアクセス
セキュリティチームのメンバーは、セキュリティサービスやツールの機能を操作したり、潜在的に設定したりするために、日常的にこれらのサービスやアプリケーションにアクセスする必要があります。このアクセスは最小限にとどめ、必要なアクション（たとえば、セキュリティツールのコンソール・ダッシュボードの表示や操作）に限定する必要があります。
可能であれば、セキュリティチームは IaC（Infrastructure-as-Code）技術を使用して、セキュリティツーリングアカウントに存在するサービスやツールの基本的な設定を自動化することを推奨します。
Security read-only access account
集約配置されたログやその他の手段が不十分な場合、「監査、探索的なセキュリティ・テスト、および調査」を支援するため、セキュリティチームのメンバーはAWS環境の各アカウントへの読み取り専用アクセスを必要とします。
一般的なアプローチは、フェデレーテッドアクセスを使用して、アカウントへの直接の読み取り専用アクセスを提供することです。AWSアカウントへの直接のフェデレーテッドアクセスでは、セキュリティ用の読み取り専用アクセスアカウントを使用する必要はありません。
しかし、直接フェデレーションではなく、クロスアカウントのロール（スイッチロール）を使用したい場合は、このセキュリティ読み取り専用アカウントを使用することを推奨します。例えば、セキュリティインシデントの疑いがある場合の調査の初期段階で、セキュリティチームのメンバーがまずこのアカウントにアクセスし、読み取り専用のIAMクロスアカウントロールを使って他のアカウントにアクセスし、リソースの状態を確認・監視するような場合です。
通常、このアカウントには永続的なワークロードは含まれていません。むしろ、チームメンバーは、他のアカウントにインタラクティブにアクセスするために、このアカウントを排他的に使用します。
セキュリティ用の読み取り専用アカウントを使用する場合は、セキュリティチームのメンバーがこのアカウントにアクセスできるように、フェデレーテッドアクセスを使用することを推奨します。セキュリティチームのメンバーがフェデレーテッドアクセスでこのアカウントにアクセスしたら、クロスアカウントIAMロールを使用して、セキュリティチームのメンバーに対象となる各アカウントへのクロスアカウントアクセスを提供することを推奨します。
Security break-glass account
セキュリティインシデントや、標準的なアクセスメカニズムが利用できない例外的なケースをサポートするために、権限のある管理者が一時的にアカウントへの必要なアクセスを得ることができるプロセスを用意する必要があります。
承認された管理者に、アカウントへの一時的なブレイクグラスアクセスを提供するための全体的なプロセスによっては、セキュリティブレイクグラスアカウントが必要ない場合があります。ただし、全体的なブレイクグラスプロセスにクロスアカウントロールの活用が含まれる場合、セキュリティブレイクグラスアカウントを使用することでメリットが得られる場合があります。
このようなアカウントはめったに利用されるものではありませんが、セキュリティチームや運用チームのメンバーが、標準的なアクセスメカニズムが利用できない場合でも、アカウントへの広範な書き込みアクセスを可能にすることが可能となります。インシデント発生時にセキュリティチームやオペレーションチームのメンバーがこのアカウントにアクセスするには、特別な権限が必要であり、すべてのアカウントアクセスは詳細に記録されます。インシデントが解決されると、このアカウントへの一時的なアクセスは取り消されます。
通常、このアカウントに必要なサポートツールは、自動化を使用してオンデマンドで作成し、インシデントが解決した後にこれらのサポートツールを削除します。
Example structure
以下の構成例は、Prod および Test の子 OU を通じて、本番環境のワークロードとリソースを非本番環境から分離することを推奨しています。
アカウント名の例には、-testおよび-prodという修飾子が付いています。test修飾子は、非プロダクション環境を意味します。prod修飾子は、特定のケイパビリティまたはワークロードに対する安定したプロダクション品質の環境を示します。prod修飾子は、ケイパビリティまたはワークロードの環境が、他の本番品質のケイパビリティまたはワークロードのサービスのみに限定されることを意味するものではありません。
例えば、log-archive-prodという例示的な名前で表されるアカウントは、すべてのアカウントにわたるすべてのログデータの統合ポイントとなることが期待されます。これは単に、ログアーカイブ機能の安定した本番品質の形態です。
同様に、他のアカウントで-prod修飾子を使用することは、それらのアカウントの本番環境への適用を制限することを意図していません。
クラウドリソースの命名規則によっては、安定した本番品質のケイパビリティやワークロードを含むAWSアカウントの名前に修飾子を適用しないこともできます。
次の例では、security-tooling-testアカウントまたは環境が含まれています。このアカウントでは、新しいリソース構成や変更されたリソース構成を、それらの変更がsecurity-tooling-prodアカウントに昇格する前にテストおよび検証することができます。
本番用と非本番用のワークロードを分離するための一般的なガイダンスについては「Organizing workload-oriented OUs」を参照してください。
Infrastructure OU
インフラストラクチャ OU は、共有インフラストラクチャ サービスを格納するための基盤となる OU です。インフラチームは、このOU、子OU、および関連するアカウントを所有し、管理する必要があります。
このOUの一般的な使用例としては、多くのネットワークリソースの集中管理が挙げられます。例えば、AWS Site-to-Site VPN接続、AWS Direct Connect統合、AWS Transit Gateway構成、DNSサービス、Amazon VPCエンドポイント、共有VPCとサブネットなどです。より高度なユースケースとしては、インターネットトラフィックのインバウンドおよびアウトバウンドのプロキシおよびフィルタリングの集中管理に使用されるVPCやネットワークセキュリティスタックがあります。
共有ネットワークサービス以外にも、このOUで他の共有インフラサービスを管理することもできます。例えば、ハイブリッドDNSとディレクトリサービスのためのAmazon Route 53リゾルバエンドポイントを含む共有インフラストラクチャサービスVPCを管理することができます。
インフラストラクチャ以外の共有サービスを含める場所についてのガイダンスは、「ワークロードOU」を参照してください。
Example structure
Security OU の例と同様に、以下の構造例は、Prod および Test の子 OU を通じて、本番環境のワークロードとリソースを非本番環境から分離することを推奨しています。
この例では、network-prod アカウントには、安定した本番品質のネットワーク機能とワークロードが含まれています。これらの機能やワークロードの性質によっては、本番環境と非本番環境の両方をサポートすることになります。
network-testおよびshared-infra-testアカウントは、本番品質の環境に変更を反映させる前に、チームが共通のネットワーク機能や共有インフラストラクチャ・サービスへの変更をテストし、検証するための個別の環境を用意する例を示しています。
本番環境と非本番環境のワークロードを分離するための一般的なガイダンスについては、「Organizing workload-oriented OUs」を参照してください。
Sandbox OU
サンドボックスOUには、AWSサービスやその他のツールやサービスを、許容される使用ポリシーに従って、一般的にビルダーが自由に探索・実験できるアカウントが含まれています。これらの環境は通常、お客様の内部ネットワークや内部サービスから切り離されています。
ビルダーまたはチームごとのサンドボックスと支払い制限
一般的には、各ビルダーや小規模なチームにサンドボックスアカウントを提供し、クラウドの利用予算を設定することで、AWSの利用がポリシーに沿っていることを確認します。より高度なシナリオでは、ビルダーやチームに複数のサンドボックスアカウントを持つオプションを提供して、複数のアカウントを使用する構成をより自由に試すことができるようにすることもできます（例えば、クロスアカウントのIAMロールの実験など）。
組織内のアカウント数には上限があります。何千人ものビルダーがいて、各ビルダーにサンドボックス環境を割り当てることを想定している場合、アカウントの最大割当数に抵触する可能性があります。組織内の最大アカウント数の詳細については、「AWS組織のクォータ」を参照してください。
数千以上のサンドボックスアカウントが必要な場合は、サンドボックスアカウントを含む1つまたは複数の別の組織を作成するか、使用しなくなったサンドボックスをリサイクルするプロセスを確立することを検討してください。
一時的なリソースと環境
永続的な開発環境とは異なり、サンドボックス環境で作成されるリソースは一時的なものであることをビルダーに期待するのが一般的です。コストコントロールの手段として、またサンドボックスリソースの一時的な性質を強化するために、これらの環境で作成されたリソースを定期的にパージする自動化された手順を導入することができます。また、コスト削減のために、通常の営業時間外にAmazon EC2インスタンスなどのリソースを自動で停止することもできます。
広範囲なアクセス
サンドボックス型のアカウントでは、各アカウント内での管理者的なアクセス、ほとんどのAWSサービスへのフルアクセス、そして場合によってはインターネットへのアウトバウンドおよびインバウンドのアクセスなど、広範囲のアクセスが一般的に提供されます。インターネットへのアクセスは、AWSサービスのAPIへの接続、外部からアクセス可能なソフトウェアパッケージのダウンロード、一般に公開されているサービスとの統合などに必要となる場合があります。
企業のリソースや非公開データへのアクセス不可
サンドボックス環境で提供されるアクセスの範囲を考えると、企業は通常、ガードレールと内部使用契約を組み合わせて、構築者がサンドボックスアカウントから企業のリソースやデータにアクセスすることを制限しています。また、サンドボックス環境では、専有のソースコードやバイナリなどの非公開データや知的財産の使用は通常認められません。
サンドボックスと開発環境
非公開データの使用や、開発環境で実行される作業のより正式な性質のため、サンドボックス環境と開発環境を高レベルで区別することを推奨します。例えば、開発環境では、お客様のチームはより正式な実験、日常的な開発、初期のテスト作業を行っており、お客様の知的財産やソースコードや成果物の管理などのエンタープライズサービスへのアクセスが必要となります。
サンドボックス環境、開発環境、およびその他の環境間の潜在的な違いについては、以下の付録を参照してください。
- Appendix B – Worksheet for mapping workload environment purposes to hosting environment types
- Appendix C – Worksheet for identifying attributes of workload hosting environments
Example structures
ビルダーまたはチームごとのサンドボックス
以下の例では、サンドボックスアカウントは、個々のビルダーとチームのために表現されています。あるユーザーは2つのサンドボックスアカウントを持っており、複数のアカウントを必要とする実験を行えるようになっています。
また、ハッカソンなどのイベントでは、一時的なチームのために一時的なサンドボックスアカウントを作成することも有効です。
一時的なリサイクルサンドボックス
以下の例では、サンドボックスのアカウントは、環境の現在のユーザーとは独立した名前になっています。サンドボックス環境は、ビルダーやチームによってチェックアウトされ、一時的に使用された後、将来の使用のためにリサイクルされます。
Workloads OU
Workloads OUは、本番環境と非本番環境の両方を含む、ビジネスに特化したワークロードのほとんどを収容することを目的としています。これらのワークロードには、市販のCOTS（Commercial Off-the-Shelf）アプリケーションと、自社で開発したカスタムアプリケーションやデータサービスが混在しています。
このOUのワークロードには、他のワークロードで使用される共有アプリケーションおよびデータサービスが含まれることがよくあります。
Example structure
以下の例は、基本的な構造を表しています。様々なビジネスユニットやチームが所有するワークロードのセットが、2つの子OUに存在します。Prod」と「Test」です。この例では、これらの領域に共通のガバナンスと運用モデルが適用されています。この例では、data-lake-prodアカウントには、他の本番ワークロードやアカウントと共有されるデータサービスが含まれています。
本番環境と非本番環境のワークロードとリソースの分離に関する一般的なガイダンスについては、「ワークロード指向のOUの整理」を参照してください。
Policy Staging OU
Policy Staging OUは、AWS環境の全体的なポリシーを管理するチームが、広範囲に影響を与える可能性のあるポリシー変更を、意図したOUやアカウントに適用する前に安全にテストすることを目的としています。例えば、SCPやタグのポリシーは、意図したOUやアカウントに適用する前にテストする必要があります。
同様に、広範囲に適用されるアカウントベースラインのIAMロールやポリシーも、ポリシーステージングOUを使用してテストする必要があります。
ワークロード固有のポリシー
ワークロード固有のIAMロールとポリシーの開発とテストは、ポリシーステージングOUを使用する必要はありません。むしろ、ワークロードを所有するチームは通常、Security, Infrastructure, and Workloads OU内の開発およびテストアカウントで、他のワークロード固有のリソースと一緒にこれらのリソースを開発およびテストします。
推奨されるテストおよびプロモーションのワークフロー
ポリシー ステージング OU で変更をテストしたら、ポリシーの変更を目的の OU 内の 1 つのアカウントに一時的に関連付けることを推奨します。変更が最終的にOUを対象としている場合は、変更を意図したOUに適用し、変更が意図したとおりに動作していることを検証した後に、アカウントから変更を削除します。
この方法では、本番環境で変更を検証してから、より広範囲に変更を適用することができます。
Example structure
この例では、一連の子 OU が全体の OU 構造を反映しています。各子OUの下には、少なくとも1つのテストアカウントが含まれています。
OU レベルで適用されることが意図されている SCP およびタグ・ポリシーのテストを支援するために、各チームはまずテスト用の子 OU の 1 つにそれらを適用する必要があります。特定のアカウントに適用されるSCPやタグ・ポリシーは、適切なテスト用の子OUの下にテスト・アカウントを作成する必要があります。
Suspended OU
Suspended OUは、一時的または恒久的に使用を停止する必要のあるアカウントの一時的な保管場所として使用されます。
アカウントをこのOUに移動しても、そのアカウントの全体的なステータスが自動的に変更されるわけではありません。例えば、アカウントの使用を永久に停止する場合は、「アカウントの閉鎖」のプロセスに従ってアカウントを永久に閉鎖します。
Suspended OU の使用例としては、以下のようなものがあります。
- ある人のサンドボックスアカウントが、その人の退社により不要になった場合。
- ワークロードアカウントが、リソースの引退や他のアカウントへの移行により不要になった場合。
停止中のアカウントでの活動の抑制
サービスコントロールポリシー（SCP）を使用して、セキュリティチームとクラウドプラットフォームチーム以外のユーザーが各アカウントでAWS APIを使用することを禁止することができます。さらに、アプリケーションレベルのアクセスを削除して、ユーザーが停止された各アカウントのアプリケーションリソースにアクセスしたり管理したりできなくすることもできます。
リスクを低減し、コストを最小限に抑える可能性があるため、停止された各アカウントで実行中のリソースやアプリケーションを停止することもできます。
アカウントの閉鎖が意図されていない限り、停止中のアカウントからリソースを削除してはいけません。
停止中のアカウントへのタグ付け
一時停止されたOUは様々な用途で使用される可能性があるため、各アカウントにタグを適用して、アカウントを移動した理由とアカウントの元となったOUを記録することを推奨します。一時停止のユースケースをサポートするために確立した各プロセスは、タグを使用して、一時停止されたアカウントを自動的に処理することができます。また、このタグは、アカウントのライフサイクルを内部で追跡・監査する際にも役立ちます。
補足：AWS Organizationsの機能で、各アカウントやOUにタグを付与することが可能です
停止されたアカウントの閉鎖
アカウントが閉鎖プロセスの開始前にこのOUに移動された場合、アカウントがこのOUに移動されてから一定の日数後にアカウント閉鎖プロセスを自動的に開始するポリシーとプロセスを実装することができます。
アカウントの閉鎖プロセスが完了すると、そのアカウントは組織内で表示されなくなります。
補足：閉鎖されたAWSアカウントは数カ月間支払い処理などの理由で削除されずに残存します。その間、CloudFormation StackSets は閉鎖されたアカウントでも実行されますがスタックは失敗します。そのため失敗しても問題がないとする Suspended OU に移動させるのは StackSets の管理面でも有効です。
Individual Business Users OU
Individual Business Users OUには、Workloads OUで管理されているリソースのコンテキスト外のAWSリソースを直接管理するためのアクセスを必要とする、個々のビジネスユーザーやチームのアカウントが収容されています。
いくつかのケースでは、少数のAWSリソースをワークロード以外のものとして考えることができます。例えば、ビジネスチームが、マーケティングビデオやデータをビジネスパートナーと共有するために、Amazon S3バケットへの書き込みアクセスを必要とする場合があります。このような場合には、ワークロードOUのアカウントではなく、個々のビジネスユーザーOU内のアカウントでこれらのリソースを管理することを選択することができます。
ガードレール
このOUと許可されたユーザーには、SCPとIAMパーミッションの組み合わせを適用することを推奨します。これにより、必要なAWSサービス、リソース、アクションのみが付与されるようになります。ユースケースの性質に応じて、このOUの個々のアカウントにガードレールを適用することができます。
アカウントへのユーザーの直接アクセスを必要としないサービス（補足：IAM Userを経ずとも使用できるサービス）
アカウントへの直接アクセスを必要とせずに、ユーザーがアプリケーションやサービスを利用するための認証や権限付与が可能な場合、個々のビジネスユーザーOUは適用されません。例えば、ビジネス・ユーザーは、ビジネス・インテリジェンス(BI)の目的でAmazon QuickSightへのアクセスを必要とすることがよくあります。QuickSightベースのBI機能をワークロードとみなした場合、Workloads OUのワークロードアカウントにQuickSightリソースとデータを配置できます。この場合、BIユーザーは、アカウントレベルでのアクセスを必要とせずにQuickSightサービスに直接アクセスする権限が与えられます。
補足：QuickSight はブラウザからURLでアクセスするサービスであり、AWSアカウントにログインして利用するサービスではないためです。このようなサービスは他にも WorkDocs や WorkSpaces 等があげられるでしょう
Exceptions OU
Exceptions OUには、Workloads OUに適用されているセキュリティポリシーの例外を必要とするアカウントが格納されます（補足：つまり、セキュリティポリシーを意図的に除外したOUです）。通常、このOUに参加させるアカウントの数は、もしあったとしても最小限とすべきです。
サービスコントロールポリシーと精査
例外というな独自の性質を考慮し、通常 SCP はこの OU のアカウントレベルで適用されます（補足：SCP は基本的に OU にアタッチしてその OU 配下の全アカウントに継承させるものですが、本 OU では例外的に各メンバーアカウントに SCP を直接アタッチするということです）。
これらのアカウントにはカスタマイズされたセキュリティ制御が適用されるため、これらのアカウントの所有者は、セキュリティ監視システムからより厳しい監視を受けることが予想されます。
Workloads OUの検討
複数のアカウントが同じ例外を必要とするパターンが発見された場合、「既存のワークロード OU 用 SCP を修正する」か、もしくは「ワークロード OU の階層構造を拡張し、そこに新たな OU と SCP を適用する」か、どちらかを検討することで、アカウントをワークロード OU 下に収容することを推奨します。ワークロード OU 下に別のレベルの OU を導入して、複数のワークロード環境に適用可能な共通のセキュリティポリシーおよび/または運用プロセスを表すことができます。詳細は、「Organizing workload-oriented OUs」を参照してください。
Deployments OU
Deployments OUには、ワークロードへの変更を構築、検証、促進、リリースする方法をサポートするリソースとワークロードが含まれています。
継続的インテグレーション／継続的デリバリ（CI/CD）機能を使用して、さまざまな種類のソースコードに対する変更の処理を管理および自動化している場合もあるでしょう。
AWS環境の外に存在するCI/CD機能の使用
AWS環境の外に存在するオンプレミスおよび/またはマネージドCI/CDに関連する機能をすでに使用しており、近い将来にAWS環境内でCI/CDサービスを使用および/または管理することが予想されない場合、Deployments OUと関連するCI/CD指向のアカウントのセットをすぐに確立する必要はないかもしれません。
このシナリオでは、AWS環境の外に存在するCI/CD機能とAWS内のワークロード環境との間のアクセスと潜在的なネットワーク接続の依存関係を解決する必要があります。
CI/CD管理機能とワークロードの分離
AWSで独自のCI/CD機能を展開・管理する場合や、AWSが管理するCI/CDサービスを使用する場合は、Deployments OU内の一連の本番用デプロイメントアカウントを使用してCI/CD管理機能を収容することを推奨します。
CI/CD管理機能をワークロード環境から分離する理由は以下の通りです。
- CI/CD機能が果たす重要な役割 - CI/CD機能は、品質検証、セキュリティ・コンプライアンス・チェック、本番候補アーティファクトの構築と公開、アーティファクトの促進、そして最終的に本番環境へのアーティファクトのリリースのトリガーを組織化する役割を担っています。これらの役割の重要性を考慮すると、ワークロード環境に適用されるものとは異なる適切なポリシーと運用方法をCI/CD機能に適用できることが重要です。
例えば、CIジョブやCDパイプラインでは、アーティファクト管理サービスに候補となるアーティファクトを公開したり、プロモートしたりするために、通常は書き込み権限が必要です。しかし、本番ワークロード環境では、すでに構築され、プロモートされた成果物を取得するために、成果物管理サービスへの読み取りアクセスのみが必要です。
- CD パイプラインが非プロダクションおよびプロダクションのワークロード環境に影響を与える - CD パイプラインが変更の検証を組織化し、最終的にプロダクションへの変更のリリースをトリガーする場合、パイプラインはしばしば非プロダクションのテストおよびプロダクションのワークロード環境の両方に存在するワークロードにアクセスする必要があります。
例えば、本番ワークロード環境でCI/CD機能を管理している場合、本番ワークロード環境から非本番環境へのアクセスを許可する必要があります。CI/CD機能をCI/CDアカウントに集約することで、本番ワークロード環境から非本番環境へのアクセスを許可しないようにすることができます。
- CI/CD機能が独自のツールに依存している - CI/CD管理機能、CIジョブ、CDパイプラインは、ワークロードの実行・運用に必要なツールとは異なるツールに依存していることが多いです。これらのツールの使用をCI/CDアカウントに限定することで、ワークロード環境の複雑さや攻撃対象を軽減することができます。
デプロイメントアカウントでのCIジョブおよびCDビルドステージの実行
CIジョブとCDパイプラインのビルドステージは正式な候補のアーティファクト(補足：正式バージョンとしてリリースされる可能性のある成果物)を生成する役割を担っているため、これらのアクティビティを本番環境で実行することを推奨します。これらのアクティビティを本番ワークロード環境で実行するのではなく、本番CI/CDアカウントで実行することを推奨します。
CI/CDアカウントとワークロードのグループとの整合性
ワークロード指向のOUで関連するワークロードをグループ化する方法に合わせて、Deployments OUでCI/CDアカウントを定義することを推奨します。そうすることで、ワークロードの各グループのセキュリティポリシーや運用要件と、それに付随するCI/CDアカウントをより簡単に一致させることができます。
この方法では、CI/CDアカウントの問題の影響範囲を単一のワークロードまたはワークロードのグループに限定することができます。1つのCI/CDアカウントで発生したアクセスの問題やリソースの競合は、ほとんどの場合、関連するワークロードのグループとワークロードが存在するアカウントにのみ影響を与える。
以下の図では、ワークロード1は、独自の本番アカウント専用のワークロードを表しています。ワークロード 2、3、および 4 は、関連するワークロードのグループとして構成され、別の本番ア カウントで管理されます。
また、テストアカウントには、ワークロードのテストインスタンスが含まれています。各テストアカウントでは、様々な形態のテストを同時にサポートできるように、特定のワークロードに 対して複数のワークロード環境が存在する可能性があります。
ワークロード 1 をサポートするために CI/CD アカウントが作成され、関連するワークロード 2、 3、4 のセットをサポートするために 2 番目の CI/CD アカウントが作成されています。各本番用CI/CDアカウントのCI/CDリソースは、テストアカウントと本番用アカウントの両方で、対象となるワークロード環境と対話する必要があるかもしれません。
マルチテナント型の共有CI/CDサービスの利用を検討する
多様なワークロードをサポートするために共通のCI/CDアカウントを使用することは、環境の管理とセキュリティの確保が困難になるため、お勧めできません。この方法では、様々なチームが共通のCI/CDサービスへのアクセスを必要とする可能性があります。共通の CI/CD アカウント内でチーム間のアクセスを分離し、多数のワークロードアカウントにまたがる悪影響を制限することは、ワークロードのグループごとに個別の CI/CD アカウントを使用する場合よりも複雑で、エラーが発生しやすくなります。
本番CI/CDサービスへのチームのアクセスを可能にする
特定のワークロードを所有するチームメンバーは、それらのワークロードに関連する本番CI/CDサービスへのある程度のアクセスを必要とします。最低でも、CIジョブやCDパイプラインの実行を監視する機能が必要です。
CIジョブとCDパイプラインが本番用CI/CDアカウントに昇格するプロセスによっては、CIジョブとCDパイプラインを所有するチーム内の指定された管理者に、CIジョブとCDパイプラインへの限定された程度の書き込みアクセスが必要な場合があります。
チームメンバーがCI/CDサービスが存在するアカウントに直接アクセスする必要があるかどうかは、使用しているCI/CDツールの種類によって異なります。例えば、独自のCI/CDツールを管理している場合、アクセス制御はCI/CDツールの中で管理され、認証はCI/CDツールが存在するアカウントのコンテキストの外で行われることが多いでしょう。この例では、チームメンバーはCI/CDアカウントに直接アクセスする必要はないでしょう。
AWSのマネージドCI/CDサービスを使用している場合、チームメンバーはCIジョブやCDパイプラインの実行を監視するために、CI/CDアカウントへの少なくとも読み取りアクセスが必要です。
次の図では、各本番CI/CDアカウントに関連するワークロードを所有するチームが、それぞれのアカウントのCI/CDリソースにアクセスしている様子が示されています。
ワークロードアカウントへの CD パイプラインアクセスの提供
CD パイプラインがワークロード環境に変更をプッシュするためにデプロイメント方法とツールを使用する場合、CD パイプラインまたはデプロイメントタスクが委任されているデプロイメントツールのいずれかが、ターゲットワークロード環境への十分な書き込みアクセスを必要とします。
ワークロード環境への変更をデプロイする別の方法として、CDパイプラインがターゲットのワークロード環境への書き込みアクセスを必要としないようにするプル型のデプロイメントがあります。プルモデルでは、対象となるワークロード環境内のツールは、対象となる変更（例えば、新しくプロモートされたアーティファクトや構成の変更など）を検出し、ワークロード環境内にそれらの変更をローカルにデプロイするために必要な権限を持っています。
CI/CD機能の変更をテストする
Deployments OUに非本番用のテストアカウントを設定することを推奨します。これらのアカウントは、本番の CI/CD 環境に変更を反映させる前に、CI/CD 機能の使用方法や管理方法の変更をテストするために使用できます。
AWSでCI/CDツールを管理することを計画している場合、CI/CD用のテストアカウントのセットを確立することが最も重要です。これらのツールの使用をサポートし、進化させるためには、本番環境とは別にテスト環境を用意する必要があります。
AWS CodePipeline、AWS CodeBuild、AWS Proton、および/またはAWS CodeDeployを含むAWSマネージドCI/CD関連サービスを使用している場合でも、テスト環境を持つことで、これらのマネージドサービスを安全に使用する方法の変更をテストすることができ、有益です。
一般的には、テスト用のCI/CD環境は、本番用のCI/CD環境や本番用のワークロード環境にはアクセスできないようにします。代わりに、テストCI/CD環境へのアクセスは、非本番のワークロード環境に限定されるべきです。
CIジョブとCDパイプラインの開発とテスト
Deployments OUは、チームがCIジョブやCDパイプラインを開発・テストするための手段として使用することを意図していません。むしろ、他のワークロードの開発や初期テストと同様に、開発用のAWS環境でCIジョブやCDパイプラインを開発、テストすることを推奨します。
他の種類のコードと同様に、CIジョブやCDパイプラインのソースを、CIジョブやCDパイプラインのプロモーションに合わせたプロセスを使って、本番のCI/CD環境にプロモートすることができます。この方法により、本番のCI/CD環境で必要なアクセスを最小限に抑え、デプロイメントOU内のテスト用CI/CD環境をCI/CD機能自体のテストに限定することができます。
Example structure
以下の例では、一連の本番アカウントは、中央で管理された共有のCI/CDサービスと、連携して管理されたビジネスユニットのCI/CDリソースのセットを表しています。
典型的なシナリオでは、-prodで修飾されたアカウントの安定した本番品質のCI/CD機能は、本番および非本番のワークロード環境の両方で変更をもたらすことが期待されます。この-prodという修飾語は、単にこれらが安定した本番品質のCI/CD環境であることを示しています。
Test OUのアカウント例は、-testで修飾されています。これらのアカウントは、安定した本番品質のCI/CD環境に変更を適用する前に、CI/CDプラットフォームへの変更やマネージドCI/CDサービスの使用方法をテストするための環境を表しています。
本番環境と非本番環境のワークロードとリソースを分離するための一般的なガイダンスについては、「Organizing workload-oriented OUs」を参照してください。
Transitional OU
移行用OUは、既存のアカウントやワークロードを、AWS環境の標準化された領域に正式に統合する前に、組織に移行するための一時的な保管場所として使用することを目的としています。
アカウントを組織に移行する一般的な理由
アカウントを組織に移行する一般的な理由は以下の通りです。
- 既にAWSを利用していてアカウントを持っている企業の買収
- 新しいAWS環境構成を構築する前に作成された独自のアカウントが存在する。
- サードパーティが管理していたアカウントの移行
AWS組織へのアカウント移行のメリット
既存のアカウントを組織に移行することで、AWS組織を利用することで以下のようなメリットが得られるようになります。
- 一元化された可視性
- 共通のポリシーを適用するためのオプション
- 統合された請求、コスト、および資産管理
- AWS Organizationsに対応したAWSセキュリティサービスの簡素化された利用
- 既存のフェデレーテッド・アクセス機能との統合
アカウントを組織に移動する際の注意点
既存の組織からアカウントを移動する場合は、まずそのアカウントを組織から削除する必要があります。詳細は、「メンバーアカウントを組織から削除する」を参照してください。アカウントを組織から削除すると、そのアカウントはスタンドアロンアカウントと呼ばれます。
他のアカウントに依存していないスタンドアロンアカウントの移動は、簡単な手順で行えます。この場合、通常、移動するアカウントの既存のワークロードを移行または変更する必要はありません。詳細は、「組織に参加するアカウントを招待する」を参照してください。
移動するスタンドアロンアカウントが他のアカウントに依存している場合は、それらの依存関係を評価して、アカウントを移動する前に対処すべきかどうかを判断する必要があります。
対象となる組織では、組織のルートにあるSCPを確認し、それらのSCPが移動するアカウントに悪影響を及ぼさないことを確認することを推奨します。
関連するアカウントのセットを組織に移動する場合は、関連するアカウントのセットのために移行OUの下に子OUを作成することができます。
アカウント移動後
時間の経過とともに、これらのアカウントとその中に含まれるワークロードの方向性をより深く理解できるようになると、アカウントをそのままワークロードOUに移動したり、ワークロードを他のアカウントに移行するための投資を行ったり、ワークロードまたはアカウントのいずれかを廃止したりすることができます。
Recommended OUs の翻訳はここまでとなります。
2024年6月13日 追記 Business Continuity OU
2024年6月現在は推奨 OU に11個目として「Business Continuity OU」が追加されています。
これ単独の解説ブログを記載しましたので、合わせてご覧ください。
余談
AWS Control Tower
AWS Control Tower について少し触れます。
2021年4月に以下の通り東京リージョンでも利用が可能となった AWS Control Tower ですが、AWS Control Tower と上記ベストプラクティスは OU の構成が異なっています。
ざっくりではありますが、以下が Control Tower の基本的な OU 構成です。
Core OU にログアーカイブ専用のアカウントと、監査用のアカウントを用意します。また Custom OU 配下にはアプリケーション等を構築するアカウントを配置していくことになります。
AWS Landing Zone
関連してですが、 AWS Landing Zone のソリューションでも異なる OU 構造になっています。
Landing Zone では、Core OU に共有サービスアカウント、ログアーカイブアカウント、セキュリティアカウントを配置するようになっています。
これらの2つは AWS から出てきているサービスやソリューションですが、その OU 構造のベストプラクティスが時間と共に変化しているのは AWS Organizations の利用が増えてきたからと考えています。
AWS の Organizations の構成に正解があるわけではありません。お客様の利用方法によって、十人十色となるものです。ただし、ベストプラクティスはあります。またそれは時代によって異なってくるものでもありますので、定期的に OU 構成の棚卸をされるのが良いかもしれません。
まとめ
本日は AWS のホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」中から「Recommended OUs」を紹介しつつ和訳させて頂きました。OUの推奨だけでもかなりのボリュームになっていましたね。
すべてのユーザーで、これらの10個の OU が必要ということではありません。また最初からこの10個の OU を SCP 含めて作りこむのには時間を用します。ホワイトペーパーには SCP の具体的な設定値である json は提供されていませんでした。
AWSの良さは、早く始めることができ、後から進捗に応じて最適化できるというところです。最小限の OU でまずは開始して、後々必要になる OU や SCP を適宜追加されるほうがクイックで良いと考えます。
私であれば、ですが。まずは Security OU、Infrastructure OU を基礎として構築し、Sandbox OU、Workloads OU を用いてアプリケーションを実装します。削除するアカウントが出てくるタイミングで Suspended OU を用意するでしょう。
どこまで OU を設計するか悩むような場合は、「Patterns for organizing your AWS accounts」にそれぞれのパターン別に構成の紹介があります。私が先に記載したものは「Basic organization with infrastructure services」と同様の設計でした。
それぞれの構成図を参考にしてみてください。
補足
後日、複数案件の OU 設計を行った結果として、以下の OU 構成が運用上ベターだと考えられるというブログを福島が記載しておりますため、合わせて参考ください。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
