developersIO
【組織ポリシー】ドメイン別の ID の制限：iam.allowedPolicyMemberDomainsとiam.managed.allowedPolicyMembersの違い

【組織ポリシー】ドメイン別の ID の制限：iam.allowedPolicyMemberDomainsとiam.managed.allowedPolicyMembersの違い

Google Cloud (GCP)組織ポリシー
FacebookHatena blogX
2025.12.03

はじめに

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

皆さんは、Google Cloudを利用していてプロジェクトのIAMに@gmail.comのアカウントや、組織のドメインと無関係なドメインのアカウントが勝手に登録されていて困ったことはないでしょうか？
私はあります。

Google Cloud組織をセキュアに運営していくうえで、誰が、何を、どこでを追跡できることは非常に重要です。
その際に、用途不明かつ謎の@gmail.comアカウントや管理外の外部ドメインのアカウントが存在する場合は誰がの部分がわかりづらくなります。

また、CCoEや情報システム部の方は、IAMの棚卸を実施する際に、上記のようなアカウントを管理しているユーザを特定するために関係者にヒヤリングしなければいけないので、かなり大変かと思います。

もし、IAMに登録することができるアカウントを自身の組織のドメインに制限することができれば、用途不明な@gmail.comアカウントや、管理外の外部ドメインのアカウントのIAMへの登録を禁止させることができ、信頼された組織内のユーザのみにGoogle Cloud環境を利用させることができます。

今回はドメイン別の ID の制限と呼ばれるIAMに登録することができるアカウントを自身の組織のドメインや許可されたドメインに制限することができる組織ポリシーを紹介したいと思います。

組織ポリシーとは

組織ポリシーとは、Google Cloudを利用する上で、組織で管理されているすべてのプロジェクトに対してルール:制約を設定し、強制的に順守させることができるサービスになります。

以前、これからGoogle Cloudの利用を開始するときに追加で有効化を検討しておきたい組織ポリシーとしてブログを執筆しましたので、組織ポリシーの概要や仕組みについては以下を参照いただけると幸いです。

https://dev.classmethod.jp/articles/gcp-organization-policies-for-beginners/

ドメイン別のIDの制限とは

ドメイン別の ID の制限とは、IAMに登録することができるプリンシパルを自身の組織のドメイン、許可されたドメインに属しているプリンシパルのみに制限することができる組織ポリシーです。

ドメイン別のIDの制限で使用できる組織のポリシーの種類は以下の3種類があります。

  • iam.managed.allowedPolicyMembers：マネージド制約
  • iam.googleapis.com/AllowPolicy：リソースを参照するカスタムの組織のポリシー
  • iam.allowedPolicyMemberDomains：以前のマネージド制約

今回は、設定する可能性の高いマネージド制約である【iam.managed.allowedPolicyMembers】と以前のマネージド制約である【iam.allowedPolicyMemberDomains】について検証を行っていきます。

事前準備

必要なロール

組織ポリシーを設定するためには、組織ポリシー管理者のロールが必要になりますので付与してください。

  • 組織ポリシー管理者：roles/orgpolicy.policyAdmin

組織IDと顧客IDの確認

ドメイン別のIDの制限の組織ポリシーを設定するためには、組織IDや顧客IDの情報が必要になります。
組織IDはGoogle Cloudの組織を一意に特定する情報で、顧客IDはGoogle Workspace（Cloud Identity）の組織を一意に特定する情報になります。

組織IDと顧客IDの情報はgcloud organizations listコマンドを利用することで取得することができます。
IDに当たる部分が組織IDの情報で、DIRECTORY_CUSTOMER_IDに当たる部分が顧客IDの情報になります。

$ gcloud organizations list
DISPLAY_NAME: example.com
ID: 123456789012
DIRECTORY_CUSTOMER_ID: XXXXXXX

iam.allowedPolicyMemberDomains

まずは、iam.allowedPolicyMemberDomainsによるドメイン別のIDの制限について、検証を行っていきます。
iam.allowedPolicyMemberDomainsは、リストパラメータによる以前のマネージド制約の組織ポリシーです。許可する組織プリンシパルセットや顧客IDを指定することで、プリンシパルが指定された組織プリンシパル セットに属しているか、指定されたドメインのみがIAMに登録することができるようになります。

https://docs.cloud.google.com/resource-manager/docs/secure-by-default-organizations?hl=ja

  1. Google Cloudコンソールから【IAMと管理】→【組織のポリシー】 をクリックします。

alt text

  1. 【組織のポリシー】の管理画面の検索欄に【iam.allowedPolicyMemberDomains】を入力し、【Domain restricted sharing】をクリックします。この時は適用状態が【非アクティブ】になっています。

alt text

  1. 【ポリシーを管理】をクリックします。

