Google PCD: ID、認証、アプリケーションセキュリティ — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloud では、アイデンティティが新たな境界線となります。アプリケーションはプリンシパル（ユーザー、サービス）を認証し、データや API への最小権限アクセスを認可すると同時に、シークレット、キー、ソフトウェアサプライチェーンを保護しなければなりません。このセクションでは、Google Cloud IAM、最新の認証プロトコル、ネットワークと API の防御、暗号化、ロギング、およびレスポンスプロセスを組み合わせた、エンドツーエンドの設計と運用のプラクティスについて概説します。重点を置くのは、短命な認証情報、一元化されたポリシー、そしてフェイルセーフな多層防御です。

アイデンティティ、認証、アクセス制御

IAM ロールとサービスアカウント
- リソース階層（組織 > フォルダ > プロジェクト）を使用し、基本ロールよりも事前定義ロールを優先します。事前定義ロールの権限が広すぎる場合にのみ、カスタムロールの使用を検討します。
- ワークロードにはサービスアカウント (SA) を割り当てます。デフォルトの Compute Engine や App Engine の SA を再利用しないでください。ワークロードの境界ごとに 1 つの SA を使用することで、最小権限の原則と信頼のローテーションが簡素化されます。
- 最も狭いリソーススコープで最小限の権限セットを付与することにより、最小権限を徹底します。
- 権限借用: 人間、CI/CD、または他のサービスがキーを保存することなく一時的なアクセス権を取得できるように、Service Account Token Creator を介した短命な認証情報を優先します。
  - 呼び出し元のアイデンティティに、ターゲット SA に対する roles/iam.serviceAccountTokenCreator を付与します。
  - 例:

undefined

Workload Identity
- GKE: Workload Identity を使用して、Kubernetes サービスアカウントを Google サービスアカウントにバインドします。トークンは自動的にプロジェクションおよび交換され、JSON キーは不要です。
- 外部ワークロード: Workload Identity Federation を使用して、(例えば GitHub Actions やオンプレミスからの) OIDC/SAML 認証情報を、長命なキーを保存することなく Google アクセストークンと交換します。
障害モードとトレードオフ
- 広すぎる権限を持つロールや広いスコープでの権限付与は、ラテラルムーブメントにつながります。Token Creator の権限が不足していると、権限借用のフローがブロックされます。JSON キーファイルは、侵害時の影響範囲を拡大させます。
OAuth 2.0、OpenID Connect、Google Identity を使用したユーザー認証
- エンドユーザー認証には、Google を IdP (ID プロバイダー) とする OIDC、または企業の IdP を使用し、サーバーサイドで ID トークンを検証します。API アクセスには、適切なスコープを持つ OAuth 2.0 アクセストークンを使用します。
- トークンの検証: IdP の JWKs を使用して iss、aud、exp、iat、および署名を検証します。JWKs をキャッシュし、キーのローテーションを強制します。
- モバイル/SPA のバックエンドには、PKCE を伴う認可コードフローを優先します。インプリシットフローは避けてください。
- サービス間通信には、OAuth 2.0 サービスアカウント JWT フローまたは mTLS を使用し、静的な API キーは避けてください。
- 例 (gcloud によるトークン権限借用):

undefined

障害モード
- aud/iss を検証しないと、トークンコンフュージョン攻撃を許してしまいます。期限切れのトークンを受け入れたり、JWKs をローテーションしなかったりすると、リスクが増大します。モバイルアプリでリフレッシュトークンを使用すると、長命な認証情報が漏洩する危険性があります。
ブラウザアクセスのための Identity-Aware Proxy (IAP)
- Cloud Run、GKE、または Compute Engine 上の HTTP アプリの前面に IAP を配置し、認証ロジックを組み込むことなく利用します。アクセスには「IAP で保護されたウェブアプリユーザー」ロールを適用します。
- アプリは署名付きヘッダー (x-goog-iap-jwt-assertion) を受け取ります。この JWT を検証してユーザーのアイデンティティとメールアドレスを信頼します。認証に X-Forwarded-* ヘッダーを信頼してはいけません。
- よくある落とし穴: IAP を経由しないバイパスパスの存在、バックエンドファイアウォールの設定ミス、Cloud Load Balancing の整合性チェックなしでのクライアント IP ヘッダーの信頼。

シークレット、キー、暗号化

Secret Manager
- API キー、DB パスワード、Webhook シークレットは Secret Manager に保存します。バージョニング、IAM による制御、監査ログを活用します。
- アクセスパターン
  - 起動時に取得してメモリ内にキャッシュし、シークレットの変更シグナル（Pub/Sub 通知）に応じて更新します。
  - シークレットをイメージや環境変数に焼き込むことは避けてください。環境変数を使用する場合は、それらがログやクラッシュレポートにダンプされないように徹底します。
