PCSE 合格対策
S2 通信のセキュア化と境界保護 🎯 Deep Dive 出題 ~22%

Network Security
公式ドキュメント深掘り

VPC / Cloud NGFW / Cloud Armor / IAP / Secure Web Proxy / VPC Service Controls / Private Service Connect / HA VPN / Cloud Interconnect / Private Google Access の各サービスを、公式仕様・SLA・典型構成・落とし穴まで深掘り。

中堅〜シニア向け VPC 公式 VPC SC 公式 IAP 公式

このページの目次

  1. 1. 防御の 5 層モデル
  2. 2. VPC / Subnet / ルーティング
  3. 3. Shared VPC vs Peering
  4. 4. Cloud NGFW(次世代 FW)
  5. 5. Hierarchical Firewall Policies
  6. 6. Identity-Aware Proxy
  7. 7. Cloud Armor 詳細
  8. 8. Secure Web Proxy
  9. 9. VPC Service Controls 詳細
  10. 10. Private Service Connect
  11. 11. Private/Restricted Google Access
  12. 12. HA VPN / Cloud Interconnect / MACsec
  13. 13. Cloud NAT
  14. 14. Certificate Authority Service
  15. 15. リスク・落とし穴総まとめ
  16. 16. 設計チェックリスト

1. 防御の 5 層モデル

「IAM だけでは防げない」攻撃面を 層別の機能 で塞ぐのが PCSE の設計原則。試験では どの層の問題か を即時判別できる必要がある。

通信セキュリティの 5 層と対応サービス L1 ID 層 IAP / Workforce Identity / IAM L2 L7 inbound Cloud Armor (WAF / DDoS / Bot) L3 L7 egress Secure Web Proxy(URL/ID 許可制御) L4 L3/L4 ネットワーク Cloud NGFW / Hierarchical FW L5 サービス境界 VPC Service Controls(API 単位の egress 防御)
図 1: 防御の 5 層モデル。問題文の「何を防ぎたいか」で層を特定し、対応サービスを選ぶ。
✅ 層の使い分け判断軸

2. VPC / Subnet / ルーティング

GCP の VPC は グローバル な仮想ネットワーク。Subnet はリージョナル、ルーティングは VPC 全体で完結(インスタンス間は Subnet をまたいでも単一 routing fabric)。

VPC 最大数 / Project
5
既定。引き上げ申請可能
Subnet / VPC
~7,000
リージョンごとに分散
最大ルート数
350
動的 + 静的の合計
FW ルール数 / VPC
~500
ポリシー化で実質拡張

VPC モード

Auto モード

  • 新規リージョンに自動でサブネット作成
  • IP 範囲は 10.128.0.0/9 から自動割当
  • 意図しない IP 重複を招きやすい
  • 本番では非推奨

Custom モード

  • サブネットを 明示的に 作成
  • RFC1918 範囲を自社で計画
  • Shared VPC / Peering 連携時の IP 重複を防げる
  • 本番の標準

Private Google Access / Private services access の関係

3. Shared VPC vs Peering vs PSC

観点VPC PeeringShared VPCPrivate Service Connect
役割VPC 間 1:1 接続1 つの VPC を複数 Project で共有サービス公開 / 消費
ガバナンスフラット(各 VPC 独立)host project 集中Producer / Consumer 分離
推移的接続×(A↔B + B↔C で A↔C は不可)◯(host VPC で完結)n/a(エンドポイント単位)
IP 重複許容しない許容しない許容(NAT 機構あり)
クォータVPC 1 つあたり最大 25 peeringhost project 数の上限ありper-service service attachment
典型ユースケースパートナーや別組織同一組織内のアプリチーム複数SaaS 提供 / 内部 IP API 化
✅ Shared VPC の典型構成

4. Cloud NGFW(次世代ファイアウォール)

従来の VPC Firewall Rules の後継・拡張。Standard / Enterprise の 2 Tier。公式 Cloud NGFW

Cloud NGFW Standard

  • L3/L4 IP-port フィルタ(旧 VPC Firewall Rules)
  • ターゲットは Service Account / Network Tag
  • Geo-IP / Threat Intel フィード対応
  • FQDN ベース宛先(GA)

Cloud NGFW Enterprise

  • L7 アプリケーション検査(IPS)
  • TLS Inspection(CAS と連携、root CA 配布要)
  • シグネチャベース侵入防止(Palo Alto 由来)
  • Endpoints を VPC に紐付けて利用、課金は時間 + パケット量

