AWS Organizations(2)AWSアカウントの管理

AWS Organizationsに関するホワイトペーパー

AWSの環境を整理するためのガイダンスとして、 Organizing Your AWS Environment Using Multiple Accountsというホワイトペーパーが公開されている。本稿ではその内容について整理/抜粋する。

会社によっては、セキュリティやコンプライアンスの制御が異なる複数のチームが存在する場合があり、明示的なセキュリティの境界、制限やスロットルの可視化、コストや請求の分離等を求めており、AWSアカウントによって環境を分離することでこれを実現できる。このホワイトペーパーは、Well-Architected Frameworkに基づいて、複数アカウントによるAWS環境の構築する方法を提示する。

複数アカウントを使用する利点

AWSを使用する際に複数のアカウントを使用するメリットは以下の通り。

  • ビジネスん目的と所有権に基づいてワークロードをグループ化し、他のワークロードの保護と依存関係や競合を回避する
  • 非本番環境と本番環境のように異なる環境下で異なるセキュリティ制御を適用する
  • 機密データへのアクセスを制御する
  • サンドボックスアカウントや開発アカウントを提供することにより、イノベーションや俊敏性を加速する
  • 問題や構成の誤り、悪意のあるアクションによる影響の範囲を制限する
  • 機能やワークロード別に複数のIT運用モデルをサポート
  • コストを管理する
  • サービスクオータを管理する

example-operating-models

設計原則

アカウント設計の設計原則は以下の通り。

  • 組織のレポート構造を反映するのではなく、機能やコンプライアンス要件などに基づいてOUを設計する
  • アカウントではなくOUにSCPなどのセキュリティガードレールを適用する
  • 深いOU階層は避ける
  • 数年後を見据えて設計するのではなく、小さく設計して必要に応じてOUを拡張する
  • 管理アカウントにはワークロードを展開しない
  • 本番ワークロードと非本番ワークロードを分離し、ワークロード指向のOUを構成する
  • 各本番アカウントには単一または小さなワークロードを割り当てる
  • SSOなどのフェデレーションアクセスを使用してアクセス管理を簡素化する

奨励されるOU構成

奨励されるOUはいくつか存在するがこの全てを作成する必要は無い。セキュリティOUとインフラストラクチャOUが基本となる。基本的なOUはクラウドエンジニアリングチームが所有する。

セキュリティOU

セキュリティOUには、ログアーカイブ、セキュリティツール、セキュリティ読み取り専用アクセス、セキュリティ用緊急アクセスの4つのアカウントを作成する。ログアーカイブアカウントには、CloudTrailのAPIアクセスログ、Configの変更ログ、VPCフローログなどの運用ログデータを保存する。セキュリティツールアカウントでは、SecurityHUb、GuardDuty、Config、IAM Access Analyzer、Detective、Macie、Firewall Managerなどを有効化する。なお、インシデント発生時の対応は、AWS Security Incident Response Guideを参照のこと。セキュリティ読み取り専用アクセスアカウントは、監査や調査のための読み取りアクセス用アカウント。このアカウントを使用する場合には、フェデレーションアクセスを使用することが奨励される。セキュリティ用緊急アクセスアカウントは、セキュリティインシデント発生時等に許可された管理者がアクセスを一時的に取得するために使用する。

Security
 ├ Prod
 │  ├ security-read-only-prod
 │  ├ security-break-glass-prod
 │  ├ security-tooling-prod
 │  └ log-archive-prod
 └ Test
    └ security-tiiling-test

インフラストラクチャOU

共通インフラストラクチャ用のOU。Site-to-Site VPN、 Direct Connect、 Transit Gateway、 DNSサービス、VPCエンドポイントなどが収容される。

Infrastructure
 ├ Prod
 │  ├ network-prod
 │  └ shared-infra-prod
 └ Test
    ├ network-test
    └ shared-infra-test

サンドボックスOU

ビルダーがAWSサービスを自由に実験できるアカウント。内部ネットワークからは隔離されている。実験は一時的かつ様々な用途が予想されることから、パージ処理の自動化や幅広いアクセス許可、非公開データを保管しないことなどが期待される。また、特定のプロダクトの開発環境とこのサンドボックス環境は明確に区別しておくことが奨励される。

Sandbox
 ├ sandbox-team-xxx
 └ sandbox-xxx

ワークロードOU

ワークロードOUは、本番環境とテスト環境の両方を含む。

