S1 アクセスの構成 🎯 Deep Dive 出題 ~25%

Identity & Access Management
公式ドキュメント深掘り

Cloud Identity・サービスアカウント・Workload/Workforce Identity Federation・IAM Allow/Deny・Conditions・Access Context Manager・PAM・組織ポリシーを、公式ベースの技術詳細と本番運用のリスク・落とし穴まで踏み込んで解説します。

中堅〜シニア向け公式 IAM ドキュメント Policy リファレンス

このページの目次

1. Identity の 4 系統
2. Cloud Identity / GCDS / SSO
3. サービスアカウント詳細
4. Workload Identity Federation
5. Workforce Identity Federation
6. Impersonation の仕組み
7. Allow ポリシー & 評価
8. Deny ポリシー
9. IAM Conditions (CEL)
10. Access Context Manager
11. Policy Intelligence 3 兄弟
12. Privileged Access Manager
13. リソース階層と継承
14. 組織ポリシー詳細
15. リスク・落とし穴総まとめ
16. 設計チェックリスト

1. Identity の 4 系統

GCP の Identity は 「誰が・どこから」 で 4 系統に整理されます。試験では 4 系統を即時に使い分けられる必要があります。

図 1: Identity を「人間 vs マシン × 内部 vs 外部」で分割したマトリクス。SA 鍵に頼らない設計の出発点。

✅ ベストプラクティス

常に「人間か / マシンか」と「内部か / 外部か」の 2 軸で考える
右下（Workload Identity Federation）と右上（Workforce Identity Federation）の利用に積極的に倒す
左下（SA）は GCP 内のみ。SA 鍵は最終手段 で、Workload Identity Federation か impersonation を優先

2. Cloud Identity / GCDS / SSO

人間ユーザーをどう調達するかの基盤レイヤ。試験では GCDS = 同期、SSO = 認証委譲 の役割分離を問う設問が頻出。

Cloud Identity 無料版 / 有料版あり

Google が提供する IDaaS。Workspace を契約しない組織でも GCP の人間ユーザー / グループ / デバイスを管理できる。GCP の Organization はドメインに紐付いて自動生成される。Free 版でも SSO / MFA 必須化 / グループ管理は可能。

Google Cloud Directory Sync (GCDS) 一方向同期

オンプレ AD / LDAP のユーザー・グループを Cloud Identity に 一方向で 同期するエージェント。GCDS は同期のみ、認証は別途 SSO で IdP に委譲する。Cron 起動の Windows/Linux サービスとして動作し、LDIF 差分計算で変更分だけを反映。

SSO (SAML 2.0) 認証委譲

Google を SP（Service Provider）、外部 IdP（AD FS / Okta / Ping / Azure AD）を IdP として認証フローを委譲。Cloud Identity 側でも MFA の追加要件を強制できる（IdP の MFA に加えて）。

図 2: SAML 2.0 SP-initiated フロー。Super Admin は SSO 適用範囲外にする運用が公式推奨。

⚠️ リスク：SSO 設定ミスでロックアウト

SAML 設定誤りで 全社員ログイン不能 に。回復には Super Admin（Google パスワード認証）が必要
Super Admin に SSO を強制適用すると、IdP 障害時に 復旧ルートが消失
対策：Super Admin は SSO 例外、ハードウェアキー必須、複数人で冗長化

Super Admin の運用ガイドライン（公式推奨）

break-glass 専用：日常運用には roles/resourcemanager.organizationAdmin + 必要最小限の組織管理ロールを持つ別アカウントを使う
2〜4 人 に分散保持、各人が独立した ハードウェアセキュリティキー（できれば 2 本 登録）
Audit Log アラート：SetIamPolicy 等の Super Admin 操作は Pub/Sub → Slack/PagerDuty 通知
recovery 情報 を金庫保管：紛失時の復旧フロー含む

3. サービスアカウント詳細

マシン用 ID。試験で最頻出のテーマであり、「鍵を発行しない」 設計を判断できるかが核。

