これからGoogle Cloudの利用を開始するときに追加で有効化を検討しておきたい組織ポリシー

はじめに

こんにちは。
クラウド事業本部コンサルティング部の渡邉です。

組織としてGoogle Cloudのガバナンス・統制を効かせていくうえで、組織ポリシーは非常に重要な機能になります。
組織ポリシーを適用することで、組織として順守するべきルールや、意図せぬ利用者のミスを防ぐことができ、安全にGoogle Cloudを利用することができます。

今回は、これからGoogle Cloudを利用を開始するとした場合に、デフォルトで適用されている組織ポリシーに加えて追加で有効化を検討したほうが良い組織ポリシーを紹介します。

組織ポリシーとは

組織ポリシーとは、Google Cloudを利用する上で、組織で管理されているすべてのプロジェクトに対してルール:制約を設定し、強制的に順守させることができるサービスです。
セキュリティ基準が厳しい業界でGoogle Cloudを利用する場合や、自社のセキュリティポリシーで許されない行為などは組織ポリシーを利用することで防止することができます。
Google Cloudで安心安全に開発を行う上で、組織ポリシーの利用は強く推奨されます。

組織ポリシーを利用することで、以下のようなルールを設定することができます。

• 作成するリソースの物理的なロケーション (リージョン) を東京リージョン (asia-northeast1)のみに制限することができる
• サービスアカウントキーの発行を禁止する
• 自社ドメインのみしかIAMに登録することができないようにする

組織ポリシーの仕組み

Google Cloudは、組織を最上位とし、その配下にフォルダ、プロジェクト、リソースと階層構造になっています。
組織ポリシーは、組織、フォルダ、またはプロジェクトリソースに対して設定を行うことができ、そのリソースおよび子リソースに制約を適用 (継承) します。
そのため、組織全体としてポリシーを効かせたい場合は、組織に対して組織ポリシーを設定し、ある特定のフォルダ配下のプロジェクトや、特定のプロジェクトのみにポリシーを適用したい場合は、フォルダ、プロジェクトに対して組織ポリシーを設定することができます。
また、継承を禁止することもできるので、特定のフォルダには組織で定義したポリシーを適用させない方法も可能です。

本図の場合は、example.com組織に、

• Cloud Storageのバケットの外部公開禁止
• VMへのパブリックIPアドレス付与禁止

の組織ポリシーが付与されているので、example.com組織配下のすべてのフォルダ、プロジェクトはこれらの組織ポリシーを継承します。
network-mngフォルダに追加で

• サービスアカウントキーの発行を禁止

の組織ポリシーを付与した場合は、network-mngフォルダ配下のプロジェクトのみが、「サービスアカウントキーの発行を禁止」の組織ポリシーを継承します。

制約

制約は、組織ポリシーにおける一つ一つのルールです。リソース階層（組織、フォルダ、プロジェクト）内でどのような操作や設定が許可または禁止されるかを制御します。

制約は以下の2つのパラメータパターンによって定義されます。
ブール値パラメータ

• 制約を適用するか、しないかの二択
• 例: TRUE（有効）、FALSE（無効）

リストパラメータ

• 許可または拒否する値のリストを指定
• より詳細な制御が可能

制約には、以下の3つの種類があります。

1. マネージド制約（現行版）

マネージド制約は、Google Cloud側によって管理・運用される制約です。後述するマネージド制約 (レガシー) に代わり、Policy Intelligenceとの統合により柔軟性と分析機能が追加されています。
ブール型、リスト型両方サポートされています。また、Policy Simulator とドライラン組織ポリシーを使用することにより、本番環境に影響を与える前にどのリソースが影響を受けるかテスト可能になるので、安全に組織ポリシーを導入することができます。

2. カスタム制約

カスタム制約は、組織が独自に定義・管理する制約です。Google Cloudが提供するマネージド制約では対応できない、組織固有の要件やコンプライアンス要件に対応することができます。
組織が定義・管理を行うため、運用管理コストがかかってくることは認識しておく必要があります。

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

レガシー版のマネージド制約はGoogle Cloud側によって定義されている制約で、「事前定義された制約」とも呼ばれる旧形式の制約です。現在は先述の新しいマネージド制約への移行が推奨されています。
ブール型、リスト型両方サポートされています。

デフォルトで有効化されている組織ポリシー

2024年5月3日以降に組織を作成した場合、以下の組織ポリシーがデフォルトで適用されます。
2024年5月3日以前は、これらの組織ポリシーはデフォルトで有効化されていませんでしたので、最近Google Cloudを組織で利用し始めたユーザは使い始めからセキュアにGoogle Cloudを利用することができています。

