マルチアカウント

なぜマルチアカウント運用を勧めるのか？ それは「シングルアカウントでは限界があるから」です。
基本的に組織には様々な部門があり、それぞれ別々の目的を持っています。

そして、AWSの運用が拡大するにつれて、どの組織も以下の課題に悩まされることになります。

もちろんシングルアカウントでも、工夫次第で実施できるかもしれません。 しかし、組織ごとにAWSアカウントを分割することで、より簡単に課題を解決できます。

一方で、マルチアカウント運用にも課題があります。

ここからは、マルチアカウント設計のポイントについて説明していきます。

AWSアカウント設計のポイントは、以下の3つです。

1つずつ見ていきましょう。

スケーラブルとは、文字通り「拡張性」です。 後からでもアカウントを追加出来る設計を心がけましょう。
「拡張性」のあるアカウント設計のポイントは、以下の3つです。

役割を分割する、について、管理に必要な機能は別のアカウントに集約しましょう。 Guardrail型アプローチについて、やってはいけない事だけを禁止するような制御の実装を心がけましょう。 Landing Zoneを設計する、について、AWSアカウントの発行・初期設定を自動化しましょう。

これらを踏まえた実装を行うことで、柔軟にAWSアカウントの増加に耐えられる設計を実現できます。

Landing Zoneで設定を投入しても、時間経過と共に歪みが生まれます。

よくある例として、以下の3つが挙げられます。

野良リソースとは、誰が管理しているか分からないリソースのことです。 関わる人間が増えると、誰が作ったのか、使われているのか、消していいのか分からないリソースが発生してきます。 ベストプラクティス違反は、AWSリソースの設定が理想値と乖離することです。 AWSリソースの設定が、実装当初からセキュリティポリシーが変わったにも関わらず放置されたり、検証に使って修正を忘れられたり、様々な原因で発生します。 パッチ未適用インスタンスとは、文字通りメンテナンスがされていないインスタンスのことです。 これらを放置することは、いずれもセキュリティリスクの増加に繋がります。

コンプライアンスを管理し、即座に対応できる仕組みを用意しましょう。

マルチアカウント運用を円滑に回していく為、活用できるサービスは活用していきましょう。
代表的なものは、以下の3つです。

AWS Organizationsを用いることで、複数アカウントの一元管理、請求の一本化、新規アカウントの発行を行えます。 また、様々なサービスとの連携機能も実装されており、アカウントを跨いだサービス管理も可能になります。

AWS IAM Identity Centerとは、複数AWSアカウントを跨いでSingle Sign onを提供するサービスです。 これによって、ユーザ管理機能を外出し出来ます。

AWS CloudFormationは、テンプレートとして用意したリソースをまとめて作成するサービスです。 AWS Organizationsと連携して、発行したアカウントに自動デプロイも可能です。

これらのサービスを活用することで、マルチアカウント運用の工数を下げることができます。

いよいよ、ここからマルチアカウントの実装例をご紹介します。 大まかなポイントは2つあります。

ポイント1つ目。 AWSアカウントの設計では、スケーラブルなアカウント設計を心がけましょう。

AWS Organizationsで組織を作成し、AWS IAM Identity Centerでユーザ管理を外出し。 更に、セキュリティ機能を専用アカウントに集約することで、情報の分散を避けることができます。

セキュリティ機能は、ログ管理と監査の2つに分けることが多いです。 ログ管理アカウントのポイントはこちらです。

まず、「管理者以外はアクセスしない」。 これによって、誤操作・故意の削除からログを守ります。 そして、各種ログを集約します。 メジャーどころだとCloudTrailログ、S3操作ログ、アプリによってはCloudWatch Logsを集めることが多いです。 SCPで、これらの削除を禁止すると更に安全です。

次は監査アカウントのポイントです。

こちらは、AWSのセキュリティサービスを集約する事が主な役割です。 1つのアカウントに集約する事で、アラート管理・発報の仕組みをシンプルに出来ます。 基本的には、AWS Config Rules、Amazon GuardDuty、Amazon Inspector、AWS Trusted Advisorを集約する仕組みを作ります。 詳細は「コンプライアンス管理の実装」でご紹介します。

次はスケーラブルなアカウント設計の、権限制御について。

Guardrail型のアプローチを心がけましょう。 SCPを使って、絶対にやってはいけない操作を禁止します。 具体的には、以下です。

• セキュリティサービスの無効化禁止
• Landing Zone作成リソースの削除禁止

その他に会社毎のポリシーがあれば、それらを追記しましょう。

スケーラブルなアカウント設計の、最後のポイントはLanding Zoneの実装です。

CloudFormationを活用して、初期構築内容を定義しましょう。 マスターアカウントからStackSetsを使ってOUにデプロイしておく事で、OUにアカウントを追加した際、自動で初期構築を行えます。

また、弊社ではAWS標準ベストプラクティスに沿った設定も投入する為、別途Lambdaで実装しています。

以上を満たすことで、スケーラブルなアカウント設計を実現できます。

続きまして、コンプライアンス管理の実装について具体的に見ていきましょう。 前述の通り、よくあるコンプライアンス課題は以下の3つです。

これらは、それぞれAWS Config Rules、Amazon GuardDuty、Amazon Inspectorのサービスで管理出来ます。 そして、AWS Security Hubを利用する事で、アラートをまとめて管理する事が可能です。

弊社では、Security Hubを起点としたアラート発報の仕組みとして、以下のようなアーキテクチャを利用します。

各種セキュリティサービスを有効化し、Security Hub経由で集約します。 その後、Step Functionsのワークフローで各サービスに応じたメッセージへと変換し、アラートを発報します。 ちなみに、Trusted AdvisorのみSecurity Hubに対応していない為、EventBridgeを経由します。

こうすることで、サービス毎にアラート発報の仕組みを用意することなく、シンプルな仕組みでセキュリティアラートを実装出来ます。

ところで、ここまでAWS Organizationsを利用する前提でアーキテクチャを組んできました。 いろいろな都合で、Organizationsを利用できない方がいらっしゃると思います。 もちろん、AWS Organizations無しでもマルチアカウント運用は可能です。

例えば、以下のようなアーキテクチャがあります。

全ユーザを踏み台アカウントに作成し、運用アカウントの操作にはSwitch Roleを使用すると、疑似的なAWS SSOのような運用を行えます。 また、CloudFormationやCloudTrail、SecurityHubもアカウントIDを指定する事で連携出来るので、Organizationsを使っても使わなくても、同じように運用が可能です。

以上が、弊社でのマルチアカウント運用の実装例でした。

最後に、ここまでの情報をまとめます。

マルチアカウントを実現する為のAWSアカウント設計では、大きく2つのポイントがありました。 1つ目はスケーラブルなアカウント設計を行う事。 何を満たすとスケーラブルと言えるのか？ ・役割を分割して、マイクロサービスアーキテクチャで設計する事。 ・ガードレール型のアプローチで権限制御をしてあげる事。 ・アカウント発行を簡単に行えるようにしておく事。

これらを満たすアカウント設計を、スケーラブルと呼ぶことが出来ます。

ポイント2つ目は、コンプライアンス管理の仕組みを実装する事。 Landing Zoneを使って共通の設定を入れても、時間が経つにつれて歪みが生じます。 それらを検知・対処する為の仕組みを作ってあげましょう。 その為にセキュリティサービスを活用して、管理工数を削減していきましょう。

以上です。 マルチアカウント運用をご検討の際は、ぜひ私までご相談下さい。 エンジニアの濱田でした！