SA の3つの利用形態

Attached SA：GCE / Cloud Run / Functions / GKE Pod に紐づける（既定推奨）
Impersonated SA：別のプリンシパルが SA トークンを発行して借りる
Federated SA：Workload/Workforce Identity Federation で外部から借りる

これ以外の SA 鍵による直接認証 は使わない方針が公式推奨。

SA メールアドレスの種類

ユーザー作成 SA: NAME@PROJECT.iam.gserviceaccount.com
Compute 既定 SA: PROJECT_NUMBER-compute@developer.gserviceaccount.com
App Engine 既定 SA: PROJECT_ID@appspot.gserviceaccount.com
Google マネージド SA: service-PROJECT_NUMBER@SERVICE.iam.gserviceaccount.com（Cloud KMS / Cloud Build 等が暗黙的に使う）

既定 SA の罠

⚠️ 既定 SA は強すぎる

GCE / Cloud Run / Cloud Functions 作成時の 既定 SA には、伝統的に roles/editor が自動付与されてきた
2024 年以降の新規 Organization では 自動付与は無効化 される方向だが、既存環境では生きている
本番では必ず 専用 SA を作成して付け替え、既定 SA は disable または最小化

gcloud 既定 SA の自動 IAM 付与を組織で無効化

gcloud resource-manager org-policies enable-enforce \
    iam.automaticIamGrantsForDefaultServiceAccounts \
    --organization=ORG_ID

SA 鍵に対する組織レベルの規律

gcloud SA 鍵作成を組織レベルで Deny

gcloud resource-manager org-policies enable-enforce \
    iam.disableServiceAccountKeyCreation \
    --organization=ORG_ID

# 例外プロジェクトを許可（フォルダ単位での上書き）
gcloud resource-manager org-policies set-policy /tmp/exception.yaml \
    --folder=EXCEPTION_FOLDER_ID

✅ SA 鍵をどうしても使う場合の規律

有効期限 90 日以内：自動ローテーション（Pub/Sub → Cloud Function）
鍵は Secret Manager 保管、アプリは起動時に取得
iam.serviceAccounts.actAs / serviceAccountKeys.create の付与を厳格管理
監査ログ google.iam.admin.v1.CreateServiceAccountKey を 必ずアラート対象
Recommender (google.iam.policy.UnusedPermissionRecommender) で未使用鍵を定期削除

4. Workload Identity Federation 詳細

外部マシンが SA 鍵なし で GCP API を呼ぶ仕組み。OIDC / SAML 2.0 / AWS Signature の 3 形式に対応。

図 3: Workload Identity Federation の信頼チェーン。Pool / Provider / Attribute Mapping / Workload Identity User の 4 要素を理解する。

GitHub Actions 連携の典型手順

