Amazon Web Services ブログ

AWS マルチアカウント統制の要件検討アプローチ例

はじめに

我々、AWS のプロフェッショナルサービスは、クラウド活用に関するお客様固有のブロッカーを取り除くための支援をするチームです。お客様の役割は様々ですが、組織全体の AWS アカウント管理を担われているお客様をご支援するケースもあります。組織全体で AWS をセキュアに利用いただくためには、クラウド利用の社内規定やガイドラインの作成だけでなく、ルールを強制的に適用したり、非準拠状態を発見・報告したりするための仕組み（このブログでは複数の AWS アカウントを統制するための基盤として統制基盤と呼びます）の構築を推奨することもあります。一方で統制基盤を構築したいと考えているが、「統制基盤のあるべき姿をどのように定義すればよいかわからない」といったお悩みを抱えているお客様も多いのではないでしょうか。

安全なマルチアカウント AWS 環境をセットアップおよび管理するための最も簡単な方法として提供されている、AWS Control Tower が提供する機能は、初期の統制基盤の一つの解となります。AWS Control Tower は AWS 利用のベストプラクティスに基づいた機能が提供されているため、その採否によらずまずは AWS Control Tower が提供する機能に着目すると統制基盤の要件を決めやすくなります。本ブログではこのアプローチで実際に要件を整理していく例を紹介いたします。

アプローチの概要

AWS Control Tower は統制基盤の基本となる機能を提供しますので、この機能に絞って統制の要件を整理してみたいと思います。まず「AWS Control Tower が提供する統制の機能」にどのようなものがあるか、何が実現できるのかを理解します。その統制の機能を踏まえた上で、「AWS マルチアカウント統制の要件」を整理します。

これにより AWS マルチアカウント統制のゴールイメージを固めやすくなります。なお、より幅広い統制またはセキュリティ機能の全体像は「AWS Security Reference Architecture: A guide to designing with AWS security services（日本語ドキュメント）」で解説しております。

１ AWS Control Tower が提供する統制の機能の理解

AWS マルチアカウント統制で重要となる概念がランディングゾーンです。 ランディングゾーンは、「AWS のベストプラクティス」に基づいて構成したセキュアなマルチアカウント AWS 環境を、スケーラブルに展開していくための仕組みの総称です。 AWS Control Tower を利用すると、このランディングゾーンに必要な機能、管理用アカウントを一括してセットアップできます。これにより下記のような機能 を実装するための設計、テスト、実装にかかる作業負荷を大きく減らすことができます。詳しくは「AWS マルチアカウント管理を実現するベストプラクティスとは ?」をご参照ください。

AWS Control Tower で管理できる機能

AWS Control Tower で管理できる機能

（図1）AWS Control Tower で管理できる機能と検討ポイント

AWS Control Tower で管理できる機能 AWS Control Tower で実現できること
AWS アカウント開設とプロビジョニング
  • AWS アカウントの開設と、ガードレールによる統制およびログ集約のためのプロビジョニングを効率的に行う事ができる
ID 管理の一元管理、管理用権限の発行
  • IAM Identity Center (旧 AWS Single Sign-On) と開設した AWS アカウントを連携させることで、効率的に ID の一元管理ができる
AWS ログの集約
  • 複数の AWS アカウントのログを集約するためのログアーカイブ用 AWS アカウントを開設する
  • S3 バケットを自動実装した上で、AWS アカウントを開設したタイミングからログの収集を開始できる
ガードレールの設置、通知設定
  • ベストプラクティスに基づいた Service control policies (SCP) による予防的ガードレールと、 AWS Config rules による発見的ガードレールを、AWS アカウントを開設したタイミングから適用できる

２ AWS マルチアカウント統制の要件を項目毎に整理

目指したい AWS マルチアカウント統制を、具体的な要件として明文化していきます。 AWS Control Tower で提供される機能も併記していますので、各項目で例えばどのような統制ができるのかをイメージしながら要件を決定できるかと思います。(この表には2022年11月現在の仕様に基づいて記載しています。最新の情報は AWS Control Tower のドキュメントにてご確認ください)

統制の対象

