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

組織のポリシー サービスを使用すると、組織の 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 サービスは、制約のタイプと値を評価して、適用される制限を決定します。

カスタム制約は機能的にはブール型制約に似ており、適用されるか適用されないかのいずれかです。

管理対象の制約には、リストまたはブール値のパラメータがあります。使用可能なパラメータは、適用するサービスによって決まります。 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

マネージド制約

マネージド制約は、カスタム組織のポリシー プラットフォーム上に構築された制約です。カスタム組織のポリシー プラットフォームを使用すると、組織のポリシーをより柔軟に設計し、Policy Intelligence ツールからより多くの分析情報を得ることができます。

マネージド制約は、同等の事前定義された制約に代わるものです。同等の事前定義された制約の制約タイプがブール値の場合、マネージド制約は同じ方法で適用または適用しないようにできます。たとえば、次の組織のポリシーは、iam.disableServiceAccountCreation と同等の制約である iam.managed.disableServiceAccountCreation を適用します。

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

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

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

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

カスタム制約

カスタム制約では、ブール値制約と同じ方法でリソースの作成と更新を許可または制限できますが、管理者はリクエスト パラメータやその他のメタデータに基づいて条件を構成できます。Policy Intelligence ツールを使用して、カスタム組織のポリシーをテストおよび分析できます。

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

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

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

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

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

条件付き組織のポリシー

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

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

継承

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

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

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

違反

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

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

Policy Intelligence

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

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

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

次のステップ