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には、以下の記述もある。

AWS Organizations(1)Organizationsの概要

AWS Organizations

AWS Organizationsは、 複数のAWSアカウントを統合 するためのアカウント管理サービス。 ビジネスの予算、セキュリティ、コンプライアンスのニーズを満たす 以下の機能が備わっている。

  • アカウントの一元管理
  • 一括請求
  • アカウントのグループ( OU )化
  • アカウント毎の アクセスコントロール
  • タグの標準化
  • AIと機械学習サービスがデータを収集/保存する方法を制御
  • 自動バックアップポリシーの使用
  • IAMの統合

これらの機能を実現するために、AWS Organizationsは以下のAWSサービスと連携している。

サービス名 有効化 実現できること
AWS IAM 不要 サービスアクティビティ による 最終アクセス時間の確認
AWS Artifact 必要 組織契約 による 契約の受諾
AWS CloudTrail 必要 組織の証跡 による 証跡の組織への適用
AWS CloudWatch Events 不要
AWS Config 必要 アグリゲータ による 集約ビュー の表示
AWS Control Tower 不要
AWS Directory Service 必要
AWS Firewall Manager 必要 AWS Firewall Manager による WAFルールの管理
AWS ライセンスマネージャー 必要
AWS RAM 必要
AWS Service catalog 必要
Service Quotas 不要
AWS シングルサインオン 必要
AWS System Manager 必要 Systems Manager Explorer によるデータの同期
タグポリシー 必要

AWS Organizationsを有効化すると、複数のAWSアカウントを一括管理することができる。それぞれのアカウントは、ルートを親として 組織単位 (OU)ごとに分類することができる。アカウントは、 管理アカウント (=ルート)と メンバーアカウント に分かれ、管理アカウントにはメンバーアカウントを管理するための様々な権限が付与される。AWS Organizationsの全ての機能を有効化することも、 一括請求機能のみを有効化 することもできる。各OUもしくはアカウント単位に、 サービスコントロールポリシー と呼ばれる各アカウントが持つ権限を明示したポリシーを適用することができる。 サービスコントロールポリシーとタグポリシーは、デフォルトでは無効化されている ので、利用する場合は有効化する。

ベストプラクティス

管理アカウントのベストプラクティス

管理アカウントにはSCPが適用されない ため CloudTrailだけを有効化 し、それ以外のAWSリソースは保有しない。また、管理アカウントのrootユーザのメールアドレスには、 マネージャーを宛先に含むグループメールを指定 する。このrootユーザの パスワードは長くて複雑なものを使用 し、 定期的に変更せずにその内容を金庫に保管、もしくはマネージャーが保管、パスワード管理ツールで保管 する。rootユーザは、MFAの使用を有効した上で、 そのアクセス方法とアクセスのログの記録方法を定める 。管理アカウントに登録する電話番号用に、 専用のSIMカードとデバイスを用意 し、こちらもそのアクセス方法とアクセスのログの記録方法を定める。アカウントへのアクセスや認証情報の 使用方法やリセット方法を定めた上で、定期的にレビュー を行う。

メンバーアカウントのベストプラクティス

メンバーアカウントのrootユーザにも、「グループメールアドレスの指定」「複雑なパスワードの使用」「MFAの有効化」を行う。また、 電話番号は管理アカウントと同一のものを指定 する。アカウントへのアクセスや認証情報の 使用方法やリセット方法を定めた上で、定期的にレビュー を行う。さらに SCPを使用して、メンバーアカウントのrootユーザが実行できることを制限 する。

組織とアカウント

組織

組織を作成する際に、全ての機能を有効化する(奨励)か、課金機能のみ有効化するかを選択することができる。全ての機能を有効化する場合には、各メンバーアカウントに、 AWSServiceRoleForOrganizations ロールが必要となる。また、全て機能を有効化した場合は、 課金機能のみの有効化に戻すことはできない

組織にアカウントを追加するには、

  • メンバーアカウントを新規で作成
  • 既存のAWSアカウントを招待

のいずれかを選ぶことができる。 組織を作成した際、管理アカウントに登録されているメールアドレス宛に確認のメールが送信される 。AWS Organizationsが持つことのできる管理アカウントは1つのみである。 管理アカウントはサービスコントロールポリシーの影響を受けない 。Organizationsを削除すると復元できず、またポリシーも削除される。削除する際には、 全てのメンバーアカウントを消去する必要 がある。