Infrastructure
 ├ Prod
 │  ├ xxx-service-prod
 │  └ xxx-service-beta
 └ Test
    └ xxx-service-test

ポリシーステージングOU

AWS全体に影響が及ぶポリシーを管理するチームが、ポリシーの変更を適用する前に安全にテストするためのOU。ワークロード固有のポリシー変更時はこのOUでテストする必要は無い。このOUでテストしたあとは、目的のOUに新たなポリシーを一時的に関連付けることが奨励される。

PolicyStaging
 ├ Security
 │  ├ Prod
 │  │  └ security-prod-policy-staging
 │  └ Test
 │     └ security-test-policy-staging
 └ Infrastructure
    ├ Prod
    │  └ infra-prod-policy-stating
    └ Test
       └ infra-test-policy-stating

Suspended OU

一時的もしくは永続的に使用を停止する必要のあるアカウントの保存領域。アプリケーションレベルのアクセスを削除して、各ユーザが各アカウントにアクセスして管理できなくする。一時停止するアカウントについては再度使用される可能性があるため、アカウントを移動した理由とアカウントが所属していたOUを記録することが奨励される。

個々のユーザ向けOU

ワークロードOU外で管理されるリソースを管理するためのOU。例えば、他社との共有を目的としたS3バケットのあるAWSアカウントやアカウントに直接アクセスする必要のないQuickSightを作成しているアカウントなど。これらのアカウントには、SCPとIAMを組み合わせて設定することが奨励される。

例外OU

ワークロードOUに適用されるポリシーの例外を必要とするアカウント。このOUに所属するアカウントはごく少数でなければならない。ワークロードOUの階層を深くすることで対応できないか検討する。

Deployments OU

ワークロードへの変更を構築、検証、リリースする方法をサポートするリソースとワークロードを含むアカウント。例えば、AWS内外のCI/CDサービスとの連携など。デプロイをするために、テスト環境と本番環境の両方にアクセスできなければならない場合が多い。CI/CD環境は、ワークロード別に作成することが望ましい。また、CI/CDパイプライン自体のテスト環境を作ることが奨励される。

Deployments
 ├ Prod
 │  └ xxx-service-cicd-prod
 └ Test
    └ xxx-service-cicd-test

移行用OU

会社の買収や第三者が管理していたアカウントの移行など、上記のOU外に存在したアカウントを受け入れる際に、一時的に保存するためのOU。他のOrganizationsと紐づいている場合には、このOrganizationsからの削除を最初に行う。移行時には、他のAWSアカウントとの依存関係がないかどうかを調査する必要がある。

ワークロード指向のOU

ワークロードは特定のコンポーネントとデータのコレクションであり、テスト用や本番用などの複数の環境を有することができ、これらの環境は分離することが奨励される。本番環境がテスト環境のリソースに依存、またはその逆が存在することは望ましくない。ただし、テスト環境から本番環境上の実データへアクセスする場合があり、この場合は読み取り専用とすることが一般的。環境別にOUを構築する場合、本番環境と非本番環境の2つのOUに分割する場合もあれば、本番環境、ステージング環境、テスト環境と3つの環境に分割する場合もある。なお、AWSの場合は、1つのアカウントに単一のワークロードが存在する場合もあれば、1つのアカウントに複数のワークロードが存在する場合もある。

example-workload-accounts-scoping

ワークロードOUでは関連するワークロード同士を同一のOUにまとめることができる。例えば、データベースOU、バックアップOUなどである。OUは組織のレポート構造を真似るのではなく、ワークロードごとにまとめる必要があるが、例えば各ビジネスユニットが独立して存在し、それぞれで大幅にポリシーが異なる場合は、ビジネスユニットごとにOUを構築する場合もある。

AWSアカウントの整理

単一のアカウントしか持っていない場合で本番ワークロードの稼働を予定している場合には、複数アカウントへの移行および移行OUの利用を検討する。また、立ち上げたばかりの組織の場合は、 Control Towerなどを利用して最小限のOUを構築することができる。

example-production-starter-control-tower

さらに拡張された場合には、InfrastructureやSandbox、CI/CDなどのOUを追加する。

example-basic-organization-cicd

このように、AWSの利用が広がるに従って組織を拡大することができる。これらを構築するために、ControlTowerやAWS Managed Servicesの使用を検討できる。

Appendixに記載のある情報

本ホワイトペーパーのAppendixには、以下の記述もある。