デフォルトで安全な組織リソースの管理  |  Resource Manager  |  Google Cloud

また、上記以外でもデフォルトで有効化されている組織ポリシーが存在します。
こちらはコンソールからのみしか確認することができないため、注意が必要です。

追加で有効化したい組織ポリシー

デフォルトで有効化されている組織ポリシーでも最低限のセキュリティは確保されていると思いますが、私個人として今までGoogle Cloudを利用してきて、
最初からこの組織ポリシーを適用されていたらよかったなと思う場面がありました。
以下に、デフォルトで有効化されている組織ポリシーに加えて、追加で有効化したい組織ポリシーを記載します。

Cloud SQL インスタンスへのパブリック IP アクセスを制限 constraints/sql.restrictPublicIp

Cloud SQLインスタンスは、デフォルトではパブリックIPを付与することができます。
Cloud SQLはデータベースなので大切な情報が格納されているため、基本的にはプライベートIPによる内部ネットワークから接続することを基本としたいです。
このconstraints/sql.restrictPublicIpの制約を適用すると、Cloud SQLインスタンスにパブリックIPを付与することができなくなるので、プライベートIPからの接続を強制することができます。
外部インターネットからの攻撃を回避するためにも、できるだけCloud SQLにパブリックIPアドレスは付与しないほうが良いと考えています。

デフォルトのネットワーク作成をスキップ constraints/compute.skipDefaultNetworkCreation

新規にプロジェクトを払い出す際に、デフォルトでは、デフォルトVPCも一緒に払い出されてしまいます。
デフォルトVPCはサブネットもファイアウォールも自動的に払い出されるため、素早く検証を行うことができる利点はありますが、オープンな(0.0.0.0/0)ファイアウォールが払い出されてしまうため、外部からの攻撃を受けやすくなる脆弱な環境を作り出してしまいます。
このconstraints/compute.skipDefaultNetworkCreationの制約を適用すると、新規にプロジェクトを払い出す際にデフォルトVPCが払い出されなくなるため、オープンな(0.0.0.0/0)ファイアウォールも払い出されず、セキュアな環境を整えることができます。

公開アクセス防止の実施 constraints/storage.publicAccessPrevention

デフォルトでは、Cloud Storageバケットに対して、AllUsersやallAuthenticatedUsersといったIAMプリンシパルを設定することで、インターネット上の誰でもアクセス可能な公開バケットを作成することができます。
公開バケットは、意図しない情報漏洩のリスクがあり、機密情報や個人情報が含まれるデータが外部に公開されてしまう可能性があります。また、設定ミスにより誤ってデータを公開してしまうケースも少なくありません。
このconstraints/storage.publicAccessPreventionの制約を適用すると、Cloud StorageバケットへのAllUsersやallAuthenticatedUsersの設定が禁止され、公開アクセスを完全に防止できます。これにより、データ漏洩リスクを大幅に低減し、組織のデータを安全に保護することができます。

VMシリアルポートアクセスを無効 constraints/compute.managed.disableSerialPortAccess

デフォルトでは、Compute Engineインスタンスのシリアルポートにアクセスすることができます。シリアルポートを使用すると、SSHなどの通常のネットワーク接続が利用できない場合でもインスタンスにアクセスできます。
シリアルポートアクセスは、ブラウザベースのコンソールからアクセス可能であり、適切なIAM権限を持つユーザーであれば誰でもアクセスできてしまいます。また、シリアルポート経由の通信は暗号化されていないため、機密情報が平文で送信されるリスクがあります。
このconstraints/compute.managed.disableSerialPortAccessの制約を適用すると、シリアルポートアクセスが無効化され、通常のSSH接続など、より安全な接続方法の利用が強制されます。これにより、不正アクセスのリスクを低減し、セキュアなアクセス管理を実現できます。

OS 構成が必要 constraints/compute.managed.requireOsConfig

デフォルトでは、Compute Engineインスタンスに対してOS構成管理(OS Config)の使用は任意です。そのため、パッチ管理やセキュリティアップデートが適切に実施されない可能性があります。
OS構成管理を使用しない場合、各インスタンスで個別にパッチ適用や構成管理を行う必要があり、管理の負担が増加します。また、セキュリティパッチの適用漏れにより、既知の脆弱性を突かれる攻撃のリスクが高まります。
このconstraints/compute.managed.requireOsConfigの制約を適用すると、すべてのCompute EngineインスタンスでOS構成管理の使用が必須化され、組織全体で統一的なパッチ管理とセキュリティアップデートの適用が可能になります。これにより、セキュリティ脆弱性への対応が迅速化され、システム全体のセキュリティレベルを向上させることができます。