alt text

  1. 【ポリシーの編集】画面では、以下を選択し【ポリシーを設定】をクリックします。
  • ポリシーのソース：親のポリシーをオーバライドする
  • ポリシーの適用：親と結合する
  • ルール
    • ポリシーの値：カスタム
    • ポリシータイプ：許可
    • カスタム値：顧客ID

alt text

  1. これで設定が完了したので適用状態が【アクティブ】になっています。

alt text

  1. iam.allowedPolicyMemberDomainsの設定が完了したので、実際にIAMに@gmailアカウントを追加するオペレーションをやってみたいと思います。今回は【Cloud Run管理者】のロールを付与してみます。

alt text

  1. すると、IAMポリシーの更新に失敗しましたとポップアップ画面が表示され、IAMの登録に失敗したことが確認できました。
    alt text

これで組織ドメイン外のIAM登録を禁止することができました。
今回は、顧客IDを設定して検証しましたが、組織プリンシパルセットを付与しても同様の結果が得られます。

iam.managed.allowedPolicyMembers

次に、iam.managed.allowedPolicyMembersによるドメイン別のIDの制限について、検証を行っていきます。
iam.managed.allowedPolicyMembersは、マネージド制約の組織ポリシーです。iam.allowedPolicyMemberDomainsと比較すると、新しい制約になっており、Policy Intelligenceとの統合により柔軟性と分析機能が追加されています。
Policy Simulator とドライラン組織ポリシーを使用することにより、本番環境に影響を与える前にどのリソースが影響を受けるかテスト可能になるので、安全に組織ポリシーを導入することができます。
iam.managed.allowedPolicyMembersには、許可するプリンシパルセットやメンバーを指定することで、プリンシパルが指定された組織プリンシパルセットに属しているか、指定されたメンバーのみがIAMに登録することができるようになります。顧客IDを指定することはできなくなっています。

  1. Google Cloudコンソールから【IAMと管理】→【組織のポリシー】 をクリックします。

alt text

  1. 【組織のポリシー】の管理画面の検索欄に【iam.managed.allowedPolicyMembers】を入力し、【Restrict allowed policy members in IAM allow policies】をクリックします。この時は適用状態が【非アクティブ】になっています。

alt text

  1. 【ポリシーを管理】をクリックします。

alt text

  1. 【ポリシーの編集】画面では、以下を選択し【ポリシーを設定】をクリックします。

alt text

せっかくなので、ドライランポリシーを設定して組織のポリシーの変更が適用される前にその効果を確認してみたいと思います。
【ドライランポリシーを設定】をクリックします。
alt text

【ドライラン】のタブにドライランポリシーとして設定がされていることが確認できました。

alt text

  1. iam.managed.allowedPolicyMembersのドライランポリシー設定が完了したので、実際にIAMに@gmailアカウントを追加するオペレーションをやってみたいと思います。今回も先ほどと同様に【Cloud Run管理者】のロールを付与してみます。

alt text

まだ、ドライランポリシーの状態なのでIAMの登録はできてしまいます。

alt text

  1. ドライランポリシーを設定した場合、ドライランのログを確認することができます。これによりドライランポリシーに違反した場合は、POLICY_VIOLATEDとしてログが記録されます。

alt text

ログの内容はこちらに記載します。
誰にどのロールが付与されたのか、どの組織ポリシーに違反したのか確認することができますね。
ドライランポリシーを設定しておくことで、クリティカルな影響がないか、正しく動作しているのか確認してから設定することができるため、とても良い機能だと思います。

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {
      "code": 7,
      "message": "POLICY_VIOLATED"
    },
    "metadata": {
      "resourcePayload": "{\"bindings\":[{\"role\":\"roles/run.admin\",\"members\":[\"user:***@***\"]}]}",
      "dryRunResult": "DENIED",
      "@type": "type.googleapis.com/google.cloud.audit.OrgPolicyDryRunAuditMetadata",
      "resourceType": "iam.googleapis.com/AllowPolicy",
      "liveResult": "ALLOWED",
      "constraint": "constraints/iam.managed.allowedPolicyMembers"
    }
  },
  "insertId": "1bs1o1rcjn1",
  "resource": {
    "type": "audited_resource",
    "labels": {
      "project_id": "***-***-***-***",
      "service": "",
      "method": ""
    }
  },
  "timestamp": "2025-12-03T01:16:30.338770483Z",
  "severity": "WARNING",
  "logName": "projects/***-***-***-***/logs/cloudaudit.googleapis.com%2Fpolicy",
  "receiveTimestamp": "2025-12-03T01:16:31.053484304Z"
}
  1. ドライランで挙動が確認することができたので、ポリシーを設定していこうと思います。【ポリシーを設定】をクリックします。

