知らないかもしれない組織ポリシーのあれこれ

2026/04/24に公開されました。
2026/04/24に更新されました。

Google Cloud組織ポリシーの罠とベストプラクティス


author: yamasaki-h

本記事はGI Cloud の Google Cloud LT 会 Vol.6で発表した内容をブログ用に書き起こしたものです。


Google Cloud歴5年くらいのyamasakiです。 メインとしてはインフラとかセキュリティの案件を担当しています。

好きな組織ポリシーは iam.allowedPolicyMemberDomains です。一番使っているかなっていうポリシーです。

組織ポリシーの役割

まず組織ポリシーの役割についてです。

  • 階層による一元管理: 組織やフォルダ単位で設定することで、その下位にある全プロジェクトにルールを継承させることができます。逆にプロジェクトから権限を上書き可能です。オーナー権限を持っていても組織ポリシーの上書きはできません。
  • IAMを超える拒否権: たとえユーザーが強力な権限(Ownerなど)を持っていたとしても、組織ポリシーによってその設定操作自体を強制的に禁止可能です。
  • ガードレールの自動化: レビュー漏れやヒューマンエラーによる事故を、システム的に未然に防止できます。

既存リソースへの影響

組織ポリシーを導入する際、「既存の稼働中リソースに影響が出ないか?」と心配になる方も多いでしょう。

結論から言うと、基本的に既存のリソースへの影響はありません。なぜなら、組織ポリシーが評価されるタイミングは以下の2つに限られるからです。

  • リソースの新規作成時
  • リソースの設定更新時

なので、デフォルトの環境に影響があるポリシーはプロジェクトの作成前に組織ポリシーを効かせてあげないといけません。

組織ポリシーのデフォルト有効化

2024年頃からGoogle Cloudの 新規組織に対して重要なセキュリティポリシーが最初から「有効」になる(デフォルト有効化) ようになりました。なので新規組織による案件をやっていなかったりすると、こういうのがあるんだという落し穴があったりします。

デフォルト有効となっている組織ポリシーの例

現在、デフォルトで有効化されている代表的なポリシーには以下のようなものがあります 。

  • SAキー作成禁止 (iam.disableServiceAccountKeyCreation): サービスアカウントの静的な鍵の発行を禁止し、認証情報が漏洩するリスクを最小化します
  • ドメイン制限 (iam.allowedPolicyMemberDomains): 自社ドメイン以外のアカウントに対する権限付与をブロックします
  • Storage公開禁止 (storage.publicAccessPrevention): Cloud Storageの「全公開」設定を無効化し、意図しないデータ流出を防御します

Domain Restricted Sharing

これは指定した組織ドメインのアカウントにしかIAM権限を付与できなくする権限です。デフォルトでは自組織のアカウントにみに付与できる状態になっています。 個人のGmailアカウントを拒否し、外部への誤設定をシステム的に防止します。

案件などで、他ドメインのプロジェクトに対してオーナー権限を依頼したりすると、この権限で引っかかることがよくあります。 数名だけ入れたい場合などでは、一旦組織ポリシーを解除して、IAM付与して、再度設定するという方法などがあります。

しかし、継続的に数名入ってくる場合はドメインの設定を行なう必要があります。

ドメインの設定方法

ここで設定する値はドメイン名ではなく、Google Workspaceにおける顧客IDを設定する必要があります。

  • ❌ 間違い: example.com のような「ドメイン名」を設定してしまう
  • ⭕️ 正解: C0123abcd のような「Google Workspaceの顧客ID」を設定する

顧客IDの確認場所は、Google Workspace管理コンソールの「アカウント設定 > アカウント プロフィール」から確認可能です。

gcloud コマンドでの顧客ID確認方法

しかし、「自分はGoogle Cloudの権限は持っているけど、Google Workspaceの管理コンソールは見られない…」という方も多いはずです。そんな時は、gcloud コマンドで確認可能です。

$ gcloud organizations describe [organization_id]

このコマンドを実行すると、以下のような結果が返ってきます。

creationTime: "creation_time"
displayName: example.com
lifecycleState: ACTIVE
name: organizations/[organization_id]
owner:
  directoryCustomerId: C0xxxxxxx

この一番最後にあるC0から始まる directoryCustomerId の値こそが、組織ポリシーに設定すべきIDとなります。

勿論これも組織に対する権限が必要ですが、Google Workspaceに対する権限よりは持ってる場合が多いです。

Restrict Resource Service Usage

最後にデフォルトで有効化されているわけではないですが、注意が必要な組織ポリシーである「gcp.restrictServiceUsage」です。 ほとんど使わないですが、「使用するAPIを制限する」組織ポリシーで、ホワイトリスト形式、ブラックリスト形式で利用を制限できます。

セキュリティ要件が厳しい場合に、「このAPI使いたくない」というケースでこのポリシーを使用します。

このポリシーは、有効にした瞬間、許可リストにない API 呼び出しは、既存のリソースであってもすべて拒否されます 正確にはリソース自体は削除されないので、GCEなどを予め立てていた場合に、ポリシーを設定してもインスタンスは残ります。しかし、APIは禁止しているのでインスタンスの停止はできない、という状態になります。

Google Cloudの場合は、デフォルトで有効になっているAPI以外は明示的に有効化する必要がありますが、明示的に有効化したものでも、後から組織ポリシーを設定したら拒否される点で注意が必要です。

※本記事は、ジーアイクラウド株式会社の見解を述べたものであり、必要な調査・検討は行っているものの必ずしもその正確性や真実性を保証するものではありません。

※リンクを利用する際には、必ず出典がGIC dryaki-blogであることを明記してください。
リンクの利用によりトラブルが発生した場合、リンクを設置した方ご自身の責任で対応してください。
ジーアイクラウド株式会社はユーザーによるリンクの利用につき、如何なる責任を負うものではありません。