AWS Organizations における組織単位のベストプラクティス

AWS のお客様は、新しいビジネスのイノベーションを生み出す際に、迅速かつ安全に行動できることを求めています。マルチアカウントフレームワークは、お客様に合ったAWS 環境を計画するのに役立つガイダンスを提供します。このフレームワークは、変化するビジネスニーズに合わせて環境の拡張と適応能力を維持しながら、セキュリティのニーズを満たすように設計されています。適切に設計されたマルチアカウントの AWS 環境の基礎は AWS Organizations です。これは、複数のアカウントを一元的に管理および管理できる AWS サービスです。

この記事では、AWS環境の構築を検討する際に役立つAWS のベストプラクティスに基づいたアーキテクチャについて詳細に説明します。推奨される組織単位の構成の説明、および具体的な実装例を提供します。これらの概念の概要について詳しく知りたい場合は、Establishing your best practice AWS environment ページを確認することをお勧めします。

マルチアカウントの AWS 環境を設定する必要があるのはなぜですか?

AWS では、柔軟で安全なクラウド環境を提供しながら、より迅速に実験、イノベーション、スケーリングを行うことができます。お客様がワークロードを構築及びデプロイする際には、リソースを分離するメカニズムが必要であり、これは複数の AWS アカウントを使用して実現できます。AWS アカウントは、AWS リソースのセキュリティ、アクセス、請求の境界を提供し、リソースの独立性と分離を実現できます。たとえば、お客様のアカウント外のユーザーは、デフォルトではお客様のアカウントのリソースにアクセスできません。同様に、消費する AWS リソースのコストは、お客様のアカウントにのみ割り当てられます。AWS ジャーニーは 1 つのアカウントから始めることができますが、ワークロードのサイズと複雑さが増すにつれ、複数のアカウントを設定することをお勧めします。マルチアカウント環境を使用することは、いくつかの利点を提供するベストプラクティスです。

さまざまな要件による迅速なイノベーション: AWS アカウントを社内のさまざまなチーム、プロジェクト、またはプロダクトに割り当てることができます。個別のアカウントは、独自のセキュリティ要件に対応しながら、迅速なイノベーションのメカニズムを提供します。
請求の簡素化: 複数の AWS アカウントを使用すると、AWS 料金に影響のあるプロダクトまたはサービスラインを特定できるため、AWS コストの割り当て方法が簡素化されます。
柔軟なセキュリティ制御: 複数の AWS アカウントを使用して、特定のセキュリティ要件を持つアプリケーションを分離したり、HIPAA や PCI DSS などのコンプライアンスに関する厳格なガイドラインを満たす必要があるワークロードを分けることができます。
ビジネスプロセスへの容易な適応: さまざまな運用、規制、予算要件など、企業のビジネスプロセスの多様なニーズを最もよく反映した方法で、複数の AWS アカウントを簡単に整理できます。

つまり、マルチアカウントの AWS 環境は、プロダクトとサービスをより迅速、安全かつスケーラブルな方法で構築できるメカニズムを提供します。しかし、マルチアカウント AWS 環境をどのように構築すべきでしょうか？アカウント構成、実装するポリシーとガードレール、監査環境の設定方法など、質問があるかもしれません。

この記事では、AWS が推奨する「ランディングゾーン」と呼ばれる安全かつ生産性の高いマルチアカウント AWS 環境を構築する要素について説明します。これは、初期フレームワークを構築するために使用できるベストプラクティスを表していますが、AWS ワークロードが時間の経過とともに増加しても柔軟性は維持されます。

マルチアカウントの AWS 環境を設定するためのベストプラクティス

始める前に、いくつかの用語に慣れてみましょう。組織単位 (Organization Unit: OU) は、AWS 組織内のアカウントの論理的なグループです。OU を使用すると、階層に基づいてアカウントを整理でき、アクセス許可の管理を簡単に行えます。AWS Organizations のサービスコントロールポリシー (SCP) は、このようなコントロールを適用するためのものです。SCP は、組織内のアカウントに対して、実行可能な AWS サービスアクション (Amazon EC2 の起動など) を定義するポリシーです。

AWS環境の構築時における重要な原則は、AWS環境を管理する運用オーバーヘッドを削減することです。これを実現するために、階層全体の深さとポリシーが適用される場所を最小限に抑えました。たとえば、SCP は、アカウントレベルではなく、トラブルシューティングを容易にするため、主に OU レベルで適用されます。このアプローチの例外については後述します。

