Cloud Identity

解決する課題

組織の従業員アカウントを一元管理し、Google Cloud・Workspace・各種 SaaS への入口を安全に揃えます。Identity Platform が「あなたのアプリにログインする顧客」を扱うのに対し、Cloud Identity は「自社の社員・グループ・端末」を管理する社内向けの ID 基盤（IDaaS）です。

• 部署ごとにアカウントがバラバラ → 組織ドメイン配下でユーザーとグループを一元管理したい
• アプリごとに別パスワード → **シングルサインオン（SSO）**でログインの入口を 1 つにまとめたい
• パスワード漏洩が怖い → **2 段階認証（2SV）**やセキュリティキーを全社で必須化したい
• 私物・貸与端末からの不正アクセスが心配 → **デバイス管理（MDM）**でアクセス条件を縛りたい
• Google Cloud の IAM で誰に権限を渡すかの「誰」の供給元を一本化したい

対応する他クラウドのサービスは Microsoft Entra ID（旧 Azure AD）、AWS では IAM Identity Center が近い位置づけです。Cloud Identity は Google Workspace と同じ管理基盤を共有し、メール等の生産性機能を外してID 管理に特化した製品にあたります。

主要概念と用語

• 組織（Organization）: Cloud Identity のドメインに対応する Google Cloud の最上位ノード。リソース階層の頂点で、IAM やポリシーの起点になる
• ユーザー: 社内の従業員アカウント（例 alice@example.com）。Google Cloud にログインする人や、IAM のプリンシパル user: の実体
• グループ: ユーザーをまとめる単位。IAM では group: として扱い、個人ではなくグループにロールを付与することで入退社に強くなる
• 管理コンソール（Admin Console）: ユーザー・グループ・デバイス・セキュリティ設定を行う管理画面（admin.google.com）
• シングルサインオン（SSO）: 1 度の認証で複数アプリにログインできる仕組み。Cloud Identity を IdP（SAML/OIDC）として外部 SaaS と連携できる
• 2 段階認証プロセス（2SV / MFA）: パスワードに加え、確認コードやセキュリティキーなど第二要素を要求する仕組み
• デバイス管理（エンドポイント管理）: スマホ・PC を登録し、画面ロックや暗号化、紛失時のワイプを強制する MDM 機能
• ディレクトリ同期: 既存の社内ディレクトリ（オンプレ AD など）とユーザー情報を同期する仕組み（Google Cloud Directory Sync 等）
• 無料エディションと Premium エディション: 基本管理は無料エディションで、デバイス管理の強化やセキュアな機能の一部は Premium で提供される

仕様・制限・クォータ

• グローバルサービスで、ID・グループ・デバイス情報は組織（ドメイン）に紐づく。リージョンには依存しない
• ドメインの所有権確認が必要。DNS レコード等でドメインを検証してから利用を開始する
• 無料エディションにはユーザー数の上限がある一方、Premium エディションは有償でデバイス管理やセキュリティ機能が拡張される
• IAM の domain: / group: プリンシパルとして参照され、Google Cloud 側の権限付与の前提になる
• Workspace との関係: 同一基盤のため、Workspace 契約があれば Cloud Identity 相当の ID 管理機能が含まれる
• 具体的な上限ユーザー数・料金・エディション差分の数値は変動するため、本番設計時は公式ドキュメントで最新値を確認すること

内部の仕組み

Cloud Identity は組織のドメインに対する**ディレクトリ（ユーザー・グループの台帳）**を保持し、認証要求の入口（IdP）として振る舞います。

1. 管理者がドメインを検証し、**組織（Organization）**が生成される
2. ユーザー・グループを管理コンソールや API、ディレクトリ同期で登録する
3. 従業員がログインすると、Cloud Identity が**パスワードと第二要素（2SV）**を検証して認証する
4. 外部 SaaS へは **SSO（SAML/OIDC）**で ID を連携し、各アプリでの再ログインを省く
5. Google Cloud では、これらのユーザー・グループが IAM のプリンシパルとして参照され、ロール付与の対象になる

設計パターン / ベストプラクティス

• 権限はグループへ: IAM ロールは個人ではなく Cloud Identity のグループに付与し、入退社はグループのメンバー変更だけで反映させる
• 2 段階認証を全社必須化: 特に管理者アカウントは**セキュリティキー（フィッシング耐性のある要素）**を必須にする
• 特権アカウントを分離: 日常業務用と組織管理者用のアカウントを分け、管理者権限の常用を避ける
• 外部 SaaS は SSO 集約: 各 SaaS のパスワードを廃し、Cloud Identity を IdP にして SSO でログインを一本化する
• デバイス条件でアクセス制御: 管理対象デバイスや画面ロック等の条件を、コンテキストアウェアなアクセス制御と組み合わせる
• オンプレ AD があれば同期: 既存ディレクトリと同期し、ID の二重管理を避ける

運用・監視

• 管理コンソールでユーザーの追加・停止・削除、グループ編成、セキュリティ設定を行う
• 監査ログでログイン試行・管理操作・デバイス操作を追跡し、不審なサインインを検知する
• **ログイン要求（2SV 登録状況）**を監視し、未登録ユーザーや弱い認証要素の利用を洗い出す
• 退職処理ではアカウント停止とデバイスのワイプ、共有データの引き継ぎを手順化する
• デバイスインベントリで登録端末を把握し、紛失・盗難時にリモートワイプを実行する

コスト

基本的な ID・グループ管理は無料エディションで利用でき、デバイス管理の強化やセキュリティ機能の一部が有償の Premium エディションで提供されます。料金はユーザー単位の月額が基本です。

セキュリティ

• 2 段階認証を必須化し、管理者にはフィッシング耐性のあるセキュリティキーを強制する
• 管理者権限を最小化し、特権アカウントを日常利用と分けて常時の高権限を避ける
• デバイス管理で、画面ロック・暗号化・未管理端末のブロックなどアクセス条件を強制する
• 不審なサインインを監査ログとアラートで検知し、侵害時はアカウント停止とセッション失効を行う
• 退職・異動時の即時失効を運用に組み込み、放置アカウントを残さない

関連サービス・比較

Cloud Identity が供給するユーザー・グループは、Google Cloud の権限制御を担う Cloud IAM のプリンシパルとして使われます。両者は役割が異なり、組み合わせて使います。

ハンズオン / CLI例

# Cloud Identity / Admin SDK 系 API を有効化
gcloud services enable cloudidentity.googleapis.com --project=my-project

# Cloud Identity のグループを作成（社内チーム用）
gcloud identity groups create dev-team@example.com \
  --organization=123456789012 \
  --display-name="Development Team"

# 作成したグループにメンバーを追加
gcloud identity groups memberships add \
  --group-email=dev-team@example.com \
  --member-email=alice@example.com

# グループ単位で IAM ロールを付与（個人ではなくグループに渡すのが定石）
gcloud projects add-iam-policy-binding my-project \
  --member="group:dev-team@example.com" \
  --role="roles/viewer"