AWS Organizations

AWS Organizations の特徴

AWS Organizations は、複数の AWS アカウントを一元管理・統制するサービスです。アカウントだけでなく、ポリシー、設定を組織全体で一元管理できます。AWS アカウントの作成を自動化することもできます。アカウントを組織単位 (OU) にグループ化し、各 OU に異なるアクセスポリシーをアタッチすることができます。

AWS Organizations は、一括請求も可能です。組織の管理アカウントを使用して、すべてのメンバーアカウントを統合し、支払うことができます。マスターアカウントが一括して、すべてのメンバーアカウントの請求を支払います。

他の AWS のサービスと統合して Organizations を使用すれば、組織のアカウント全体の設定とリソース共有を一元的に定義できます。すべての AWS のユーザーは、追加料金なしで AWS Organizations を利用できます。

何のために AWS Organizations を利用するのか

AWS アカウントは、企業が AWS を利用していくうえ重要な境界になります。AWS アカウントを分けることで、権限・コスト・セキュリティ・運用責任を分離することができます。AWS 公式でも、アカウントは permission、security、costs、workloads の自然な境界だと説明しています。

AWS Organizations を利用することによるメリット

AWS Organizations の一括請求を使用することで、S3 を統合することができ、毎月かかるストレージの合計コストを安く抑えられることができます。

OU（組織単位）

OU は、Organizational Unit の略で、アカウントをグループ化する箱（単位）になります。OU にポリシーを付けると、その OU 配下のアカウントにまとめて適用できます。OU の中に子 OU を作ることもできます。

SCP（サービスコントロールポリシー）の特徴

SCP は、組織（Organization Unit、OU）のアクセス許可の管理に使用できる組織ポリシーです。組織のすべての AWS アカウントで使用可能な最大アクセス許可を一元的に制御できます。アカウントが組織のアクセスコントロールガイドラインに従っていることを確認するのに役立ちます。

SCP は個別の IAM ポリシーより優先されます。そのため、SCP で明示的に Deny されている場合は、個別の IAM ポリシーで Allow にしても許可されません。

SCP はすべての機能が有効になっている組織でのみ使用できます。

SCP は組織ルート、OU、AWS アカウントに対して割り当てることができます。ポリシーは継承して適用されます。

SCP は OU に対してデフォルトでフルアクセス権限が付与されています。例外として Root OU には SCP が適用できません。

管理アカウントの IAM ユーザーには SCP が影響されない

SCP はメンバーアカウントに効きます。委任管理者アカウントもメンバーアカウントなので、SCP の対象です。
一方で、管理アカウントの IAM ユーザーには SCP は効きません。

サービスリンクロール（Service-Linked Role）には SCP が影響されない

SCP（サービスコントロールポリシー）の設定により一元的に組織（アカウント）を管理できますが、サービスにリンクされた IAM ロール（サービスリンクロール、Service-Linked Role）には影響しません。IAM ロールはアカウントではなくロールあり、アカウントに代わってサービスから他のサービスを呼び出す構造のためとなります。

SCP で Effect : Allow

SCP で明示的に Effect : Allow を設定した場合はどうなるでしょうか。

AWS Organizations では、作成時にFullAWSAccess という AWS 管理 SCP が、ルート・OU・アカウントにデフォルトでアタッチされます。これは 全サービス・全アクションを Allow する SCP です。デフォルトでアタッチされているので、個別に明示的にEffect : Allow を設定しても意味がないように見えます。しかし例えばFullAWSAccess を別の SCP に置き換えて明示的に Action を許可する戦略も可能です。その場合は個別に SCP で Effect:Allow を設定することは戦略の一つとしては有効です。

管理アカウント

管理アカウントとは、組織を作成するために使用するAWSアカウントのことです。管理アカウントは、アカウント管理、ポリシー、他の AWS サービスとの統合、一括請求など、前述のすべての管理タスクにとって重要なアカウントです。

管理アカウントは組織の最終的な所有者であり、セキュリティ、インフラストラクチャ、および財務ポリシーに対する最終的な管理権限を持ちます。このアカウントは支払アカウントとしての役割も担い、組織内のアカウントで発生したすべての料金の支払いを担当します。

管理アカウントは1つだけしか作れません。更に後から別アカウントに切り替えることはできません。

管理アカウントで一括してメンバーアカウントの設定が可能

AWS Organizations を利用することでメンバーアカウントに対して1つ1つ設定をしなくても管理アカウントで一括してメンバーアカウントの設定が可能です。

例えば監査の設定をしなければいけない場合、メンバーアカウントに対して1つ1つ設定をしなくても管理アカウントで一括してメンバーアカウントに対して CloudTrail の設定をすることが可能です。これにより設定もれをなくすことができます。

メンバーアカウント

メンバーアカウントとは、管理アカウント以外の組織に属する AWS アカウント全部のことです。

メンバーアカウントの作成と権限

AWS Organizations コンソールを使用してメンバーアカウントを作成すると、アカウントの IAM ロールの権限である OrganizationAccountAccessRole が自動的に作成されます。

このロールには、メンバーアカウントの完全な管理権限が含まれます。

逆に既存のアカウントをメンバーアカウントに設定する場合は、OrganizationAccountAccessRole が自動的に割り当てられないので改めて割り当てをする必要があります。

• マスターアカウント　←　AWS Organizations での管理者
• メンバーアカウント　←　AWS Organizations で管理されるアカウント

メンバーアカウントを削除する場合

組織が変更された場合は AWS Organizations からメンバーアカウントを削除することができます。

ただし削除する前にメンバーアカウントでの請求を IAM ユーザーアクセスで有効にした後でないとメンバーアカウントを削除できません。

委任管理者アカウント

委任管理者アカウント（Delegated Administrator）は管理アカウントの代わりに、メンバーアカウントの中から選ばれる、特定サービスを組織全体で管理するために任命されるアカウントです。

例えば、バックアップはこの AWS アカウント（アカウントC）で一番管理を任せたいという時に、アカウント C に AWS Backup を設定して AWS Backup の委任管理者アカウントにして運用させることができます。管理アカウント上で全てやろうとすると、様々な役割のメンバーが入り混じり権限や責任が不明確になります。そのため、委任管理者アカウントを作成して運用メンバーと対象サービスを分けるとよりガバナンスが効いた状態になります。

組織の証跡

AWS Organizations で組織を作成した場合は、その組織内のすべての AWS アカウントのすべてのイベントを記録する証跡を作成できます。

これを「組織の証跡」と呼びます。

すべての機能（機能セット）を選択すると、CloudTrailコンソールの設定機能で「組織の証跡」を有効化する設定が表示されるようになります。

組織の証跡を設定すると、組織内のマスターアカウントとすべてのメンバーアカウントの CloudTrail イベントを同じ Amazon S3 バケット、CloudWatch Logs、CloudWatch イベントに配信できるようになります。

2つの機能セット

AWS Organizations では 2つの機能セットを利用できます。

• すべての機能　←　組織を作成する際、デフォルトで「すべての機能」が有効になっています。SCP（サービスコントロールポリシー）を利用する場合は「すべての機能」を有効化する必要があります。
• 一括請求機能　←　組織内のアカウント管理を一元化するために使用できる基本的な管理ツールが提供されます。

Organizations のセキュリティ対応

ルートユーザーの使用を制御する

ルートユーザーの仕様を制御するには、AWS Organizations で OU（組織単位）を作成し、ルートユーザーの使用を制御する SCP（サービスコントロールポリシー）を適用します。そして、すべてのメンバーアカウントをこのOU に追加します。