シラバス詳細 — Professional Cloud Security Engineer
公式試験ガイドの全範囲を日本語化し、各項目に 「何が問われるか」「キーサービス」 を補足したものです。
学習前にここで地図を頭に入れ、各論は 02_学習資料/ で深掘りしてください。
凡例：🔑 = 頻出キーサービス／⚠️ = ひっかけ・判断ポイント
🔐 セクション1：アクセスの構成（~25%）★最重要
ID 管理・認証・認可・リソース階層の上流設計。出題比重が最も高いセクション。
1.1 Cloud Identity の管理
- Google Cloud Directory Sync (GCDS) と第三者 IdP との SSO 構成
- スーパー管理者アカウント の管理（最小化・MFA・別アカウント運用）
- ユーザーライフサイクル管理の 自動化（オンボード/オフボード）
- ユーザー/グループの プログラマティック管理（Admin SDK / Cloud Identity API）
- Workforce Identity Federation（外部 IdP の人間ユーザーを GCP リソースに連携）
🔑 Cloud Identity / GCDS / SAML / OIDC / Workforce Identity Federation ⚠️ スーパー管理者は緊急用に分離（複数人・物理鍵管理・通常運用には使わない）
1.2 サービスアカウント管理
- サービスアカウント（デフォルト含む）の保護
- サービスアカウントが必要なシナリオの見極め
- 作成・無効化・権限付与
- サービスアカウント鍵 のセキュア化・監査・利用最小化
- 短期間クレデンシャル（short-lived credentials）の発行と管理
- Workload Identity Federation（外部ワークロードを SA 鍵なしで連携）
- サービスアカウントのなりすまし（impersonation）の管理
🔑 サービスアカウント / SA 鍵 / Workload Identity Federation / iam.serviceAccountTokenCreator
⚠️ SA 鍵の長期保有・配布は禁忌 → Workload Identity / impersonation が "正解の型"
1.3 認証の管理
- ユーザーアカウントのパスワード・セッション管理ポリシー
- SAML / OAuth の設定
- 2段階認証 の構成と強制（セキュリティキー優先）
🔑 SAML 2.0 / OAuth 2.0 / 2SV / FIDO セキュリティキー / Context-Aware Access ⚠️ 「攻撃に強い MFA」→ TOTP より ハードウェアセキュリティキー
1.4 認可の管理と実装
- 特権ロール と 職務分掌（separation of duties）
- IAM と ACL の権限管理
- IAM Conditions と IAM Deny ポリシー による条件付き付与/拒否
- 組織/フォルダ/プロジェクト/リソースで 最小権限
- Access Context Manager の構成（アクセスレベル）
- Policy Intelligence（IAM Recommender、Policy Troubleshooter、Policy Analyzer）の活用
- グループ を介した権限管理
- Privileged Access Manager (PAM) のユースケース・構成（一時的な特権昇格）
🔑 IAM / カスタムロール / IAM Conditions / IAM Deny / Access Context Manager / PAM / IAM Recommender ⚠️ 「すべての deny は allow より強い」「Deny で広範に止め、Allow で穴を開ける」設計 ⚠️ Recommender = 余剰権限の特定、Troubleshooter = なぜ deny されたかの調査
1.5 リソース階層の定義
- 大規模な フォルダ/プロジェクト 管理
- 組織ポリシー（事前定義/カスタム）の管理
- 継承を使ったアクセス制御
🔑 組織 / フォルダ / プロジェクト / 組織ポリシー / カスタム制約 / Tag
⚠️ 「特定リージョン以外で作らせない」→ gcp.resourceLocations 制約、SA 鍵の作成禁止 → iam.disableServiceAccountKeyCreation
🌐 セクション2：通信のセキュア化と境界保護（~22%）
ネットワーク境界・セグメンテーション・プライベート接続の設計と構成。
2.1 境界セキュリティの設計と構成
- ネットワーク境界制御：Cloud NGFW（次世代ファイアウォール）ルール/ポリシー、Identity-Aware Proxy (IAP)、ロードバランサ、Certificate Authority Service
- Cloud NGFW の L7 アプリケーション層インスペクション
- プライベート IP vs パブリック IP の使い分け
- Cloud Armor によるウェブアプリケーションファイアウォール (WAF)
- Secure Web Proxy のデプロイ（egress 検査）
- Cloud DNS のセキュリティ設定（DNSSEC ほか）
- 構成済み API の継続監視と制限
🔑 Cloud NGFW / IAP / Cloud Armor / Certificate Authority Service / Secure Web Proxy / Cloud DNS ⚠️ 「VPN や踏み台不要で社内 Web アプリへセキュアアクセス」→ IAP（BeyondCorp 流） ⚠️ DDoS・WAF・地理ブロック・bot 防御 → Cloud Armor
2.2 境界セグメンテーションの構成
- VPC / VPC Peering / Shared VPC / ファイアウォールルール のセキュリティ特性
- N 層アプリの ネットワーク分離とデータカプセル化
- VPC Service Controls (VPC SC) のユースケースと構成
🔑 VPC / Shared VPC / VPC Peering / Firewall Rules / Hierarchical Firewall Policies / VPC Service Controls ⚠️ 「正規認証情報の漏洩でもデータ持ち出しを防ぐ」→ VPC SC（サービス境界） ⚠️ Shared VPC は集約管理（host project = ネットワーク部、service projects = ワークロード）
2.3 プライベート接続の確立
- VPC ネットワーク間/プロジェクト間（Shared VPC、VPC Peering、Private Google Access for on-premises hosts）
- データセンタ⇔VPC の暗号化プライベート接続：HA VPN / Cloud Interconnect
- VPC ⇔ Google API のプライベート接続：Private Google Access、Private Google Access for on-premises hosts、Restricted Google Access、Private Service Connect (PSC)
- Cloud NAT による outbound
🔑 Private Google Access / Restricted Google Access / Private Service Connect / HA VPN / Cloud Interconnect / Cloud NAT
⚠️ 「Google API へ Public IP 経由を完全排除しオンプレからも」→ Private Google Access + Restricted VIP (restricted.googleapis.com)
⚠️ 「内部 IP で API を消費・公開」→ Private Service Connect (PSC)
🛡️ セクション3：データ保護（~23%）
機微データ保護・暗号化（保存中/転送中/使用中）・AI ワークロード保護。
3.1 機微データ保護とデータ損失防止
- Sensitive Data Protection (SDP / 旧 Cloud DLP) の構成
- PII の検出と redaction
- 疑似化（pseudonymization） と format-preserving encryption (FPE)
- Google Cloud データサービス（BigQuery / Cloud Storage / Cloud SQL）への アクセス制限
- Secret Manager によるシークレット保護
- コンピュートインスタンスの メタデータ保護（メタデータサーバ・OS Login）
🔑 Sensitive Data Protection (SDP) / Secret Manager / OS Login / Shielded VM ⚠️ PII を保存しない → SDP で取り込み時にトークン化、可逆要件 → format-preserving encryption (FPE)
3.2 保存中/転送中/使用中の暗号化
- Google 既定暗号化 / CMEK / Cloud External Key Manager (EKM) のユースケース
- ソフトウェア鍵 vs ハードウェア鍵 (HSM) の使い分け
- CMEK / EKM の鍵作成・管理（ローテーション・失効・インポート）
- ユースケース別の暗号化方式
- Cloud Storage の オブジェクトライフサイクル 構成
- Confidential Computing（使用中の暗号化）の有効化
🔑 Cloud KMS / Cloud HSM / Cloud EKM / Confidential VM / Confidential GKE Nodes ⚠️ 「鍵を GCP に一切預けない」→ EKM（外部 KMS）／HSM は GCP 上で FIPS 140-2 Level 3 ⚠️ 「メモリ上の処理データも暗号化」→ Confidential Computing（AMD SEV / Intel TDX）
3.3 AI ワークロードのセキュリティ
- AI/ML システムの データ/モデルの意図しない流出 を防ぐコントロール
- IaaS でホストするモデル と PaaS でホストするモデル のセキュリティ要件の違い
- Vertex AI に対するセキュリティ制御（CMEK / VPC SC / IAM / Private Endpoints）
🔑 Vertex AI / Model Garden / VPC SC（Vertex AI 境界）/ CMEK on Vertex AI / Private Endpoints ⚠️ 「学習データ漏洩防止」→ Vertex AI への VPC SC 境界＋データソース側にも境界 ⚠️ プロンプトインジェクション・モデル抽出・データ汚染の認識
⚙️ セクション4：運用管理（~19%）
自動化・ロギング・モニタリング・脅威検出・インシデント対応。
4.1 インフラ・アプリのセキュリティ自動化
- CI/CD での CVE 自動スキャン（Artifact Registry の脆弱性スキャン）
- Binary Authorization で GKE / Cloud Run の署名済みイメージのみ許可
- VM / コンテナイメージ作成の自動化（hardening、メンテナンス、パッチ管理）
- 大規模な ポリシー管理とドリフト検知（Cloud Security Posture Management、カスタム組織ポリシー、Security Health Analytics のカスタムモジュール）
🔑 Binary Authorization / Artifact Registry vuln scanning / OS Patch Management / Security Health Analytics ⚠️ 「未署名イメージのデプロイをブロック」→ Binary Authorization のポリシー強制
4.2 ロギング・モニタリング・検知の構成
- ネットワークログの構成と分析：Cloud NGFW logs、VPC Flow Logs、Packet Mirroring、Cloud IDS、Log Analytics
- 効果的なロギング戦略 の設計
- セキュリティインシデントの ログ・モニタリング・対応・修復
- ログへの セキュアアクセス の設計
- 外部セキュリティシステム（SIEM）へのログエクスポート
- Cloud Audit Logs とデータアクセスログの構成と分析
- ログエクスポート（log sinks、aggregated sinks）の構成
- Security Command Center (SCC) の構成と監視
🔑 Cloud Audit Logs (Admin/Data/System Event/Policy Denied) / Log Sinks / VPC Flow Logs / Cloud IDS / Security Command Center (SCC) / Event Threat Detection / Container Threat Detection ⚠️ Admin Activity ログは既定有効・無料・400日保持。Data Access ログは既定無効（コスト注意） ⚠️ 組織全体のログ集約 → Aggregated Sink、SIEM 連携 → Pub/Sub Sink → SIEM ⚠️ SCC Premium/Enterprise の差（Premium = Event Threat Detection / SHA / Web Security Scanner / VM Threat Detection、Enterprise = SIEM/SOAR 機能含む）
📋 セクション5：コンプライアンス要件への対応（~11%）
規制・業界標準への準拠と、Google Cloud のコンプライアンス機能の活用。
5.1 規制・業界標準への準拠
- コンピュート/データ/ネットワーク/ストレージ観点での技術要件の特定
- 責任共有モデル の評価（Google 側責任 vs 顧客側責任）
- コンプライアンスを支える Google Cloud のセキュリティ機能：
- Assured Workloads（規制対応ワークロード分離・データ所在地・人員制約）
- 組織ポリシー
- Access Transparency / Access Approval（Google 側オペレーターのアクセスを可視化・承認制に）
- データとサービスの リージョン化
- 規制対象範囲（in-scope）の Google Cloud 環境の特定
- コンプライアンス要件を Google Cloud サービス・セキュリティ制御にマッピング（ネットワーク/アクセス分離、監査ログのカバレッジ）
🔑 Assured Workloads / Access Transparency / Access Approval / 組織ポリシー / Compliance Reports Manager ⚠️ FedRAMP High / IL4 / HIPAA / EU Sovereign Controls などのサポートゾーン ⚠️ Access Transparency = ログとして見える（受動的）／ Access Approval = 承認が必要（能動的）
🎯 学習優先度マトリクス
| セクション | 比重 | 難易度 | 学習優先度 |
|---|---|---|---|
| 1. アクセスの構成 | 25% | 中〜高 | ⭐⭐⭐⭐⭐ |
| 3. データ保護 | 23% | 中 | ⭐⭐⭐⭐ |
| 2. 通信と境界 | 22% | 高 | ⭐⭐⭐⭐ |
| 4. 運用管理 | 19% | 中 | ⭐⭐⭐ |
| 5. コンプライアンス | 11% | 低 | ⭐⭐ |
戦略：上位3セクション（1+3+2 = 70%）で確実に得点する。特にセクション1は IAM の細部（Deny / Conditions / Workload Identity / PAM）まで突っ込まれるので、表面理解で止めず手を動かす。セクション5は範囲が狭いので暗記中心で十分。