はじめに
今回はAWSのマルチアカウント管理に便利なサービス「AWS Organizations」を紹介したいと思います。
複数のAWSアカウントを一元的に管理するサービスですが、以下のような事が行なえます。
１．複数AWSアカウントを組織単位でグループ化、階層化し、組織単位でポリシーを適応することができる
２．複数AWSアカウントの請求をまとめて一括請求することができる
３．コンソール、SDK,CLIで新規のAWSアカウントを作成できる
4.AWS CloudTrail、AWS Security Hub、AWS Single Sign-Onなどの多くのサービスと連携し、これらのサービスの一元管理ができる
「１」はよくあるケースだと思いますが、例えば情報システム部門が会社全体で適応したいポリシーを定義・適応したい場面などで活用できます。
「２」は複数のAWSアカウントの請求を１つにまとめるサービスです。請求処理を簡略化するのにも便利ですが、一番のメリットはコスト削減かと思います。
サービス利用量を統合できるので、スケールメリットを得やすくなります。
「３」はアカウント作成の自動化をしたい場合などに便利です。
「4」は連携するサービスによって色々メリットがありますが、AWS CloudTrailやAmazon GuardDutyの一元管理などのセキュリティ関連のポリシー定義が一元管理できるのは便利だと思います。
AWS Organizationsの料金
AWS Organizationsサービス自体は無料で利用できます。
AWS Organizationsの用語と概念
まずは基本的な構成を見てみましょう。以下の図は公式ドキュメントの抜粋です。
AWS Organizations の用語と概念
ぱっと見ややこしいですが、概念的にはシンプルです。
・基本は「OU（組織単位)」でAWSアカウントを管理します。OUは図のように階層化することも出来ます。OUの最上位には「Organization root」が存在します。
・OUやOrganization rootにはポリシーを適応することが出来ます。
ポリシーにはSCP(サービスコントロールポリシー) やバックアップポリシーなどがあり
代表的なものはSCPです。SCPはIAMポリシーに似た機能を提供し、各組織で利用可能なサービス、アクションを定義することが出来ます。
基本的な用語をまとめてみます。
| 用語 | 内容 |
|---|---|
| 組織 | AWS Organizationsで管理する対象の全体 |
| OU (組織単位) |
組織内にある複数のAWSアカウントをグルーピングしたもの |
| SCP (サービスコントロールポリシー) |
使用できるサービスやアクションを指定するポリシー |
| マスターアカウント | AWS Organizations全体を管理するAWSアカウント |
| メンバーアカウント | 組織内にあるマスターアカウント以外のAWSアカウント |
OU(組織単位)の分割指針
ポリシーはOUの階層に従い継承されるので、AWS Organizationsを利用する上でOUの設計は重要です。
単純に一括請求を行うだけの場合は、あまり悩むことはないと思いますが、役割、責任に応じて分割する場合は悩むことも多いと思います。
分割指針の推奨構成については以下AWSのドキュメントも公開されているので参考にしてみてください。
Recommended OUs
一般的なものとしては以下のような分割があるかと思います。
・ 本番、開発環境などの環境別に分割
・ インフラチームとセキュリティチームの分割
・ 開発チームと監査チームの分割
・ ログ管理やデプロイ用など作業、機能に応じた分割
他のサービスとの連携：CloudTrail
AWS Organizationsを利用すると簡単にCloudTrailの一元管理を行うことが出来ます。
マスターアカウントでメンバーアカウントのCloudTrail有効化が設定出来、ログの出力先バケットを指定することが可能です。
マスターアカウントのS3に保存することも出来ますし、例えば監査用アカウントにログを集約することも可能です。
（S3と同様にオプションのCloudWatchLogsも有効化・集約することが出来ます）
他のサービスとの連携：Amazon GuardDuty
Amazon GuardDuty（以降GuardDuty)はマネージド型の脅威検出です。
S3イベント、CloudTrail、VPCフローログ、DNSログをAIで分析し、セキュリティリスクを検知します。
GuardDuty では「管理アカウント」と「メンバーアカウント」という概念があり、AWS Organizationsを利用せず複数のアカウントを管理したい場合、「管理アカウント」から「メンバーアカウント」を招待し、「メンバーアカウント」が承諾する必要があります。
AWS Organizationsを利用した場合はこのあたりの管理が楽になります。
AWS Organizationsでは GuradDuty の管理アカウントを指定し、委任することが出来ます。
委任されたアカウントでは所定のリージョンで GuardDuty が自動的に有効になり、そのリージョン内の組織すべてのアカウントに対して GuardDuty を有効にし管理する権限が付与されるので管理が少し楽になります。
以下公式ドキュメントにも記載がありますが、AWS Organizationsの管理アカウントを GurdDutyの管理アカウントに指定することは推奨されません。
組織の管理アカウントを委任された管理者として設定することは推奨されません。
組織の管理アカウントは委任された管理者になることはできますが、これは最小特権の原則
に従う AWS セキュリティのベストプラクティスに基づいて推奨されません。
AWS Organizations を使用した GuardDuty アカウントの管理
他のサービスとの連携：AWS Single Sign-On
AWS Single Sign-On(以降AWS SSO)とAWS Organizationsを統合すると複数AWSアカウントのシングルサインオン環境が簡単に構築できます。
AWS SSOを利用するとIAMユーザを作成作成することなく、アカウントの切り替えが可能になります。
AWS SSOではIAMロールとよく似た 「アクセス許可セット」 を作成し、アカウントに紐付けることで権限管理を行います。
アクセスが簡単になるメリットに加えて、AWS SSOを利用するとクレデンシャル情報は一時的なクレデンシャル情報となるため、セキュリティ面でもメリットがあります。
以上