Google Cloudの組織のポリシーを活用しよう: よりセキュアなクラウド運用への道

2023.09.25 XIMIX 多田

はじめに

Google Cloudを利用していく上で、必ずセキュリティは意識する必要があります。
不必要な外部IPを設定させたくない、日本国外のリージョンを利用させたくないといった観点は、運用上またはセキュリティ上でてくると思われます。

Google Cloudでは組織のポリシーを利用することで、上記対応を実現できます。
今回は組織のポリシーのユースケースや実際の利用方法を踏まえて紹介していきます。

また組織のポリシーは弊社の過去ブログでも紹介していますので、ぜひご確認ください！

組織のポリシーとは

組織のポリシーの概要は公式ドキュメントでも記載されています。

内容を要約すると、次の通りとなります。

Google Cloud内で特定の制約を設定するためのセキュリティ設定
組織、フォルダ、プロジェクトのリソースに適用可能
設定時に範囲のルール定義が可能。タグを付与することにより細かい粒度での制限も可能

組織のポリシーは 組織レベルで設定可能な特定ルールに基づいたセキュリティ設定 となります。
組織に設定した場合、フォルダ及びプロジェクトにも同じ設定を反映させることもできます。

組織のポリシーのメリット・デメリット

では組織のポリシーのメリット・デメリットを考えてみましょう。

設定するメリット
- セキュリティの向上
  - Google Cloudが定義するセキュリティ設定により、簡単にセキュリティレベルの向上を期待できます
  - 例えば、VMインスタンスに対して外部IPアドレスを付与したくない環境に対して組織のポリシー設定を行うことで簡単に実現ができます
- 一貫性のある運用が可能
  - 組織のポリシーは組織全体、特定フォルダ配下、特定プロジェクトのみといった設定が可能です
  - 組織全体のルールとしてサービスアカウントキーを作成させない、特定フォルダ配下にCloud Intercoonnectリソースを作成するため、Cloud Intercoonnectに対するルールを設定するといったように一貫性のある設定や運用が可能となります
設定するデメリット
- 管理対象の増加
  - 組織のポリシーを新たに追加する場合、既存で運用していたリソースに加えて組織のポリシーの運用も必要となります
  - 設定変更対応や設定追加等、運用上の学習コストも増える可能性があります
- 意図しない設定をされる可能性の増加
  - 組織のポリシーは柔軟な設定が可能ですが、意図しない設定による弊害も考えられます
  - 本来設定する必要のないプロジェクトに適用してしまい、特定サービスが利用できなくなることも考えられます

組織のポリシーを設定するユースケース

組織のポリシーのユースケースは以下の通りとなります。
こちらはあくまでも一例となりますので、他にも利用可能なユースケースはございます。

セキュリティポリシーを組織全体で定めて強化したい
- 組織配下のフォルダ、PJに対して同一設定を実施することにより、均一的なセキュリティ設定による管理が可能となる。また均一的なルール定義により、セキュリティインシデントのリスク低減にも繋がります
IAMや他サービスのみで実施できない対応を設定したい
- IAMや拒否ポリシー、Firewall設定のみではカバーできない範囲のセキュリティ設定が可能となります
Google Cloud上で実施したい要件に即した設定を定義したい
- 外部通信を禁止し内部通信のみ実施する、特定リソースの作成を組織全体で制限したい、IAMに追加可能なワークスペースやドメインを定義したいといった対応に利用可能となります

組織のポリシーの種類

組織のポリシーには、フラグ型設定とリスト型設定の2つがあります。

フラグ型設定は名前の通り、設定時にTrue/Falseを定義する、つまりポリシーを適用するか適用しないかのみ定義する設定です。
フラグ型設定を利用した場合、組織全体、フォルダ配下全体に設定適用が実施されます。

リスト型設定は、カスタム定義を用いることで、xxxのみを許可/拒否するといった複雑な設定を実施することができます。
例えば、Cloud SchedulerのキックをPub/Subのみ受け付けるといった形で定義します。

ポリシー自体がリスト型定義かフラグ型定義かは、公式ドキュメントに記載されていますので詳細はこちらをご確認ください。

組織のポリシーの設定方法

組織のポリシーの設定を実施する際、組織に対して組織ポリシー管理者の権限付与が必要となります。
またCLIベースでの組織のポリシー適用を実施する際、プロジェクトに対してOrganization Policy APIの設定有効化が必要となります。GUIベースで作業される場合は設定する必要がございません。

今回はコマンドベース及び定義ファイルベースでの設定方法の共有となりますので、本記事を参考に実施する場合は定義設定をお願いいたします。

フラグ型の設定（コマンドベース）

コマンドベースの場合は下記コマンドにて設定を実施します。下記コマンドは、組織全体に対して組織のポリシーを有効化するコマンドとなります。

gcloud resource-manager org-policies enable-enforce [組織のポリシーID] --organization=[組織ID]

組織IDの部分は、 --folder=[フォルダID] や --project=[プロジェクトID]に変更することで、フォルダやプロジェクトに設定可能となります。
組織のポリシーIDは、constraints/配下に定義されているIDとなります。下記画像であれば、iam.allowServiceAccountCredentialLifetimeExtensionが組織IDとして定義されます

organization-policy_1

では実際に設定してみましょう。
今回は例として、サービスアカウントキー作成を無効化する、サービスアカウントキーの作成を無効化(constraints/iam.disableServiceAccountKeyCreation)ルールを有効化してみます。

## オプション部分は適宜修正してください
$ gcloud resource-manager org-policies enable-enforce iam.disableServiceAccountKeyCreation --project=[プロジェクトID]
booleanPolicy:
  enforced: true
constraint: constraints/iam.disableServiceAccountKeyCreation
etag: CNPEr6gGEODO4YID
updateTime: '2023-09-21T06:27:31.811100Z'

こちらで反映が完了しました。実際の画面を見てみましょう。
プロジェクトを選択し、[IAMと管理] → [組織のポリシー] を選択。検索欄にて「Disable service account key creation」を入力して詳細ルールを確認します。

下記画像のように、ステータス適用済みと出力されていれば成功です

organization-policy_2

リスト型の設定（定義ファイルベース）

次はリスト型のポリシー設定です。
リスト型のポリシーはGUI上でも設定できますが、定義ファイルを指定することで設定も可能となります。

今回は、ロケーションベースで作成できるGoogle Cloudリソースの制限を行う「リソースロケーションの制限（gcp.resourceLocations）」を定義してみます。

定義ファイルは下記の通りとなります。ブール型と同じく、プロジェクトに対して適用を実施します。
今回はasia-northeast1とasia-northeast2のロケーションを許可する設定を実施し、定義ファイルはyamlベースで作成します。

name: projects/[プロジェクトID]/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
        - in:asia-northeast1-locations
        - in:asia-northeast2-locations

こちらの定義ファイルを利用して、ポリシー反映を実施します。コマンド含めた実行結果は下記のとおりとなります。

$ gcloud org-policies set-policy resourceLocationsPolicy.yaml
Created policy [projects/[プロジェクトID]/policies/gcp.resourceLocations].
name: projects/[プロジェクトNo]/policies/gcp.resourceLocations
spec:
  etag: CKqo4acGEMDn39kd27
  rules:
  - values:
      allowedValues:
      - in:asia-northeast1-locations
      - in:asia-northeast2-locations
  updateTime: '2023-09-06T10:27:54.709080Z'

こちらも画面上から確認してみましょう。

下記画像のとおりになっているはずです。これで、作成可能なリソースがasia-northeast1とasia-northeast2の日本国内リージョンのみとなりました。

organization-policy_3