AWSでマルチアカウント管理を考える（その２）

投稿日: 2022/07/22

はじめに

こんにちは、園田です。
本記事は、「AWSでマルチアカウント管理を考える（その２）」となります。
第1回目を見ていないという方はこちらを参照ください。

https://www.ctc-g.co.jp/solutions/cloud/column/article/52.html

本ブログはAWSでマルチアカウント管理を行う際の設計を行う際に、どんなことを考慮する必要があるよ。というのを記載します。
第2回はOrganizationsについてです。

AWS Organizationsとは

複数のＡWSカウントの「取りまとめ」と「制限をかける」ことが出来る機能となります。
大きく分けて以下の4つの機能が存在します。

• １．利用機能の制限
  サービスコントロールポリシー（SCP）の機能を利用して、各アカウントに対して共通の制限を設定

• ２．AWSアカウントの新規作成の自動化
  →　リセラー経由の場合、お客様では管理不用（リセラーが実施）

• ３．複数のAWSアカウントの請求を一括管理
  →　リセラー経由の場合、お客様では管理不用（リセラーが実施）

• ４．「AWS Control Tower」「AWS IAM Identity Center （旧SSO）」などのAWSサービスと連携して、統制を強化

リセラーを経由してAWSアカウントを契約している場合、上記のうち２と３はリセラーにて実施する（のが一般的）項目になります。そのため、特に利用者にて考慮する必要はありません

Organizationsですが、リセラーを経由している場合、そもそも利用できないケースもあります。これは、Organizations自体がアカウントを管理ツールとなるため、Organizationsを増やすことでリセラーの管理の手間が増えてしまいます。そのため、リセラー経由でアカウントを契約している場合、最初にOrganizations機能は利用可能か、またどのような権限をユーザに付与することが可能かをチェックするのが良いでしょう。

AWS環境の統制（Organizations）管理について

Organizationsにて管理するアカウントの全体像は以下の通りです。

また、用語と説明については以下の通りです。

ここで見ていただきたいのは、「OU」と「SCP」になります。
基本的にOUはADのOUと一緒と考えていただいて問題ありません。管理したい単位でOUを作り、そこにAWSアカウントを配置する形となります。
制限をかけるSCPはアカウント単位に割り当てることもできますが、基本的にOUに割り当てるのが管理上適切かと思います。

ここまで見ていただければなんとなくわかるかと思いますが、Organizationsを設計するということは、

• ①OUをどのように設計するか
• ②どのようなOUに対し、どのようなSCPを適用するか

ということを検討するということになります。

では1つずつ検討していきましょう。

OUの検討について

OUについては実際にSCPでどのような制限をかけたいか、ということに左右されます。
そのため、一律でこのようなOU形態にしておけばOKというのはありません。
また、お客様によってはどのようなSCPが必要になるかわからないため、後で要件が出た際に柔軟に対応できるようにしたい。という要望もあるかと思います。
その場合、システムアカウントを作成するタイミングで新規OUを作成してSCPを追加するというやり方もあります。ただ、この場合会社としてどのような方針を掲げているのかが、不明確になってしまいますのでやはりある程度の指針は定めておいたほうが良いでしょう。

という訳である程度の指針を持たせた設定例を記載します。

管理用OU

管理するアカウントが多くなってくると「共通機能を持たせるアカウント」（ログ集約、監視など）があったほうが管理しやすくなります。
また、別途Control towerのところで記載しますが、 Control tower利用にあたっては「log Archive Account」、「Audit Account」の2つのアカウントの利用が必要となります。
今後の統制も考慮し、管理用OUを作成し、サービス提供と分離しておくのが良いかなと思います。

サービス提供用OU

実際にシステム構築等で利用するアカウントが利用するOUです。
今回の例では、公開するシステムと社内のみ利用についてはデータの重要度に差異があるということで、「インターネットから直接接続可能とするシステム」と「社内からのみアクセス（インターネットからの直接アクセス不要）」という形でさらにOUを分割しています。
インターネットから接続不要な場合、VPCへのigwのアタッチを拒否するSCPを適用することで対応が可能です。

検証用OU

すでに利用しているAWSアカウントに対し、Organizationsを適用する場合きちんとシステムが動作するか不安という場合もあるかと思います。
検証用OUではOUに対しSCPを適用せず、アカウントに対しSCPを適用することで問題発生時に対象アカウントのSCPのみ変更が可能としています。（多分、問題が発生することはないと思いますが。）

SCPの検討について

SCPについては、このような操作のみをさせるという「ホワイトボックス形式」と、基本すべての操作を可能とするがこれだけは実施させないという「ブラックボックス形式」の設定方法が存在します。
基本AWSはどんどん新規の機能がリリースされますので、都度許可を追加するというホワイトボックス形式は運用に負荷がかかるためお勧めできません。 （特に利用できる機能を増やすつもりがないのであれば、運用不可は増えないのですがその場合、クラウドを使うメリットが損なわれてしまいます。方針次第ですが基本はブラックボックス形式が良いでしょう）

というわけで「どのような操作はさせたくないか」ですが、これも社内ポリシー等で「XXXの操作は望ましくない」などの規定があれば特に悩むことはないのですが、実際にはそのような規定があるお客様はほぼないかと思います。

基本SCPはIAMのポリシー定義とほぼ同様の記載ができるため、ほぼすべての操作について実施させないということが可能です。とはいえ、何でもできますと言ってもよくわからないと思いますので、以下にサンプルを載せたいと思います。

基本的には「無効化禁止」については実施しておいて問題ないかと思います。
この場合、特定のユーザやロールのみは無効化対象から外すということができるため、例外を持たせておいたほうが良いでしょう。（rootユーザ、および一部管理者のみは許可するなど）
SCPの制限はアカウントに実施するものとなるため、制限してしまうとrootユーザであっても実施することができませんのでご注意ください。

セキュリティグループの変更禁止などはきちんと運用ルールを定義する必要があるものについては、運用を実施していく中で必要であれば定義していく。というスタンスのほうが良いかと思います。

参考までに「特定のユーザやロールのみは無効化対象から外す例外設定」についてサンプルを記載します。

■特定のユーザ、ロール、rootからDeny制限を無効化するSCP設定

    {
        "Version": "2012-10-17",
        "Statement": [
            {
            "Sid": "DenyXXXXXX",
            "Effect": "Deny",
            "Action": [
                "XXXXXXXXX"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringNotLike": {
                "aws:PrincipalARN": [
                    "arn:aws:iam::*:user/XXXXX",
                    "arn:aws:iam::*:role/XXXXX",
                    "arn:aws:iam::*:root"
                ]
                }
            }
            }
        }
        

AWS Organizationsを利用しての基本統制について

また、ずいぶんと長くなってしまいましたが、第２回でOrganizations自体の設計については必要なものを説明できたかと思います。

とはいえ、実際は統制を取るということについては、

• ユーザ管理（IAM、SSO）
• Control tower
• Security Hub、GuardDuty、AWS Config
• NW全体設計

など様々な設計を実施する必要があります。

また、ずいぶん長くなってしまったため、一旦こちらで切らせていただきます。
第３回はユーザ管理（IAM、SSO）を予定しています。ユーザ管理とControl towerまで設計できれば統制の土台はできたという形になるかと思いますので、もう少々お付き合いください。

では、「AWSでマルチアカウント管理を考える（その３）」でお会いしましょう。

おわりに

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。