⛑️

[AWS]Organizationsにおけるマルチアカウント構成のベストプラクティスについて

2022/10/25に公開約7,200字

背景

ゴリゴリ系エンジニア、pageoです。
最近エンタープライズでの大規模な新規開発PJによく参加するのですが、権限管理周りで沼にハマるPJの99%はシングルAWSアカウントだと気づきました。
そこで、自分の経験をもとに、後に権限管理などで苦労しない拡張性の高いマルチアカウント設計のpageo的ベストプラクティスについて解説したいと思います。

はじめに

想定読者

  • AWS初学者,SAA, CLF保有者
  • スタートアップのインフラ担当者
  • 初めてAWSアカウントの運用担当になった開発者

前提知識

以下に、この記事を読むのに必要な前提知識を示します

  • 各IAMサービスの理解
  • AWS Organizationsについての理解
  • Switch Roleの理解
  • AWS SSO(IAM Identity Center)の理解

各IAMサービスの参考記事
https://blog.usize-tech.com/iam-rightmanage-1/
AWS Organizationsの参考記事
https://cloudnavi.nhn-techorus.com/archives/3977
Switch Roleの参考記事
https://dev.classmethod.jp/articles/samples-switchroles-policy-boundary-1/
AWS SSO(IAM IdentityCenter)の参考記事
https://dev.classmethod.jp/articles/aws-sso-wakewakame/

そもそもなぜマルチアカウントなのか

例えば以下のケースについて考えてください。

  • PJの規模が拡大して新規にプロダクトを開発する必要が出てきた
  • さまざまなAWSサービスでセンシティブな情報を扱う必要が出てきた
  • データ分析基盤/監視基盤だけでもかなり大規模になりそう
  • さまざまな関係者/ベンダーが関わる大規模PJになりそう

上記のケースにおいて、シングルアカウントで運用していると以下のように弊害が生じてきます

PJの規模が拡大して新規にプロダクトを開発する必要が出てきた

→ IAM PolicyやTagの設計を徹底していないと、意図しないIAM Userに他PJへのリソースへのアクセスを許してしまう
→ 例えば、誤ってAWS管理コンソール上から他PJの本番環境のEC2を停止してしまうなど、操作ミスが起因でインシデンをを起こしてしまう

さまざまなAWSサービスでセンシティブな情報を扱う必要が出てきた

→ IAM PolicyやTagの設計を徹底していないと、業務委託先の開発者などに情報漏洩してしまう

データ分析基盤/監視基盤だけでもかなり大規模になりそう

→ データ分析や監視のみ担当している開発者/関係者に不必要なAWSリソースへのアクセスを許してしまう

さまざまな関係者/ベンダーが関わる大規模PJになりそう

→ IAM PolicyやTagの設計を徹底していないと、業務委託先の開発者などに情報漏洩してしまう

などなど、PJ/プロダクトが大規模になるにつれてシングルアカウントでは運用難易度やセキュリティリスクが上がってしまいます
マルチアカウント構成であれば,例えば「PJの規模が拡大して新規にプロダクトを開発する必要が出てきた」というケースの「意図しないIAM Userに他PJへのリソースへのアクセスを許してしまう」という懸念に対して、
新規プロダクトに関するAWSアカウントを分離してAWS SSO(※1.3章で説明します)を使用したSwitch Roleによるアクセスに制限することで、「IAM PolicyやTagの設計を徹底していないといけない」対応に必要な運用工数を削減することができます

0. 先に結論

マルチアカウント設計のベストプラクティスは以下になります

  • アカウントの分離基準を決める
  • OU(Organization Unit)の分離基準を決める
  • AWS SSOを用いて認証する場所を集約する
  • 認証時のMFAを強制させる
  • 関係者をグルーピングして最小権限のみを与える

以下の章で詳しく説明したします

1. マルチアカウント設計

1.1 アカウントの分離を考える

アカウントの分離基準は何か

1.1章でマルチアカウントの必要性について認識できたところで、次はAWSアカウントの分離基準について説明します

