組織ポリシー サービスの概要

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

利点

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

一般的なユースケース

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

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

Identity and Access Management との相違点

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

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

組織のポリシーの仕組み

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

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

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

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

制約

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

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

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

管理対象の制約には、適用する Google Cloud サービスによって決定されるリスト パラメータまたはブール パラメータがあります。

カスタム制約は、ブール値パラメータを持つ管理対象制約と機能的に類似しており、適用されるかされないかのいずれかです。

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

マネージド制約

マネージド制約は、同等の以前のマネージド制約を置き換えるように設計されていますが、ポリシー インテリジェンス ツールによる柔軟性と分析情報が追加されています。これらの制約は、カスタム組織のポリシーの制約と似た構造を持ちますが、Google によって管理されます。

同等の以前のマネージド制約の制約タイプがブール値の場合、マネージド制約は同じ方法で適用または適用されません。たとえば、次の組織のポリシーは、iam.disableServiceAccountCreation と同等の制約である iam.managed.disableServiceAccountCreation を適用します。

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

同等の以前のマネージド制約の制約タイプがリストの場合、マネージド制約は、制約によって制限されるリソースと動作を定義するパラメータの定義をサポートします。たとえば、次の組織ポリシーでは、example.com ドメインと altostrat.com ドメインのみを organizations/1234567890123 の重要な連絡先に追加できるマネージド制約が適用されます。

name: organizations/1234567890123/policies/essentialcontacts.managed.allowedContactDomains
spec:
   rules:
     - enforce: true
       parameters:
          allowedDomains:
               - @example.com
               - @altostrat.com

マネージド制約の使用の詳細については、制約の使用をご覧ください。

カスタム制約

マネージド制約と同様に、カスタム制約ではリソースの作成と更新を許可または制限できます。ただし、カスタム制約は Google ではなく組織によって管理されます。Policy Intelligence ツールを使用すると、カスタム組織のポリシーをテストして分析できます。

カスタム制約をサポートするサービス リソースの一覧については、カスタム制約でサポートされているサービスをご覧ください。

カスタム組織のポリシーの使用の詳細については、カスタム組織のポリシーの作成と管理をご覧ください。

カスタム制約のサンプルの一覧については、GitHub のカスタム組織ポリシー ライブラリをご覧ください。

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

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

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

ルールを一覧表示する

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

ドライラン モードの組織のポリシー

ドライラン モードの組織のポリシーは、他の組織のポリシーと同様に作成、適用され、ポリシーの違反は監査ログに記録されますが、違反アクションは拒否されません。

ドライラン モードの組織のポリシーを使用すると、ポリシーの変更が適用される前に、それがワークフローにどのような影響を与えるかをモニタリングできます。詳細については、ドライラン モードで組織のポリシーを作成するをご覧ください。

条件付き組織のポリシー

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

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

継承

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

子孫リソースに組織のポリシーを設定して、継承を上書きするか、親リソースの組織のポリシーを継承できます。後者の場合、2 つの組織ポリシーは階層評価のルールに基づいて統合されます。これにより、組織のポリシーが組織全体にどのように適用され、どこで例外を適用するかを正確に制御できます。

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

違反

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

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

Policy Intelligence

Policy Intelligence は、セキュリティ ポリシーの管理に役立つように設計されたツールスイートです。これらのツールは、リソースの使用状況の把握、既存のセキュリティ ポリシーの理解と改善、ポリシーの構成ミスの防止に役立ちます。

一部の Policy Intelligence ツールは、組織のポリシー サービスのポリシーのテストと分析に役立つように特別に設計されています。組織のポリシーに対するすべての変更のテストとドライランを行うことをおすすめします。Policy Intelligence を使用すると、次のようなタスクを実行できます。

これらのツールやその他の Policy Intelligence ツールの詳細については、Policy Intelligence の概要をご覧ください。

次のステップ