組織のポリシーの概要

組織のポリシー サービスを使用すると、組織の Cloud de Confiance リソースをプログラマティックに一元管理できます。組織のポリシー管理者は、リソース階層全体にわたって制約を構成できます。

利点

  • 組織のリソースの使用方法に関する制限を構成して集中管理できます。
  • 開発チームがコンプライアンスを遵守できるように違反防止策の定義と確立ができます。
  • プロジェクト オーナーとチームがコンプライアンス違反を恐れずに迅速に行動できるようになります。

一般的なユースケース

組織のポリシーを使用すると、次のことができます。

組織のリソースをきめ細かく制約できる制約は数多くあります。詳細については、組織のポリシーの制約すべての一覧をご覧ください。

Identity and Access Management との相違点

Identity and Access Management で重要なのは「誰であるか」です。管理者は、特定のリソースに対して誰がアクションを実施できるかを権限に基づいて承認します。

組織ポリシーで重要なのは「何」で、管理者は特定のリソースに対して制限を設定し、どのような構成が可能であるかを決定できます。

組織のポリシーの仕組み

組織のポリシーは、1 つ以上の Cloud de Confiance サービスを制限する単一の制約を構成します。組織のポリシーは、組織、フォルダ、またはプロジェクト リソースに対して設定され、そのリソースおよび子リソースに制約を適用します。

組織のポリシーには、制約を適用する方法と適用条件を指定するルールが 1 つ以上含まれます。たとえば、組織のポリシーに、environment=development タグのあるリソースにのみ制約を適用するルールと、他のリソースに制約が適用されないようにするルールを含めることができます。

組織のポリシーがアタッチされているリソースの子孫は、組織のポリシーを継承します。組織のポリシーを組織リソースに適用すると、組織のポリシー管理者は、組織全体で組織のポリシーの適用と制限の構成を制御できます。

組織のポリシーのコンセプト

制約

制約は、Cloud de Confiance サービスまたは Cloud de Confiance サービスのリストに対する特定のタイプの制限です。制約は、どのような行動が制御されているかを定義する青写真と考えることができます。たとえば、compute.storageResourceUseRestrictions 制約を使用して、プロジェクト リソースが Compute Engine ストレージ リソースにアクセスできないように制限できます。

このブループリントは、リソース階層内のリソースに組織のポリシーとして設定され、制約で定義されたルールが適用されます。その制約にマッピングされ、そのリソースに関連付けられた Cloud de Confiance サービスにより、組織のポリシー内で構成された制限が適用されます。

組織のポリシーは、適用する制約と、必要に応じて制約が適用される条件によって、YAML ファイルまたは JSON ファイルで定義されます。各組織のポリシーは、アクティブ モード、ドライラン モード、またはその両方で 1 つの制約のみを適用します。

以前のマネージド制約には、制約タイプに基づいて 1 つ以上のリストルールまたはブール値ルールがあります。リストルールは、許可または拒否された値のコレクションです。ブール値ルールでは、すべての値を許可するか、すべての値を拒否するか、制約が適用されるかどうかを判断できます。

マネージド制約（レガシー）

以前のマネージド制約の制約タイプはリストまたはブール値で、適用チェックに使用できる値を決定します。適用を行うCloud de Confiance サービスは、制約のタイプと値を評価して、適用される制限を決定します。

これらの以前の制約は、以前は事前定義された制約と呼ばれていました。

ルールを一覧表示する

リストルールのレガシー マネージド制約は、組織ポリシーで定義されている値のリストを許可または禁止します。以前は、これらの以前の制約はリスト制約と呼ばれていました。許可または拒否される値のリストは、階層サブツリー文字列として表されます。サブツリー文字列は、適用先のリソースのタイプを指定します。たとえば、以前のマネージド制約 constraints/compute.trustedImageProjects は、projects/PROJECT_ID の形式のプロジェクト ID のリストを受け取ります。

すべての値を許可する、すべての値を拒否する、または特定の値のリストを許可または拒否するように指定できます。許可値または拒否値のリストを指定すると、組織のポリシーは、これらの値のみが許可または拒否されることを暗黙的に評価します。たとえば、projects/PROJECT_ID のみを許可する制約がある場合、他のすべての値は暗黙的に拒否されます。