VMインスタンスの外部IPを制限 constraints/compute.managed.vmExternalIpAccess

デフォルトでは、Compute Engineインスタンスに対して外部IPアドレス(パブリックIP)を自由に割り当てることができます。
外部IPアドレスを持つインスタンスは、インターネットから直接アクセス可能となり、外部からの攻撃対象となるリスクが高まります。また、意図しない外部公開により、不正アクセスやDDoS攻撃を受ける可能性があります。
このconstraints/compute.managed.vmExternalIpAccessの制約を適用すると、Compute Engineインスタンスへの外部IPアドレスの割り当てを制限でき、内部ネットワーク経由でのアクセスを基本とする構成を強制できます。Cloud NATやLoad Balancerなどを経由した安全なアクセス方法を採用することで、攻撃面を最小化し、セキュアなネットワーク構成を実現できます。

GKE クラスタでセキュリティ情報通知を有効にする constraints/container.managed.enableSecurityBulletinNotifications

デフォルトでは、GKEクラスタでのセキュリティ脆弱性通知の有効化は任意です。そのため、重要なセキュリティ情報を見逃す可能性があります。
セキュリティ通知が有効化されていない場合、Kubernetesやコンテナランタイムに関する重大な脆弱性情報が公開されても、迅速に把握することができず、対応が遅れる可能性があります。結果として、既知の脆弱性を悪用した攻撃を受けるリスクが高まります。
このconstraints/container.managed.enableSecurityBulletinNotificationsの制約を適用すると、すべてのGKEクラスタでセキュリティ脆弱性通知が自動的に有効化され、重要なセキュリティ情報をタイムリーに受け取ることができます。これにより、脆弱性への迅速な対応が可能になり、クラスタのセキュリティを維持することができます。

GKE の Workload Identity Federation を有効にする constraints/container.managed.enableWorkloadIdentityFederation

デフォルトでは、GKEクラスタでのWorkload Identity Federationの使用は任意です。そのため、Podから他のGoogle Cloudサービスにアクセスする際に、サービスアカウントキーを使用する方法が選択される可能性があります。
サービスアカウントキーは永続的な認証情報であり、漏洩した場合に深刻なセキュリティリスクとなります。また、キーのローテーションや管理の負担も大きくなります。Workload Identity Federationを使用しない場合、Kubernetes Secretにサービスアカウントキーを保存する必要があり、キーの漏洩リスクが高まります。
このconstraints/container.managed.enableWorkloadIdentityFederationの制約を適用すると、すべてのGKEクラスタでWorkload Identity Federationの使用が必須化され、サービスアカウントキーなしで安全にGoogle Cloudサービスへアクセスできるようになります。一時的な認証情報を使用することで、キーの漏洩リスクを排除し、セキュアな認証基盤を構築できます。

デフォルトの Compute Engine サービス アカウントをノードプールのサービス アカウントとして使用することを禁止 constraints/container.managed.disallowDefaultComputeServiceAccount

デフォルトでは、GKEノードプールのサービスアカウントとして、デフォルトのCompute Engineサービスアカウントを使用することができます。
デフォルトのCompute Engineサービスアカウントは、プロジェクト内のEditorロールに近い広範な権限を持っており、最小権限の原則に反します。このサービスアカウントがノードで使用されると、ノード上で動作するすべてのワークロードが過剰な権限を持つことになり、セキュリティリスクが高まります。
このconstraints/container.managed.disallowDefaultComputeServiceAccountの制約を適用すると、GKEノードプールでデフォルトのCompute Engineサービスアカウントの使用が禁止され、必要最小限の権限を持つカスタムサービスアカウントの作成と使用が強制されます。これにより、最小権限の原則に基づいたセキュアなGKE環境を構築できます。

GKE クラスターでプライベート ノードを有効にする constraints/container.managed.enablePrivateNodes

デフォルトでは、GKEノードに対してパブリックIPアドレスを割り当てることができ、ノードがインターネットから直接アクセス可能な状態で作成される可能性があります。
パブリックIPアドレスを持つノードは、インターネットから直接到達可能であり、外部からの攻撃対象となるリスクが高まります。また、ノードが侵害された場合、クラスタ全体のセキュリティが脅かされる可能性があります。
このconstraints/container.managed.enablePrivateNodesの制約を適用すると、すべてのGKEクラスタでプライベートノード(内部IPのみを持つノード)の使用が必須化され、ノードへの外部からの直接アクセスが防止されます。インターネットへのアクセスはCloud NATを経由して行われ、攻撃面を最小化したセキュアなGKE環境を実現できます。

