AWS Innovateマルチアカウント戦略

エンタープライズ組織がサービス開発を継続して行うとき、増え続けるAWSシステムに対して１つのAWSアカウントで管理を続けていくことは難しいです。

多数のシステムをシンプルかつスケーラブルに管理するためには、マルチアカウントによる管理と仕組みの活用が効果的らしい。。

AWSで稼働するシステム数による管理の変移

• 1システム
  • そのシステムの管理者がAWS自体の管理も行う
• 数個
  • 共通基盤チームがAWS自体の管理と個別システムの監査を行う
• 多数
  • 共通基盤チームが人海戦術で管理、監査を行うことが困難になってくる
  • 利用API単位でアカウントを分ける
    • ログ集約
    • アカウント保護
    • システム開発
    • 請求管理
  • 権限管理を簡素化、強制化
    • IAM
    • Organizations
      • SCP
      • Landing Zone
  • AWS環境提供の自動化

アカウントを分割する目的

分離するだけならVPCレベルでも良いのでは？

→APIのレベルでアカウントを分けることで・・

環境

• 開発
• テスト
• 本番

のような環境をセキュリティやガバナンス、規制のために分離できる

ex)PCI DSS、HIPAA...

課金

部門単位やシステム単位でAWSのコストが明確に分離できる

ビジネス推進

事前に定義されたガバナンスフレームワークの中で特定のビジネス部門に対する権限の移譲が行える

→要は研究開発だったりのためにある程度自由なサンドボックス環境を提供できる

ワークロード

リスクやデータ分類、要求に応じてワークロード自体を分離できる

マルチアカウント管理のフレームワーク

AWSが提唱するフレームワーク図

引用：AWS Innovate　[S-7] 増加するシステムをマルチアカウントで効率よく管理する

• コアOU

  • 環境を管理するためのOU群

    セキュリティ

    • ログアーカイブ用
    • セキュリティログ閲覧用
    • セキュリティログ集約用
    • セキュリティツール管理用

    インフラストラクチャ

    • 共有サービス
    • ネットワーク提供
      • DXやDNS周り、Directoryサービスなど

• 追加のOU

  • サンドボックス
    • 限定されたリソースを自由に使える環境
    • システムネットワークからは切り離されている
  • 個別システム開発用

Landing Zone

Landing Zoneとは？

セキュアで事前設定済みのAWSアカウントを提供する仕組みの総称

要は、組織で複数のAWSを管理する際のあるべき状態の定義

AWS Control Tower

Landing Zoneを展開するマネージドサービス

※東京リージョン未対応なので割愛

Landing Zoneを独自で実装するには？

大雑把に

1. アカウントの発行
2. 管理用権限の発行
3. 共有サービスへのアクセス
4. AWSログの集約
5. ガードレールの設置

ガードレールが肝になる

ガードレールとは？

AWSが提唱している概念

アカウントに対して硬すぎる制限を設けるのではなく、できるだけ自由を確保しつつ望ましくない領域のみ制限、または発見できる仕組みを構築する考え

予防的ガードレール（制限）

• 対象の操作を実施できないようにするガードレール
• Organizations Service Control Policy (SCP)で実装する
• OUやアカウントに対する許可/拒否ポリシーを設定

発見的ガードレール（発見）

• 望ましくない操作を行った場合、それを発見するガードレール
• 管理しつつ開発のスピードを上げるために効果的
• AWS Config Rulesで実装する

実装のアプローチ

Control Towerを参考にする

→Control Towerの実装はAWSサービスの組み合わせになっているため、ユーザーガイドを参考にLanding Zoneを実装することが好ましい

AWS ガードレールリファレンス

マルチアカウント実装例

アカウント構成

引用：AWS Innovate　[S-7] 増加するシステムをマルチアカウントで効率よく管理する

アカウントの発行

• スクリプト（AWS CLI）やプログラムで実装
  • 基本的にはOrganizationsのAPIキックにより実現
    • Organizations でアカウント作成
    • Organizations SCPの設定
  • 基本設定用のCFnを作成
    • 管理者用IAMRoleの発行
    • AWS Config Rulesの設定
    • 標準VPCの作成・設定など

AWS Organizationsを利用したアカウント作成の自動化 | Amazon Web Services

管理用権限の発行

• Landing Zone管理者あるいは各アカウントの管理者が対象アカウントを操作するための権限

• 認証にはIAM UserではなくSSOを使い、各アカウントにロールのみを作成することを推奨

  ※あくまで推奨

共有サービスへのアクセス

• オンプレミスとの接続経路を提供
• 共有サービスを配置するVPC
  • ファイルサーバ
  • ActiveDirectory
• Transit Gatewayを使ったマルチアカウントVPC間の通信
• Route53 Private Hostingを使った統一的な名前解決（によるPrivateLinkの共有）
  • Route53Resolver
• SharedVPCを使ったネットワークリソースの共有

AWSログの集約

• CraudTrailのログとAWS Configのログをログアカウントのバケットに集約
• 保存バケットのバケットポリシーと各サービスんさう新崎設定だけで実現可能

ログ送信を停止させられないようにログ送信元アカウントへのログ集約を停止させないSCPを付与する

SCPの設定

• 予防的ガードレールの設定
  • Organizations SCPによる設定
  • カスタマイズ可

必要最低限の設定を十分なテストを実施して適用すること

• 発見的ガードレールの設定

  • AWS Config Rulesの設定をCloudFormationで展開
  • StackSetsで複数のアカウント・リージョンに一括展開

  [新機能] CloudFormation StackSetsを試してみた | Developers.IO

  • ControlTowerで設定できる推奨項目はCloudFormationテンプレートがドキュメントに記載されている
  • 他のルールを使用したりAWS Config RDK(Rule Developing Kit)を使ったカスタムルールの作成も可能

参考：CloudFormation StackSets

• 1つのCFnテンプレートから複数のアカウント、リージョンにStackを同時展開する機能
• 各アカウントに用意した管理者権限を有するロールでStackを作成

参考：Control Towerのガードレール

• 必須のガードレール
  • Control Towerを正常に稼働させるために必要な禁止事項をSCPで定義したもの
  • 独自に実装する場合は必須ではないが、ログ保存を停止させない実装などが参考になる
• 強く推奨されるガードレール
  • マルチアカウントのベストプラクティスに基づく制限事項
  • SCPの例：rootユーザでアクセスキーを作らない、rootユーザで操作しないなど
  • ConfigRulesの例：EBSボリュームが暗号化されていること、S3のパブリック読み書き禁止など
• 選択的ガードレール
  • エンタープライズで一般的に利用されている制限事項
  • SCPの例：MFAなしのS3バケット削除禁止、S3バケットのクロスリージョンレプリカ禁止など
  • ConfigRulesの例：MFAなしのIAMユーザアクセス禁止、バージョニングのないS3の禁止など

まとめ

1. 多数のシステムをシンプルかつスケーラブルに管理するためにマルチアカウントによる管理と仕組みの活用が効果的
2. 1の構成を定義したLanding Zoneの実装はControlTowerの実装を参考にする
3. 基盤設定はCloudFomation StackSetsを使用してスケーラブルに展開

参考

AWS Innovate オンラインカンファレンス - [S-7] 増加するシステムをマルチアカウントで効率よく管理する