ルール優先度と暗黙ルール

gcloud SA ベースのファイアウォール(Service Account ターゲット)
# Web tier の SA から App tier の SA への 8080 番のみ許可
gcloud compute firewall-rules create allow-web-to-app \
    --direction=INGRESS --priority=1000 --network=prod-vpc \
    --action=ALLOW --rules=tcp:8080 \
    --source-service-accounts=web-tier@PROJECT.iam.gserviceaccount.com \
    --target-service-accounts=app-tier@PROJECT.iam.gserviceaccount.com
✅ FW ルール設計の原則

5. Hierarchical Firewall Policies

組織 / フォルダレベルで強制する FW ポリシー。配下プロジェクトでオーバーライド不可(goto_next で次レベルに委譲)。公式

評価順

FW ポリシーの評価順(上から) ① Organization Firewall Policy ② Folder Firewall Policy ③ Network Firewall Policy ④ VPC Firewall Rules (legacy)
図 2: FW の評価順。上位ポリシーで Allow/Deny/goto_next を表明。
✅ 組織標準ベースライン例

6. Identity-Aware Proxy(IAP)

VPN・踏み台を なし にして、Google アイデンティティで Web/SSH/RDP にアクセスさせる。公式概要

2 モード

IAP for HTTP(S)

  • HTTPS LB の前段で動作
  • App Engine / GCE / GKE / Cloud Run(外部 LB 経由)対応
  • ロール:roles/iap.httpsResourceAccessor
  • JWT ヘッダ x-goog-iap-jwt-assertion でバックエンドに ID 伝搬

IAP for TCP forwarding

  • SSH / RDP / カスタム TCP を Tunneled で接続
  • gcloud compute ssh --tunnel-through-iap
  • ロール:roles/iap.tunnelResourceAccessor
  • VM に外部 IP 不要、踏み台 VM が不要

Context-Aware Access の組み合わせ

IAP + Access Context Manager の Access Level で、「日本国内 / 企業端末 / 業務時間内」のみ許可するゼロトラスト構成が可能。

bash IAP TCP 経由で SSH
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    --tunnel-through-iap

# IAP TCP の前提:
#  - VM がプライベート IP のみでも OK
#  - 35.235.240.0/20 からの ingress を 22 番に許可しておく
⚠️ IAP の落とし穴

7. Cloud Armor 詳細

L7 WAF / DDoS / 地理ブロック / Bot Management。Standard / Plus / Enterprise の 3 Tier。公式

3 Tier の機能差

機能StandardPlusEnterprise
Preconfigured WAF(OWASP)
カスタムルール(CEL)
Rate-based rules
Geo / IP リスト
Adaptive Protection (ML)
Bot Management
reCAPTCHA Enterprise 統合
専任サポート / DDoS 保証

OWASP プリセット(一例)

CEL カスタムルール:地理ブロック + 認証パスの Rate Limit
# Rule 1: 中国とロシアからのアクセスをブロック
expression: origin.region_code == "CN" || origin.region_code == "RU"
action: deny(403)
priority: 1000

# Rule 2: /login への過剰リクエストを Throttle
expression: request.path.matches("/login")
action: throttle
rate_limit_options:
  rate_limit_threshold: { count: 10, interval_sec: 60 }
  exceed_action: deny(429)
  enforce_on_key: IP
priority: 1100
✅ Cloud Armor 設計の型

8. Secure Web Proxy

egress 通信を ID + URL ベースでフィルタするマネージドプロキシ。公式

⚠️ Secure Web Proxy の注意点

9. VPC Service Controls 詳細

"サービス境界(Service Perimeter)" を作って API 単位の egress を防ぐ最終防衛線。IAM とは独立した別レイヤ。公式概要

VPC Service Controls の構成要素 Service Perimeter Project A BigQuery / Storage Project B Vertex AI Restricted Services(明示指定) - bigquery.googleapis.com - storage.googleapis.com - aiplatform.googleapis.com Access Levels - corp_device_jp_only Ingress / Egress Rules - 監査 SA 限定の Ingress - Public Iceberg への Egress 境界外 / インターネット
図 3: VPC SC の構成要素。Perimeter / Restricted Services / Access Levels / Ingress-Egress Rules の 4 要素。

4 要素の詳細

Service Perimeter

保護対象 Project と保護対象サービスを宣言する箱。1 つの Project は 1 perimeter にのみ所属可能。

Restricted Services

境界に 明示的にリストアップ した API のみ保護対象。デフォルトでは何も保護されない(落とし穴)。

