セクション 1：アクセスの構成

Cloud Identity・サービスアカウント・認証・認可（IAM）・リソース階層の 上流設計。出題比重 25% の最重要セクション。

出題 ~25% ★最重要 📘 基礎 🔧 応用 🎯 要点と暗記

🎯 公式深掘り Deep Dive ページへ Workload Identity Federation の attribute-condition、Deny ポリシー、PAM、CEL 詳細、組織ポリシーの公式深掘り

🔑 TL;DR — このセクションの要約人間は Cloud Identity / Workforce Identity Federation、マシンは サービスアカウント / Workload Identity Federation の 2 系統に振り分け。SA 鍵を撒く選択肢は基本的に不正解。IAM は 最小権限 + グループ + Condition、広域禁止は Deny ポリシー、特権は常時保有させない（PAM）。上から強制するのは 組織ポリシー。

📚 他のセクションへ

アクセス

通信・境界

データ保護

運用管理

コンプライアンス

📖 学習コンテンツ

概念とサービスの役割を理解することがゴール。設計判断は「🔧 応用」タブで扱います。

1.1 Cloud Identity の管理

① Cloud Identity

Cloud Identity は Google の IDaaS。ユーザー / グループ / デバイス管理を提供。GCP の組織はドメインに紐付いて自動作成される。

② SSO と GCDS

Google Cloud Directory Sync (GCDS)：オンプレ AD / LDAP を Cloud Identity に 一方向 同期
SSO：認証を外部 IdP（AD / Okta）に委譲（SAML 2.0）

[ 社員 ] ── ログイン要求 ──► [ Google ] ── SAML AuthnRequest ──► [ 外部 IdP ] ◄── SAML Response ──┘

③ スーパー管理者

通常運用には 使わない（緊急用 break-glass）
複数人で分散保管、必ず ハードウェアセキュリティキー で 2SV
通常タスクには「組織管理者ロール」の別アカウント

④ Workforce Identity Federation

外部 IdP の 人間ユーザー を Cloud Identity アカウントなしで GCP に連携。取引先・委託メンバー・監査人向け。

1.2 サービスアカウント管理

① サービスアカウント (SA)

GCP の 非人間用 ID。`@.iam.gserviceaccount.com` 形式。

② デフォルト SA

GCE / Cloud Run 作成時に自動付与。既定で Editor ロール を持つ過大権限の危険源。本番では専用 SA に置き換える。

③ SA 鍵

鍵漏洩リスク大。組織ポリシー iam.disableServiceAccountKeyCreation で 鍵作成自体を禁止 可能。

④ Workload Identity Federation

外部ワークロード（AWS / Azure / GitHub Actions / K8s）から SA 鍵なし で GCP API を呼ぶ。

[ GitHub Actions ] ── OIDC トークン ──► [ Workload Identity Pool ] │ Trust 検証 ▼ [ SA を impersonate ] ──► GCP API

⑤ サービスアカウントの impersonation

roles/iam.serviceAccountTokenCreator = SA トークン発行（impersonate に必須）
roles/iam.serviceAccountUser = SA をリソースに割り当てる権限

1.3 認証の管理

① パスワード / セッションポリシー

パスワード強度・履歴・有効期限、セッション再認証間隔を Cloud Identity / Workspace 管理コンソールで設定。

② SAML / OAuth

SAML 2.0：人間ユーザーのフェデレーション認証
OAuth 2.0：アプリ間の認可フロー（アクセストークン発行）

③ 2 段階認証 (2SV)

方式	強度	コメント
SMS / 音声	低	SIM スワップに弱い。非推奨
Authenticator (TOTP)	中	一般的
Google プロンプト	中	スマホへのプッシュ
セキュリティキー (FIDO)	高	フィッシング耐性、特権必須

1.4 認可（IAM）の管理と実装

① IAM 基本モデル

プリンシパル（ユーザー/グループ/SA/ドメイン/allUsers） │ に ▼ ロール（権限の束 = permissions）を付与 │ 対象は ▼ リソース（組織 / フォルダ / プロジェクト / 個別リソース）

② ロールの 3 階層

基本ロール（Owner / Editor / Viewer）：広すぎて本番非推奨
事前定義ロール：サービスごとに Google が用意
カスタムロール：必要な権限だけを集めた自前ロール

③ IAM Conditions

CEL 式での条件付き付与。時間・リソース・Access Level を条件に。

expression: 'request.time.getHours("Asia/Tokyo") >= 9
             && request.time.getHours("Asia/Tokyo") <= 18
             && resource.name.startsWith("projects/_/buckets/secure")'

④ IAM Deny ポリシー

Allow より強い「絶対禁止」を表現。組織レベルで「全社員に対し X を禁止」のような広域防御に使う。

⑤ Access Context Manager

Access Level（IP / デバイス / 時間など）の定義。IAM Condition や VPC SC で参照。

⑥ Policy Intelligence 3 兄弟

ツール	役割
IAM Recommender	余剰権限の特定（90 日基準）
Policy Troubleshooter	「なぜ deny/allow か」の診断
Policy Analyzer	「誰が何にアクセスできるか」の網羅検索