- ローテーション
  - Cloud Scheduler + Cloud Functions/Run で自動化し、新しいバージョンを作成し、依存コンポーネントを更新し、古いバージョンを非推奨にします。
  - 例:

undefined

障害モード
- リクエストごとに Secret Manager を過剰に呼び出すと、レイテンシが増加し、割り当てを使い果たすリスクがあります。roles/secretAccessor が不足していると、ランタイムで 403 エラーが発生します。
Cloud KMS とアプリケーションの暗号化
- エンベロープ暗号化を使用します。ローカルで生成されたデータ暗号化キー (DEK) がデータを暗号化し、Cloud KMS の顧客管理の暗号化キー (CMEK) がその DEK を暗号化します (KEK)。
- キーを定期的にローテーションし、再暗号化を計画します。書き込み時には「古いキーで復号し、新しいキーで暗号化」する方式を優先します。保存データ (at-rest data) の一括再暗号化ジョブはコストが高くなります。
- コンプライアンス要件がある場合は、サービス (BigQuery, GCS, Pub/Sub, Cloud SQL など) に対して CMEK を有効にします。KMS キーはデータと同じリージョンに保持します。
- CLI の例:
  - 暗号化:

undefined

- 復号:

undefined

実装エラーを避けるため、十分に検証された暗号ライブラリ (例: Tink) を使用します。
障害モード
- ロケーションの不一致は CMEK の使用を妨げます。リクエストごとの KMS 復号はレイテンシを追加するため、ローテーションを意識して DEK をメモリにキャッシュします。roles/cloudkms.cryptoKeyEncrypterDecrypter が不足していると 403 エラーが発生します。

サプライチェーンセキュリティ、ロギング、およびレスポンス

ソフトウェアサプライチェーンのセキュリティ
- アーティファクトは Artifact Registry に保存し、脆弱性スキャンを強制します。ポリシーの例外を追跡しつつ、高/クリティカルなCVEが検出された場合はビルドを失敗させます。
- 依存関係とベースイメージをピン留めし、「latest」タグの使用を避けます。SBOMを生成・検証します。Binary Authorization を使用して、デプロイ前に署名付きイメージを要求します。
- Cosign でイメージに署名し、来歴（provenance）を記録します。SLSAに準拠したビルドプラクティスを採用します。CIには Workload Identity Federation を使用して、JSONキーを排除します。
- 障害モード
  - ピン留めされていない依存関係が脆弱なリリースを取り込んでしまう。来歴の記録をスキップすると、イメージの改ざんが可能になる。CIログにレジストリの認証情報やサービスアカウントキーを保存すると、シークレットが漏洩する。
