ACE 試験対策Section 4 / ~20%2025年6月版 試験ガイド対応
Section 4: Configuring
Access and Security
IAMポリシーの設計・ロール管理・サービスアカウントのライフサイクル・権限借用・Workload Identity Federationまで、アクセスとセキュリティの全領域を完全網羅。中級者〜上級者向け実践ガイド。
~20%試験配点比率
2主要セクション(4.1 / 4.2)
8+試験ガイド記載の出題トピック
30+公式ドキュメントリンク
基礎-AGoogle Cloudセキュリティモデルの核心
Section 4 が問うのは「誰が何にアクセスできるか」を設計・実装・管理する能力です。単純な暗記ではなく、なぜその設計が安全なのかを理解していることが問われます。
3つの基本原則
| 原則 | 説明 | Google Cloud での実装 |
|---|---|---|
| 最小特権(Least Privilege) | 必要な権限だけを、必要な期間だけ付与する | 事前定義ロール・IAM Conditions |
| 職務分掌(Separation of Duties) | 一人がすべての操作を単独で実行できない設計 | 承認フロー・PAM(Privileged Access Manager) |
| 深層防御(Defense in Depth) | 複数のセキュリティ層を重ねる | IAM + VPC Firewall + Cloud Armor + KMS |
IAM の構成要素
▶ IAM の 3 要素とポリシーの関係
~5–6問
4.1-AIAMポリシーの表示と作成
IAMポリシーの構造(JSON)
version: 3 が必要な理由: IAM Conditions(条件付きバインディング)を使う場合は必ずポリシーバージョンを
3 に設定します。バージョン 1 では条件を付与できません。{
"version": 3,
"bindings": [
{
"role": "roles/storage.objectViewer",
"members": [
"user:alice@example.com",
"group:dev-team@example.com",
"serviceAccount:my-app@project.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.instanceAdmin.v1",
"members": ["user:bob@example.com"],
"condition": {
"title": "Business Hours Only",
"expression": "request.time.getHours('Asia/Tokyo') >= 9 && request.time.getHours('Asia/Tokyo') < 18"
}
}
],
"etag": "BwXxyzAbcde="
}IAMポリシーの表示コマンド
# プロジェクトの IAM ポリシーを確認gcloud projects get-iam-policy PROJECT_ID # JSON 形式で出力(スクリプト処理向け)gcloud projects get-iam-policy PROJECT_ID --format=json # フォルダの IAM ポリシーを確認gcloud resource-manager folders get-iam-policy FOLDER_ID # 組織の IAM ポリシーを確認gcloud organizations get-iam-policy ORG_ID # Cloud Storage バケットの IAM ポリシーを確認gcloud storage buckets get-iam-policy gs://my-bucket # Cloud Run サービスの IAM ポリシーを確認gcloud run services get-iam-policy SERVICE_NAME --region=REGIONIAMポリシーの作成・変更コマンド
# ユーザーにロールを付与gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/compute.instanceAdmin.v1" # グループにロールを付与(推奨)gcloud projects add-iam-policy-binding PROJECT_ID \ --member="group:dev-team@example.com" \ --role="roles/run.developer" # 条件付きロールバインディング(IAM Conditions)gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:contractor@example.com" \ --role="roles/viewer" \ --condition='title=Temporary Access,expression=request.time < timestamp("2025-12-31T23:59:59Z")' # ロールを削除gcloud projects remove-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/compute.instanceAdmin.v1" # ポリシーファイルを使った一括更新(注意:完全上書き)gcloud projects set-iam-policy PROJECT_ID policy.jsonset-iam-policy の危険性:
add/remove-iam-policy-binding は個別バインディングを変更しますが、set-iam-policy はポリシー全体を上書きします。必ず現在のポリシーを取得してから編集し適用してください。Deny Policy(拒否ポリシー)
Deny Policy は Allow Policy より優先されます。特定の権限を明示的に拒否でき、組織全体の重要リソースを保護するのに効果的です。
# 拒否ポリシーの確認gcloud iam policies list \ --attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID \ --kind=denypolicies # 拒否ポリシーの作成(JSON ファイルを使用)gcloud iam policies create POLICY_ID \ --attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID \ --kind=denypolicies \ --policy-file=deny-policy.json1
個人ではなくグループにロールを付与する — メンバー変更時にIAMを変更せず済む
2
add/remove-binding を優先・set-policy は避ける — 競合状態と上書きを防止
3
IAM Conditionsで有効期限・時間帯・リソースパスを制限 — 永続的な過剰権限のリスクを排除
4
Deny Policyで重要リソースへの危険な操作を禁止 — Allow Policyより優先される強力な保護
4.1-B組織階層でのロール付与と継承
▶ IAM ポリシーの継承メカニズム
試験最頻出の落とし穴: 有効な権限 = すべての祖先レベルで付与されたポリシーの和集合(Union)。下位で削除しても上位の継承は無効にならない。上位の許可を制限したい場合は Deny Policy を使用する。
各階層でのロール付与コマンド
# === 組織レベル ===gcloud organizations add-iam-policy-binding ORG_ID \ --member="group:security-team@example.com" \ --role="roles/securitycenter.admin" # === フォルダレベル ===gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \ --member="group:dev-team@example.com" \ --role="roles/editor" # === プロジェクトレベル ===gcloud projects add-iam-policy-binding PROJECT_ID \ --member="user:alice@example.com" \ --role="roles/run.developer" # === リソースレベル(Cloud Storage バケット)===gcloud storage buckets add-iam-policy-binding gs://my-bucket \ --member="serviceAccount:app@project.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # === リソースレベル(Cloud Run サービス)===gcloud run services add-iam-policy-binding SERVICE_NAME \ --region=asia-northeast1 \ --member="serviceAccount:caller@project.iam.gserviceaccount.com" \ --role="roles/run.invoker"1
Organization レベルのロール付与は最小限に — 影響範囲が最大のため慎重に管理
2
複数プロジェクト共通の権限は親フォルダで付与 — 個別設定の手間と漏れを防止
3
環境(dev/prod)は別フォルダ・別プロジェクトで分離 — 誤操作のリスクを低減
4
同一信頼境界のリソースを同一プロジェクトにまとめる — セキュリティポリシーの一貫性を確保
4.1-Cロール種別の管理とカスタムIAMロールの定義
▶ ロール選択フローチャート
試験頻出の事前定義ロール一覧
| サービス | ロール | 権限概要 |
|---|---|---|
| Compute Engine | roles/compute.admin | Compute Engine の完全管理 |
roles/compute.instanceAdmin.v1 | VM の作成・管理(ネットワーク変更は不可) | |
roles/compute.osLogin | OS Login での SSH 接続(sudo なし) | |
roles/compute.osAdminLogin | OS Login での SSH 接続(sudo あり) | |
| Cloud Storage | roles/storage.admin | バケット・オブジェクトの完全管理 |
roles/storage.objectAdmin | オブジェクトの完全管理(バケット設定変更は不可) | |
roles/storage.objectCreator | オブジェクトのアップロードのみ | |
roles/storage.objectViewer | オブジェクトの閲覧のみ | |
| IAM / SA | roles/iam.serviceAccountAdmin | SA の作成・管理 |
roles/iam.serviceAccountUser | SA を VM 等にアタッチする権限(actAs) | |
roles/iam.serviceAccountTokenCreator | SA の短期トークン生成(権限借用) | |
roles/iam.workloadIdentityUser | Workload Identity 経由での SA へのアクセス | |
roles/iam.roleAdmin | カスタムロールの作成・管理 | |
| Secret Manager | roles/secretmanager.secretAccessor | シークレット値の読み取りのみ |
| Cloud Run | roles/run.developer | デプロイ・設定変更 |
roles/run.invoker | Cloud Run へのリクエスト送信 |
カスタムロールの作成
# YAML でカスタムロールを定義cat > custom-deployer-role.yaml <<EOFtitle: "Cloud Run Deployer"description: "Cloud Run へのデプロイと Artifact Registry の読み取りのみ"stage: "GA"includedPermissions: - run.services.create - run.services.update - run.services.get - run.services.list - artifactregistry.repositories.get - artifactregistry.tags.get - storage.objects.get - storage.objects.listEOF # プロジェクトレベルでカスタムロールを作成gcloud iam roles create cloudRunDeployer \ --project=PROJECT_ID \ --file=custom-deployer-role.yaml # 組織レベルでカスタムロールを作成(組織全体で再利用可能)gcloud iam roles create cloudRunDeployer \ --organization=ORG_ID \ --file=custom-deployer-role.yaml # カスタムロールの一覧確認gcloud iam roles list --project=PROJECT_ID --filter="name~customRoles" # 権限を追加gcloud iam roles update cloudRunDeployer \ --project=PROJECT_ID \ --add-permissions=run.routes.get # 無効化(削除前のステップ)gcloud iam roles update cloudRunDeployer \ --project=PROJECT_ID \ --stage=DISABLED # 削除gcloud iam roles delete cloudRunDeployer --project=PROJECT_IDカスタムロールのライフサイクル
▶ カスタムロールのステージ遷移
1
本番環境での基本ロール(Editor/Owner)使用を禁止 — 過剰権限リスクを排除
2
事前定義ロールを優先しカスタムロールは最小限に — 管理コストが高いため
3
ALPHA → BETA → GA の段階を踏む — 予期せぬ権限の付与を防止
4
組織レベルのカスタムロールはプロジェクト間で再利用 — 重複した定義の乱立を防止
~5–6問
4.2-Aサービスアカウントの作成と基本概念
▶ サービスアカウントの二重の役割
サービスアカウントの種類
| 種類 | 作成者 | 命名規則 | 注意事項 |
|---|---|---|---|
| ユーザー管理 SA | ユーザーが作成 | NAME@PROJECT_ID.iam.gserviceaccount.com | アプリ・CI/CD・GKE Pod 用(推奨) |
| デフォルト SA | Google が自動作成 | PROJECT_NUMBER-compute@developer.gserviceaccount.com | 過剰権限のため本番では非推奨 |
| Google 管理 SA | Google が内部で使用 | PROJECT_ID@cloudservices.gserviceaccount.com | 直接操作は不可 |
デフォルトSAの危険性: Compute Engine と App Engine のデフォルト SA は
roles/editor に近い過剰な権限を持ちます。本番環境では専用の最小権限 SA を作成して使用してください。# SA の作成(用途が分かる命名規則を使う)gcloud iam service-accounts create vm-web-server \ --display-name="Web Server VM Service Account" \ --description="Prod web server VM - reads GCS, writes Firestore" # Workload Identity Federation 用(wlif- プレフィックス)gcloud iam service-accounts create wlif-github-deploy \ --display-name="GitHub Actions Deployment SA" # GKE Workload Identity 用(wlifgke- プレフィックス)gcloud iam service-accounts create wlifgke-api-backend \ --display-name="GKE API Backend Service Account" # SA の一覧確認gcloud iam service-accounts list # SA の無効化(削除ではなく一時停止)gcloud iam service-accounts disable \ vm-web-server@PROJECT_ID.iam.gserviceaccount.com # SA の削除(30日間は復元可能)gcloud iam service-accounts delete \ vm-web-server@PROJECT_ID.iam.gserviceaccount.com # SA の復元(削除後30日以内)gcloud iam service-accounts undelete SA_UNIQUE_ID1
1つのSAは1アプリ/1目的のみ — 最小権限の原則と追跡可能性を確保
2
デフォルト SA を本番で使わない — 専用の最小権限 SA を作成する
3
命名規則を統一する(vm- / wlif- / wlifgke-) — 一目で用途を識別できる
4
不要になったSAは無効化→削除の順で対処 — 30日間の復元猶予期間を活用
4.2-B最小権限でのIAMポリシー利用
▶ SA への権限付与の意思決定フロー
Policy Analyzer: 特定のリソースにアクセスできる全 Identity を特定したり、特定の権限を誰が持っているかを調査できます。過剰権限の検出や、インシデント発生時の影響範囲把握に有効です。
# SA に必要な権限だけを付与する例 # Cloud Storage への読み取りのみ(プロジェクトレベル)gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # BigQuery への読み取りのみgcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/bigquery.dataViewer" # Secret Manager のシークレット読み取りのみgcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/secretmanager.secretAccessor" # より細かい制御:特定のバケットのみにアクセスを制限(リソースレベル)gcloud storage buckets add-iam-policy-binding gs://specific-bucket \ --member="serviceAccount:my-app@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # Policy Analyzer: 特定リソースにアクセスできる全 Identity を分析gcloud asset analyze-iam-policy \ --organization=ORG_ID \ --full-resource-name="//storage.googleapis.com/projects/_/buckets/my-bucket" # Policy Analyzer: 特定の権限を持つ Principal を検索gcloud asset analyze-iam-policy \ --project=PROJECT_ID \ --permissions="storage.objects.delete"1
roles/editor / roles/owner を SA に付与しない — 過剰権限リスクの根本的排除
2
プロジェクトレベルよりリソースレベルの付与を優先 — 影響範囲を最小限に絞る
3
Policy Recommender で不要な権限を定期的に削除 — 権限のクリープ(肥大化)を防止
4
Policy Analyzer でアクセス権限を定期的に棚卸し — 意図しないアクセスを早期発見
4.2-Cリソースへのサービスアカウント割り当て
スコープ(Scope)の理解
| スコープ | 説明 | 推奨度 |
|---|---|---|
cloud-platform | すべての GCP API へのアクセスを SA の IAM で制御 | ✅ 推奨 |
| 個別スコープ(例: storage.read_only) | 特定の API のみ(旧来の方法) | ⚠️ 非推奨 |
default | 一部の API のみデフォルトで有効 | ❌ 非推奨 |
なぜ cloud-platform スコープが推奨されるのか? スコープではなく SA の IAM ロールで権限を制御することで、コンソールや gcloud からの権限変更が即座に反映されます。
# VM 作成時に SA をアタッチ(推奨設定)gcloud compute instances create my-vm \ --zone=asia-northeast1-a \ --machine-type=n2-standard-4 \ --service-account=vm-web-server@PROJECT_ID.iam.gserviceaccount.com \ --scopes=cloud-platform # 既存 VM の SA を変更(VM を停止してから実行)gcloud compute instances stop my-vm --zone=asia-northeast1-agcloud compute instances set-service-account my-vm \ --zone=asia-northeast1-a \ --service-account=new-sa@PROJECT_ID.iam.gserviceaccount.com \ --scopes=cloud-platformgcloud compute instances start my-vm --zone=asia-northeast1-a # Cloud Run サービスに SA をアタッチgcloud run deploy my-service \ --image=gcr.io/PROJECT_ID/my-app:latest \ --region=asia-northeast1 \ --service-account=wlif-cloudrun@PROJECT_ID.iam.gserviceaccount.com # Cloud Functions に SA をアタッチgcloud functions deploy my-function \ --gen2 --runtime=python312 --trigger-http \ --service-account=func-sa@PROJECT_ID.iam.gserviceaccount.com \ --region=asia-northeast14.2-DサービスアカウントのIAM権限管理(actAs権限)
SA の IAM 権限管理には2つの側面があります。①SA が GCP リソースにアクセスするための権限と、②誰がこのSAを使えるか(SA自体に対するIAM設定)です。
▶ actAs 権限の重要性
# SA への actAs 権限の付与(SA を VM にアタッチできるようにする)gcloud iam service-accounts add-iam-policy-binding \ privileged-sa@PROJECT_ID.iam.gserviceaccount.com \ --member="user:alice@example.com" \ --role="roles/iam.serviceAccountUser" # SA の IAM ポリシー(誰がこの SA を使えるか)を確認gcloud iam service-accounts get-iam-policy \ privileged-sa@PROJECT_ID.iam.gserviceaccount.com # SA の IAM ポリシーを更新gcloud iam service-accounts set-iam-policy \ privileged-sa@PROJECT_ID.iam.gserviceaccount.com \ policy.json4.2-Eサービスアカウント権限借用(Impersonation)の管理
▶ 権限借用のシーケンス
通常の権限付与 vs 権限借用 vs PAM
| 方法 | 権限の永続性 | 監査性 | リスク |
|---|---|---|---|
| 直接ロール付与 | 永続的 | 操作ログのみ | 高(常に特権を持つ) |
| SA 権限借用 | 一時的(最大1時間) | 誰がいつ借用したかが明確 | 低(時間制限あり) |
| PAM(Privileged Access Manager) | 承認制・時間制限 | 完全な監査証跡 | 最低 |
# Step 1: privileged-sa に必要な権限を付与gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:privileged-sa@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.admin" # Step 2: alice に SA のトークン作成権限を付与gcloud iam service-accounts add-iam-policy-binding \ privileged-sa@PROJECT_ID.iam.gserviceaccount.com \ --member="user:alice@example.com" \ --role="roles/iam.serviceAccountTokenCreator" # Step 3a: alice が権限借用で操作(gcloud コマンド)gcloud storage ls gs://my-bucket \ --impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com # Step 3b: 一時的なアクセストークンを生成gcloud auth print-access-token \ --impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com # Step 3c: gcloud CLI のデフォルトで権限借用を設定gcloud config set auth/impersonate_service_account \ privileged-sa@PROJECT_ID.iam.gserviceaccount.com # 設定を解除gcloud config unset auth/impersonate_service_account # 権限借用のイベントを Cloud Logging で検索gcloud logging read \ 'protoPayload.methodName="GenerateAccessToken" AND protoPayload.request.name=~"privileged-sa"' \ --limit=10 --format=json1
特権操作は直接ロール付与ではなくSA権限借用を使う — 一時的な権限 + 詳細な監査ログ
2
TokenCreator はプロジェクトレベルではなくSAリソースレベルで付与 — 影響範囲を特定SAに限定
3
PAMで承認フローを組み込む — 承認なしに特権SAを借用できないようにする
4.2-F短期クレデンシャルの作成と管理
| 種類 | 用途 | 有効期限 | API |
|---|---|---|---|
| OAuth 2.0 アクセストークン | Google API 呼び出し | デフォルト1時間(最大12時間) | generateAccessToken |
| OIDC ID トークン | Cloud Run / API Gateway の認証 | 1時間 | generateIdToken |
| 自己署名 JWT | 一部の Google API 認証 | 1時間 | signJwt |
| 自己署名バイナリオブジェクト | カスタム認証 | 任意 | signBlob |
# OAuth 2.0 アクセストークンの生成(権限借用)gcloud auth print-access-token \ --impersonate-service-account=my-sa@PROJECT_ID.iam.gserviceaccount.com # OIDC ID トークンの生成(Cloud Run のエンドポイント向け)gcloud auth print-identity-token \ --impersonate-service-account=my-sa@PROJECT_ID.iam.gserviceaccount.com \ --audiences=https://my-cloud-run-service-url # REST API を使ってアクセストークンを生成curl -X POST \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ -d '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \ "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/my-sa@PROJECT_ID.iam.gserviceaccount.com:generateAccessToken" # 委任チェーンでトークンを生成(複数の SA を経由)gcloud auth print-access-token \ --impersonate-service-account=sa1@PROJECT.iam.gserviceaccount.com,sa2@PROJECT.iam.gserviceaccount.com,sa3@PROJECT.iam.gserviceaccount.com自己権限借用(Self-Impersonation)は禁止: SA の短期クレデンシャルを使って、同じ SA の新しいアクセストークンを生成することは禁止されています。盗まれたトークンを無限に更新する攻撃を防ぐためです。
委任チェーン(Delegation Chain)
複数の SA を経由してクレデンシャルを生成するパターン。SA-1 が SA-2 の TokenCreator 権限を持ち、SA-2 が SA-3 の TokenCreator 権限を持つことで権限を段階的に移譲できます。ただし複雑さが増すと監査が困難になるため最小限に留めること。
▶ 委任チェーンのアーキテクチャ
1
SA の静的 JSON キーより短期クレデンシャルを優先 — 自動失効するため漏洩リスクが低い
2
アクセストークンの有効期限を最小限に設定 — デフォルト1時間を必要に応じて短縮
3
OIDC ID トークンは特定のオーディエンスに限定 — 他のサービスへの不正な転用を防止
4
委任チェーンは複雑になるため最小限に — 複雑さが増すと監査が困難になる
4.2-GGKEアプリケーションでのサービスアカウント利用
▶ Workload Identity Federation for GKE のアーキテクチャ
✕ アンチパターン:JSON キーを Secret にマウント
SA の JSON キーを Kubernetes Secret に保存してPodにマウント。キー漏洩リスク・ローテーション管理の煩雑さが問題。絶対に使わないこと。
✓ 推奨:Workload Identity Federation for GKE
KSA と GSA を紐付けるだけ。JSON キー不要。メタデータサーバーから自動的に短期トークンを取得。GKE Autopilot では自動有効化。
# Step 1: GKE クラスタで Workload Identity を有効化gcloud container clusters update my-cluster \ --workload-pool=PROJECT_ID.svc.id.goog \ --region=asia-northeast1# ※ GKE Autopilot では自動的に有効化される # Step 2: GSA を作成gcloud iam service-accounts create wlifgke-api-backend \ --display-name="GKE API Backend GSA" # Step 3: GSA に必要な権限を付与gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer" # Step 4: KSA が GSA を使えるように IAM を設定gcloud iam service-accounts add-iam-policy-binding \ wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" # Step 5: KSA を作成してアノテーションを付けるkubectl create serviceaccount my-ksa --namespace my-namespacekubectl annotate serviceaccount my-ksa \ --namespace my-namespace \ iam.gke.io/gcp-service-account=wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.comKubernetes マニフェスト
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-ksa
namespace: my-namespace
annotations:
iam.gke.io/gcp-service-account: wlifgke-api-backend@PROJECT_ID.iam.gserviceaccount.com
---
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
serviceAccountName: my-ksa # ← KSA を指定するだけ(JSON キー不要)
containers:
- name: my-container
image: gcr.io/PROJECT_ID/my-app:latest
# GOOGLE_APPLICATION_CREDENTIALS の設定不要!
# アプリは自動的に Workload Identity を使用する1
JSON キーは絶対に使わずWorkload Identityを使用 — キー漏洩リスクを根本から排除
2
GKE Autopilotを使うとWorkload Identityが自動有効 — 設定漏れを防止
3
Namespace単位・Pod単位でKSAを分離 — 最小権限の原則をコンテナレベルで適用
4
GSAの命名はwlifgke-プレフィックスを付ける — Workload Identity用SAだと一目で分かる
4.2-HWorkload Identity Federation のプロビジョニング重要
▶ Workload Identity Federation の全体フロー
GitHub Actions との設定(最もよく使われるパターン)
# Step 1: Workload Identity Pool を作成gcloud iam workload-identity-pools create github-pool \ --location=global \ --display-name="GitHub Actions Pool" \ --description="GitHub Actions Workload Identity Pool" # Step 2: GitHub の OIDC Provider を登録gcloud iam workload-identity-pools providers create-oidc github-provider \ --location=global \ --workload-identity-pool=github-pool \ --display-name="GitHub OIDC Provider" \ --issuer-uri="https://token.actions.githubusercontent.com" \ --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.actor=assertion.actor" \ --attribute-condition="assertion.repository_owner == 'my-org'" # Step 3: GSA を作成gcloud iam service-accounts create wlif-github-deploy \ --display-name="GitHub Actions Deployment SA" # Step 4: GSA に必要な権限を付与gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/run.developer" # Step 5: Workload Identity Pool が GSA を権限借用できるように設定WORKLOAD_IDENTITY_POOL_ID=$(gcloud iam workload-identity-pools describe github-pool \ --location=global --format="value(name)") gcloud iam service-accounts add-iam-policy-binding \ wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com \ --role="roles/iam.workloadIdentityUser" \ --member="principalSet://iam.googleapis.com/\${WORKLOAD_IDENTITY_POOL_ID}/attribute.repository/my-org/my-repo"GitHub Actions ワークフロー(SA キー不要)
name: Deploy to Cloud Run
on:
push:
branches: [main]
permissions:
contents: read
id-token: write # OIDC トークンの生成を許可(必須)
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# Workload Identity Federation で認証(SA キー不要!)
- id: auth
uses: google-github-actions/auth@v2
with:
workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
service_account: 'wlif-github-deploy@PROJECT_ID.iam.gserviceaccount.com'
- name: Deploy to Cloud Run
run: |
gcloud run deploy my-service \
--image=gcr.io/PROJECT_ID/my-app:${{ github.sha }} \
--region=asia-northeast1セキュリティ強化のための attribute-condition
# GitHub Actions: 特定の Organization のリポジトリのみ許可--attribute-condition="assertion.repository_owner == 'my-org'" # GitHub Actions: 特定のリポジトリのみ許可(より厳密)--attribute-condition="assertion.repository == 'my-org/my-repo'" # AWS: 特定の IAM ロールのみ許可--attribute-condition="attribute.aws_role == 'arn:aws:sts::ACCOUNT:assumed-role/ROLE'"AWS との設定例
AWS 用の WIF 設定コマンドの例です。AWS アカウントIDを指定して Provider を作成し、AWS IAM ロールの ARN を
attribute-condition でバインドします。# AWS 用 Workload Identity Pool を作成gcloud iam workload-identity-pools create aws-pool \ --location=global \ --display-name="AWS Pool" \ --description="AWS Workload Identity Pool" # AWS 用 Workload Identity Pool Provider を作成gcloud iam workload-identity-pools providers create-aws aws-provider \ --location=global \ --workload-identity-pool=aws-pool \ --display-name="AWS Provider" \ --account-id=AWS_ACCOUNT_ID # AWS EC2 インスタンスが Pool を使えるように設定gcloud iam service-accounts add-iam-policy-binding \ wlif-aws-app@PROJECT_ID.iam.gserviceaccount.com \ --role="roles/iam.workloadIdentityUser" \ --member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/aws-pool/attribute.aws_role/arn:aws:sts::AWS_ACCOUNT_ID:assumed-role/MY_ROLE_NAME"WIF のセキュリティリスクと対策
| リスク | 対策 |
|---|---|
| なりすまし(Spoofing) | attribute-condition で許可する外部 IdP を制限 |
| 権限昇格(Privilege Escalation) | Pool Provider に最小限の属性マッピングを設定 |
| 否認不可性の欠如 | Cloud Audit Logs で権限借用イベントを監視 |
1
SA JSON キーの代わりに常にWIFを使用 — キー管理不要・自動失効・より安全
2
attribute-conditionで外部IdPの範囲を必ず限定 — なりすまし攻撃を防止
3
環境(dev/staging/prod)ごとに別のPoolを作成 — 環境間の分離を確保
4
直接リソースアクセスをSA権限借用より優先 — シンプルで管理しやすい
5
GSAの命名にwlif-プレフィックスを使用 — WIF用SAだと一目で識別できる
6
Pool Providerは環境を表す意味のある名前にする — 管理・監査が容易になる
試験-0頻出シナリオ別 解法ガイド(選択問題対策)
以下は試験で実際に出題される典型的なシナリオです。問題文のキーワードから正解を導く思考プロセスを確認してください。
パターン①: ロール選択問題
❌ 典型的な誤答パターン
「Cloud Run へのデプロイと Artifact Registry の読み取りだけできればいい」
❌
❌
❌
❌
roles/editor(過剰:あらゆるリソースの変更権限を含む)❌
roles/owner(過剰:IAM管理権限まで含む)❌
roles/run.admin(過剰:Cloud Run 管理権限を含む)✓ 正解の考え方(最小権限)
必要な操作を正確に特定してロールを選択:
✅ Cloud Run へのデプロイ →
✅ Artifact Registry の読み取り →
この2つのロールの組み合わせが最小権限の正解。
✅ Cloud Run へのデプロイ →
roles/run.developer✅ Artifact Registry の読み取り →
roles/artifactregistry.readerこの2つのロールの組み合わせが最小権限の正解。
パターン②: GKEでのSA問題
❌ よくある誤答
「GKE 上のアプリが Cloud Storage バケットにアクセスする必要がある」
❌ SA の JSON キーを Kubernetes Secret に保存してマウントする
❌ Node の SA に直接権限を付与する(すべての Pod に影響)
❌ アプリコード内に認証情報をハードコードする
❌ SA の JSON キーを Kubernetes Secret に保存してマウントする
❌ Node の SA に直接権限を付与する(すべての Pod に影響)
❌ アプリコード内に認証情報をハードコードする
✓ 正解: Workload Identity Federation for GKE
KSA と GSA を紐付けてキーレス認証を実現:
✅ GKE クラスタで Workload Identity を有効化
✅ KSA に
✅ GSA に
✅ JSON キーは一切不要
✅ GKE クラスタで Workload Identity を有効化
✅ KSA に
iam.gke.io/gcp-service-account アノテーション付与✅ GSA に
roles/iam.workloadIdentityUser を設定✅ JSON キーは一切不要
パターン③: Workload Identity Federation 問題
❌ よくある誤答
「GitHub Actions から SA JSON キーを使わずに GCP リソースを操作したい」
❌ SA JSON キーを GitHub Secrets に保存する(SA キー自体が非推奨)
❌ ADC を GitHub Actions 環境に設定する(GKE 等のコンピュート外では使えない)
❌ SA JSON キーを GitHub Secrets に保存する(SA キー自体が非推奨)
❌ ADC を GitHub Actions 環境に設定する(GKE 等のコンピュート外では使えない)
✓ 正解: Workload Identity Federation
キーレス認証のセットアップ手順:
✅ 1. Workload Identity Pool を作成
✅ 2. GitHub の OIDC Provider を Pool に登録
✅ 3. GSA に
✅ 4. GitHub Actions で
✅ 5. permissions:
✅ 1. Workload Identity Pool を作成
✅ 2. GitHub の OIDC Provider を Pool に登録
✅ 3. GSA に
roles/iam.workloadIdentityUser を付与✅ 4. GitHub Actions で
google-github-actions/auth@v2 を使用✅ 5. permissions:
id-token: write を設定(必須)パターン④: 短期クレデンシャル・権限借用問題
❌ よくある誤答
「あるユーザーが特定の管理タスクを一時的に実行する必要がある。最小権限の原則に従い監査証跡を残すには?」
❌ ユーザーに直接
❌ SA の JSON キーを一時的に渡す(キー管理が困難)
❌ ユーザーに直接
roles/storage.admin を付与する(永続的で過剰)❌ SA の JSON キーを一時的に渡す(キー管理が困難)
✓ 正解: SA 権限借用(Impersonation)
一時的な特権アクセスのベストプラクティス:
✅ 特権 SA に
✅
✅ 操作は Cloud Audit Logs に自動記録
✅ 1時間でトークンが自動失効
✅ 特権 SA に
roles/iam.serviceAccountTokenCreator を付与✅
gcloud --impersonate-service-account フラグで操作✅ 操作は Cloud Audit Logs に自動記録
✅ 1時間でトークンが自動失効
試験-Aキーワード → 正解サービス・設定 即答マップ
🔑 Pattern A: IAMロール選択
「Cloud Run にデプロイのみ」roles/run.developer
「Cloud Runを呼び出すだけ」roles/run.invoker
「GCSのオブジェクト読み取りのみ」roles/storage.objectViewer
「SSH接続のみ(sudo不要)」roles/compute.osLogin
「SSH接続のみ(sudo必要)」roles/compute.osAdminLogin
「SAをVMにアタッチしたい」roles/iam.serviceAccountUser
「SAの権限を一時的に借用したい」roles/iam.serviceAccountTokenCreator
「シークレット値の読み取りのみ」roles/secretmanager.secretAccessor
🤖 Pattern B: SA認証方式選択
「GCE/GKE/Cloud RunからGCP APIへ」SAをリソースにアタッチ
「ローカル開発からGCP APIへ」ADC (gcloud auth app-default login)
「GitHub ActionsからGCP APIへ」Workload Identity Federation
「AWS EC2からGCP APIへ」Workload Identity Federation
「一時的に特権操作が必要」SA Impersonation
「承認フロー付きの特権アクセス」PAM (Privileged Access Manager)
「GKEのPodからGCP APIへ」Workload Identity for GKE
📜 Pattern C: IAMポリシー操作
「既存ポリシーにバインディングを追加」add-iam-policy-binding
「既存ポリシーからバインディングを削除」remove-iam-policy-binding
「ポリシー全体を置き換え(危険)」set-iam-policy
「特定の権限を強制的に拒否したい」Deny Policy
「有効期限付きの権限を付与したい」IAM Conditions
「不要な権限を自動検出したい」Policy Recommender
「特定リソースにアクセスできる全Identityを調査」Policy Analyzer
🚨 Pattern D: 引っかけに注意
「SA JSONキーは90日で自動失効」❌ 失効しない(無期限)
「下位で上位のロールを削除できる」❌ できない(和集合)
「基本ロールは開発環境なら使っていい」❌ 原則禁止
「GKEでのJSON Keyを K8s Secret で管理」❌ Workload Identity を使う
「カスタムロールはPJとOrg間で共有可能」❌ それぞれで独立管理
「自己権限借用でトークンを無限更新」❌ IAMが禁止している
「GKE Autopilotでは Workload Identity は任意設定」❌ 自動有効化される
「SA JSONキーをローテーションすれば安全」❌ WIF/短期クレデンシャルが最安全
罠-A試験で狙われる「よくある誤解」 10選
以下のパターンは試験で頻繁に出題される「引っかけ」です。全問正答できるまで繰り返し確認してください。
| よくある誤解(問題文に出る表現) | 正しい理解 |
|---|---|
| 「SA JSON キーをローテーションすれば安全」 | ✅ キー自体を使わない WIF / 短期クレデンシャルが最安全。ローテーションしても漏洩リスクは残る。 |
| 「SA キーは90日で自動失効する」 | ❌ SA キーはデフォルトで失効しない(無期限)。IAM Conditions などで明示的に期限設定が必要。 |
| 「基本ロール(Editor)は開発環境なら使っていい」 | ❌ 本番/開発問わず原則禁止。事前定義ロールを用途に合わせて使うこと。 |
| 「下位階層でロールを削除すれば上位の権限を制限できる」 | ❌ 下位で削除しても上位の継承は無効にならない(権限は和集合)。制限したい場合は Deny Policy を使う。 |
| 「カスタムロールはプロジェクトと組織レベルで共有できる」 | ✅ Organizationレベルで作成されたカスタムロールは、同じ組織内のプロジェクトやフォルダに直接バインドして割り当てることができます。別々に作成し直す必要はありません。組織階層全体で直接利用可能です。(※プロジェクトレベルで作成されたカスタムロールは、そのプロジェクト内でのみ利用可能です) |
| 「GKE Autopilot では Workload Identity は任意設定」 | ❌ GKE Autopilot では Workload Identity が自動有効化される。無効化できない。 |
| 「自己権限借用で短期トークンを無限に更新できる」 | ❌ IAM は自己権限借用を明示的に禁止している。盗まれたトークンを使って新しいトークンを取得する攻撃を防ぐため。 |
| 「roles/iam.serviceAccountUser があればSAの短期トークンを生成できる」 | ❌ 短期トークンの生成には roles/iam.serviceAccountTokenCreator が必要。serviceAccountUser は SA を VM 等にアタッチする (actAs) 権限。 |
| 「Node の SA に権限を付与すれば GKE の Pod から GCP API にアクセスできる」 | ⚠️ 技術的には可能だが全 Pod に影響するため非推奨。Pod 単位で KSA を使った Workload Identity を設定すること。 |
| 「set-iam-policy は add-iam-policy-binding より細かく制御できる」 | ❌ set-iam-policy はポリシー全体を上書きする危険なコマンド。個別バインディングには add/remove-iam-policy-binding を使う。 |
Check-A4.1 IAMの管理
Check-B4.2 サービスアカウントの管理
📝 AdviceSection 4 学習の最終アドバイス — 必ず押さえる5つのポイント
Section 4 はセキュリティ設計に関するドメインで、試験配点は約20%です。他のドメイン(GKE・Cloud Run・Terraform)とも深く連携しており、IAM・SA の知識は試験全体を通じて問われます。
①
SA JSON キーは使わない
→ WIF / 短期クレデンシャル / Workload Identity を使う。キーは漏洩・失効なし・管理困難のリスクを持つ。
→ WIF / 短期クレデンシャル / Workload Identity を使う。キーは漏洩・失効なし・管理困難のリスクを持つ。
②
基本ロール(Editor/Owner)は本番禁止
→ 必ず事前定義ロールを用途に合わせて選択。カスタムロールは管理コストを考慮して最小限に。
→ 必ず事前定義ロールを用途に合わせて選択。カスタムロールは管理コストを考慮して最小限に。
③
GKE での SA 利用は Workload Identity Federation for GKE 一択
→ KSA + GSA の紐付けでキーレス認証。GKE Autopilot では自動有効化。
→ KSA + GSA の紐付けでキーレス認証。GKE Autopilot では自動有効化。
④
権限借用(Impersonation)で一時的な特権アクセスを管理
→ TokenCreator ロールで短期トークンを取得。1時間で自動失効し、Cloud Audit Logs に記録される。
→ TokenCreator ロールで短期トークンを取得。1時間で自動失効し、Cloud Audit Logs に記録される。
⑤
Workload Identity Federation で外部ワークロードのキーレス認証
→ Pool + Provider + attribute-condition の3点セットで設定。GitHub Actions / AWS / オンプレミスを SA キーなしで認証。
→ Pool + Provider + attribute-condition の3点セットで設定。GitHub Actions / AWS / オンプレミスを SA キーなしで認証。
IAM の継承(和集合)・Deny Policy の優先・SA の二重の役割・自己権限借用の禁止は試験頻出の概念です。理屈から理解することで、初見の問題でも正解を導けます。
ACE 試験公式ページ認定資格の概要・登録
試験ガイド PDF(2025年6月版)出題範囲の詳細
IAM リソース階層とアクセス制御継承メカニズムの詳細
IAM ロールの概要ロール種別の説明
カスタムロールの作成と管理YAML定義とライフサイクル
Deny Policy 概要拒否ポリシーの仕組み
IAM Conditions条件付きバインディング
SA のベストプラクティス安全なSA管理の指針
SA の権限借用Impersonationの設定方法
短期クレデンシャルの作成トークン種別と生成方法
SA クレデンシャルの種類OAuth / OIDC / JWT
SA 権限のロールactAs権限の詳細
Workload Identity Federation 概要外部ワークロードの認証
WIF ベストプラクティスセキュアな設定の指針
Workload Identities for GKEGKEでのWIF設定
デプロイパイプラインでのSAベストプラクティスCI/CD向け設定
GKE Autopilot セキュリティ自動セキュリティ強化
組織レベルのアクセス制御Org IAM管理
IAM ベストプラクティスガイド実務向け設計指針