AWSマルチアカウント構成の設計と実践 - Tips紹介

蒲晃平 - 2022-2023 APN AWS Top Engineers （Security分野）

はじめに

こんにちは。アマゾンウェブサービス（AWS）関連の技術支援を担当している蒲です。

近年、AWSのマルチアカウント構成が流行ってますよね。マルチアカウント構成を導入することで、アカウントの効率的な管理やセキュリティとガバナンスの向上が期待できます。実際にお客様からAWS環境をマルチアカウント構成にしたいと相談される事が多くあります。

ただし、多くの組織ではマルチアカウント構成にするための設計や実装は一度だけ行われることが多く、何度も繰り返し行うものではありません。そのため、マルチアカウント構成を始める場合、社内に有識者がおらず、何から始めればいいのかわからないと悩まれるお客様が多いです。

私自身、多くのプロジェクトでエンタープライズ企業にマルチアカウント構成を導入してきました。
このブログでは、自分の経験をもとに、利便性と拡張性が高いマルチアカウント設計の考え方と取り込むべき共通機能などの実践的なTipsを紹介します。

そもそもなぜマルチアカウント構成にする必要があるのか？

端的に言うと、シングルアカウントの場合、運用上様々な問題が発生する可能性が高いためです。
例えば、複数のプロジェクトで複数のベンダーがシングルアカウントで開発しているケースを考えてみましょう。1つのアカウントに複数の環境を同居させることにより、誤ってAWSマネジメントコンソール上から他システムの本番環境のAmazon Elastic Compute Cloud（Amazon EC2）を停止してしまう等のインシデントが発生することがあります。また、プロジェクトごとにAWS利用料を配賦しようと思っても計算が非常に複雑で大変になります。
このようにシングルアカウントでの運用は、最初は困らなくても将来弊害が出てくることが多いです。

また、別観点からのマルチアカウント構成にする理由を下記の弊社ブログで解説していますので、あわせてご覧ください。

AWSマルチアカウント管理のススメ｜atlax/アトラックス｜野村総合研究所(NRI) - atlax blogs

マルチアカウント設計の考え方

アカウントを分割すれば課題は解決するのか？

シングルアカウントをやめて、システムやプロジェクトごとの単位で適切にアカウントを分けていけばそれでOKというものではありません。いたずらにアカウントだけ増えた場合、運用負荷はアカウント数に比例して増加してしまいますし、セキュリティレベルはアカウントごとにばらばらになり、セキュリティ対策がなされているか不明瞭な野良アカウントが生まれてしまうなどの弊害が起きえます。

こうなるともはやシングルアカウントの方が管理も行き届きやすく、マルチアカウントよりもシングルアカウントの方がトータルでメリットが大きいということになってしまいます。

目的に立ち返る

ここで改めてマルチアカウント管理の目的に立ち返ってみましょう。役割ごとに目的が変わってくるため、大きくアカウント管理者と開発者の目線で分けて記載してみます。

アカウント管理者目線

アカウント数が増えても運用負荷が大きくならないようにすること（アカウント管理の効率化）
どのアカウントにも均一なセキュリティ対策を施し、管理不透明なアカウントをなくすこと（ガバナンスの向上）

開発者目線

欲しい時にアカウントが払い出されて、直ぐに開発を始められること（アジリティの向上）
ガードレール^※1の中でセキュアな環境で安心・安全に開発できること（セキュリティレベルの向上）
アカウントごとの環境差異を意識せずに開発できること（開発体験の向上）

ただアカウントを分割するだけではなく、上記の目的を達成できるよう設計をすることがマルチアカウントの設計ポイントになってきます。最近では、複数のアカウント間で共通的に設定するものを集約管理できる共通機能がAWSから多くリリースされています。これら共通機能を上手く活用することこそマルチアカウントの目的を達成するためのポイントです。

ここからは、マルチアカウント管理に必要な共通機能の活用ノウハウを紹介していきます。

マルチアカウント設計のポイント

ポイント①：ユーザと権限を集約管理するために AWS IAM Identity Centerを活用する

AWSアカウントごとにAWS Identity and Access Management （IAM）ユーザと権限を作成すると運用が非常に煩雑になります。
下記の図のように、開発者はAWSアカウントごとにID・パスワード・多要素認証（MFA）デバイスを管理する必要があります。AWSアカウントごとにこれらを管理するのは大変です。

また、アカウント管理者にとっても、AWSアカウントごとにユーザの権限を管理する必要があるため、アカウントが増えるごとに管理負荷は増大していきます。

この課題を解決するのがAWS IAM Identity Center（IAM Identity Center）です。

IAM Identity Centerを使うことで、ユーザと権限を一箇所で管理することができ、開発者はAWSアカウントにログイン時にIAM Identity Centerのポータル側で認証されるため、ID・パスワード・MFAデバイスを1つだけ管理すれば良くなります。

