Google PCA: セキュリティ、コンプライアンス、データ保護アーキテクチャ — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

Google Cloudにおけるセキュリティ、コンプライアンス、データ保護は、責任共有と多層防御に基づいて構築されています。Googleが基盤となるインフラストラクチャを保護し、ユーザーは安全なアイデンティティ、ネットワーク、アプリケーション、データハンドリングを設計します。ゼロトラストを指導モデルとして採用します。つまり、ネットワークを暗黙的に信頼せず、アイデンティティとコンテキストを継続的に検証し、最小権限を厳格に適用します。侵害を前提とした設計：認証情報が漏洩し、エンドポイントが探索され、内部サービスが悪用される可能性を想定します。複数の統制（予防的、検知的、対応的）、強力な暗号化と鍵管理、堅牢なモニタリング、そして訓練されたインシデントレスポンスによってこれを補います。

トレードオフは避けられません。より強力な統制は、レイテンシ、運用上の複雑さ、コストを増大させる可能性があります。アーキテクチャでは、証明可能なコンプライアンスとフォレンジック対応能力を維持しつつ、リスクとユーザビリティおよびパフォーマンスを明確に比較検討する必要があります。

アイデンティティとアクセスアーキテクチャ

• 原則とモデル

  • デフォルトでの最小権限：タスクの完了に必要な最小限の権限セットを付与し、基本ロール（オーナー、編集者、閲覧者）よりも事前定義ロールまたはカスタムロールを優先します。
  • 職務の分離：ビルダー（CI/CD）、デプロイヤー、オペレーター、セキュリティ担当者でロールを分割します。緊急時には、強力な統制とロギングを備えたブレークグラスアカウントを使用します。
  • ゼロトラストの強制：コンテキストアウェアアクセスを使用して、ユーザー、デバイス、場所、リスクを検証し、強力なMFAを要求し、セッションコンテキストを継続的に評価します。
  • 組織のポリシーとIAM Deny：ガードレール（例：サービスアカウントキー作成の禁止、ドメイン共有の制限）をコード化し、Denyポリシーを使用して譲歩できない境界を強制します。

• IAMの実装とサービスアカウント戦略

  • 階層駆動のアクセスモデルを確立する：フォルダは事業部門や環境（本番、非本番）を反映し、プロジェクトは影響範囲と課金を分離し、サービスアカウント（SA）はワークロードを表します。
  • 1ワークロード、1サービスアカウント：関連のないサービス間でSAを共有することを避けます。権限をデプロイメントスコープ（プロジェクト）とリソーススコープに紐付けます。
  • Service Account ImpersonationとWorkload Identity Federationを介した短期的な認証情報を優先します。ユーザー管理のサービスアカウントキーは無効にします。避けられない場合は、使用を分離し、頻繁にローテーションし、監査ログで監視します。
  • Access Boundariesを使用して、権限借用されたSAがリクエスト時にアクセスできるものを制限し（例：GCSオブジェクトパスの制限）、権限の強いSAが悪用された場合でも影響範囲を封じ込めます。
  • 条件付きIAM：リソースレベルの条件（時間、IP、プリンシパルの属性）を適用してアクセスを制約します。例：企業のIP範囲から、かつ変更ウィンドウ中を除き、本番環境へのアクセスを禁止します。

• 障害モードとトレードオフ

  • 過剰な権限を持つロール（例：プロジェクトスコープの編集者）はリスクを増大させます。より粒度の細かいロールを優先し、ポリシーアナライザで検証します。
  • CI/CDやローカルスクリプトにおけるサービスアカウントキーの乱立は、一般的な侵害経路です。権限借用を使用する場合、一部のレガシーツールは適応が必要になる場合があります。
  • IAM Denyポリシーは強力ですが、トラブルシューティングが難しい場合があります。変更は、非本番環境で明示的なドライランを行ってステージングおよびテストします。

例（キーを作成しない権限借用）：

• gcloud auth print-access-token –impersonate-service-account=svc-ci@proj.iam.gserviceaccount.com

データ保護と暗号化

• Cloud KMSと鍵管理モデル
  • ネイティブな保存時の暗号化がデフォルトです。追加の制御が必要な場合は、BigQuery、Cloud Storage、Compute Engineディスク、Pub/Sub、GKE永続ボリュームなどのサービスで、顧客管理の暗号鍵（CMEK）を使用します。
  • 環境やデータドメインごとに鍵階層を設計します。ロケーションごとにキーリングを分け、アプリケーションやデータセットごとに鍵を分けることで、影響範囲（ブラスト半径）を限定します。
  • ローテーション：スケジュールされたローテーションを有効にし、アプリケーションのエンベロープ暗号化を使用して、古い鍵バージョンを段階的に非推奨にします。ローテーションの頻度を上げる前に、コンシューマーの互換性を検証します。
  • External Key Manager（EKM）とExternal Key Access（EKA）は、規制上の管理のために鍵をGoogle Cloudの外部に配置します。トレードオフとして、レイテンシの増加や外部HSMの可用性への依存が含まれます。縮退モードでの運用を計画してください。
  • CryptoKeyにはIAMの最小権限を適用します。アクセス証跡として鍵レベルの監査ログを使用します。