実際にマルチアカウントを設計するにあたり、「どんな基準でアカウントを分離するのが良いか?」を悩まれている方が多いと思います
ここはさまざまな意見があると思いますが、以下の基準が考えられるのではないでしょうか

  • プロダクト/サービスごとに分ける
  • 基盤特性(アプリ基盤/分析基盤/監視基盤/データ基盤など)ごとに分ける
  • 環境(prod/stg/devなど)ごとに分ける

分離基準には対しては1つの正解があるわけではなく、そのPJの特性ごとに検討するのが良いと思います
例えば、センシティブな情報を扱う金融系/医療系のPJであれば、「プロダクト/サービスごと」かつ「環境ごと」に分離したり、プロダクトごとに開発者が違うようなPJであれば「プロダクト/サービスごと」に分離するなど、状況によってベストな分離基準は変わると思います

OUの分離基準は何か

分離基準が定まったところで、次はOrganizations Unit(以後、OU)の分離基準について説明します。
OUの設計も重要です。
例えば、後にSCPを用いたOUごとでの権限管理を行いたくなった場合などに、OUの設計が適切になされていればSCPの記述で困ることはありません。

OUの分離基準も、マルチアカウントの場合と同じくPJの特性ごとに検討するのが良いと思います
以下は基準の一例です

  • プロダクト/サービスごとに分ける
  • 基盤特性(アプリ基盤/分析基盤/監視基盤/データ基盤など)ごとに分ける
  • 環境(prod/stg/devなど)ごとに分ける

1.2 認証する場所は集約する

なぜ集約するのか

マルチアカウント構成の一番のデメリットは「AWSアカウントごとのIAM User認証情報の管理が煩雑になる」だと思います。
例えば、AWSアカウントごとにIAM Userを作成する運用をしてしまうと、各AWSアカウントにアクセスするたびにID/PW/OTPの入力をすることになり、非常に煩雑です。

そのため、AWS SSOを用いて認証/認可の管理を1つのAWSアカウントに集約するのがベストプラクティスになります。

Auth AccountでSSO

認証/認可の管理を集約するマスターAWSアカウント(以後、Auth Account)では、以下のリソースを管理します。

  • AWS Organizations
    • AWSアカウント
    • OU
  • AWS SSO
    • アクセス権限セット
    • ユーザー
    • グループ

Auth Accountで、グループ-AWSアカウント-アクセス権限セットを紐づけることにより、グループごとのアクセス可能なAWSアカウントとそれぞれの権限範囲を一元管理することができます
※ここでのグループとはSSOでの概念であり、IAM Groupとは別であることに注意

他AWSアカウントへのアクセスは、Auth Accountからのログイン(Switch Role)に集約できます

1.3 MFAは当たり前です

MFAを強制させましょう。
AWS SSOでMFA デバイス強制の設定が可能なので、「サインイン時に MFA デバイスの登録を必須とする」を必ず有効化しましょう
参考

AWS SSOが東京リージョンでGAされる前は、自前でMFA強制させるIAM Policyを設定する必要がありましたが、現在はAWS SSO(IAM Identity Center)がよしなにやってくれるみたいですね。便利な世の中になりました

1.4 グループを設計する

PoLPの重要性

スタートアップなど少人数での開発を前提とした企業やPJならまだしも、大規模開発/大企業/ミッションクリティカルなPJなどでIAM Policyを適当に設計するのはセキュリティ上かなり危険です。
セキュリティ(情報漏えい)事故の70%以上は内部犯行[1]と言われている昨今では、PJに参加した管理者/開発者/監査人含めて全ての人間が不正を起こす可能性を持っているという性悪説を前提に、権限管理を徹底すべきです
[1]: 経済犯罪実態調査

そのため、アクセス権限セットの設定では、PoLP: Principle of Least Privilege(最小権限/最小特権の原則)を必ず意識しましょう。
PJの初期段階でユーザー/グループを細かく設計し、役割ごとにアクセス権限セットのIAM Policyを適切なものに設定すべきです。