Organizationsに参加したメンバーアカウントでは、サービスコントロールポリシーやタグポリシーが即座に適用され、またサービスの信頼を有効化している場合は、そのサービスからメンバーアカウントに対してアクションを実行することが許可される。また、Organizations内で新規のメンバーアカウントを作成することもできる。

アカウント

メンバーアカウントを新規で作成した場合は、 ルートアカウントと AWSServiceRoleForOrganizations ロール、 OrganizationAccountAccessRole が作成 される。一方で、既存のAWSアカウントを招待した場合には、 AWSServiceRoleForOrganizations ロールのみが作成される。既存のAWSアカウントを招待した場合でも、運用の統一性を考慮して、 OrganizationAccountAccessRole ロールを作成することが望ましい。

新規でメンバーアカウントを作成すると、 アカウント名や電話番号などの情報が管理アカウントからコピー される。また、 rootアカウントのパスワードが自動作成されるが、これを取得することはできない 。このパスワードを取得するためには、パスワードの回復プロセスを実行する必要がある。

組織に属する アカウントの一覧はCSVファイルでエクスポートすることができる

メンバーアカウントを新規で作成した場合は、作成から7日以降に組織から削除することができる 。また、メンバーアカウントが組織を離れると全てのタグが削除される。アカウント自体を閉鎖する場合には、 rootユーザのパスワードを取得した上でアカウントの閉鎖処理を行う。

OU

OUは最大5レベルの深さまでネスト できる。OUは名前の変更、タグ付け、アカウントとの紐付け、削除が可能。

組織ポリシー

組織にはサービスポリシーと管理ポリシーが存在する。 ポリシーはルート, OU, アカウントに関連づけることができルートもしくはOUに紐づけられたポリシーは、そのOUもしくはその下にあるOUが継承 する。

ポリシーの継承

サービスポリシーの場合、フィルタのように振る舞うため、 上位のSCPにDeny構文があった場合、下位のSCPでそのサービスを許可することはできない 。拒否リストの場合は、まず全てのサービスが許可されていて、不要なサービスを明示的に拒否する。 拒否リスト戦略は、AWSのサービスが追加された場合でもメンテナンスが不要 である。 許可リストの場合は、デフォルトのFullAWSAccessを削除して暗黙的なDenyを適用 し、必要なサービスのみを許可したSCPをアタッチする。

How SCP Permissions Work

管理ポリシーの場合、構文内に 継承演算子 が含まれており、これに従った動作を行う。継承演算子には、 @@assign, @@append, @@remove が存在する。

サービスポリシー( SCP

サービスポリシーは、 最大で使用できるアクセスの権限を各アカウントに対して指定できる機能 。Organizationsの全ての機能を有効化した場合に使用できる。 メンバーアカウントのルートユーザにも適用されアカウントに与える影響が非常に大きいため、適用する際には詳細なテストが必要である。IAMのサービスアクティビティに表示される、各アカウントの最終アクセス時刻を参考にポリシーの内容を決定することが望ましい。

サービスポリシーは以下のタスクには影響しない。

  • 管理アカウント
  • Service-linked Role
  • ルートユーザの認証
  • サポートプランの変更
  • CloudFrontの一部機能

サービスポリシーは、IAMポリシーとほぼ同じ構文を使用する。 Principal, NotPrincipal, NotResource は使用できない。複数のポリシーが適用されている場合は、明示的なDenyがAllowよりも優先される。ポリシーの例は、 サービスコントロールポリシーの例 を参照のこと。

管理ポリシー

AIサービスのオプトアウトポリシー は、Amazon CodeGuru Profiler、Amazon Comprehend、Amazon Lex、Amazon Polly、Amazon Rekognition、Amazon Textract、Amazon Transcribe、Amazon TranslateなどのAIサービスで行われるサービス改善のためのコンテンツ保存のオプトアウトを設定できる。

バックアップポリシー は、AWS Backupを使用したバックアップのルール(バックアップの頻度、バックアップが発生する時間枠、バックアップするリソースを含むAWSリージョン、バックアップを保存するボールト)を指定できる。

タグポリシーは、タグキーおよびタグ値の大文字と小文字の処理方法の設定などを規定することができる。デフォルトでは、タグポリシーへのコンプライアンスの強制はされない。強制をサポートするAWSサービスは 強制をサポートするサービスとリソースタイプ を参照のこと。

参考リンク