このドキュメントでは、Google グループを使用して Identity and Access Management（IAM）で Google Cloud リソースへのアクセスを管理するためのベスト プラクティスについて説明します。
グループの種類
ここで説明するグループの種類は、Google グループの考え方、使用方法、管理方法の 1 つです。これらのグループタイプは、Google グループ属性によって設定されません。ただし、Google グループ管理の全体的なアプローチでこれらのグループタイプを使用すると、一般的なセキュリティ上の落とし穴を回避できます。
このドキュメントでは、次のタイプのグループを使用します。
組織グループ
組織グループは組織の構造のサブセットを表し、通常は人事データから取得されます。部門、レポート構造、地域、その他の組織グループに基づく場合があります。
組織グループのメンバーは、従業員が組織に加入したとき、別の部門に異動したとき、または組織を退職したときに変更されます。
組織グループの全体的な構造は、ビジネスの再編成によって変更される可能性があります。組織変更により、新しいグループが作成されたり、既存のグループが廃止されたりすることがあります。
組織グループの例としては、
org.marketing-fte、org.finance-all、org.msmith-reports、org.apac-all、org.summer-internsなどがあります。組織グループは通常、メールでのコミュニケーションに使用されます。
コラボレーション グループ
コラボレーション グループは、プロジェクトでコラボレーションしたり、特定のトピックについて話し合ったりしたいワークグループ、プロジェクト メンバー、ユーザーを表します。
コラボレーション グループの構造は、組織構造にリンクされていません。多くの場合、アドホックなセルフサービスで作成されます。
コラボレーション グループのメンバーシップは制限なしに設定でき、組織内のすべてのユーザーが参加できます。また、コラボレーション グループをセルフマネージドにすることもできます。つまり、特定のメンバーがグループに含める他のユーザーを決定できます。
コラボレーション グループの例としては、
collab.security-discussやcollab.website-relaunchなどがあります。コラボレーション グループは通常、メールでのコミュニケーションに使用されます。
アクセス グループ
アクセス グループは、アクセスを提供することを唯一の目的として使用されます。ジョブ機能は、ジョブ機能を表し、これらのジョブ機能を実行するために必要なロールの割り当てを簡素化するために使用されます。個々のプリンシパルにロールを付与するのではなく、グループにロールを付与し、グループ メンバーシップを管理します。
アクセス グループの構造は、組織内のリソースまたはワークロードの構造の影響を受けます。新しいリソースまたはワークロードをデプロイする場合は、新しいアクセス グループの作成が必要になることがあります。
アクセス グループのメンバーシップは通常、1 つ以上のグループ オーナーによって管理されます。グループ オーナーは、ユーザーをグループに招待するか、ユーザーのグループへの参加リクエストを承認します。
アクセス グループの例としては、
access.prod-firewall-admins、access.finance-datamart-viewers、access.billing-dashboard-usersなどがあります。アクセス グループは、アクセス権を付与するためにのみ使用されます。通信目的では使用されません。
適用グループ
適用グループはアクセス グループに似ていますが、アクセス権を付与するのではなく、アクセス制限ポリシーを適用するために使用される点が異なります。
通常、違反措置グループの構造は、コンプライアンス要件と組織構造の組み合わせによって影響を受けます。
違反措置グループのメンバーシップは通常、ユーザーのクリアランス レベル、勤務地、組織内の役割を確認する一連の事前定義されたルールによって決定されます。
適用グループの例としては、
enforcement.users-in-restricted-locations、enforcement.fedramp-low、enforcement.sso-usersなどがあります。適用グループは、アクセス制限ポリシーを適用する場合にのみ使用されます。通信目的では使用されません。
グループにタイプを反映した名前を付ける
このドキュメントの残りの部分でベスト プラクティスに従うには、名前からグループのタイプを判断できるグループ名を使用します。命名規則またはセカンダリ ドメインを使用できます。
命名規則
グループタイプを可視化するための命名規則の例を次に示します。
組織グループ:
org.GROUP_NAME@example.com。例:org.finance-all@example.comコラボレーション グループ:
collab.TEAM_NAME@example.com。例:collab.msmiths-team@example.comアクセス グループ:
access.JOB_FUNCTION@example.com。（例:access.billing-dashboard-users@example.com）です。適用グループ:
enforcement.GROUP_DESCRIPTION@example.com。例:enforcement.sso-users@example.com
組織に適しており、グループ管理ソフトウェアでサポートされている規則を採用します。接頭辞を使用すると、グループは機能ごとにアルファベット順に並べられますが、ビジネス向け Google グループなどの一部のグループ管理システムでは接尾辞のみがサポートされています。接頭辞を使用できない場合は、接尾辞またはセカンダリ ドメインを使用できます。
セカンダリ ドメイン
命名規則の代わりに、セカンダリ ドメインを使用してグループタイプを名前に埋め込むこともできます（例: access.example.com）。確認済みドメインのサブドメインであるセカンダリ ドメインは、確認する必要はなく、DNS に存在する必要もありません。さらに、セカンダリ ドメインの DNS Mail Exchange（MX）レコードを作成しないことで、通信を目的としていないグループに受信メールが届かないようにできます。
ネストルール
グループの種類によって、ネスト（グループをメンバーとして受け入れる）が許可されるかどうかのルールが異なります。
組織グループのネストルール
組織図を反映するように組織グループをネストすることをおすすめします。このアプローチでは、すべての社員が 1 つのグループに含まれ、グループが互いに含まれます。たとえば、org.finance-all グループには、org.finance-us、org.finance-germany、org.finance-australia の各グループがメンバーとして含まれる場合があります。
組織グループは、他のグループ タイプにメンバーとして追加できます。これは、組織グループのすべてのメンバーを別のグループに追加するよりもはるかに簡単です。
組織グループに他の種類のグループをメンバーとして追加しないでください。組織階層の一部として、アクセス グループ、適用グループ、コラボレーション グループを使用しないでください。
コラボレーション グループのネストルール
すべてのコラボレーション グループには、メンバーの追加方法を決定する明確なポリシー セットが必要です。2 つのコラボレーション グループが同じメンバーシップ ポリシーに従っている場合は、ネストできます。ただし、異なるメンバーシップ ポリシーを持つコラボレーション グループをネストすると、グループのメンバーシップ ポリシーを満たしていないメンバーがメンバーになる可能性があります。コラボレーション グループをネストする前に、メンバーシップ ポリシーをよく確認してください。
コラボレーション グループには、組織グループをメンバーとして含めることができます。
アクセス グループのネストルール
通常、アクセス グループをネストしないでください。アクセス グループをネストすると、どのリソースに誰がアクセスできるかを判断するのが難しくなります。また、アクセス ポリシーが異なるアクセス グループをネストすると、プリンシパルが厳格なアクセス グループ メンバーシップ ポリシーを回避できる可能性があります。
アクセス グループには、組織グループをメンバーとして含めることができます。
適用グループのネストルール
違反措置グループをネストしないでください。適用グループをネストすると、プリンシパルのアクセスが拒否される理由を特定するのが難しくなる可能性があります。また、メンバーシップ ポリシーが異なる適用グループをネストすると、一部のプリンシパルが意図しない制限の影響を受ける可能性があります。
違反措置グループには、組織グループをメンバーとして含めることができます。
組織グループを管理する
組織グループを管理するには、次のベスト プラクティスに沿ってください。
唯一の正確な情報源からプロビジョニング
組織グループは人事データに基づいているため、これらのグループは人事情報システムまたは外部信頼できる情報源（外部 ID プロバイダ（IdP）や Sailpoint、Okta、Entra ID などの ID ガバナンス システムなど）からのみプロビジョニングすることをおすすめします。
グループの変更を許可しない
組織グループにユーザーを手動で追加または削除しないでください。また、ユーザーが組織グループから自身を削除できるようにしないでください。
組織グループを使用してリソースへのアクセス権を付与しない
組織グループ内のすべてのユーザーがリソースに対して同じレベルのアクセス権を必要とすることはほとんどありません。このため、組織グループにアクセス権を付与すると、グループの一部のメンバーが実際に必要とするよりも多くのアクセス権を持つ可能性があります。
また、外部 IdP から Cloud Identity への同期頻度によっては、外部 IdP で変更が加えられてから Cloud Identity に反映されるまでに時間がかかることがあります。この遅延により、過剰な権限が拡散する可能性があります。たとえば、リソース オーナーは、リソースにアクセスする必要がないユーザーが既存のグループに含まれている場合でも、新しいグループを作成するのではなく、既存のグループにアクセス権を付与する可能性があります。
組織グループを使用してアクセス権を付与する必要がある場合は、アクセス権を直接付与するのではなく、組織グループをアクセス グループにメンバーとして追加し、組織閲覧者など、権限が制限されたロールのみを付与します。それ以外の場合は、アクセス グループを使用してリソースへのアクセス権を付与します。
組織グループにサービス アカウントと外部ユーザーを許可しない
サービス アカウントはユーザーを表さないため、組織グループに含めないでください。
外部ユーザー（別の Google Workspace アカウントまたは Cloud Identity アカウントのユーザー）は通常、組織に属していないため、組織グループのメンバーになる理由はありません。外部従業員を独自の Google Workspace アカウントまたは Cloud Identity アカウントにオンボーディングすると、その従業員は内部ユーザーと見なされ、組織グループに含めることができます。
これらのルールを適用するには、Cloud Identity セキュリティ グループとグループ制限を使用します。
コラボレーション グループを管理する
コラボレーション グループを管理するには、次のベスト プラクティスに沿ってください。
ビジネス向け Google グループを使用してコラボレーション グループを管理する
Google Workspace を使用している場合は、ビジネス向け Google グループを使用してコラボレーション グループを管理できます。これにより、ユーザーは Google グループを使用してグループを作成、閲覧、参加できるようになります。ユーザーが新しいコラボレーション グループを作成できるように、ビジネス向け Google グループを構成する必要があります。
ビジネス向け Google グループを使用していない場合は無効にする
Google Workspace ではなく Cloud Identity を使用している場合は、Cloud Identity にコラボレーション グループを作成する必要はありません。そのため、ビジネス向けグループを無効にして、ユーザーが Cloud Identity でグループを作成できないようにすることをおすすめします。
コラボレーション グループにサフィックスを強制的に適用する
ビジネス向け Google グループを使用している場合は、接尾辞を適用するように設定します。これは、すべてのユーザーに新しいビジネス向け Google グループの作成を許可している場合に特に重要です。
サフィックスを適用すると、ユーザーが外部ソースからプロビジョニングされるアクセス グループまたは組織グループと意図的に競合する名前のグループを作成できなくなります。このシナリオでは、誤った名前のコラボレーション グループの作成者が権限をエスカレーションできる可能性があります。
アクセス制御にコラボレーション グループを使用しないでください
コラボレーション グループは緩いアクセス制御を目的としており、通常は明確に定義されたライフサイクルに従いません。そのため、コラボレーションには適していますが、アクセス制御には適していません。
コラボレーション グループの命名規則を厳密に遵守している場合は、カスタムの組織のポリシー制約を作成して、コラボレーション グループに IAM ロールが付与されないようにすることができます。
同様に、コラボレーション グループを外部でプロビジョニングして管理する場合は、Cloud Identity にプロビジョニングしないでください。アクセス制御の目的で不正使用される可能性があります。
アクセス グループを管理する
アクセス グループを管理する際は、次のベスト プラクティスに沿って行ってください。
適切なツールを選択してアクセス グループを管理する
アクセス グループはワークロード オーナーが管理するため、セルフサービスに適したツールを使用します。ツールでは、ユーザーが既存のアクセス グループを見つけ、次のコントロールを適用するセキュリティ ガードレールを適用できるようにする必要があります。
- アクセス グループに参加できるユーザー（どの組織グループのメンバー）
ユーザーがグループに参加するために満たす必要がある要件
たとえば、ユーザーが理由を示す必要はありますか？
グループ メンバーシップの最大存続期間
メンバーシップの承認が必要かどうか、承認が必要であれば誰が承認するか
監査証跡のサポート
これらの要件を満たすツールの 1 つが JIT グループです。
アクセス グループを使用してジョブ機能をモデル化し、リソースへのアクセス権を付与する
ジョブ機能ごとにアクセス グループを作成し、そのジョブ機能のユーザーが必要とするすべてのリソースへのアクセス権を付与します。その後、個々のユーザーに同じロールを付与するのではなく、その職務のユーザーをグループに追加して、必要なアクセス権を付与できます。
1 つのアクセス グループを使用して、複数のリソース、さらには複数のプロジェクトへのアクセス権を付与できます。ただし、グループに付与するアクセス権を各グループ メンバーが必要としていることを確認してください。一部のユーザーが追加のアクセス権を必要としない場合は、新しいアクセス グループを作成し、そのグループに追加のアクセス権を付与します。
特定のワークロードにアクセス グループを使用する
複数のワークロードでアクセス グループを再利用すると、過剰な権限設定と複雑な管理につながります。
ワークロード オーナーのアクセス グループの作成の障壁を取り除く
既存のアクセス グループを再利用する誘惑を減らすには、アクセス グループの作成と維持を簡単にします。ワークロード オーナーは、適切な命名をサポートしながら、セルフサービスでアクセス グループを作成できる必要があります。
ユーザーがアクセス グループを検索して参加できるようにする
ユーザーが既存のアクセス グループを見つけて、必要なグループに参加できる場合、不要な権限が蓄積される可能性は低くなります。必要に応じて、招待または承認プロセスを使用して、グループに参加できるユーザーを制御できます。
メンバーシップをデフォルトで自動的に期限切れにする
一定の期間が経過した後に、ユーザーがアクセス グループに再び参加するか、メンバーシップを延長することを必須にします。この方法では、アクセス グループのメンバーとして維持するための手間を意図的に増やし、不要なメンバーシップを失効させるインセンティブを作成します。このベスト プラクティスは、ゼロ スタンディング権限（ZSP）の目標を達成するために重要であり、外部ユーザーにとって特に重要です。
ただし、アクセス グループからサービス アカウントを削除するとサービスが中断される可能性があるため、このルールをサービス アカウントに適用しないでください。
各グループに指定されたオーナーを割り当てる
すべてのアクセス グループには、1 つ以上の指定されたオーナーが必要です。これにより、グループ メンバーシップに対する責任感が促進されます。オーナーは、グループに関連付けられたワークロードを所有するユーザーまたはチームと同じにできます。
アクセス グループの公開設定を制限する
アクセス グループをグループ ディレクトリに表示しない。（アクセス グループ管理ツールで検出可能である必要があります）。また、グループ メンバーのみが他のメンバーを確認できるようにします。こうした対策により、不正な行為者が貴重な情報を入手するのを防ぐことができます。
外部メンバーを制限する
ドメイン制限共有（DRS）ポリシーの制約はグループに適用されますが、グループ メンバーには適用されないため、外部メンバーを許可するアクセス グループは、DRS を損なう抜け穴を作成する可能性があります。
Cloud Identity セキュリティ グループとグループ制限を使用して、アクセス グループに外部メンバーを許可または拒否します。また、外部メンバーを許可するアクセス グループには、external.access.GROUP_NAME@example.com などの特別な命名規則を使用することを検討してください。
違反措置グループを管理する
違反措置グループを管理するには、次のベスト プラクティスに沿ってください。
適切なツールを選択して違反措置グループを管理する
違反措置グループのメンバーシップは組織のルールに基づいており、セキュリティ制限の適用に使用されるため、メンバーが違反措置グループからオプトアウトしたり、自分自身を削除したりすることはできません。
動的グループを使用すると、適用グループのプロビジョニングを自動化できます。外部 IdP を使用している場合は、IdP から提供される動的グループを使用して、Cloud Identity にプロビジョニングします。外部 IdP を使用すると、ポリシーの更新に遅延が生じる可能性があります。
動的グループを使用できない場合は、Terraform などの Infrastructure as Code（IaC）ツールを使用して適用グループをプロビジョニングすることを検討してください。IaC を使用して適用グループを作成する場合は、パイプラインに不必要に広範なアクセス権を付与しないようにしてください。
強制アクセス制御と認証制御に適用グループを使用する
アクセス グループを使用して強制アクセス制御を適用します。Google Cloud は、次のようなさまざまなサービスとツールで強制アクセス制御をサポートしています。
適用グループは、SAML プロファイルの割り当てや 2 段階認証プロセス（2SV）などの認証制御を適用するためにも使用されます。
これらのコントロールはすべて機能を制限するかアクセスを削除するため、適用グループが適しています。
ユーザーが違反措置グループを離れないようにする
ユーザーが適用グループから離脱できるようにすることは、強制アクセス制御の原則に反しています。ユーザーがグループを退会できないようにするには、Groups Settings API を使用して whoCanLeaveGroup プロパティを NONE_CAN_LEAVE に設定します。
外部 IdP のベスト プラクティス
認証に外部 IdP を使用している場合は、その IdP を使用して組織グループと適用グループをプロビジョニングすることもできます。
アクセス グループに外部ソースを使用しないようにする
外部 IdP でアクセス グループを管理し、Cloud Identity にプロビジョニングすることは可能ですが、この方法にはいくつかの欠点があります。
プロビジョニングの遅延
外部 IdP で行った変更がアクセス グループに反映されるまでに、最長で数時間かかることがあります。
分散のリスク
一部の IdP は、グループの信頼できる管理を行いません。たとえば、外部で削除された後に Cloud Identity のグループを削除しなかったり、Cloud Identity に存在するが IdP に存在しないグループ メンバーを積極的に削除したりする場合があります。
不一致があると、ユーザーが不要なアクセス権を保持し、アクセス権を持つユーザーに関する誤った情報が提供される可能性があります。また、アクセス グループの作成に手間がかかります。
このような落とし穴を回避するには、外部 IdP を使用して組織グループと適用グループのみをプロビジョニングし、JIT グループなどのツールを使用して Cloud Identity でアクセス グループを直接管理します。
グループを名前でマッピングする場合は、セカンダリ ドメインを使用します。
Cloud Identity はメールアドレスでグループを識別しますが、外部 IdP のグループにメールアドレスがない場合があります。
多くの IdP では、my-group@example.com を使用するなど、グループ名から疑似メールアドレスを取得することで、この問題を回避できます。これは機能しますが、このメールアドレスが別のグループまたはユーザーによってすでに使用されている場合は、競合が発生する可能性があります。最悪の場合、この名前の競合が悪意のある行為者によって悪用され、精査の少ない別のグループタイプを装ったセキュリティ グループが作成される可能性があります。
競合のリスクを回避するには、外部ソース（groups.example.com など）からプロビジョニングするグループに専用のセカンダリ ドメインを使用します。
デプロイ パイプラインにグループ管理者ロールを付与しない
IaC を使用してグループを管理する場合（Terraform など）、デプロイ パイプラインにタスクを実行するために必要な権限が必要です。グループ管理者ロールはグループの作成を承認しますが、そのロールを持つすべてのプリンシパルが Cloud Identity アカウント内のすべてのグループを管理できるようにします。
パイプラインに付与されるアクセス権を制限するには、1 つの権限（グループを作成する権限）のみを持つサービス アカウントを作成し、パイプラインを作成するグループのオーナーにします。これにより、パイプラインは、作成したグループを管理し、さらにグループを作成できますが、作成していないグループを管理する権限は付与されません。
このアプローチの概要は次のとおりです。
Admin API グループの作成権限のみを含むカスタム管理者ロールを作成します。
このロールにわかりやすい名前を付けます（グループ作成者など）。
サービス アカウントを作成し、グループ作成者のロールを割り当てます。
パイプラインのサービス アカウントを使用し、グループの作成時に
WITH_INITIAL_OWNERフラグを渡します。
Cloud Logging を使用してグループを監査およびモニタリングします。
Logging を使用すると、グループ アクティビティを収集、モニタリング、分析できます。
メンバーシップの変更を監査する
組織グループ、アクセス グループ、適用グループのメンバーを追加または削除すると、メンバーがアクセスできるリソースに影響する可能性があるため、これらの変更を追跡する監査証跡を保持することが重要です。
アクセス グループへの参加の理由を求める
モニタリング データをより有用にするには、ユーザーがグループに参加する際、またはグループへの参加をリクエストする際に理由を提示し、その理由を記録するようにします。承認プロセスがある場合は、リクエストを承認したユーザーの詳細を記録します。
この追加メタデータは、後で、あるユーザーがグループに追加された理由や、特定のリソースへのアクセス権が付与された理由を分析する際に役立ちます。
Cloud Identity 監査ログの共有を有効にする
ログを Cloud Logging に転送するように Cloud Identity を構成して、これらの監査ログを他の Google Cloud ログと同じ方法で処理できるようにします。たとえば、アラートの設定や外部セキュリティ情報およびイベント管理（SIEM）システムの使用などです。