関係者とその役割を洗い出す

グループの設計で一番最初にすべきことは関係者の洗い出しです
現時点だけでなく将来関係するであろう人たちも含めて洗い出します。
関係者としては以下がよく挙げられます

  • 管理者:
    • PJ/プロダクト全般の管理者
    • 請求対応/IAM権限管理/緩和申請などを対応する
  • 開発者:
    • アプリケーションの開発者
    • アプリケーションの開発を担当する
    • 規模によってはBE/FE/Infraごと、またはプロダクトごとに分割する
  • 監査担当者:
    • PJ/プロダクト全般の監査担当者
    • リリース前/セキュリティインシデント時の監査対応をする
  • ベンダー:
    • 開発の一部などを委託されたベンダー
    • 限定された範囲のみ権限を付与する
    • 規模によってはベンダーごとに分割する

この関係者ごとにグループを作成し、アクセス権限セットとそれに紐づくIAM Policyを設計していきます。
例えば、AWSアカウントを「環境(prod/stg/devなど)ごと」且つ「プロダクト/サービスごと」に分離している場合は、最終的に以下のような構成になるのが理想です。

2. PJ事例

1章で設計方法を解説したので、2章では事例ごとのpageo的ベストプラクティスなマルチアカウント構成を説明していきたいと思います

2.1 小規模PJ

想定するPJ

PJ概要は以下を想定します

  • 比較的小規模(PM一人、開発者数人)
  • 環境はPRD/DEVのみ
  • プロダクトは1つ
  • 本番リリース後はPRD環境へのアクセスを厳格に制限する予定

AWSアカウントの分離基準は「プロダクト/サービスごと」かつ「環境(PRD/DEV)ごと」とします
OUの分離基準は、今後のプロダクト/サービスの拡張を見込んで「プロダクト/サービスごと」とします
関係者は管理者(PM)と開発者のみを想定しています

AWSアカウント構成イメージ

このPJの場合のAWSアカウント構成は、以下がpageo的にベストです

2.2 マルチサービスなPJ

想定するPJ

PJ概要は以下を想定

  • 中規模(PM: サービスごとに1名ずつ、開発者数人、テスター数人)
  • 環境はPRD/STG/DEV
  • プロダクトは2つ
  • 本番リリース後はPRD環境へのアクセスを厳格に制限する予定
  • 監視基盤/分析基盤が大規模になる予定

AWSアカウントの分離基準は「プロダクト/サービスごと」かつ「環境(PRD/STG/DEV)ごと」かつ「基盤特性(アプリ基盤/分析基盤/監視基盤/データ基盤など)ごと」とします
OUの分離基準は、今後のプロダクト/サービスの拡張を見込んで「プロダクト/サービスごと」かつ「基盤特性(アプリ基盤/分析基盤/監視基盤/データ基盤など)ごと」とします
関係者は管理者(PM)と開発者、閲覧者(テスター)、監査担当者を想定しています

AWSアカウント構成イメージ

このPJの場合のAWSアカウント構成は、以下がpageo的にベストです

最後に

IAM関連のサービスやAWS SSOの概念、Switch Roleなどについての説明を記載した記事はよく見るのですが、それらを応用した実際の設計や運用についての記事がなかったので、今回はマルチアカウント設計をベースにしてAWS Organizations/AWS SSO/IAMについての記事を書いてみました。

pageo的観測ではエンタープライズ系の会社ですらIAM設計/マルチアカウント設計を疎かにしているPJ/プロダクト/サービスをよく目にするので、この記事を見ていただいた方には是非気をつけていただきたいと思います。

参考

https://cloudnavi.nhn-techorus.com/archives/3977
https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/how-to-configure-mfa-device-enforcement.html
https://dev.classmethod.jp/articles/aws-sso-wakewakame/
https://katsuya-place.com/aws-force-mfa/

Discussion

ログインするとコメントできます