まず、作成するアカウントグループまたは OU を検討します。OU を使用すると、機能に基づいてアカウントをまとめ、共通ポリシーを適用し、まとめた AWS アカウント間で一元管理されたリソースを簡単に共有できます。OU は、会社のレポート構造を反映するのではなく、機能または共通の制御セットに基づいている必要があります。

プロダクトおよびソフトウェア開発ライフサイクル (SDLC)

基本的な OU について検討する前に、ソフトウェア開発ライフサイクル (Software Development LifeCycle: SDLC) について検討しましょう。ほとんどの企業が異なる本番ワークロードのポリシー要件を持つため、一部の OU は非本番環境 (SDLC) と本番環境 (Prod) のネストされた OU を持つことが考えられます。SDLC OU 内のアカウントは、非本番環境、つまり開発、テスト、プリプロダクションをホストします。これら非本番環境のアカウントから本番環境への依存関係を持つべきではありません。Prod OU のアカウントは、名前が示すように、本番ワークロードをホストします。お客様が自作していないアプリケーションおよびサービス、たとえば、既製のプロダクトはワークロード OU の SDLC OU 配下の開発環境に、本番環境はワークロード OU の Prod OU 配下の Prod アカウントにホストすることができます。

お客様は、アカウントの開発のすべての段階をホストする単一の SDLC OU を作成することも可能ですが、ライフサイクルの中で OU ポリシーにばらつきがある場合、SDLC OU は Dev OU や Preprod OU などの複数の OU に置き換えることもできます。いずれにしても、通常、本番ワークロードをホストするには、別個の Prod OU が存在する必要があります。

要件に応じて、OU レベルでポリシーを適用し、本番環境と SDLC 環境を管理します。一般的に、ポリシー管理と潜在的なトラブルシューティングが簡単になるため、個々のアカウントレベルではなく OU レベルでポリシーを適用することをお勧めします。

基盤 OU (Foundational Organization Units)

AWS では、セキュリティとインフラストラクチャを念頭に置いて開始することをお勧めします。ほとんどの企業には、組織全体のセキュリティやインフラストラクチャを管轄するチームがあります。そのため、これらの特定の機能のためにインフラストラクチャ OU とセキュリティ OU を分割した基盤 OU を作成することをお勧めします。

OU: インフラストラクチャ (Infrastructure)

ネットワークや IT サービスなどの共有インフラストラクチャサービスのためにインフラストラクチャ OU は使用されます。必要なインフラストラクチャサービスの種類ごとにアカウントを作成します。

例: お客様には、企業ネットワーク、RabbitMQ (メッセージバスサービス) を使用したホスト型メッセージングサービス、および一般的な共有インフラストラクチャアカウントの3 つの共有インフラストラクチャとネットワーキングサービスがあり、アクセス権限を提供します。OU とアカウントの構造は次のようになります。

OU: セキュリティ (Security)

セキュリティ OU は、セキュリティ関連のアクセスおよびサービスをホストするために使用されます。セキュリティ OU、その子 OU、および関連付けられた AWS アカウントは、セキュリティ組織が所有および管理する必要があります。

推奨アカウント

ログアーカイブ (Log Archive) : このAWS アカウントは環境内のすべての AWS アカウントから収集されたセキュリティに関連する AWS アクセスログおよび監査ログを統合します。

セキュリティ用読み取り専用アクセス (Security ReadOnlyAccess) : この AWS アカウントの目的は、セキュリティチームのメンバーが、監査、探索的セキュリティテスト、および調査のために、組織内の他の AWS アカウントに読み取り専用の権限を使用してアクセスできるようにすることです。たとえば、セキュリティインシデントが疑われる調査の初期段階では、セキュリティチームのメンバーはまずこの AWS アカウントにアクセスし、読み取り専用の IAM クロスアカウントロールを使用し、他の AWS アカウントにアクセスしてリソースの状態を確認および監視します。

セキュリティ用緊急アクセス (Security Breakglass) : このAWSアカウントは平常時はほとんど使用されないものの、セキュリティインシデント時にセキュリティチームのメンバーが使用できる AWS アカウントです。このアカウントは、AWS アカウントへの広範な書き込みアクセスを有効にします。インシデントの発生時に、セキュリティチームのメンバーがアクセスできるように特別な承認が必要になります。インシデントが解決されると、一時的なアクセスは取り消されます。すべてのアクセスは詳細にログに記録されます。