また、アカウントごとに権限を作成する必要もなくなるため、アカウント管理者にとっても権限管理が楽になります。マルチアカウント構成ではIAM Identity Centerを使うことが定石になります。

IAM Identity Centerは無料で使えますし、さらに他にも便利機能があるため紹介していきます。

MFAデバイスの登録を必須にしよう

AWSアカウントの不正利用を防ぐために、ユーザにはMFAデバイスの登録を必須にしましょう。IAM Identity Centerを使えば、ユーザが初回ログイン時に必ずMFAデバイス登録することを強制できます。

IAM Identity Centerを使用せずにIAMを使う場合、MFAデバイス登録を強制するには複雑なIAMポリシーを記載する必要がありました。IAM Identity Centerでは下記の設定を有効化するだけMFAデバイス登録をユーザに強制できます。これは非常に便利ですので設定することを強く推奨します。

IAM Identity Centerを自社のID基盤と連携しよう

IAM Identity Center内でユーザを作成できますが、社内にはActive Directory やGoogle Workspace などのID基盤^※2がすでに存在しており、既存のID基盤側でユーザを管理したいケースはかなり多いと思います。

IAM Identity Centerは外部のID基盤と連携でき、ユーザの管理・認証を外部で行うことができます。既存のID基盤とユーザの二重管理を防ぐために、外部連携することをお勧めします。

AWSサービスと連携してシングルサインオンしよう

AWSサービスにはIaaSやPaaSだけではなく様々なSaaSサービスがあります。

SaaSサービスは独自のIDを作成する必要があったり、外部のID基盤と連携できるものも多いですが、最近はIAM Identity Centerとネイティブで統合できるサービスが増えてきました。つまり、IAM Identity Center上のユーザの認証情報で直接SaaSサービスにシングルサインオンができるということです。

IAM Identity Center のユーザでシングルサインオンできるサービスの例としては

- Amazon Managed Grafana

- Amazon SageMaker Studio

- Amazon CodeWhisperer

- Amazon QuickSight

などが挙げられます。（2023年8月時点）

他のサービスにも順次拡大していくと予想されますので、IAM Identity Center を使うだけで他のサービスもどんどん使いやすくなっていきます。

ポイント②：AWS Organizations の統合機能を使いこなそう

AWS Organizations とは？

AWS Organizations（Organizations ）とは、「組織」というグループに複数のAWSアカウントを所属させて、AWSアカウントを効率的に集約管理するアカウント管理サービスです。集約管理において管理用の親アカウントは「マスターアカウント」と呼ばれ、その他のアカウントは「メンバーアカウント」と呼ばれます。

Organizations の統合機能とは？

簡単に言うと、別のAWSサービスをマスターアカウントで有効にすることで、その他のメンバーアカウントでもそのAWSサービスを有効にしたり、メンバーアカウント上の設定をマスターアカウントから集約管理できるようになります。

多数のアカウントの設定をマスターアカウントから一括で設定導入・変更できるため、効率的なアカウント管理にはこの統合機能を使いこなすことがポイントになってきます。

現在では30個以上のAWSサービスがOrganizationsの統合機能に対応しており、サポートされるAWSサービスは順次追加されています。サポートされているAWSサービスは下記のAWSドキュメントから確認できます。https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_integrate_services_list.html

統合機能の具体的な活用イメージ

上記の説明では統合機能の活用イメージが湧かないと思いますので、AWS Security Hub（Security Hub）を例にして説明します。

AWS Security Hub とは？ AWSが用意したルールに基づいてAWSリソースの設定値のセキュリティチェックを行うサービスです。また、他のセキュリティサービスと統合されており、様々なセキュリティチェックの検知結果をダッシュボードで可視化することができます。

マスターアカウントからメンバーアカウントに一括設定（組織全体への展開）

統合機能を使わない場合、メンバーアカウントごとにSecurity Hubを有効化する必要があります。
組織統合機能を使うことで、メンバーアカウント作成時に自動で有効化されるため、全てのアカウントに対して漏れなくセキュリティ対策を実施できることがメリットになります。アカウント管理者にとって、アカウント発行時の作業負荷が下がり、ガバナンスの向上につながります。

メンバーアカウント内のSecurity Hub上のセキュリティ検知結果を集約・可視化

統合機能を使わない場合、Security Hubのセキュリティ検知結果は各メンバーアカウント上でのみ閲覧できます。アカウント管理者がセキュリティ対策状況を確認する際は、各メンバーアカウントに1個1個ログインしてSecurity Hub上のダッシュボードを確認する必要があります。

統合機能を使うことで、メンバーアカウント上のセキュリティ検知結果は自動でマスターアカウントに集約されます。アカウント管理者はメンバーアカウントを巡回する必要はなくなり、マスターアカウント上で全アカウントのセキュリティ対策状況を確認できることが大きなメリットになります。

統合機能をどこまで有効にすべきか？

