Zenn
🏢

Google Cloud の組織のポリシーのまとめと検証

2022/09/16に公開
Google Cloud
Security
policy
constraints
Organization Policy
tech

こんにちは、クラウドエースのシステム開発部/SREディビジョン所属の菊池と申します。

本記事では以下の記事を参考にして、Google Cloud の組織のポリシーを簡易にまとめてみました。
組織ポリシー サービスの概要

また、組織のポリシーを適用して検証させた記事も少なかったので、実際に組織ポリシーを適用させて検証しました。
検証では同じディビジョンの山﨑に協力していただきました。

まず組織とは

  • Google Cloud では、組織やプロジェクトなどのコンテナ リソースを使用して、他の Google Cloud リソースをグループ化し、階層的にまとめることができます。
    この階層的な組織により、アクセス制御や構成設定など、リソースに共通の側面を管理できます。
    引用 : Resource Manager のドキュメント
  • 組織、フォルダ、プロジェクトはResource Managerによって階層的に整理されます。
    組織が階層のルートノードであり、プロジェクトとフォルダは組織の子ノードです。
    フォルダにプロジェクトや別のフォルダを含めることで、リソースを階層化して整理することができます。
    プロジェクトは基本レベルの構成要素であり、Google Cloudサービスの作成、有効化、APIの管理、課金の有効化を管理します。
    例えば Compute Engine VM や Cloud Storage バケットなどはプロジェクトで管理します。
    各リソースの親は1つだけです。
    親リソースでアクセス管理ポリシーや構成内容を指定することで、子リソースにも適用されます。
  • 次の図は、Google Cloud リソース階層の一例です。
    cloud-hierarchy

組織のポリシーの概要

組織のポリシー サービスを使用すると、Google Cloud 組織に特定の設定を強制したり、リソースのロケーションを限定するといった制約を適用することができます。

利点

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

Identity and Access Management との相違点

  • Identity and Access Management で重要なのは「誰が何を操作できるか」です。
    管理者は、何のリソースに対して誰がどのような操作を許可するか、
    を権限に基づいて認可します。
  • 組織ポリシーで重要なのは「何」で、
    管理者は何のリソースに対してどのような操作・設定を制限するか、
    を組織のポリシーの制約に基づいて決定できます。

仕組み

組織ポリシー

  • 組織のポリシーは、制限の構成です。
    組織のポリシーの管理者は組織のポリシーを定義し、その組織のポリシーを組織、フォルダ、プロジェクトに設定することにより、そのリソースと子リソースに制限を適用します。

  • 組織のポリシーの定義には、制約を選択します。
    その組織のポリシーを組織、フォルダ、プロジェクトに設定することにより、そのリソースと子リソースに制限を適用します。

  • 対象のリソース階層ノードの子孫は、組織ポリシーを継承します。
    組織のポリシーをルート組織ノードに適用すると、組織全体で組織のポリシーの適用と制限の構成を効果的に行うことができます。

  • 引用 : 組織ポリシー

制約

  • 組織のポリシーの個々のルールで有る制約は、Google Cloud サービスまたは Google Cloud サービスのリストに対する特殊な制限です。

  • 制約のタイプは、リストとブールのいずれかです。

  • リスト制約は、指定する許可値または拒否値のリスト（仮想マシンに接続できる IP アドレスの許可リストなど）を使用して制約を評価します。

  • ブール制約は、特定のリソースに対して適用されるかされないかにかかわらず、特定の動作（外部サービス アカウントを作成できるかどうかなど）を決定します。

  • 引用 : 制約

継承

  • 組織のポリシーは、”組織”・”フォルダ”・”プロジェクト”にそれぞれ設定でき、その子孫はデフォルトで組織のポリシーを継承します。
  • 組織ポリシー管理者の役割を持つユーザーは、継承された制限の上書きも出来ます。

違反

  • 違反とは、Google Cloud サービスがリソース階層の範囲内にある組織のポリシー制限の構成に反して動作している状況を指します。
  • すでに発生しているサービスの動作や状態に対して新しい組織のポリシーにより制限が設定された場合、ポリシー違反状態とみなされますが、サービスは元の動作を停止しません。
    この場合は手動で対処する必要があります。