デフォルトのサービス アカウントの特権基本ロールを禁止 constraints/iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts

デフォルトでは、App EngineやCompute Engineなどのサービスによって自動作成されるデフォルトサービスアカウントに対して、EditorやOwnerといった特権的な基本ロールを付与することができます。
基本ロール(Editor、Owner)は非常に広範な権限を持ち、最小権限の原則に反します。デフォルトサービスアカウントは多くのリソースで使用される可能性があるため、これらに特権ロールが付与されると、意図しない権限昇格や不正アクセスのリスクが高まります。また、一つのサービスアカウントが侵害された場合の影響範囲が広がります。
このconstraints/iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccountsの制約を適用すると、デフォルトサービスアカウントに対するEditorやOwnerなどの特権基本ロールの付与が禁止され、より細かく制御された事前定義ロールやカスタムロールの使用が強制されます。これにより、最小権限の原則に基づいたセキュアなIAM設定を実現し、権限の過剰付与によるリスクを低減できます。

terraformコードは以下に記載しておきますので、興味がある方はご覧ください。

data "google_organization" "org" {
  domain = var.organization_domain
}

# ブール型制約
## Cloud SQL インスタンスへのパブリック IP アクセスを制限する
resource "google_org_policy_policy" "sql_publicip_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/sql.restrictPublicIp"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## デフォルトのネットワーク作成をスキップ
resource "google_org_policy_policy" "default_network_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/compute.skipDefaultNetworkCreation"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## 公開アクセス防止の実施
resource "google_org_policy_policy" "public_access_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/storage.publicAccessPrevention"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## VMシリアルポートアクセスを無効にする
resource "google_org_policy_policy" "serial_port_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/compute.managed.disableSerialPortAccess"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## OS 構成が必要
resource "google_org_policy_policy" "os_config_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/compute.managed.requireOsConfig"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## VMインスタンスの外部IPを制限する
resource "google_org_policy_policy" "vm_publicip_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/compute.managed.vmExternalIpAccess"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## GKE クラスタでセキュリティ情報通知を有効にする必要があります。
resource "google_org_policy_policy" "gke_security_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/container.managed.enableSecurityBulletinNotifications"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## GKE の Workload Identity Federation を有効にする必要があります。
resource "google_org_policy_policy" "gke_wif_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/container.managed.enableWorkloadIdentityFederation"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## デフォルトの Compute Engine サービス アカウントをノードプールのサービス アカウントとして使用することを禁止します。
resource "google_org_policy_policy" "gke_default_sa_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/container.managed.disallowDefaultComputeServiceAccount"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## GKE クラスターでプライベート ノードを有効にする必要があります。
resource "google_org_policy_policy" "gke_private_node_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/container.managed.enablePrivateNodes"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

## デフォルトのサービス アカウントの特権基本ロールを禁止する
resource "google_org_policy_policy" "sa_basic_role_policy" {
  name   = "organizations/${data.google_organization.org.org_id}/policies/iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts"
  parent = "organizations/${data.google_organization.org.org_id}"

  spec {
    rules {
      enforce = "TRUE"
    }
  }
}

provider "google" {
  project               = var.project_id
  region                = var.region
  user_project_override = true
  billing_project       = var.project_id
}

variable "project_id" {
  description = "Google Cloud プロジェクトID"
  type        = string
}

variable "region" {
  description = "リージョン"
  type        = string
  default     = "asia-northeast1"
}

variable "organization_domain" {
  description = "Google Cloud 組織ドメイン"
  type        = string
}

terraform {
  required_version = ">= 1.12.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 7.0.0"
    }
  }
}

最後に

今回は、組織ポリシーの概要と、デフォルトで有効化されている組織ポリシーに加えて追加で有効化を検討したい組織ポリシーについて記載しました。
組織ポリシーを使用することで、組織にガードレールを引くことができ開発者に安全にGoogle Cloudを利用してもらうことができます。
ある程度Google Cloudの利用が進んでいる組織にポリシーを適用すると、考慮する事項が増えて導入のハードルが上がってきますので、Google Cloudの利用を開始した早い段階で組織ポリシーの適用を検討することをお勧めします。
また、特定のプロジェクトやフォルダに対して、組織ポリシーを無効化することもできますので、開発環境では緩めのポリシーを適用し、本番環境では厳しいポリシーを適用することを検討してもよいと思います。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部コンサルティング部の渡邉でした！