ドメインで制限された共有

ドメインで制限された共有を使用すると、ドメインまたは組織リソースに基づいてリソース共有を制限できます。ドメイン制限付き共有が有効になっている場合、許可されたドメインまたは組織に属するプリンシパルのみ、 Google Cloud 組織で IAM ロールを付与できます。

ドメイン別の共有を制限する方法

Organization Policy Service を使用して、ドメインまたは組織リソースに基づいてリソースの共有を制限するには、いくつかの方法があります。

  • iam.googleapis.com/AllowPolicy リソースを参照するカスタム組織のポリシー: カスタム組織のポリシーを使用すると、特定のプリンシパル セットにのみロールを付与できます。

    この方法では、次の CEL 関数を使用して、組織でロールを付与できるユーザーを定義します。

    組織内のすべてのプリンシパルにロールを付与できるようにするには、memberInPrincipalSet 関数で組織のプリンシパル セットを指定し、制約に組織のプリンシパル セットを含めます。

    これらの CEL 関数を使用してカスタムの組織のポリシーを作成する方法については、カスタムの組織のポリシーを使用してドメイン制限付き共有を実装するをご覧ください。

  • iam.managed.allowedPolicyMembers マネージド制約: このマネージド制約を適用すると、制約にリストされているプリンシパルとプリンシパル セットにのみロールを付与できます。

    このマネージド制約を使用すると、ロールの付与を許可するプリンシパルとプリンシパル セットを一覧表示できます。ただし、この方法はカスタム組織ポリシーを使用する方法よりも柔軟性に欠けます。たとえば、メンバータイプに基づいて許可されたプリンシパルを構成したり、特定のプリンシパルにロールを付与できないようにしたりすることはできません。

    組織内のすべてのプリンシパルにロールを付与できるようにするには、制約に組織のプリンシパル セットを含めます。

    この制約を設定する方法については、iam.managed.allowedPolicyMembers 制約を使用してドメイン制限付き共有を実装するをご覧ください。

  • iam.allowedPolicyMemberDomains 事前定義制約: この事前定義制約を適用すると、組織内のプリンシパルにのみロールを付与できます。組織リソース ID または Google Workspace のお客様 ID に基づいてアクセスを制限できます。これらの ID の違いについては、このページの組織リソース ID と Google Workspace のお客様 ID をご覧ください。

    この制約では、特定のプリンシパルの例外を構成することはできません。たとえば、iam.allowedPolicyMemberDomains 制約を適用する組織内のサービス エージェントにロールを付与する必要がある場合を考えてみましょう。サービス エージェントは Google によって作成、管理されるため、組織、Google Workspace アカウント、Cloud Identity ドメインの一部ではありません。そのため、サービス エージェントにロールを付与するには、制約を無効にしてロールを付与してから、制約を再度有効にする必要があります。

    フォルダまたはプロジェクト レベルで組織のポリシーをオーバーライドして、どのフォルダまたはプロジェクトでロールを付与できるユーザーを変更できます。詳細については、プロジェクトの組織のポリシーをオーバーライドするをご覧ください。

    この制約を設定する方法については、iam.allowedPolicyMemberDomains 制約を使用してドメイン制限付き共有を実装するをご覧ください。

ドメインで制限された共有の仕組み

組織のポリシーを使用してドメインで制限された共有を適用すると、指定したドメインと個人以外のプリンシパルに組織の IAM ロールを付与することはできません。

以降のセクションでは、組織でドメイン制限付き共有制約がどのように機能するかについて、主な詳細を説明します。

制約は遡及的ではありません

組織のポリシーの制約は遡って適用されません。ドメイン制限が設定されると、この制限はその時点より後の許可ポリシーの変更に適用され、過去の変更には適用されません。

たとえば、examplepetstore.comaltostrat.com の 2 つの関連する組織について考えてみましょう。examplepetstore.com ID に altostrat.com の IAM ロールを付与しました。後で、ドメインごとに ID を制限することにし、altostrat.com にドメイン制限の制約を含む組織のポリシーを実装しました。この場合、既存の examplepetstore.com ID は altostrat.com へのアクセス権を失いません。その時点で、IAM ロールを付与できるのは altostrat.com ドメインの ID に限られます。

制約は、IAM ポリシーが設定されるたびに適用されます。

ドメイン制限の制約は、IAM ポリシーが設定されているすべてのアクションに適用されます。これには、自動アクションも含まれます。たとえば、制約は、サービス エージェントが別のアクションに応じて行う変更に適用されます。たとえば、BigQuery データセットをインポートする自動化サービスがある場合、BigQuery サービス エージェントは新しく作成されたデータセットに対して IAM ポリシーを変更します。このアクションは、ドメイン制限の制約によって制限され、ブロックされます。

制約にドメインが自動的に含まれない

ドメイン制限の制約を設定しても、組織のドメインがポリシーの許可リストに自動的に追加されることはありません。ドメイン内のプリンシパルに組織内の IAM ロールを付与するには、ドメインを明示的に追加する必要があります。ドメインを追加せず、ドメイン内のすべてのユーザーから組織のポリシー管理者ロール(roles/orgpolicy.policyAdmin)が削除されると、組織のポリシーにアクセスできなくなります。

Google グループとドメインで制限された共有

組織でドメイン制限の制約が適用されている場合、グループが許可されたドメインに属していても、新しく作成された Google グループにロールを付与できないことがあります。これは、グループが Google Cloudに完全に伝播されるまでに最大 24 時間かかる可能性があるためです。新しく作成した Google グループにロールを付与できない場合は、24 時間待ってからもう一度お試しください。

また、グループが許可されたドメインに属しているかどうかを評価する際、IAM はグループのドメインのみを評価します。グループのメンバーのドメインは評価されません。そのため、プロジェクト管理者は、外部メンバーを Google グループに追加し、その Google グループにロールを付与することで、ドメイン制限の制約を回避できます。

プロジェクト管理者がドメイン制限の制約を回避できないようにするために、Google Workspace 管理者は、グループ オーナーが Google Workspace 管理者パネルでドメイン外のメンバーを許可できないようにする必要があります。

組織リソース ID と Google Workspace お客様 ID

iam.allowedPolicyMemberDomains の事前定義された制約を使用してドメインで制限された共有を実装する場合は、組織リソース ID または Google Workspace お客様 ID に基づいてアクセスを制限できます。

組織リソース ID を使用すると、次のプリンシパルに組織内のロールを付与できます。

  • 組織内のすべての Workforce Identity プール
  • 組織内の任意のプロジェクト内のすべてのサービス アカウントと Workload Identity プール
  • 組織のリソースに関連付けられているすべてのサービス エージェント

Google Workspace お客様 ID を使用すると、次のプリンシパルに組織内のロールを付与できます。

  • Google Workspace のお客様 ID に関連付けられているすべてのドメイン(サブドメインを含む)内のすべての ID
  • 組織内のすべての Workforce Identity プール
  • 組織内の任意のプロジェクト内のすべてのサービス アカウントと Workload Identity プール
  • 組織内のリソースに関連付けられているすべてのサービス エージェント

特定のサブドメインに対してドメイン制限付きの共有を実装する場合は、サブドメインごとに個別の Google Workspace アカウントを作成する必要があります。複数の Google Workspace アカウントの管理の詳細については、複数の組織の管理をご覧ください。