AWS Organizations
ユーザーガイド

AWS Organizations の用語と概念

このトピックでは、AWS Organizations の使用開始に役立ついくつかの重要な概念について説明します。

次の図は、基本的な組織を示しています。この組織は、7 つのアカウントで構成されており、そのアカウントは、ルートを親として、4 つの組織単位 (OU) に分類されています。この組織には、複数のポリシーがあり、OU の一部、またはアカウントに直接アタッチされています。これらの各項目の詳細については、このトピックの定義を参照してください。


      基本的な組織の図
組織

AWS アカウントを統合するために作成するエンティティ。AWS Organizations コンソールを使用して、組織内のすべてのアカウントを一元的に表示および管理できます。組織には、1 つのマスターアカウントと、ゼロ以上のメンバーアカウントを含みます。最上部が ルートの階層ツリーを模擬した構造のアカウントや、ルート下に作られた組織単位を整理できます。各アカウントは、ルートに直接含めるか、階層内の OU のいずれかに配置することができます。組織には、有効にする機能セットによって決定された機能を含みます。

ルート

組織のすべてのアカウントが設定された親コンテナポリシーをルートに適用する場合は、組織内のすべての組織単位 (OU)アカウントに適用されます。

注記

現在、ルートは 1 つのみ持つことができます。組織の作成時に、AWS Organizations によって自動的に作成されます。

組織単位 (OU)

ルート内のアカウントのコンテナです。また、OU は他の OU に含めることもでき、上下反転したツリーのような階層を作成できます。最上部にはルートがあり、下に向かって OU の枝が広がり、先端にはツリーの葉であるアカウントがあります。階層内のノードのいずれかにポリシーをアタッチすると、その配下にあるすべての枝 (OU) や葉 (アカウント) に適用されます。OU は、厳密に親を 1 つ持つことができ、現在、各アカウントを厳密に 1 つの OU のメンバーにすることができます。

アカウント

AWS リソースを含む標準の AWS アカウント。1 つのアカウントにポリシーをアタッチして、そのアカウントのみ制御することができます。

組織には、1 つのアカウントがマスターアカウントとして指定されています。組織は、このアカウントで作成します。組織に属する残りのアカウントは、メンバーアカウントと呼ばれます。組織のマスターアカウントを使用すると、組織のアカウント作成、組織への他の既存アカウントの招待、組織からのアカウント削除、招待の管理、組織内のエンティティ (ルート、OU、アカウント) へのポリシーの適用を行うことができます。アカウントが組織のメンバーになることができるのは、一度にひとつのみです。

マスターアカウントには、支払いアカウントだけでなく、メンバーアカウントによって発生したすべての料金を支払う責任があります。

招待

別のアカウント組織に招待するプロセスです。招待は、組織のマスターアカウントでのみ発行することができ、招待済みのアカウントに関連付けられたアカウント ID または E メールアドレスに通知されます。招待済みのアカウントによって招待が承認されると、そのアカウントが、組織のメンバーアカウントになります。一括請求機能のみのサポートから、組織のすべての機能のサポートへの変更にすべてのメンバーが承認する必要が出てきた場合に、現在のすべてのメンバーアカウントに招待を送信することもできます。招待は、ハンドシェイクを交換するアカウントによって行われます。AWS CLI または AWS Organizations API を使用している場合、AWS Organizations コンソールで実行するとハンドシェイクが表示されない場合がありますが、ハンドシェイクを使用して直接操作する必要があります。

ハンドシェイク

二者間で情報を交換する複数ステップのプロセスです。AWS Organizations の主な用途のひとつは、invitations の基盤実装として提供することです。ハンドシェイクメッセージは、両者が現在のステータスを随時把握していることを確認する方法で、ハンドシェイク実行者と受信者間で受け渡しされます。また、ハンドシェイクは、一括請求機能のみのサポートから、AWS Organizations で提供されるすべての機能のサポートへ組織を変更する際にも使用されます。通常、ハンドシェイクは、AWS Organizations API または AWS CLI などのコマンドラインツールを使用する場合にのみ、直接交換する必要があります。