セキュリティツール (Security Tooling) : 広く適用可能なセキュリティ関連のワークロードとサービス、ツール、およびデータをホストする 1 つ以上の AWS アカウントです。このアカウントで設定されるツールおよびサービスの一般的な例としては、Amazon GuardDuty 管理アカウント、AWS Security Hub 管理アカウント、Amazon Detective 管理アカウント、およびサードパーティのモニタリングサービスやツールなどがあります。Infrastruct as Code (IaC) およびその他の自動化技術を使用し、管理目的でのこれらの AWS アカウントへのアクセスを最小限に抑える必要があります。直接のアクセスや変更が必要な場合、権限のある管理者は十分な書き込みアクセス権が必要です。セキュリティチームのメンバーがセキュリティサービスの機能設定を行う等、管理者アクセス以外にも追加のアクセスが必要になる場合があります。

基盤 OU が整備されたら、プロダクトやサービスの構築または運用に直接関係する OU を作成することをお勧めします。多くの AWS のお客様が基盤 OU でインフラストラクチャとセキュリティを確立した後、後述するサンドボックス OU やワークロード OU といった OU を構築しています。

OU: サンドボックス (Sandbox)

この OU は個々の技術者の AWS アカウントを対象とし、AWS のサービスを学び、深く掘り下げるために存在します。この Sandbox 内のアカウントは、お客様の内部ネットワークから切り離すことをお勧めします。AWS サービスにアクセスするにはインターネットへのアクセスが必要ですが、制限することをお勧めします。また、外れ値や過剰使用量を追跡するために、月額100ドルなど、これらのアカウントの固定支出限度額を検討し、管理者に報告してください。

例: お客様はすべての従業員に Sandbox アカウントを提供します。

OU: ワークロード (Workloads)

これらは、ソフトウェアライフサイクルに関連する AWS アカウントが作成される OU です。デプロイされたアプリケーションが組織変更の影響を受けにくくするため、お客様のチームや部署にアカウントをマッピングするのではなく、ソフトウェアサービスを分離してワークロードアカウントを作成することをお勧めします。あるチームから別のチームへ一連のアカウントへのアクセスを移すのは簡単ですが、ソフトウェアサービスをあるアカウントから別のアカウントに移動することは、はるかに高負荷な作業です。

SDLC OU や非 Prod OU のアカウントは、ソフトウェアサービスの非本番環境という位置づけとなるため、他の OU に依存するべきではありません。
他の追加された OU のアカウントは本番環境に関連することになるため、ワークロード OU 配下の Prod OU にのみ依存する必要があります。

例: お客様には、製造、消費者サービス、マーケティングという 3 つの異なるビジネスユニットがあり、そのすべてがガバナンスモデルと運用モデルを共有しています。コンシューマーサービスにはパブリックベータがあり、OU にはありません。この場合、次の構造を持つことをお勧めします。

プロセスのこの時点で、基盤 OU とビジネス OU が確立され、クラウドジャーニーを開始できます。これが開始時点でのフレームワークです。

特定のニーズに応じて、メンテナンスと継続的な拡張のために、ビジネス OU を拡充することをお勧めします。これらは、既存の AWS のお客様のプラクティスに基づく一般的なテーマです。

OU: ポリシーステージング (PolicyStaging)

AWS Organizations にポリシーや構造を変更する場合は、変更内容を広く適用する前に確認することが重要です。変更を確認するには、管理者は、本番環境に影響しない方法で、必要な変更を作成して適用する機能が必要です。「OU: ポリシーステージング」は非本番環境の OU で、組織管理者にとって、検討している OU の設定をテストし、ポリシーの適用結果を確認するための場所となります。

変更をテストするに、子 OU とアカウントを作成することをお勧めします。変更を理解して検証したら、より広範な組織に徐々に変更を適用していきます。影響範囲を最小限に抑えるため、目的の設定変更対象のアカウントの最小レベルで開始することをお勧めします。変更への信頼度が高まれば OU の変更を柔軟に促進できるようになります。

例: Policy チームは、セキュリティ OU、インフラストラクチャ OU、ワークロード OU 、コード OU、およびデプロイメント OU のポリシーを管理しています。これらのポリシーステージング OU は、次の構造となります。

OU: 停止 (Suspended)

閉鎖され、組織から削除されるのを待っている AWS アカウントが含まれます。この OU に、すべてのアクションを拒否するサービスコントロールポリシー (SCP) をアタッチします。アカウントを再開する必要がある場合は、トレーサビリティに関する詳細が記載されたタグが付いていることを確認します。

旧従業員所有のアカウントと退職したアカウントは、「停止」に移行する必要があります。アカウントには、再開が必要な場合やトレーサビリティの理由から、どこから来たのかなどの詳細をタグ付けする必要があります。

アカウントが閉鎖されてから完全に削除されるまでには90 日間経過する必要があります。その後はアカウントとそのリソースは復元できなくなります。閉鎖されたアカウントは、組織内で「停止」状態で表示されます。アカウントが完全に削除されると、そのアカウントは組織に表示されなくなります。