例（ローテーションありのCMEK）：

undefined

undefined

• アプリケーションレベルの暗号化

  • アプリケーション層で機密フィールドを暗号化するためにエンベロープ暗号化（例：Tink）を使用し、選択的なアクセスとテナントデータの分離を可能にします。テナントごとに鍵を派生させ、テナント間の影響を最小限に抑えます。
  • 改ざんやリプレイを防ぐために、完全性を検証します（AEAD）。

• Secret Managerとシークレットのライフサイクル

  • 認証情報、トークン、APIキーはバージョン管理されたシークレットとして保存し、イメージ、Git、インスタンスメタデータには決して保存しません。実行時のサービスアカウントに対して、シークレットまたはプロジェクトレベルでIAMを付与します。
  • ローテーション：Pub/SubをトリガーとするCloud Functions/Cloud Runを使用して自動化し、新しいバージョンを作成し、依存コンポーネントを更新し、古いバージョンを無効化します。長期間有効なDBパスワードは、IAMベースのデータベース認証や短期間有効なトークンに置き換えることが推奨されます。
  • 構成のセキュリティ：シークレットではない構成（ConfigMap、環境変数）をシークレットから分離します。ログやエラーメッセージでシークレットが漏洩するのを防ぎます。

例（新しいシークレットバージョンの追加）：

undefined

• コンピューティングの堅牢化とConfidential Computing
  • Shielded VMs：セキュアブート、vTPM、整合性モニタリングを有効にして、ブートキットやルートキットから保護します。組織のポリシーを介して強制し、CI/CDパイプラインで検証します。
  • Confidential VMs：デフォルトのメモリ暗号化により、最小限の構成変更で使用中のデータを保護します。高スループットで暗号化処理が重いワークロードに対するパフォーマンスへの影響を評価してください。
  • 堅牢化されたイメージ：Google最適化済みまたはCISで堅牢化されたベースラインから開始し、OS Configでパッチを管理し、不要なパッケージやポートを無効にします。

ネットワークとエッジのセキュリティ

• ネットワークセグメンテーションと下り（egress）制御

  • 階層と機密性に応じて、個別のVPC、サブネット、階層型ファイアウォールポリシーを使用してセグメント化します。IDを認識するファイアウォールタグとサービス間制約（例：GKE NetworkPolicy）を組み合わせて、東西（east-west）方向の通信を制御します。
  • Cloud NAT、DNSポリシー、制限付きの限定公開のGoogleアクセスを使用して下り（egress）トラフィックを制御し、データ漏洩を最小限に抑えます。正当な理由がある場合は、明示的な下り（egress）許可リストとプロキシによる検査を使用します。

• VPC Service Controls (VPC SC)

  • 対象データをホストするプロジェクトの周りにサービス境界を構築し、GoogleマネージドAPI（GCS、BigQuery、Secret Manager、Pub/Subなど）からのデータ漏洩を軽減します。
  • アクセスレベル：境界内のサービスにアクセスするために満たす必要があるコンテキスト条件（ユーザーID、IP範囲、デバイスの状態）を定義します。
  • 制御された複数境界間のワークフローには境界ブリッジを、宛先を制限するには下り（egress）ルールを使用します。パイプラインの破損を避けるために、ドライランモードでテストします。
  • 制限事項：Compute EngineのIPへのトラフィックを直接保護するものではありません。ファイアウォールや下り（egress）制御で補完します。一部のツールやハイブリッドパターンでは、境界を認識するサービスアカウントや、制限されたVIPへのPrivate Service Connectが必要になる場合があります。

• エッジとアプリケーションの保護

  • Cloud Armor：グローバル外部ロードバランサの背後にあるHTTP(S)アプリケーションを、L3/L4/L7 DDoS緩和、IP許可/拒否リスト、地理ベースの制御、レート制限で防御します。
  • WAFルール：OWASP Top 10対策として、事前構成済みのマネージドルールとカスタムシグネチャを適用し、誤検知を減らすためにチューニングします。バックエンドサービスごとにアタッチし、APIバージョンやアプリコンポーネントに応じてポリシーを調整します。
  • API保護：API GatewayまたはApigeeをAPIの前面に配置して、認証、割り当て、スキーマ検証、脅威検出を行います。エッジでの強制のためにCloud Armorを統合し、必要に応じてreCAPTCHA Enterpriseとボット制御を検討します。
  • トレードオフ：より詳細な検査は、レイテンシと運用上のノイズを増加させる可能性があります。ルールをプレビューモードでステージングし、ログを監視し、段階的に適用します。