Pool 作成　gcloud iam workload-identity-pools create で組織別の Workload Identity Pool を作成。
--display-name と --description に運用情報を残す。
Provider 追加（OIDC）　GitHub の OIDC issuer (https://token.actions.githubusercontent.com) を Provider として登録。必ず attribute-condition で repository などを絞る こと（無条件で許可しない）。
SA 作成 + 最小権限　操作対象に応じた事前定義ロールを付与。Owner / Editor は厳禁。
workloadIdentityUser バインド　roles/iam.workloadIdentityUser を「特定 principal セット」に限定して付与。
- 例: principalSet://iam.googleapis.com/.../subject/repo:OWNER/REPO:ref:refs/heads/main
GitHub Actions YAML　google-github-actions/auth@v2 で Pool / Provider / SA を指定。出力で access_token が短期発行される。
監査　sts.googleapis.com の Audit Log（Admin Activity）を必ず Sink に流す。

gcloud Pool / Provider / Binding 作成例

# 1. Pool 作成
gcloud iam workload-identity-pools create github-pool \
    --location=global \
    --display-name="GitHub Actions pool"

# 2. Provider (OIDC) 追加（attribute-condition で repo を絞る）
gcloud iam workload-identity-pools providers create-oidc github-provider \
    --workload-identity-pool=github-pool --location=global \
    --issuer-uri="https://token.actions.githubusercontent.com" \
    --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.ref=assertion.ref" \
    --attribute-condition="attribute.repository == 'my-org/my-repo'"

# 3. SA に workloadIdentityUser を main ブランチのみで許可
gcloud iam service-accounts add-iam-policy-binding \
    deploy-sa@PROJECT.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/NUM/locations/global/workloadIdentityPools/github-pool/attribute.repository/my-org/my-repo"

⚠️ Workload Identity Federation の落とし穴

attribute-condition を書かずに作成：全リポジトリ / 全ブランチが SA を借りられる致命的な穴になる
workloadIdentityUser を `principal://...` で広く付与：principalSet で repo / branch / ref を必ず絞る
同じ Pool に複数組織を混在：CEL を分けても誤許可リスク。組織別に Pool 分離が公式推奨
OIDC issuer のキー切り替えに追従しないと突然認証不能

5. Workforce Identity Federation

外部 IdP の 人間ユーザー を Cloud Identity アカウントを作らずに GCP に連携。Workload と混同しないこと。

Workforce Identity Federation

対象：人間ユーザー
入口：GCP Console / gcloud / API
連携 IdP：OIDC / SAML 2.0 / Azure AD / Okta / Ping
用途：取引先・委託・監査・M&A 時のアクセス付与
付与方式：principalSet://... の人間プリンシパル
セッション：Cookie ベース、IdP 側ロックアウトが効く

Workload Identity Federation

対象：マシン / ワークロード
入口：GCP API のみ（短期トークン）
連携 IdP：OIDC / SAML / AWS Sig
用途：CI/CD・他クラウド・オンプレ K8s
付与方式：principalSet://... のワークロードクレーム
セッション：1 時間有効な access_token を都度発行

Workforce Identity Federation の典型ユースケース

M&A 期間中：買収先の Okta ユーザーに買収側 GCP の特定プロジェクトだけアクセス許可
監査人：四半期に一度、外部監査人に roles/iam.securityReviewer + IAM Condition の期間制限
BPO 委託先：委託先 IdP の人間ユーザーに、IAM Condition と組み合わせて時間 / IP 制限

6. Impersonation の仕組み

ユーザーが SA として短期的に行動 する仕組み。試験で serviceAccountUser vs serviceAccountTokenCreator の使い分けは頻出。

ロール	何ができるか	典型シナリオ
`roles/iam.serviceAccountUser`	SA をリソースに割り当てる（GCE VM / Cloud Run / Cloud Functions / GKE Pod の設定時）	運用者が VM 作成時に既定 SA 以外の SA を選ぶ
`roles/iam.serviceAccountTokenCreator`	SA の access_token / id_token / signedBlob / signedJwt を発行（=impersonate）	開発者が一時的に本番 SA として gcloud / API 操作
`roles/iam.serviceAccountKeyAdmin`	SA 鍵の作成・削除	原則として誰にも付与しないことが推奨
`roles/iam.workloadIdentityUser`	Workload Identity Federation でこの SA を借用	WIF Pool の principalSet をこの SA に紐付ける

gcloud impersonation の実例

# Alice が prod-deploy@PROJECT.iam.gserviceaccount.com として gcloud を実行
gcloud compute instances list \
    --impersonate-service-account=prod-deploy@PROJECT.iam.gserviceaccount.com

# 監査ログには両方の identity が記録される：
#  authenticationInfo.principalEmail        = alice@example.com
#  authenticationInfo.serviceAccountDelegationInfo = prod-deploy@...

✅ Impersonation のベストプラクティス

運用者には 本番 SA のロールを直接持たせず、serviceAccountTokenCreator だけを付与
監査ログで「誰が誰として行動したか」を必ず追跡（delegationInfo）
長期に許可するなら PAM で時間制限 + 承認制と組み合わせる

7. Allow ポリシー & 評価

IAM ポリシーは 「Deny → Allow」 の順で評価され、Allow は 加算式（どこかで許可されていれば通る）。

Deny ポリシー で表現する Conditions は Allow の binding に付与する（Deny にも別途付けられる）

図 4: IAM 評価順。Deny → Allow の 2 段階で、Deny がヒットすれば即拒否、Allow は加算式。

⚠️ Allow ポリシーで「取り消せない」罠

組織レベルで Owner を付けてしまうと、配下プロジェクトの Allow を引いて打ち消すことは できない
「強すぎる Allow を後から狭める」発想ではなく、「初手から最小権限」または「Deny で広域禁止」
Quota: 1 つの allow ポリシーには最大 1,500 バインディング、組織ポリシーで iam.allowedPolicyMemberDomains を併用

8. Deny ポリシー

Allow より 強制力が高い ポリシー。広域禁止・特権昇格防止・規制対応に必須。公式 Deny 概要

Deny ポリシーの構造

deniedPrincipals：誰を禁止するか（例：全 Google アカウント = principalSet://goog/public:all）
exceptionPrincipals：上記から除外するプリンシパル
deniedPermissions：禁止する permission（最大 5,000）
exceptionPermissions：上記から除外する permission
denialCondition：条件付き Deny（CEL）

yaml Deny ポリシー例：監査ログ用 SA の権限を絶対に変更させない

denyRules:
- description: "Protect security-audit SA from privilege changes"
  deniedPrincipals:
  - "principalSet://goog/public:all"
  exceptionPrincipals:
  - "principalSet://iam.googleapis.com/.../break-glass-group"
  deniedPermissions:
  - "iam.googleapis.com/serviceAccounts.setIamPolicy"
  - "iam.googleapis.com/roles.delete"
  - "iam.googleapis.com/serviceAccounts.delete"
  denialCondition:
    expression: "resource.matchTag('123/audit-protected', 'true')"
    title: "Only protected SAs"

典型 Deny パターン

広域禁止

Cloud Storage の buckets.delete を組織全員に Deny
監査ログ SA の setIamPolicy を Deny
本番タグの付いた組織ポリシーの変更を Deny

特権昇格防止

iam.serviceAccounts.actAs を限定グループ以外には Deny
iam.roles.create / update をエンジニアグループに Deny し、Platform チームのみ許可

✅ Deny の活用指針

「Allow 制御では絶対防げない事故」を Deny で物理ブロック
Deny ポリシー名と description に 適用理由・ロールバック手順を明記
exceptionPrincipals に 緊急時の解除ルートを 1 つだけ用意

9. IAM Conditions（CEL）

CEL（Common Expression Language）で条件付き付与を表現。resource.type / request.time / request.auth / resource.matchTag() が中核。公式 Conditions 概要

使える属性カテゴリ

属性	例	用途
`resource.name`	`resource.name.startsWith("projects/_/buckets/finance")`	特定リソース限定
`resource.type`	`resource.type == "storage.googleapis.com/Bucket"`	リソース種別フィルタ
`resource.matchTag()`	`resource.matchTag("123/env", "prod")`	タグベース制御
`request.time`	`request.time < timestamp("2026-12-31T23:59:59Z")`	期間限定付与
`request.auth.claims`	`'group_admin' in request.auth.claims.groups`	外部クレーム参照
`request.auth.access_levels`	`"accessPolicies/POLICY/accessLevels/japan_only" in request.auth.access_levels`	Access Context Manager との連携

Conditions 対応サービスの罠

⚠️ Conditions が効くサービスは限定的

すべての GCP サービスが Conditions に対応しているわけではない（例：Cloud KMS の一部、古い API）
Conditions 非対応サービスでは Allow binding が 常に有効 として扱われる
必ず対応サービス一覧を確認

典型 CEL パターン集

CEL よく使う条件式

# 業務時間内のみ（JST 09:00-18:00、月-金）
request.time.getHours("Asia/Tokyo") >= 9
&& request.time.getHours("Asia/Tokyo") <= 18
&& request.time.getDayOfWeek("Asia/Tokyo") >= 1
&& request.time.getDayOfWeek("Asia/Tokyo") <= 5

# 日本国内 + 企業端末のみ（Access Context Manager の Access Level を利用）
"accessPolicies/123/accessLevels/japan_corp_device" in request.auth.access_levels

# 期限付き付与（2026 年末まで）
request.time < timestamp("2026-12-31T23:59:59Z")

# prod タグの付いたリソース以外に対して
!resource.matchTag("123/env", "prod")

# 特定バケットの prefix のみ
resource.name.startsWith("projects/_/buckets/team-foo-")

10. Access Context Manager

「誰が・どこから・どんな端末で」を束ねた Access Level を定義し、IAM Conditions / VPC SC から参照。BeyondCorp Enterprise の中核。公式 ACM ドキュメント

Basic Access Level

属性ベースの条件式（CEL ライク）。

device.encryption_status
device.os_type / os_version
device.is_corp_owned_device
origin.ip / origin.region_code
levels（他レベルとの AND/OR）

Custom Access Level (CEL)

CEL 式の自由記述。

device.encryption_status == "ENCRYPTED"
&& device.is_corp_owned_device
&& origin.region_code == "JP"

✅ ACM のベストプラクティス

レベルは 用途別（admin / employee / contractor / audit）に細かく分け、ID Condition から参照
VPC SC の Ingress Rule と組み合わせて「正当な業務端末からの境界外アクセスのみ許可」
レベルの組み合わせは combiningFunction: AND/OR で表現

11. Policy Intelligence 3 兄弟

IAM Recommender

過去 90 日 間に使われていない権限を検出し、より絞った推奨ロールを提示。

「過剰権限の自動棚卸し」用途。

Active Assist の一部。Cloud Asset Inventory と連動。

Policy Troubleshooter

「X というプリンシパルが、Y というリソースに、Z という権限でアクセス可能か」を 解説付き で判定。

deny の原因を継承階層まで遡って表示。

Policy Analyzer

「誰が・どのリソースに・どの権限を持っているか」の 網羅検索。

Cloud Asset Inventory のクエリ機能で、組織横断の権限棚卸しに必須。

使い分けの判断軸

聞かれていること	選ぶツール
「未使用権限を削減したい」	IAM Recommender
「なぜ Bob は deny されたのか」	Policy Troubleshooter
「組織内で `pubsub.topics.publish` を持つ全プリンシパル」	Policy Analyzer
「外部メンバーへの付与の有無を可視化」	Policy Analyzer + Recommender

12. Privileged Access Manager (PAM)

特権ロールを 常時保有させず、申請 → 承認 → 自動付与 → 期限自動剥奪する Just-In-Time アクセスの仕組み。公式 PAM 概要

図 5: PAM の Entitlement → Grant フロー。Audit Log には申請・承認・付与・剥奪のすべてが残る。

Entitlement 設計のポイント

最大有効時間：4 時間 / 1 営業日 / 7 日など、ロールの危険度で短く
承認者：自分以外の上長 + Platform チームの 2 人組み合わせ
正当化理由（justification）：自由記入 + チケット番号必須
通知：申請・承認・付与イベントを Slack / メールに連携

13. リソース階層と継承

図 6: 階層モデル。継承は加算式で下位は強くなるのみ。広域禁止は Deny / 組織ポリシーで上から打つ。

14. 組織ポリシー詳細

事前定義された Constraint または Custom Constraint（CEL）を組織 / フォルダ / プロジェクトに適用する仕組み。IAM が「許可」、組織ポリシーは「禁止 / 制限」。公式 OPS 概要

頻出 Constraint と落とし穴

Constraint	目的	注意点
`gcp.resourceLocations`	リージョン / マルチリージョンの許可リスト	新リージョン追加時は `in:asia-locations` 等の値グループの差分に注意
`iam.disableServiceAccountKeyCreation`	SA 鍵作成禁止	既存鍵には影響しない。鍵作成監視と組み合わせる
`iam.allowedPolicyMemberDomains`	許可ドメイン以外への IAM 付与禁止	`allUsers` / `allAuthenticatedUsers` も同時にブロックされる
`compute.vmExternalIpAccess`	外部 IP 割り当て制限	例外 VM はリスト or タグで明示。Cloud NAT 必須
`compute.requireOsLogin`	OS Login 強制	既存 SSH 鍵が無効化されるので段階展開
`compute.requireShieldedVm`	Shielded VM 強制	非対応 OS イメージで作成失敗するので互換性確認
`iam.automaticIamGrantsForDefaultServiceAccounts`	既定 SA への自動 Editor 付与を無効化	新規プロジェクトのみ。既存プロジェクトの既定 SA は別途修正
`gcp.restrictNonCmekServices`	CMEK でないサービス利用を禁止	サポートサービスのリスト指定が必要

Custom Organization Policy

yaml Cloud Storage バケットに `compliance` ラベルを必須化

name: "organizations/ORG_ID/customConstraints/custom.gcsRequiresComplianceLabel"
resourceTypes:
- storage.googleapis.com/Bucket
methodTypes:
- CREATE
- UPDATE
condition: "resource.labels.compliance != ''"
actionType: ALLOW
displayName: "GCS buckets must have compliance label"
description: "Buckets must declare a `compliance` label (pii / pci / public / internal)."

✅ 組織ポリシーの段階展開

新規 Constraint は Dry Run モードで違反件数を計測してから enforce
本番フォルダは段階的に enforce、例外プロジェクトは inheritFromParent: false で上書き
Custom Constraint は CEL 文法エラーで 全リクエストブロック のリスクあり → テスト必須

15. リスク・落とし穴総まとめ

🚨 試験頻出のリスクトピック

SA 鍵が GitHub にコミットされる：シークレットスキャン + 組織ポリシーで鍵作成禁止が標準
Workload Identity Federation の attribute-condition 未指定：全リポジトリ・全ブランチが SA を borrow 可能になる致命的設定ミス
既定 SA の Editor ロール残置：本番 VM が広範囲のリソースを変更できてしまう
Owner ロールの組織レベル付与：下位で Allow を狭めるのは不可、Deny で物理的に塞ぐしかない
Super Admin への SSO 強制：IdP 障害時にロックアウト。Super Admin は SSO 例外にする
Conditions 非対応サービスへの依存：Conditions が無視されて binding が常時有効になる
カスタム組織ポリシーの CEL バグ：全リクエストブロックでサービス停止
Tag に基づくアクセス制御の継承：Tag は親リソースから継承可能だが、複雑になりやすい

16. 設計チェックリスト

人間ユーザーは Cloud Identity または Workforce Identity Federation で集中管理
マシン認証で SA 鍵が選択肢にあれば再検討（Attached SA / Workload Identity Federation / Impersonation を先に検討）
Workload Identity Federation の Provider には 必ず attribute-condition を設定
IAM 付与は 個人ではなく Google グループ単位
事前定義ロールで足りない場合のみ カスタムロール、基本ロールは避ける
強力な権限は PAM で JIT、常時保有させない
監査ログ書き込み SA など重要 SA は Deny ポリシー で改変防止
組織ポリシーで iam.disableServiceAccountKeyCreation / iam.allowedPolicyMemberDomains / compute.vmExternalIpAccess を Enforce
Super Admin は break-glass 専用、複数人 / ハードウェアキー / SSO 例外
Policy Recommender / Analyzer を 四半期に一度 走らせて棚卸し

📚 関連リソース

Identity & Access Management公式ドキュメント深掘り