alt text

プロジェクトのポリシーを設定しますか？と聞かれるので、【確認】をクリックします。

alt text

【実施中】のタブにポリシーとして設定がされていることが確認できました。

alt text

  1. これで設定が完了したので適用状態が【アクティブ】になっています。

alt text

  1. 先ほど同様に、IAMに@gmailアカウントを追加するオペレーションをやってみたところ、IAMポリシーの更新に失敗しましたとポップアップが表示され、IAMの登録に失敗したことが確認できました。
    iam.allowedPolicyMemberDomainsで拒否されたポップアップと異なるポップアップが表示されましたね。

alt text

これで組織ドメイン外のIAM登録を禁止することができました。

注意点

ドメイン別の ID の制限を適用するにあたり、いくつか気を付けておくべき点があります。
一部のGoogle Cloudサービスでは、サービスアカウント、サービスエージェント、その他のアカウントを使用して、ユーザーの代わりにアクションを実行します。その際に、使用するサービスアカウント・サービスエージェントにIAMロールが自動付与されなくなり、特定の機能が失敗する可能性があります。

公式ドキュメントに記載されている影響を受ける可能性のあるオペレーションを記載します。

アクション プリンシパル ID
請求先アカウントの BigQuery ログシンクを有効にする serviceAccount:bUNIQUE_ID@gcp-sa-logging.iam.gserviceaccount.com
ストレージ アクセス ロギングを有効にする serviceAccount:cloud-storage-analytics@google.com
Google Chat アプリのエンドポイントとして Pub/Sub を使用する serviceAccount:chat-api-push@system.gserviceaccount.com
Pub/Sub を使用して Google Play からリアルタイム デベロッパー通知を受信する serviceAccount:google-play-developer-notifications@system.gserviceaccount.com
Cloud CDN で署名付き URL を使用する serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com
Cloud CDN でのプライベート オリジンの認証 serviceAccount:service-PROJECT_NUMBER@https-lb.iam.gserviceaccount.com

iam.managed.allowedPolicyMembersマネージド制約を使用している場合は、上記のプリンシパルIDを許可されたメンバーのリストに追加することで回避することができます。
iam.allowedPolicyMemberDomainsを使用している場合は、一時的に組織ポリシーを無効化して設定をするか、タグによる例外設定を行うことで回避することができます。

また、Cloud Runサービスを外部公開している場合、組織外のユーザーがCloud Runサービスにアクセスできなくなります。
こちらの回避策としては、Cloud Runサービスの設定にある【起動元の IAM チェック】を無効化するか、タグによる例外設定を行うことで回避することができます。

詳細は以下の公式ドキュメントを確認してください。

https://docs.cloud.google.com/resource-manager/docs/organization-policy/restricting-domains?hl=ja#configure-exceptions

さいごに

今回はドメイン別の ID の制限と呼ばれるIAMに登録することができるアカウントを自身の組織のドメインに制限することができる組織ポリシーを紹介しました。

iam.managed.allowedPolicyMembersとiam.allowedPolicyMemberDomainsの二つの組織ポリシーについて検証を行いましたが、個人的にはiam.managed.allowedPolicyMembersの利用を推奨したいです。

理由としては、以下の二つあります。

  • ドライランポリシーを設定することができるので、ポリシー適用前に動作確認や影響確認を行うことができる
  • iam.allowedPolicyMemberDomainsと比較して、特定のプリンシパルの例外設定を柔軟に行うことができる

iam.allowedPolicyMemberDomainsは、新しく作成した組織ではデフォルトで有効化されていますが、iam.managed.allowedPolicyMembersのほうが柔軟性があるので移行することを検討してもよいかもしれません。

ドメイン別のIDの制限の仕組みを理解するにあたっては、以下の公式ドキュメントも一読する価値ありです。
https://docs.cloud.google.com/resource-manager/docs/organization-policy/domain-restricted-sharing?hl=ja#how-drs-works

また、今回はコンソールから設定を行いましたが、TerraformなどのIaCで設定を行ったほうが変更履歴やなぜ変更を行ったのかトレースすることができますので、組織ポリシーはIaCで管理することをお勧めします。

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

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

この記事をシェアする

FacebookHatena blogX

関連記事

ADK × Cloud Run で、気軽にAIエージェントを開発＆デプロイする
すらぼ
2025.12.03
Agent Development Kit（ADK）へ入門してローカル環境で動作を確認する
渡邉 光
2025.12.02
Claude CodeにGoogleカレンダーから参加ステータスの予定を取得するツールを作ってもらう
渡邉 光
2025.12.01
Microsoft 365 導入企業必見！NotebookLM Enterprise なら Entra ID 認証で NotebookLM を利用できる！
村田一紘
2025.12.01