このドキュメントでは、Google グループを使用して Identity and Access Management（IAM）で Google Cloud リソースへのアクセスを管理するためのベスト プラクティスについて説明します。
グループのタイプ
ここで示すグループのタイプは、Google グループについて考え、使用し、管理するための一つの方法です。これらのグループタイプは、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 でコラボレーション グループを作成する必要性はありません。そのため、ビジネス向け Google グループを無効化して、Cloud Identity でユーザーがグループを作成できないようにするのが最善です。
コラボレーション グループに接尾辞を適用する
ビジネス向け Google グループを使用している場合は、接尾辞を適用するように設定します。これは、すべてのユーザーに新しいビジネス向け Google グループの作成を許可している場合に特に重要です。
接尾辞を適用すると、外部ソースからプロビジョニングされるアクセス グループまたは組織グループと意図的に競合させた名前のグループをユーザーが作成することを防止できます。このようなグループの作成が可能な状況では、名前を偽ったコラボレーション グループの作成者が権限を昇格できる可能性があります。
アクセス制御にコラボレーション グループを使用しない
コラボレーション グループは緩いアクセス制御を目的としており、明確に定義されたライフサイクルには通常従いません。そのため、共同作業には適していますが、アクセス制御には不向きです。
コラボレーション グループの命名規則を厳密に遵守している場合は、カスタムの組織のポリシー制約を作成して、コラボレーション グループへの IAM ロールの付与を防ぐことができます。同様に、コラボレーション グループを外部でプロビジョニングして管理する場合は、Cloud Identity にプロビジョニングしないでください。アクセス制御の目的で不正使用される可能性があります。
アクセス グループを管理する
アクセス グループを管理する際のベスト プラクティスは以下のとおりです。
適切なツールを選択してアクセス グループを管理する
アクセス グループはワークロード オーナーが管理するため、セルフサービスに適したツールを使用します。こうしたツールでは、ユーザーが既存のアクセス グループを見つけて、次のような制御を適用するセキュリティ ガードレールを実施できる必要があります。
- 誰（どの組織グループのメンバー）がアクセス グループに参加できるか
ユーザーがグループに参加するには、どのような要件を満たす必要があるか
例: ユーザーは正当な理由を示す必要があるか
グループ メンバーシップの最大有効期間
メンバーシップの承認が必要かどうか。必要な場合、誰が承認するか
監査証跡のサポート
これらの要件を満たすツールの一つが JIT Groups です。
アクセス グループを使用して職務をモデル化し、リソースへのアクセス権を付与する
職務ごとにアクセス グループを作成し、その職務のユーザーが必要とするすべてのリソースへのアクセス権をグループに付与します。その後、その職務のユーザーをグループに追加することで、必要なアクセス権をユーザーに付与できます。この方法では、各ユーザーに同じロールを付与せずに済みます。
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 Groups などのツールを使用して 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）システムの使用などが可能になります。