アカウントの閉鎖の詳細については、AWS アカウントの閉鎖に関するドキュメントを参照してください。

OU: 個々のビジネスユーザー (IndividualBusinessUsers)

技術者ではないビジネスユーザーの AWS アカウントを含む制限付きアクセスが設定された OU です。これらのユーザーは、ビジネスの生産性に関連するアプリケーションを作成できます。たとえば、S3 バケットを設定して、パートナーとファイルを共有が可能です。

OU: 例外 (Exceptions)

ビジネスユースケースによって、「OU: ワークロード」で定義されているセキュリティまたは監査条件からの例外が保証される場合があります。これらのケースの1つが特定されると、例外が許可されることがあります。このような場合、カスタマイズされたセキュリティの規則に従うことになります。「OU: 例外」の配下のアカウントでは、ユースケースの独自性により、OU ではなくアカウントに直接適用される SCP があります。また、これらのアカウントの所有者は、カスタマイズされた予防的な統制により、(Amazon CloudWatch イベント、AWS Config ルールなどの) システムの検出と反応の精度を高めることを期待できます。

たとえば、極秘プロジェクトは例外 OU に該当する特殊なケースです。最終的にはコンプライアンスとセキュリティについてどんな SCP が定義されているか、関連する SCP が定義するガイドライン内で新プロダクトを発売できるかどうかによって状況が変わります。新プロダクトで求められるセキュリティが厳しく、新しい別の OU が必要であると感じる場合、将来的に主要な OU に厳しいセキュリティ要件を適用する際のリスクとコストが増大します。

OU: デプロイメント (Deployments)

CI/CD デプロイ用の AWS アカウントが含まれます。このOUは、ワークロード OU (Prod および SDLC) のアカウントと比較して、CI/CD 展開のガバナンスおよび運用モデルが異なる場合に作成できます。CI/CD の配布は、中央チームが運営する共有 CI/CD 環境への依存を減らすのに役立ちます。ワークロード OU 内のアプリケーションの SDLC/Prod AWS アカウントのセットごとに、デプロイメント OU 配下に CI/CD のアカウントを作成します。

CI/CD デプロイパイプラインは、AWS Code シリーズまたはセルフホストサービスのいずれかになります。CI/CD は、ビルドおよびデプロイするソフトウェアサービスの運用モデルと一致するように配布することをお勧めします。

非本番環境 OU のアカウントは CI/CD サービスをステージングするためのものであり、他の OU からの依存関係を持つべきではありません。

例: お客様には 3 つの異なるビジネスユニットがあります。独自の運用モデルを管理している製造部門と、ガバナンスと運用モデルを共有しているコンシューマーサービス部門とマーケティング部門。この場合、次の OU とアカウントを持つことをお勧めします。

CI/CD デプロイ OU は、2 つの間でガバナンスと運用モデルが異なるため、異なる階層と AWS アカウントに分割することをお勧めします。

構築される各サービスについて、開発ライフサイクルに一致するアカウントは Teams OU の下に作成されます。本番環境は「OU: ワークロード」の「OU: Prod」の配下になります。開発ライフサイクルの他のすべての段階は、「OU: ワークロード」の「OU: SDLC」の配下になります。

各サービス (SDLC アカウントのセット) には、展開に対応するアカウントが存在します。このアカウントは「OU: デプロイメント」の配下にあります。たとえば、foo というサービスに dev、ベータ、QA、本番環境がある場合、その全体的な環境は次のように構成されます。

これで、追加の OU とアカウントが確立されました。

まとめ

適切に設計されたマルチアカウント戦略は、セキュリティとスケーラビリティのニーズを満たすと同時に、AWS での迅速なイノベーションを支援します。この記事で説明されているフレームワークは、AWS ジャーニーの出発点として使用する必要がある AWS のベストプラクティスを表しています。

独自の環境の構築を開始するには、AWS Organizations の開始方法を参照してください。または、AWS Control Tower を使用すると、数回のクリックで、安全な AWS 環境を迅速にセットアップできます。

著者について

Sam-Elmalak-bio

Sam Elmalak は AWS の WW Tech Leader で、セキュリティコミュニティのメンバーです。お客様の技術課題の解決の他、組織文化の変革のサポートも行っています。Sam はビジネス課題や潜在的なニーズを技術の力で解決できるように力を注いでいます。彼は素晴らしいことを成し遂げる力が皆にあると信じています。

原文はこちら。翻訳はSA桂井が担当しました。

Amazon Web Services ブログ