セキュリティのロギングとモニタリング
- 重要なプロジェクトやサービスに対して、管理アクティビティ監査ログとデータアクセス監査ログを有効にします。ログはアクセスが制限された専用のプロジェクトにルーティングします。
- 認証失敗、権限拒否、ポリシー評価エラーに対して Cloud Logging メトリクスを作成し、Cloud Monitoring 経由でアラートを送信します。
- 例（カスタムカウンターメトリクスのアイデア）：/api/* に対する401/403エラー率をカウントし、ベースラインからの逸脱時にアラートを送信します。
- 脅威のトリアージと修復
  - Security Command Center を使用して検出結果を集約し、主要なシナリオ（キーの漏洩、ブルートフォース攻撃、IAMの異常な変更）に対するプレイブックを作成します。
  - 一般的な修復措置（トークンの失効、キーの無効化、シークレットのローテーション、サービスアカウントの隔離）を自動化します。
- プライバシーを意識した設計
  - PII（個人を特定できる情報）を最小限に抑え、可能な限りトークン化します。ログから機密値を墨消しし、分類には Cloud DLP を使用します。最小保持期間ポリシーとリージョンストレージポリシーを適用します。
- 障害モード
  - データアクセスログを無効にすると、データ引き出しの検知ができなくなります。カーディナリティの高いラベルはコストを急増させます。シークレットをロギングすると、永続的な漏洩リスクを生み出します。

実践的な問題シナリオ

Acme Retail社は、Cloud Run上にマルチテナントの分析ポータルを構築します。構成はReactのフロントエンド、PythonのAPI、テナントごとのBigQueryデータセットです。要件には、従業員と顧客向けのSSO、テナント分離、シークレットとキーの管理、プライベートなデータベースアクセス、WAFとレート制限、そして長期的なキーを使用しない強力なCI/CD体制が含まれます。

アプローチ：

IDの確立と最小権限

マイクロサービスごとに専用のGoogleサービスアカウント（api-sa, ingest-sa）を作成します。プロジェクトまたはデータセットのスコープで最小権限のロール（例：テナントのデータセットに対する roles/bigquery.dataEditor）を付与します。
理由：サービスごとのSAは影響範囲（blast radius）を限定し、ローテーションを簡素化します。スコープを絞ったロールはラテラルムーブメント（水平移動）のリスクを低減します。

CI/CDに Workload Identity Federation を使用

GitHub Actions OIDCを設定し、roles/iam.workloadIdentityUser と roles/iam.serviceAccountTokenCreator を介して deployer-sa を借用（impersonate）できるようにします。借用したトークンを使用してCloud Runにデプロイします。
理由：CIからJSONキーを排除できます。短命な認証情報は盗難リスクを低減します。

フロントエンドとユーザー認証

Cloud Runサービスの前段にあるHTTPSロードバランサでIAPを設定します。従業員向けにはGoogleをIdPとして、顧客のIdPとはフェデレーションを介して統合します。「IAP-secured Web App User」ロールを使用して、認可されたグループにアクセスを制限します。
理由：ブラウザアプリの認証を一元化できます。サービス内に認証ロジックが不要になり、SSOをサポートします。

APIでのIAP IDの検証

APIで x-goog-iap-jwt-assertion ヘッダーを検証します。tenant_id クレーム（グループまたはカスタムクレームからマッピング）の存在を強制します。
理由：IAPから強力なID保証が得られます。各リクエストにテナントコンテキストを埋め込むことで、下流での一貫した認可を保証します。

テナントを意識した認可の実装

テナントごとのポリシーを保存し、ユーザーをロール（viewer, analyst, admin）にマッピングします。各リクエストで、ロールとABACの条件（tenant_idの一致、機能フラグ）をチェックします。
理由：RBACのシンプルさとABACの柔軟性を組み合わせます。テナントのスコープを強制することでIDOR（Insecure Direct Object Reference）を排除します。

シークレットとデータベースアクセス

DBのパスワードやサードパーティAPIのトークンをSecret Managerに保存し、APIのSAにのみ roles/secretmanager.secretAccessor ロールを付与します。起動時にシークレットにアクセスし、Pub/Subのローテーション通知で更新します。
理由：認証情報をハードコーディングしません。アクセスは監査可能で、再起動なしでタイムリーなローテーションが可能です。

データ暗号化とCMEK

環境ごとにCloud KMSのキーリングとキーを作成します。BigQueryデータセットとCloud StorageバケットでCMEKを有効にします。アプリケーションで保存する機密性の高いブロブには、エンベロープ暗号化を使用します。
理由：顧客管理の暗号鍵（CMEK）はコンプライアンス要件を満たし、職務の分離を提供します。

プライベート接続とサービス境界

Cloud SQLのプライベートIPにはプライベートサービスアクセスを使用します。BigQueryとGCSをホストするプロジェクトに対してVPC Service Controlsの境界を作成し、企業の管理者アクセス用にアクセスコンテキストポリシーを追加します。
理由：パブリックな下り（egress）パスを排除し、データ引き出しのリスクを低減します。

APIセキュリティ、レート制限、CORS、CSRF

外部HTTP(S) LBに、WAFのマネージドルールとレート制限を含むCloud Armorセキュリティポリシーを適用します。パートナーIPの許可リストを調整します。APIには厳格なCORS（明示的なオリジン）を設定し、Authorization bearerトークンを使用します。クッキーは使用しません。
理由：OWASP Top 10や不正利用を緩和します。オリジンをまたいだ認証情報の漏洩を防ぎ、クッキーを使用しないことでCSRFを回避します。

サプライチェーンの強化

イメージはArtifact Registryに保存します。脆弱性スキャンを有効にし、クリティカルなCVEが検出された場合はビルドを失敗させます。Cosignでイメージに署名し、本番環境ではAcme社の署名を要求するようBinary Authorizationを強制します。
理由：未検証のアーティファクトの実行を防ぎ、来歴（provenance）を維持します。

ロギング、モニタリング、アラート

監査ログを有効にし、一元管理されたプロジェクトにルーティングします。401/403の急増、BigQueryからのpermissionDenied、Secret Managerへのアクセスについて、ログベースのメトリクスを作成します。異常を検知したらアラートを送信し、パブリックエンドポイントに対してCloud Monitoringの稼働時間チェックを設定します。
理由：認証の失敗や不正利用を早期に検知し、可用性を監視します。