Ingress Rule

境界外 → 境界内の例外。identityType + sources + operations で許可される境界突破を細かく定義。

Egress Rule

境界内 → 境界外の例外。例:公開 BigQuery 一般公開データセットへの参照を許可。

Dry Run モード

本番影響なしで違反を可視化 できる検証モード。dryRunPolicy を構成し、Policy Denied Audit Log でブロック候補を確認 → 例外 Rule を整備してから enforce。

yaml Perimeter 設定(Ingress Rule の例)
name: "accessPolicies/POLICY/servicePerimeters/prod-data-perimeter"
title: "Prod data perimeter"
status:
  resources: ["projects/123", "projects/456"]
  restrictedServices:
    - "bigquery.googleapis.com"
    - "storage.googleapis.com"
    - "aiplatform.googleapis.com"
  accessLevels:
    - "accessPolicies/POLICY/accessLevels/corp_device_jp"
  ingressPolicies:
  - ingressFrom:
      identities: ["serviceAccount:audit-reader@audit-PROJECT.iam.gserviceaccount.com"]
      sources:
      - accessLevel: "accessPolicies/POLICY/accessLevels/audit_partner_ip"
    ingressTo:
      resources: ["projects/123"]
      operations:
      - serviceName: "bigquery.googleapis.com"
        methodSelectors:
        - method: "google.cloud.bigquery.v2.JobService.GetQueryResults"
⚠️ VPC SC の落とし穴

10. Private Service Connect(PSC)

プライベート IP で サービス公開 / 消費 する仕組み。VPC Peering の代替・補完。公式

3 つのバリアント

PSC for Published Services

Producer が内部 L4 LB を Service Attachment として公開、Consumer の VPC で PSC Endpoint として消費。SaaS 提供の標準。

PSC for Google APIs

*.p.googleapis.com エンドポイントを VPC 内 IP 化。Private Google Access の高度版。

PSC for Interconnect

オンプレ⇔Google API のプライベート消費。グローバルアクセスを VPC SC と連携。

✅ PSC を VPC Peering より選ぶ理由

11. Private / Restricted Google Access

Google API へのプライベートアクセス VIP の使い分け private.googleapis.com 199.36.153.8/30 通常の Private Google Access 大半の Google API が到達可能 VPC SC 連携は不要なシナリオ restricted.googleapis.com 199.36.153.4/30 VPC SC 対応 API のみ到達可能 Public IP 経由を完全に遮断 高セキュリティ / 規制要件
図 4: private vs restricted の使い分け。VPC SC と連携するなら restricted、それ以外は private。

DNS 設定の典型

DNS オンプレからプライベートアクセスする場合の DNS 解決
# Cloud DNS Private Zone で *.googleapis.com を private VIP に向ける
zone:       googleapis.com
record:     googleapis.com.       CNAME  private.googleapis.com.
            *.googleapis.com.     CNAME  private.googleapis.com.
            private.googleapis.com. A     199.36.153.8
                                    A     199.36.153.9
                                    A     199.36.153.10
                                    A     199.36.153.11

# オンプレ DNS から Cloud DNS への Forward を設定(HA VPN / IC 経由)

12. HA VPN / Cloud Interconnect / MACsec

HA VPN SLA
99.99%
2 トンネル + 2 BGP セッション
HA VPN 帯域
3 Gbps
トンネルあたり、合計 6 Gbps
Dedicated IC 帯域
10/100 Gbps
物理回線、複数本で冗長
Partner IC 帯域
50 Mb〜50 Gb
パートナー経由

暗号化の選択肢

接続方式暗号化レイヤメモ
HA VPNIPSec(AES-256-GCM)L3既定で暗号化、設定不要
Dedicated Interconnectなし(オプション MACsec)L2物理セキュリティ + MACsec または HA VPN over IC
Partner Interconnectなし(HA VPN over IC 推奨)パートナー責任範囲を確認
Cross-Cloud Interconnectなし(同上)他クラウドへの直接接続
✅ Interconnect 暗号化の設計指針

13. Cloud NAT

外部 IP を持たない VM の egress を可能にする マネージド NAT。受信は不可(egress 専用)。

主要仕様

⚠️ Port exhaustion のリスク

14. Certificate Authority Service(CAS)

マネージドプライベート PKI。内部サービス間の mTLS / Cloud NGFW Enterprise の TLS Inspection に活用。公式

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

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

16. 設計チェックリスト

📚 関連リソース