最初にどの AWS アカウントを統制の対象とするかを決めます。わかりやすい例として「組織で利用する全 AWS アカウントを統制する」という要件がある一方、システムの都合により利用中の AWS アカウントの設定を変えたくないケースなどもあるかもしれません。また統制の対象とした AWS アカウントを分類した上で、分類毎に統制方法を変える必要があるケースもあります。この要件を踏まえて、AWS Organizations の Organizational unit (OU) の構成を反映します。

要件項目 要件の例 AWS Control Tower の機能
統制の対象とする AWS アカウントの範囲 利用中の AWS Organizations 配下の AWS アカウントと、新規に作成する AWS アカウントの全てを共通の統制基盤で一元的に管理する
  • AWS Control Tower からサービス連携などの設定がされた AWS Organizationsを自動的に作成できる (利用中の AWS Organizations に AWS Control Tower を適用させることも可能)
AWS アカウントの分類

以下2つの軸で AWS アカウントを分類した上で、統制レベルを分けて管理する

  • 開発組織の単位による分類
  • 環境による分類 (本番/疑似検証/開発)
  • AWS Control Tower のコンソールで OU ごとに適用するガードレールを管理できる
  • AWS Control Tower のコンソールで OU と関連する AWS アカウント、適用済みガードレールの準拠状況を確認できる

参考:

統制基盤の機能要件

統制の対象に対して、具体的にどのような統制機能が必要かを検討します。 AWS Control Towerで自動実装されるセキュリティ機能は、 AWS Control Towerを利用していないお客様でも統制において必須とされるケースが多いです。なお「要件の例」に記載した機能は、全て AWS Control Tower で自動実装することができます。

要件項目 要件の例 AWS Control Tower の機能
監査ログの集約 全 AWS アカウントの監査ログ(AWS CloudTrail, AWS Config) を、独立した１つの AWS アカウントに集約する
  • AWS Control Tower 利用開始時に、ログアーカイブ AWS アカウントを自動作成できる
  • CloudTrail, AWS Config のログに関するログアーカイブ AWS アカウントへの集約設定を、各アカウント作成時に自動的にプロビジョニングできる
発見的ガードレール 以下の設定を発見的ガードレール(AWS Config rules)で検出した上で、1つの AWS アカウントで確認する
<例>

  • Amazon EBS ボリュームの暗号化が有効になっていない
  • ルートユーザーの MFA が有効になっていない
  • パブリックアクセスをブロックする S3 の設定がアカウントで true に設定されていない
  • AWS Control Tower 利用開始時に、監査用 AWS アカウントを自動作成できる （利用中の AWS アカウントを監査用 AWS アカウントに指定することも可能）
  • 発見的ガードレール (AWS Config rules) の検知結果に関する監査用 AWS アカウントへの集約設定を、各アカウント作成時に自動的にプロビジョニングできる
  • ベストプラクティスとして厳選された発見的ガードレール (AWS Config rules) を活用できる、特に選択型の AWS Config rules を AWS Control Tower のコンソールで管理できる
予防的ガードレール 以下の操作を全ての AWS アカウントで禁止する
<例>

  • CloudTrail の設定変更
  • ルートユーザーのアクセスキーの作成
  •  S3 バケットのレプリケーション設定の変更
  • ベストプラクティスとして厳選された予防的ガードレール (SCP) を活用できる、特に選択型の SCP を AWS Control Tower のコンソールで管理できる
ID 管理方式

対象の AWS アカウントで利用する利用者 ID を一元的に管理できる

  • 利用者 ID の払い出しは AWS マネージドのサービスで行う
  • 1つの統制アカウントで一元的に認証、認可の設定を行う
  • AWS Control Tower 利用開始時に、IAM Identity Center を自動的に構築できる
  • 自動的に作成された統制に必要なアクセス許可セットを利用することができる
  • 「Active Directory, 外部 IdP の関連付け」、「設定ユーザ、グループ」、「アクセス許可セット」を含む利用中の IAM Identity Center 設定を踏襲することができる
各 AWS アカウントが利用するリージョン

記載のリージョンを利用対象とした上で、その他のリージョンでの作業を拒否する
<例>

  • ap-northeast-1 (東京)
  • us-east-1 (バージニア北部)
  • us-east-2 (オハイオ)
  • eu-west-1 (アイルランド)
  • 発見的統制を自動実装する対象リージョン (利用対象) を選択することができる
  • 上記以外のリージョンでの操作を拒否するガードレールを、オプションとして実装することができる

参考:

統制基盤の非機能要件