セキュリティオペレーション、モニタリング、コンプライアンス

• Security Command Center (SCC) と脅威検出

  • SCC は、プロジェクトや組織を横断してアセットインベントリと検出結果を集約します。これを使用して、（公開バケット、オープンなファイアウォールルールなどの）ポスチャのベースライン化、ドリフトの追跡、修正ワークフローを推進します。
  • Premium の脅威検出には、Event Threat Detection、VM Threat Detection、Container Threat Detection が含まれ、マルウェア、クリプトマイニング、異常な振る舞いを特定します。
  • 検出結果をチケット発行システムや SOAR パイプラインと統合し、アラート疲れを避けるために有効期限付きの抑制/例外ポリシーを定義します。

• 脆弱性とアーティファクトのセキュリティ

  • Artifact Analysis を使用してコンテナイメージの CVE をスキャンし、CI からの署名付き証明書と Binary Authorization を用いて、デプロイ時のポリシーを強制します。
  • OS Config によるパッチ管理。カナリアリリースを用いて、露出期間を監視し、ロールアウトを自動化します。

• 監査ログ、プライバシー、証拠

  • Cloud Audit Logs は、デフォルトで管理者アクティビティログとシステムイベントログを提供します。データアクセスログはサービスごとに有効化でき、有料です。分析のためにログを BigQuery に、不変性を保った保持とリーガルホールドのために Cloud Storage にルーティングします。
  • データ分類: Cloud DLP を使用して PII を検出し分類し、ラベルやタグを適用し、保護レベル（CMEK, VPC SC, Confidential VMs）にマッピングします。
  • プライバシーとデータレジデンシー: 組織のポリシーを介してロケーションを制約し、CMEK とストレージのロケーションを規制要件に合わせます。
  • リーガルホールドと保持: バケットの保持ポリシーとホールドを有効にします。必要に応じてオブジェクトのバージョニングを使用します。フォレンジックイメージとログの加工・流通過程（chain of custody）を文書化し、法的証拠能力のある証拠を作成します。

• インシデントレスポンスとフォレンジックへの備え

  • ランブック、アクセスパス、自動化を準備します。レスポンダーが最小権限のアクセス権を持ち、組織、フォルダ、プロジェクト全体で監査が有効になっていることを確認します。
  • 封じ込め: インスタンスをロードバランサから削除したり、egress を拒否するファイアウォールルールを適用したり、プロジェクトをより厳格な組織ポリシーを持つ場所に移動したりして隔離します。侵害されたサービスアカウントを無効にし、シークレットとキーをローテーションします。
  • フォレンジック: オフライン分析のためにディスクをスナップショットし、イメージをエクスポートします。エクスポートによりログを保全します。該当する場合はパケットミラーリングを使用します。証拠の変更を避け、コピーから作業します。
  • 復旧: 信頼できるイメージから再構築し、シークレットを再適用し、スモークテストとセキュリティテストで検証します。インシデント後のレビューを実施し、教訓をガードレールと検出機能にフィードバックします。

実践的な問題シナリオ

フィンテック SaaS である NimbusPay は、Google Cloud 上のマルチテナントマイクロサービスで PCI タグ付きデータを処理し、EU でのデータレジデンシーを強制し、API レイヤーの攻撃から保護し、管理策の監査可能な証拠を提出する必要があります。彼らは、同じホスト名で v1 を稼働させ続けたまま、新しい v2 API を展開します。

アプローチ:

1. プロジェクトとアイデンティティの分割

• 環境ごと、およびマイクロサービスの階層（インジェスト、処理、レポーティング）ごとに個別のプロジェクトを作成します。サービスごとに一意のワークロードサービスアカウントを割り当てます。論理的根拠: 影響範囲（blast radius）を隔離し、個別のワークロードに最小権限をマッピングします。

2. ゼロトラストと最小権限の強制

• サービスアカウントと DevOps グループに事前定義/カスタムロールを付与します。本番環境へのアクセスを企業の IP と時間帯に制限するために、条件付き IAM を適用します。論理的根拠: ラテラルムーブメント（水平展開）と偶発的な変更を削減します。

3. 静的なサービスアカウントキーの削除

• 組織のポリシーを介して、ユーザー管理の SA キーを無効にします。CI/CD とオペレーションにはサービスアカウントの権限借用を使用します。テナントごとに GCS パスを制限するアクセス境界を適用します。論理的根拠: 頻繁に発生する認証情報漏洩の経路を排除し、トークンが盗まれた場合でもデータアクセスを制約します。