良く使われそうな制約

  • 組織のポリシーの制約は、数多く存在します。
  • 制約の一覧は以下のドキュメントをご参照ください。
    組織のポリシーの制約
  • 良く使われそうな制約は、以下にリストしました。
対象のサービス 制約 形式 説明
複数 Google Cloud Platform - リソース ロケーションの制限 リスト型 ロケーション ベースの GCP リソースを作成できる一連のロケーションを制限します。
リソースを作成できるリージョンを限定することができます。
例えば asia-northeast1とasia-northeast2に限定することで、リソースを必ず日本国内に限定して作成することができます。
複数 リソース サービスの使用を制限する リスト型 組織、フォルダ、プロジェクト内で使用できる一連の Google Cloud リソース サービス（compute.googleapis.com や storage.googleapis.com など）を制限します。
例えば Compute Engine と Cloud Storage しかリソースサービスを使えないように制限できます。
デフォルトでは、すべての Google Cloud リソースサービスが認可されています。
複数 許可される Google Cloud API とサービスを制限する リスト型 リソースで有効にできるサービスと、そのサービスの API を制限します。
例えば Compute Engine API の使用を制限することが可能です。
デフォルトでは、すべてのサービスが認可されています。
Cloud Storage 公開アクセスの防止を適用する ブール型 公開アクセスの防止を適用して、Cloud Storage データが一般に公開されないようにします。
例えば Cloud Storage で意図しないオブジェクトの公開を未然に防ぐことができます。
Identity and Access Management ドメインで制限された共有 リスト型 プリンシパルを IAM ポリシーに追加できる 1 つ以上の Cloud Identity または Google Workspace のお客様 ID を定義します。
この制約が有効な場合、許可された顧客 ID に属するプリンシパルのみを IAM ポリシーに追加できます。
例えば、自社の Google Workspace のお客様 ID のみを使用して組織のポリシーを作成した場合、自社のドメインのプリンシパルだけを IAM ポリシーに追加できます。
Identity and Access Management サービス アカウント キーの作成を無効化 ブール型 サービス アカウントの外部キーの作成が無効になります。
例えば、プリンシパルがユーザー管理のサービス アカウント キーを作成できないようにすることで、セキュリティリスクを低減できます。
Service Consumer Management デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化 ブール型 アカウント作成時にプロジェクトの IAM ロールを自動的に付与しなくします。
例えば、デフォルトの App Engine や Compute Engine サービスアカウントは、アカウント作成時に編集者のロールが自動的に付与されますが、それを防ぐことができます。

組織ポリシーの検証

以下の 2 つの制約をかけて組織ポリシーを適用し、上手くいったか検証してみました。

  1. Google Cloud Platform - リソース ロケーションの制限
  2. Cloud Storage - 公開アクセスの防止を適用する

Google Cloud Platform - リソース ロケーションの制限

検証結果

  1. まずは適当にリソースを作成します。(今回は Compute Engine の disk を作成)
    Google Cloud Console で [ ディスク ] に移動します。
    [ ディスクを作成 ] をクリックします。
    [リージョン ] を “europe-north1”
    [ ゾーン ] を “europe-north1-a”
    を選択し [ 作成 ] をクリックします。
    disk_create.png

  2. disk が作成された事を確認できました。
    created_disk.png

  3. 次に組織のポリシーの設定を行います。
    [ IAM と管理 ] のページから [ 組織のポリシー ] を選択します。
    orgpolicy.png

  4. [ Google Cloud Platform - リソース ロケーションの制限 ] を選択し、[ 編集 ] ボタンをクリックします。
    この制約では、ロケーション ベースの GCP リソースを作成できる一連のロケーションを定義します。
    詳細は組織のポリシーの制約に記載されています。
    [ 対象 ] で、[ カスタマイズ ] を選択します。
    [ ポリシーの適用 ] では親リソースから継承されたルールが有るのであれば置き換えたいので、[ 置き換える ] を選択します。
    [ ADD RULE ]を選択します。
    [ ポリシータイプ ] で、[許可]
    [ ポリシーの値 ] ボックスに “in:asia-locations” を入力し、
    [ 保存 ] をクリックします。
    policy_edit
    policy_edit_2

  5. 組織のポリシーが更新された事を確認できました。
    [ 有効なポリシー ] から [ 許可 ] の一覧をみてると asia のゾーンしかないことが確認できます。
    policy_disc

  6. 最後に組織のポリシーのテストを行います。
    作成されたディスクの [操作] から [ ディスクのクローン作成 ] を選択します。
    disk_clone.png

  7. [ ロケーション ] の下の [ レプリカのゾーン ] で、”europe-north1-b” を選択し、
    [ 作成 ] をクリックします。
    disk_cloning.png

  8. “constraints/gcp.resourceLocations” の制約に違反した
    という旨のエラーが表示され、ディスクのクローンは作成されませんでした。
    正しく組織のポリシーが適用されていることが確認できました。
    after_policy_err

  9. また、組織のポリシーを適用させた後に、再度 [ ディスクを作成 ] を選択しました。
    [ リージョン ] の選択では、あらかじめ asia のリージョンしか選択できないようになっていることが確認できました。
    after_disk_create.png