利用可能な機能セット
  • 一括請求 (コンソリデーティッドビリング) – これは共有請求機能を提供しますが、この機能には別のアカウントのユーザーやロールで実行できる操作を制限するためのポリシーの使用など、AWS Organizations の高度な機能は含まれていません。高度な AWS Organizations 機能を使用するには、組織のすべての機能を有効にする必要があります。

  • すべての機能 – AWS Organizations で利用できる完全な機能セットです。一括請求のすべての機能だけでなく、高度な機能を使用して、組織のアカウントを詳細に制御できます。たとえば、すべての機能が有効な場合、組織のマスターアカウントは、メンバーアカウントより完全に制御できます。マスターアカウントでは、サービスやアクションを制限する SCP を適用できます。これにより、アカウントのユーザー (ルートユーザーを含む) やロールで組織にアクセスすることはできますが、メンバーアカウントが組織を離れることはできなくなります。すべての機能を有効にして組織を作成するか、組織の設定を一括請求機能のみのサポートからすべての機能のサポートに変更することができます。すべての機能を有効にするには、招待済みのすべてのメンバーアカウントを使用して、マスターアカウントでプロセスを開始する際に送信される招待を承認し、変更を承認する必要があります。

サービスコントロールポリシー (SCP)

ユーザーやロールが、SCP による影響を受けるアカウントで使用できるサービスやアクションを指定するポリシーです。アクセス権限が付与されない点を除き、SCP は、IAM アクセス権限ポリシーと類似しています。その代わり、SCP は、影響を受けるアカウントで指定のサービスやアクションのみを使用できるようにするフィルターです。IAM アクセス権限ポリシーが適用されている完全な管理者アクセス権限がユーザーに付与されている場合でも、対象アカウントに影響を及ぼす SCP によって明示的に許可されていない、または明示的に拒否されているアクセスはすべてブロックされます。たとえば、データベースサービスのみ、「データベース」アカウントにアクセスできる SCP を割り当てると、アカウントのユーザー、グループ、ロールによる他のすべてのサービスのオペレーションへのアクセスは拒否されます。SCP は、組織のすべての機能が有効な場合にのみ使用できます。SCP は次にアタッチできます。

  • ルート。組織のすべてのアカウントに影響します。

  • OU。OU のすべてのアカウントや、その OU のサブツリーにある OU のすべてのアカウントに適用されます。

  • 個々のアカウント

重要

組織のマスターアカウントは、組織、ルート、またはマスターアカウントが所属している OU のいずれかに SCP がアタッチされていても、影響を受けることはありません。

ホワイトリストとブラックリスト

ホワイトリストおよびブラックリストは、SCP を適用して、アカウントで使用できるアクセス権限をフィルタリングする際に使用できる完全な技術です。

  • Whitelisting – 許可するアクセス権限を明示的に指定します。その他のアクセス権限はすべて暗黙的にブロックされます。デフォルトでは、AWS Organizations によって、FullAWSAccess と呼ばれる AWS 管理ポリシーがすべてのルート、OU、アカウントにアタッチされます。そのため、組織を構成する際は、設定しない限り一切ブロックされません。つまり、デフォルトではすべてのアクセス権限がホワイトリストに登録されます。アクセス権限を制限する準備ができたら、FullAWSAccess ポリシーを、制限かつ指定された一連の権限のみ使用できるポリシーに変更します。影響を受けるアカウントのユーザーやロールは、IAM ポリシーですべてのアクションを実行できる場合でも、対象アクセスレベルのみ実行できます。ルートのデフォルトポリシーを変更する場合、組織内のアカウントはすべて、制限が適用されます。SCP は、権限を付与することができず、フィルタリングのみを行うため、階層の下位レベルで追加し直すことはできません。

  • Blacklisting – 許可しないアクセス権限を指定します。その他のアクセス権限はすべて有効になります。このシナリオでは、明示的にブロックされる場合を除き、すべてのアクセス権限が有効です。これが AWS Organizations のデフォルトの動作です。デフォルトでは、AWS Organizations によって、FullAWSAccess と呼ばれる AWS 管理ポリシーがすべてのルート、OU、アカウントにアタッチされます。そのため、どのアカウントでも、AWS Organizations– の制限が適用されることなく、サービスやオペレーションにアクセスできます。上記で説明されたホワイトリストの手法を使用する場合とは異なり、ブラックリストを使用すると、通常はデフォルトの FullAWSAccess ポリシーはそのままになります (「すべて」許可) が、望まないサービスやアクションへのアクセスを明示的に拒否するための追加のポリシーをアタッチします。IAM アクセス権限ポリシーを使用するように、サービスアクションを明示的に拒否すると、許可されたアクションも上書きされます。