値に prefix:value 形式の接頭辞を付け、値をサポートする制約に条件を追加することもできます。

  • is: - 正確な値との比較を適用します。これは接頭辞がない場合と同じ動作で、値にコロンが含まれる場合には必須です。

  • under: - 値とそのすべての子の値に対して比較を適用します。この接頭辞が付いているリソースが許可または拒否される場合、その子リソースも許可または拒否されます。指定する値は、組織、フォルダ、プロジェクトのリソースの ID である必要があります。

  • in: - この値を含むすべてのリソースに対して比較を適用します。たとえば、constraints/gcp.resourceLocations 制約の拒否リストに in:us-locations を追加して、us リージョンに含まれるすべてのロケーションをブロックできます。

値のリストが指定されていない場合、または組織のポリシーが Google 管理のデフォルトに設定されている場合、制約のデフォルトの動作が適用され、すべての値が許可されるか、すべての値が拒否されます。

次の組織のポリシーは、organizations/1234567890123 の Compute Engine VM インスタンス vm-1 と vm-2 が外部 IP アドレスにアクセスできるようにする、以前のマネージド制約を適用します。

name: organizations/1234567890123/policies/compute.vmExternalIpAccess
spec:
  rules:
  - values:
      allowedValues:
      - is:projects/project_a/zones/us-central1-a/instances/vm-1
      - is:projects/project_b/zones/us-central1-a/instances/vm-2

ブール値のルール

ブール型ルールを含む以前のマネージド制約は、適用されるか適用されないかのいずれかです。たとえば、constraints/compute.disableSerialPortAccess には次の 2 つの状態があります。

  • 適用 - 制約が強制適用され、シリアルポート アクセスは許可されません。
  • 適用なし - disableSerialPortAccess 制約は強制適用も選択もされないため、シリアルポートへのアクセスが許可されます。

組織のポリシーが Google 管理のデフォルトに設定されている場合、制約のデフォルトの動作が適用されます。

これらの以前の制約は、以前はブール値の制約と呼ばれていました。

次の組織のポリシーは、organizations/1234567890123 で外部サービス アカウントの作成を無効にする以前のマネージド制約を適用します。

name: organizations/1234567890123/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

条件付き組織のポリシー

タグを使用すると、リソースに特定のタグが付加されているかどうかに基づいて、条件付きで制約を適用できます。タグを使用し、条件付きでの制約の適用を使用すると、階層内のリソースを集中管理できます。

タグの詳細については、タグの概要をご覧ください。タグを使用して条件付き組織のポリシーを設定する方法については、タグを使用して組織のポリシーのスコープを設定するをご覧ください。

継承

リソースに組織のポリシーが設定されている場合、そのリソースのすべての子孫はデフォルトでその組織のポリシーを継承します。組織リソースで組織のポリシーを設定した場合、そのポリシーで定義されている制限の構成は、子孫であるすべてのフォルダ、プロジェクト、サービス リソースに受け継がれます。

子孫リソースに組織のポリシーを設定して、継承をオーバーライドするか、親リソースの組織のポリシーを継承できます。以前のマネージド制約を適用する組織のポリシーは、階層評価のルールに基づいて統合されます。このシステムにより、組織のポリシーが組織全体にどのように適用され、どこで例外を適用するかを正確に制御できます。

詳細については、階層評価をご覧ください。

違反

違反とは、 Cloud de Confiance サービスがリソース階層のスコープ内にある組織のポリシー制限の構成に反して動作している状況を指します。 Cloud de Confiance サービスは制約を適用して違反を防止しますが、通常、新しい組織のポリシーの適用は遡及的ではありません。組織のポリシーの制約がさかのぼって適用されている場合は、[組織のポリシーの制約] ページでその旨のラベルが付けられます。

すでに発生しているサービスの動作や状態に対して新しい組織ポリシーにより制限が設定された場合、ポリシー違反状態とみなされますが、サービスは元の動作を停止しません。この違反には手動で対処する必要があります。この動作は新しい組織ポリシーによってビジネスの継続性が完全に損なわれるリスクを防ぐためのものです。

次のステップ