Organizationsに統合機能にはAWSサービスごとに特色と制約があります。

例えば、Amazon GuardDuty（GuardDuty）ではメンバーアカウント側ではセキュリティの検出結果を抑止することができなくなる等の制約があり、マスターアカウントを管理しているアカウント管理者しか実施出来ないことが増えたりします。また、Security Hubを例にとるとセキュリティの検出結果の抑止は組織統合を有効化した場合もメンバーアカウント側で実施でき、逆にマスターアカウント側では実施できません。

もし、チームの役割分担として、セキュリティ検知時の一時対応や誤検知時の抑止対応などのタスクをメンバーアカウントを使用する開発者のタスクと整理している場合、もしかしたらGuardDutyの組織統合は有効にしない方が良いかもしれません。（GuardDutyを統合機能でマスターアカウントから有効化するのではなく、アカウント発行時にAWS CloudFormation等を使用して有効化する方針にするなどで代替）

このようにサービスごとの統合機能の制約を把握し、チームの運用方針とマッチする場合に組織統合を使うことをお勧めします。サービスごとの制約はサービスごとのAWS公式のユーザガイドから確認できます。

ポイント③ガードレールの中でも予防的ガードレール（SCP）の適用は慎重にする

開発者の開発を阻害せず安心・安全にAWS環境を利用してもらうためにガードレールを導入します。

マルチアカウントの定石として、ガードレールの内「予防的ガードレール」をOrganizationsの機能であるService Control Policies (SCP)を使って実装します。

SCPとは？

アカウントやOU（Organizational Unit：アカウントをグルーピングする単位）に適用する権限制御のためのポリシーです。IAMポリシーと似た構文でルールを定義します。
IAMポリシーがアカウント内での権限制御に用いられるのに対して、SCPはアカウント全体に適用される権限制御です。

SCPはアカウント内の「ルートアカウント」・「全てのIAMユーザ/ロール」に効力を発揮します。つまり、どんな強権限のユーザを使ったとしてもそのアカウント内ではSCPの制限が適用されます。

オススメのSCP適用方針

オススメのSCP適用方針は「最低限の制限にすること」です。

必要な権限までSCPで制限してしまうと、開発を阻害するばかりか、下記図のようなアカウント管理上も例外対応（SCPの適用範囲外に一時的にアカウントを退避するなど構成変更）の頻度が上がってしまいます。これでは運用負荷がアカウント数に比例して増大してしまい、マルチアカウント管理の目的と反してしまいます。

検知と是正ができれば問題のない操作は、予防的ガードレールではなく発見的ガードレール側で実装することを推奨します。

具体的なSCPの制限

参考までに、「最低限の制限」である具体的なルールの例を記載します。

アカウント管理者であっても禁止すべき操作の禁止

- 目的：通常運用ではアカウント管理者であっても、可監査性、情報漏えいの観点からすべきでない操作を禁止する

- 制限する項目

　- MFA認証されてない場合ルートユーザの利用を禁止

　- Organizationsからの離脱

　- 外部ネットワークとの接続の確立

　- Organizations外部とのリソース共有の作成

さいごに

いかがでしょうか。

正直に言いますとまだまだ書きたい設計ノウハウがたくさんありますが、分量が多くなりすぎるため、別の機会に発信したいと思います。

マルチアカウント構成については検討すべき項目がたくさんありますし、実際に運用してみないと組織にあった設計になっているのかわからないことも多いです。

また、有識者が不足のため、一から設計することはなかなか難しいものであり、AWSからAWS Control Towerなどのソリューションも出ていますが、使いこなすのは容易ではありません。

QUMOAには、マルチアカウント構成の導入・運用ソリューションがあります。AWSベストプラクティスとNRIがエンタープライズのお客様10社以上に設計・運用してきたノウハウを組み合わせたマルチアカウント構成を提供・運用します。また、既存の環境でも適用可能ですので、マルチアカウントでお悩みの方がいればぜひご相談ください。

QUMOAとは
「QUMOA」はクラウド黎明期から多数のお客様のAWS導入・運用を支援してきた「ノウハウと人材」を多彩なサービスで提供します。AWSの専門知識に加えて、バックエンド・フロントエンド開発、プライベートクラウド開発など、多彩なバックボーンやスキルを持ったメンバーがお客様のクラウド活用を支援します。QUMOAを導入することで、お客様は「クラウドを使って本当に取り組むべきこと」に集中できるようになります。

atlax.nri.co.jp

※1 ガードレール: セキュリティ上問題のある操作をしないよう検知、または防止する仕組みです。リスクがある構成などを検知・通知する「発見的ガードレール」と呼ばれ、一方実施してはいけない操作をポリシーで禁止する「予防的ガードレール」と呼ばれます。
※2 ID基盤：社内システムやクラウドサービスの利用に必要なID・パスワードを一元管理できる認証基盤