⑦ Privileged Access Manager (PAM)

特権を一時的に昇格（JIT アクセス）。申請 → 承認 → 自動付与 → 期限で自動剥奪。特権の常時保有を排除。

1.5 リソース階層

組織 (Organization) └── フォルダ (Folder) └── プロジェクト (Project) └── リソース (VM / バケット / DB ...)

組織ポリシーの定番制約

制約	目的
`gcp.resourceLocations`	特定リージョンのみ許可
`iam.disableServiceAccountKeyCreation`	SA 鍵作成禁止
`iam.allowedPolicyMemberDomains`	自社ドメイン以外への IAM 付与禁止
`compute.vmExternalIpAccess`	外部 IP 禁止
`compute.requireOsLogin`	OS Login 強制

設計判断・トレードオフ・試験のひっかけに焦点。

「鍵を使わない」設計の正解パターン

ワークロード	推奨される認証方式
GCE VM	アタッチド SA（メタデータサーバ）
GKE Pod	Workload Identity for GKE
Cloud Run / Functions	アタッチド SA（実行時 ID）
GitHub Actions / GitLab CI	Workload Identity Federation（OIDC）
AWS / Azure 上のワークロード	Workload Identity Federation（外部 IdP）

⚠️ 試験頻出 「鍵ファイルを作る選択肢は基本的に不正解」。Workload Identity を選ぶ。

IAM Conditions の典型パターン

パターン	条件式
特定バケットのみ	`resource.name == "projects/_/buckets/finance"`
日本国内 IP のみ	`request.auth.claims.access_levels.contains("japan_only")`
業務時間内のみ	`request.time.getHours("Asia/Tokyo") >= 9 && <= 18`
期限付き付与	`request.time < timestamp("2026-12-31T23:59:59Z")`
特定タグの付いたリソースのみ	`resource.matchTag("env", "prod")`

IAM 評価順

1. 組織レベル Deny 2. フォルダレベル Deny 3. プロジェクトレベル Deny 4. リソースレベル Deny 5. 上記すべて Allow される条件で評価

Deny が 1 つでもヒットしたらアクセス拒否。Allow は加算式。

Policy Intelligence の使い分け

状況	使うツール
90 日アクセスのない権限を棚卸し	IAM Recommender
「なぜ Bob は X バケットにアクセスできない？」	Policy Troubleshooter
「誰が `pubsub.publish` を持っているか組織全体で知りたい」	Policy Analyzer

🎯 統合シナリオ演習

シナリオ：①社内 AD ②取引先 10 社にも期限付き ③開発者の本番 SA は JIT 昇格 ④CI/CD は鍵なし ⑤監査ログ SA の権限は剥奪させない

社内 AD → GCDS → Cloud Identity 同期、SAML SSO で認証委譲
取引先は Workforce Identity Federation + IAM Condition で期限・スコープ絞り
開発者は Privileged Access Manager で JIT 昇格 + 承認制
GitHub Actions は Workload Identity Federation（OIDC）
監査ログ SA に対する setIamPolicy / deleteRole を組織レベル Deny ポリシー

試験直前の総ざらい。

暗記必須テーブル

Identity 種別の使い分け

種別	用途
Cloud Identity ユーザー	自社の人間
Workforce Identity Federation	取引先・委託の人間。外部 IdP 経由
サービスアカウント	マシン。GCP 内のサービス用
Workload Identity Federation	マシン。外部ワークロードから GCP API

SA 関連ロール

ロール	何ができるか
`serviceAccountUser`	SA をリソースに割り当てる
`serviceAccountTokenCreator`	SA のトークン発行（impersonate）
`serviceAccountKeyAdmin`	SA 鍵管理（誰にも与えない方針）
`workloadIdentityUser`	Workload Identity でこの SA を借用

一問一答（クリックで答え）

Q. GitHub Actions から GCP API を呼ぶ際に SA 鍵を配布しない方法は？

Workload Identity Federation。OIDC トークンで SA impersonate。

Q. 「`storage.buckets.delete` を組織内の全員に絶対させない」を実現する仕組みは？

IAM Deny ポリシーを組織レベルで設定。

Q. 90 日以上使われていない権限を棚卸ししたい。使うツールは？

IAM Recommender。

Q. 開発者が本番 SA を impersonate するために必要なロールは？

roles/iam.serviceAccountTokenCreator（User ではない）。

Q. 開発者の常時保有特権をなくし、必要時に承認制で 30 分だけ昇格させたい。使う機能は？

Privileged Access Manager (PAM)。

Q. 「自社ドメインのアカウント以外には IAM 付与できない」を組織全体に強制する組織ポリシーは？

iam.allowedPolicyMemberDomains。

🎯 ひっかけ注意

「SA 鍵を渡す」選択肢は基本的に不正解。Workload Identity Federation か impersonation を選ぶ
serviceAccountUser ≠ serviceAccountTokenCreator。impersonate には Token Creator
「IAM ロールで対処」と思わせて実は Deny ポリシー
最も強い MFA は TOTP ではなく FIDO セキュリティキー
基本ロール（Owner / Editor / Viewer）を選ぶ選択肢はほぼ間違い