AWS Organizations / マルチアカウント戦略

目的

複数プロダクト、複数環境(本番/ステージング) を構築する際に、明確なセキュリティ境界を設ける

ネットワーク的な境界としてはVPC、権限の制御にはIAMが利用できるが

複雑なポリシーを設定するよりかは、シンプルにアカウントという単位で切っておく

ある程度の組織規模になってくると、権限移譲を行いつつ、統制を行っていく必要がある

AWS Organization

複数のAWSアカウントを管理する

マスターアカウントとメンバーアカウント

メンバーアカウントの請求はマスターアカウントで一括で行われる ( Consolidated Billing )

SCP ( Service Control Policy ) を用いて、メンバーアカウントが必要なセキュリティ要件を満たしているかチェックする

Control Tower

AWS が推奨するマルチアカウント設定のベストプラクティスにそって、設定をセットアップしてくれる

一般的なマルチアカウントの考え方・戦略については、この辺りを参考にする。Control Tower が構築する構成もこれに近しい

2019/06 にリリース

一部のリージョンで設定を行える (米国東部 (オハイオ)、欧州 (アイルランド)、米国東部 (バージニア北部)、米国西部 (オレゴン)

有効にすると、次のことが自動で行われる

Audit アカウントと Log Archive アカウントが作成される

SSO が有効化される

ガードレールのセットアップ

アカウント構造

次のように、Core という OU (Orgnization Unit) に Audit アカウントと Log Archive アカウントが作成される。

Root (OU)

Master

Core (OU)

Audit

Log archive

メンバーアカウントの追加

Control Tower で管理されるメンバーアカウントを追加するには、 Control Tower 内の Account Factory というページから行う。

実際には Service Catalog のページに飛ぶので、そこで必要な項目を入力しアカウント作成を行う

メンバーアカウントのメールアドレス管理

メンバーアカウント ( Audit アカウント Log Archive アカウントも含む ) には、rootユーザのために必ず固有のメールアドレスが必要になる。

rootユーザのパスワードリセットも行えるアドレスになるので、限られた人のみが利用できるアドレスである必要がある。

会社でGSuite を使っている場合は、 Google Group を一つ作り、aws+account_name@example.com のような形で管理していくと、都度アドレス追加をしなくてよいので楽に思える。

Audit アカウント と Log Archive アカウント

Control Tower によって、AWS Config のアグリゲータが設定されており、各メンバーアカウントを監視が行われる。

ログは Log archive アカウントに送られる。

メンバーアカウントの CloudTrail のログは、 Log archive アカウント内のS3に集約される。

GuardDuty はマルチアカウントで統合して運用することができる。

Audit アカウントを Guard Duty のマスターアカウントとして運用するのが良いように思われる

SSO

Control Tower を設定するとマスターアカウントにシングルサインオンがセットアップされる

各ユーザは、シングルサインオンで各メンバーアカウントへのログインが行える

既存アカウントの組み込み

すでに運用中のアカウントを Organization に組み込む場合

マスターアカウントの Organization の招待をおこなう

Control Tower で設定される内容と同様のことを行うには、少し工夫が必要

Control Tower では、 Cloudformation StackSets を使うことで、IAM / AWS Config / CloudTrail のセットアップを行っているようである

なので、マスターアカウントから同じように、Organizationに追加した既存メンバーアカウントに対して StackSets の適用を行えば良い