統制基盤検討においては「新しい統制機能の運用」、「統制の可用性」などの非機能要件も定義する必要があります。また既に現環境で統制機能を実装している場合は「新しい統制基盤への移行の難易度」を評価する必要があります。下表では AWS Control Tower の提供する機能と現環境の統制機能が重複した場合を想定し、活用できる機能にも言及しています。

要件項目 要件の例 AWS Control Tower の機能
ガードレールの変更管理 新しいガードレール（SCP, AWS Config rules）が必要となった場合は、全 AWS アカウントに一斉に反映する
  • AWS Control Tower でマネージドに提供される予防的ガードレール (SCP)、発見的ガードレール (AWS Config rules) を、コンソール上で追加、削除できる
  • 発見的ガードレール (AWS Config rules) の検知結果を AWS Control Tower のコンソールで一元的に確認できる
AWS アカウントのライフサイクル管理 AWS アカウント作成、ベースラインの実装を効率的に実施できる
  • Account Factory を用いることで、AWS アカウントの作成、ベースラインの実装を1回の作業で実現することができる
  • 上記作業が完了済みか否かを AWS Control Tower のコンソール上で一元的に確認ができる
障害発生時における統制の継続 リージョン単位の障害があった場合でも、ガードレールによる統制を継続できる
  • 予防的ガードレール (SCP) はグローバルサービスとして動作、発見的ガードレール (AWS Config rules) は各リージョン毎に独立して動作するため、それぞれリージョン単位の障害に耐性がある
利用中の AWS アカウントの統制基盤からの移行

利用中の AWS Organizations における統制のための AWS アカウントを活用する

  • 作成済みのログアーカイブアカウントを継続利用する
  • 利用中のワークロード用 AWS アカウントは段階的に統制環境に加える
  • 利用中の AWS Organizations を OU 構成、 AWS アカウントに影響を与えることなく、AWS Control Tower を有効化することができる
  • 同じ AWS Organizations の中で AWS Control Tower の統制対象とするアクティベーションを段階的に AWS アカウントに適用することができる
  • 利用中の AWS アカウントを、ログアーカイブ AWS アカウント、監査アカウントとして登録することができる

参考:

３ AWS マルチアカウント統制のゴールに向けた次のステップ

このように最低限必要となる統制基盤の要件を固めたことで、要件に対応する実装方針も決めやすくなります。特に要件を実現するサービスとして、AWS Control Tower の採否を決める場合、上記までで整理した要件との適合度に加えて、AWS Control Tower 固有の考慮ポイントも参考にして導入の難易度を評価します。

AWS Control Tower の考慮ポイントの例

  • 既存 AWS Organizations を利用する場合と、新規に AWS Organizations を構築する場合の手順が異なる
  • 予防的ガードレール (SCP) と発見的ガードレール (AWS Config rules) の中で、必須で適用されるもの、選択可能なものがある
  • AWS Control Tower の管理対象とするリージョンが選択できる一方で、管理外としたリージョンにおいてもマルチリージョンで実装される CloudTrail, SCP は有効となる
  • AWS Control Tower で追加される SCP や AWS CloudFormation StackSets などのリソースによって、クォータ (設定量の上限) を超えないように設計する
  • AWS Control Tower の予防的ガードレール (SCP)、発見的ガードレール (AWS Config rules) に無い項目を付け加えたい場合は、各機能のコンソールまたは「AWS Control Tower のカスタマイズ (CfCT)」を活用して実装することができる

最後に

本ブログでは、AWS Control Tower の機能に着目して AWS マルチアカウント統制の要件を整理する手法の例をご紹介いたしました。このアプローチにより統制基盤に求められる要件を効率的に決定し、実装につなげることができると考えます。

プロフェッショナルサービスでは、このような検討を含めクラウドのセキュリティや統制のノウハウを様々なお客様とともに育んでいます。今後も様々な形で皆様のビジネス推進におけるセキュアなクラウド活用をご支援していきますのでご期待ください。

このブログの著者

須田 聡（Suda, Satoru）
プロフェッショナルサービス本部
シニアセキュリティコンサルタント
中村 賢介（Nakamura, Kensuke）
プロフェッショナルサービス本部
シニアセキュリティコンサルタント
畠中 亮（Hatanaka, Ryo）
プロフェッショナルサービス本部
シニアセキュリティコンサルタント