Cloud Storage 公開アクセスの防止を適用する

Google Cloud Storage(以下、GCS)に以下の組織ポリシーをかけて、
保存してあるデータを一般に公開されないようにしてみました。
この制約でallUsersやallAuthenticatedUsersのアクセス権をブロックします。

公開アクセスの防止を適用する

検証手順

  1. GCSでバケットを作成します(gcloudコマンドでも作成できますが、今回はコンソールでの作業に統一します)

    • Google Cloud Consoleで【Cloud Storage】→【バケット】に移動し、【バケットを作成】を押下します

    • 【バケット名】を一意の名前で作成し、【続行】を押下します

    • ロケーションタイプは【Region】を選択し、【asia-northeast1】を選択します

      • 検証なので一番費用のかからない【Region】を選択しました
      • 使用用途によって変更してください

    • バケットは検証後、削除する予定なのでストレージクラスは【Standard】を選択します

    • 後の設定はデフォルトで【作成】します

    • 作成したバケットに【ファイルをアップロード】で適当なファイルをアップロードし、以下のようになります。
      cerate_bucket.png

    • 実は既に公開アクセスが非公開になっています。一見、公開アクセスを防止をしているように見えますが、権限を追加できるユーザーが閲覧権をallUsers等に付与すると簡単に公開できます。試しに公開してみます。

  2. 公開アクセスを【公開】にする
    • 【権限】をクリックして【追加】を押下します
    • 新しいプリンシパルに【allUsers】と【allAuthenticatedUsers】を選択し、ロールに【Storage オブジェクト閲覧者】を追加します
      add_roles_alluser
    • 【オブジェクト】を選択して先ほどの画面に戻ると、公開アクセスが【インターネットに公開】になっています
      public_status
    • URLをコピーしてシークレットウインドウなどで開くと画像が開けます
      cat.png
  3. 組織ポリシーをかけて公開アクセス禁止にしてallUsersとallAuthenticatedUsersのアクセス権をブロックします
    • 現在使用しているアカウントに【storage.objects.setIamPolicy】と【storage.objects.getIamPolicy】の権限を付与します
    • 【権限】を選択し、公開アクセスの欄で【公開アクセスの防止】を選択します
      org_policy
    • 【設定】を確認すると権限の公開アクセスの欄が更新されており、組織ポリシーが適用されており非公開になっています
      confirm_public_status
  4. 組織ポリシーがきちんと適用されているか確認

    • 組織ポリシーが適用されている間は【allUsers】や【allAuthenticatedUsers】に新たなプリンシパルを追加できなくなります
      block_alluser_permission

    • 組織ポリシーが適用されている間は新たに作成したバケットにもデフォルトで適用されます
      confirm_obj_policy

まとめ

  • 本記事では、まず組織の説明をし、組織のポリシーの概要や仕組み・よく使われそうな制約、最後に検証をしてみました。
  • 私が感じたことは、組織のポリシーの制約が多いなと思ったこと、思ったよりも簡単に組織のポリシーを適用できたことです。
  • 組織のポリシーの制約は多いので、もしこの記事を見られた方は、記事内の"良く使われそうな制約"を参考にしてみてください。
  • また組織のポリシーの適用も簡単ですので、事故を未然に防ぐためにも、是非組織のポリシーを適用することをオススメします。
    組織のポリシーを適用することで、開発者はより開発に集中できると思いますし、コンプライアンス違反を心配せずに迅速に行動できるようになるとも思います。

Discussion