4. CMEK とリージョン制御によるデータ保護

• europe-west リージョンに Cloud KMS のキーリングとキーを作成します。BigQuery データセット、GCS バケット、Persistent Disk に対して CMEK を有効にします。スケジュールされたローテーションとバージョンの監視を設定します。論理的根拠: EU のレジデンシーと PCI に準拠した、証明可能な暗号化制御。

5. カードデータに対するアプリケーションレイヤー暗号化の採用

• CMEK でラップされたテナントごとのデータキーを使用して、エンベロープ暗号化（Tink AEAD）を使用します。データベースには暗号文のみを保存します。論理的根拠: フィールドレベルの保護と、インシデントトリアージ中のスコープの最小化。

6. シークレットの集中管理と自動ローテーション

• DB の認証情報と API トークンを、サービスごとの IAM を設定した Secret Manager に保存します。新しいバージョンを作成してデプロイを更新する、Pub/Sub トリガーのローテーションジョブを実装します。可能な場合は、Cloud SQL の IAM DB 認証に切り替えます。論理的根拠: 最小限のダウンタイムで監査可能なシークレットのライフサイクル。

7. ネットワークのセグメント化と egress の制御

• 階層型ファイアウォールポリシーを使用して、web→API→DB のフローを強制し、web→DB の直接通信を拒否します。Google API 向けに、egress の許可リストを持つ Cloud NAT と Private Google Access (restricted) を有効にします。論理的根拠: east-west（内部間）の移動を制約し、許可されていないデータ持ち出しをブロックします。

8. VPC Service Controls によるデータサービスのラップ

• BigQuery、GCS、Secret Manager のプロジェクトをサービス境界内に配置します。企業の IP と管理対象デバイスを要求するアクセスレベルを定義します。ドライランでテストしてから、強制します。論理的根拠: 盗まれたトークンや設定ミスのあるクライアントによるデータ持ち出しを軽減します。

9. エッジと API の保護

• グローバル HTTPS ロードバランサの前面に、Cloud Armor のマネージドルールとレート制限を配置します。パスベースのルーティングを使用して /v1 と /v2 を別々のバックエンドサービスに分離し、バージョンごとに調整された WAF ポリシーを適用します。認証、クォータ、スキーマ検証のために Apigee を統合します。論理的根拠: 階層化された API 保護、スムーズな v1→v2 移行、および誤検知の最小化。

10. コンピュートの強化とアーティファクトの証明

• 処理ノードに Shielded VMs と Confidential VMs を有効にします。CIS で強化されたベースイメージを採用します。Artifact Registry でイメージをスキャンし、GKE のために Binary Authorization で署名付き証明書を要求します。論理的根拠: ブートチェーンと使用中のデータを保護し、サプライチェーンの信頼を強制します。

11. SCC によるポスチャと脅威の監視

• SCC Premium を有効にして、リスクのある設定やランタイムの脅威を検出します。SLA のためにチケット発行システムと統合します。許容されたリスクは有効期限付きで抑制します。論理的根拠: 継続的な保証と、アクションにつながるシグナル。

12. ログ記録、保持、証拠の作成

• 管理者アクティビティ、データアクセス、VPC フローのログを、保持ポリシーとリーガルホールドを設定した BigQuery と Cloud Storage にルーティングします。データセットにレジデンシーと機密度のラベルを付けます。論理的根拠: スコープを限定したアクセスで、調査と外部監査をサポートします。

13. インシデントレスポンスとフォレンジックの準備

• 侵害されたサービスを隔離するためのランブックを作成します。具体的には、プロジェクトをより厳格なポリシーを持つ隔離フォルダに移動し、関連する SA を無効にし、オフライン分析のためにディスクをスナップショットします。論理的根拠: 証拠を保全しつつの迅速な封じ込め。

ロールアウトをサポートする短いコマンド:

• gcloud kms keyrings create pci-ring –location=europe-west1
• gcloud kms keys create tenant-wrap –keyring=pci-ring –location=europe-west1 –purpose=encryption –rotation-period=90d
• gcloud access-context-manager levels create corp-devices –title=corp-devices –basic-level-spec=‘ipSubnetworks: [“203.0.113.0/24”]’

これらのステップにより、NimbusPay は階層化された保護（アイデンティティ、暗号化、ネットワーク、エッジ）、検証可能なコンプライアンス、単一ホスト名下での制御された API の進化、そしてインシデントの検出・封じ込め・復旧への備えを実現します。

← ネットワーキング、ハイブリッド接続、トラフィックアーキテクチャ · すべてのドメイン · 信頼性、ディザスタリカバリ、事業継続性 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Googleを閲覧 →