Google PCNE: ファイアウォール ポリシー、Cloud Armor、ネットワーク セキュリティ — 学習ガイド

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

概要

Google CloudのFirewall policy、Cloud Armor、およびネットワークセキュリティは、連携してセグメンテーション、攻撃対象領域の削減、DDoS耐性、および可観測性のための階層的な制御を提供します。効果的な設計では、IDを意識したターゲティング、階層的な適用、最小権限のイングレスとエグレス、そしてGoogleのグローバルロードバランサーに連携したエッジでの保護を組み合わせます。運用を成功させるには、ルールの評価、暗黙の動作、ロギングのスコープ、そしてさまざまなロードバランシングモードでトラフィックが実際にどこから発信されるかを理解することが重要です。

VPCファイアウォールルールとIDを意識したターゲティング

VPCファイアウォールルールはステートフルであり、ネットワーク、方向、優先度ごとに評価されます。

• 方向と暗黙のルール：
  • イングレスはVMのNICに入るトラフィックに対して評価され、エグレスはVMから出るトラフィックに対して評価されます。
  • すべてのVPCには2つの暗黙のルールが存在します。暗黙のすべてのイングレスを拒否するルールと、暗黙のすべてのエグレスを許可するルールです。これらは変更できず、ログも生成しません。デフォルトネットワークでは、いくつかの寛容なルールも作成されますが、カスタムVPCでは作成されません。
• 優先度と評価：
  • 優先度は0～65535の範囲で、数値が小さいほど先に評価されます。最初に一致したルールがアクションを完全に決定します。
  • 同じ優先度の複数のルールが一致した場合、最も具体的なIP範囲が優先されます。具体性が同じでアクションが競合する場合は、拒否が優先されます。同じ優先度での重複は避けてください。
• ターゲットと送信元：
  • ターゲットは、ルールが適用されるVMを定義します。ネットワークタグ、VMサービスアカウント、またはセキュアタグを使用できます。送信元/宛先はIP CIDRです。イングレスの場合、同じVPC内の送信元に対して送信元サービスアカウントまたはタグを指定することもできます。
  • ネットワークタグは、プロジェクトユーザーが設定できるVMメタデータであり、シンプルですが、制御は緩やかです。サービスアカウントは、ワークロードIDとIAMに連携したID認識型のターゲティングを提供し、悪用されにくいです。セキュアタグ（IAMを介してバインドされた組織レベルのリソースマネージャータグ）を使用すると、開発者が保護をバイパスするタグを自己割り当てすることを許可せずに、セキュリティチームがルールがターゲットにできるVMを制御できます。より強力なガバナンスのためにこれらを使用します。
• ロギング：
  • ファイアウォールルールロギングをルールごとに有効にすると、そのルールに一致した許可または拒否された接続をキャプチャできます。暗黙の拒否はログに記録されません。拒否ログが必要な場合は、ロギングを有効にした明示的な高優先度の拒否ルールを追加してください。
  • ログには、ルール参照、アクション、5タプル、バイト数が含まれ、フォレンジックのためにエクスポートできます。

設計と運用：

• 最小権限のイングレス：明示的な高優先度の拒否ルールを使用してデフォルトで拒否することを優先し、次にサービスアカウントまたはセキュアタグによってスコープを限定した許可を追加します。ロードバランサーの背後にあるインスタンスグループについては、実際にトラフィックを発信するロードバランサーまたはヘルスチェック範囲からのみ許可します。
• 最小権限のエグレス：暗黙の許可を、明示的な高優先度の全エグレス拒否ルールと、ターゲットを絞った許可（NAT範囲、パートナーIP、またはPrivate Google Access経由のGoogle APIなど）に置き換えます。戻りのフローを壊さないように注意してください。ステートフル性により、許可された接続への応答は追加のルールなしで許可されます。
• IDを意識したターゲティング：
  • IPの移動性とは無関係に、「誰が通信できるか」というポリシーにはサービスアカウントを使用します。
  • 開発者が寛容なネットワークタグを自己適用するのを防ぐために、セキュアタグを使用します。
• 一般的な落とし穴と障害モード：
  • ロードバランサーの送信元ID：外部HTTP(S)ロードバランサーの場合、バックエンドにはクライアントIPからではなく、Google Front Endプロキシからの接続が見えます。クライアントIPの許可/拒否にはCloud Armorを使用し、GFEのエグレスとヘルスチェック範囲を許可するにはVPCファイアウォールを使用します。TCP/UDP Network Load Balancerの場合、バックエンドにはクライアントIPが見えます。クライアントIPのファイアウォール許可リストが直接適用されます。
  • 拒否ログの欠落：暗黙のルールによる拒否はログに記録されません。ブロックされたトラフィックを観測するには、ロギングを有効にした明示的な拒否ルールを追加します。
  • NATバイパス：VMに外部IPがある場合、エグレスにそのIPを使用し、Cloud NATをバイパスします。NATの使用を強制するには、外部IPを削除します。
  • ルールの不一致の診断：方向、ターゲットID（タグ/サービスアカウント/セキュアタグ）、優先度、送信元フィルタを確認します。ログに一致がない場合、トラフィックは期待しているルールにヒットしていません。

簡単な例：ロギングを有効にしたID認識型イングレス許可：

• ターゲット: サービスアカウント sa: web-backend@project.iam.gserviceaccount.com
• 送信元範囲: GFEプロキシ範囲 + Googleヘルスチェック
• 優先度: 100
• アクション: allow tcp:80,443
• ロギング: on

階層型ファイアウォール ポリシー、セグメンテーション、サービス境界

階層型ファイアウォール ポリシーは、VPC レベルのルールよりも先に、組織またはフォルダ全体のルールを適用します。これらを使用してガードレール（例：「ロードバランサを使用していない VM へのインターネットからのすべての内向きトラフィックを拒否する」、「0.0.0.0/0 からの RDP/SSH を拒否する」）を保証します。下位レベルの VPC ルールは、すでに一致した組織/フォルダレベルの拒否ルールを上書きできません。

セグメンテーション戦略:

• 内向き（Ingress）のセグメンテーション:
  • 組織/フォルダ ポリシー: リスクの高いポートに対する高優先度の拒否ルールと、認可されたエントリポイントを除くデフォルトでの拒否を設定します。必要な場合は、Google のヘルスチェック範囲を許可します。
  • VPC ルール: サービスアカウントまたはセキュアタグでターゲット指定された、ワークロード固有の許可ルールを設定します。内部サービスの場合は、Private Service Connect または内部ロードバランシングを使用して、制限されたルールで東西（east-west）アクセスを実現します。
• 外向き（Egress）のセグメンテーション:
  • 組織/フォルダまたは VPC スコープで、暗黙のすべて許可の外向きルールを高優先度のすべて拒否の外向きルールに置き換え、その後、必要なものだけを開放します:
    • Cloud NAT または承認された外向きファイアウォール経由のインターネットへの外向きトラフィック。
    • Private Google Access および private.googleapis.com または restricted.googleapis.com エンドポイント経由の Google API。restricted エンドポイントは VPC Service Controls と組み合わせることで、未承認のアイデンティティやプロジェクトへのデータ漏洩を防ぎます。
    • 0.0.0.0/0 をサードパーティのファイアウォール経由でルーティングする設計で、かつヘアピンニングなしで Google API への直接アクセスが必要な場合は、Google API の VIP ブロックへの静的ルートをデフォルト インターネット ゲートウェイに追加し、サブネットで Private Google Access を有効にします。これにより、セキュリティ制御を維持しつつ、ファーストパーティサービスに対するサードパーティデバイスへの依存とレイテンシを削減できます。

サービス境界との相互作用:

• VPC Service Controls は、プロジェクトとサポートされている Google API の周りに境界を定義し、データ漏洩を軽減します。境界が有効になっている場合:
  • API コールが境界のコンテキスト内に留まるように、restricted.googleapis.com を優先的に使用します。
  • DNS が関連ドメインを restricted または private エンドポイントに解決し、ルートが信頼できない外向きデバイスにバックホールしないようにします。
  • 境界外のエンドポイントへの意図しない漏洩を避けるために、境界ポリシーと外向きファイアウォールの許可リストを組み合わせます。

トレードオフ:

• 組織レベルの拒否ルールはリスク管理を簡素化しますが、変更管理が遅いと正当な実験をブロックする可能性があります。セキュアタグと文書化されたリクエストワークフローを使用して例外を委任します。
• 積極的な外向き拒否ルールは影響範囲（ブラスト半径）を縮小しますが、サービス停止を防ぐためには堅牢なサービスディスカバリと変更管理が必要です。

Cloud Armor、WAF、グローバルエッジでの保護

Cloud Armor は、外部 HTTP(S) および外部 TCP/SSL プロキシロードバランサにセキュリティポリシーをバインドし、エッジで保護を提供します。

• WAF ルール:
  • OWASP Top 10 や一般的な CVEs に対応する事前構成済みルールや、ヘッダー、IP、国、URI などに一致させる式言語を使用したカスタムルールを使用します。
  • バックエンドサービスごとにアタッチし、ルールを優先度順に並べます。アクションには、許可、特定のレスポンスを伴う拒否、または HTTP(S) のリダイレクトが含まれます。
• レート制限:
  • スライディングウィンドウとバースト制御を使用して、キーごと（例：クライアント IP、ヘッダー、Cookie）のクォータを適用します。レートベースの BAN は、不正なソースに対して一時的な拒否ルールを自動的に追加します。
• Adaptive Protection:
  • ML 駆動の異常検出が通常のリクエストパターンを学習し、L7 DDoS や不正利用を表面化させます。ルールの候補を提案または自動生成でき、まずはプレビューモードでデプロイします。
• プレビューモード:
  • トラフィックに影響を与えることなく新しいルールを評価します。プレビュー結果はログに記録されるため、低リスクでのチューニングが可能です。検証後に適用モードに移行します。

DDoS 防御とグローバルロードバランサの制御:

• Google のグローバルエニーキャストエッジは、大規模な L3/L4 攻撃を吸収します。SYN/ACK 検証、不正な形式のパケット処理、エッジキャパシティの自動スケーリングは、外部 HTTP(S) および TCP/SSL プロキシのプラットフォームに組み込まれています。
• Cloud Armor と組み合わせることで、L7 フラッド攻撃、クレデンシャルスタッフィング、アプリケーションの不正利用を軽減します。
• ロードバランサで TLS ポリシー、最新の暗号スイートを適用し、必要に応じてクライアント mTLS を適用します。IPv6 の要件がある場合は、IPv6 VIP を持つグローバル外部 HTTP(S) または TCP/SSL プロキシロードバランサを使用します。
• ロードバランスされたアプリに対して特定のクライアント IP を許可リストに登録する場合:
  • HTTP(S) を使用している場合、クライアント IP をキーとする Cloud Armor の許可リストを優先的に使用し、バックエンドのファイアウォールルールは GFE とヘルスチェックのソースに限定します。
  • TCP/UDP ネットワークロードバランサを使用している場合、バックエンドは実際のクライアント IP を認識します。ターゲットインスタンス（セキュアタグまたはサービスアカウントで指定）に直接 VPC ファイアウォールの許可リストを適用し、Google のヘルスチェック IP を含めます。

運用上の注意点:

• ルールはエッジで評価されるため、不正確な許可リストは即座にグローバルなサービス停止を引き起こす可能性があります。プレビューと段階的なロールアウトを使用し、Cloud Armor のログとロードバランサのメトリクスを監視します。
• セッションアフィニティのニーズは様々です。混合プロトコル（例：同じクライアントから同じバックエンドプールへの HTTP と TFTP）の場合、ロードバランサのクライアント IP アフィニティはポートをまたいでスティッキネス（セッション維持）を保持します。

可視性、検査、インシデント対応

可観測性:

• VPC フローログは、サンプリング、メタデータエンリッチメント、集約間隔を設定可能な、サブネットごとのサンプリングされた 5 タプルのフローレコードを提供します。パフォーマンスのベースライン化や異常検知に使用します。
• ファイアウォールルールのロギングは、ロギングが有効な特定のルールについて、接続ごとの許可と拒否をキャプチャします。暗黙の拒否に該当するブロックをログに記録するには、明示的な拒否ルールを作成します。
• Cloud Armor のリクエストログとプレビュー結果には、ルールの一致、アクションの決定、エッジでのレート制限の結果が表示されます。

検査と検出:

• Packet Mirroring は、ディープパケットインスペクションや IDS のために、同じリージョン内のコレクターにトラフィックをコピーします。オーバーヘッドを制限するために、サブネット、タグ、またはサービスアカウントでミラーリングのスコープを限定します。Packet Mirroring はアウトオブバンドであり、ブロックは行いません。Cloud IDS またはサードパーティのセンサーと組み合わせて使用します。
• インライン L7 検査には、2-NIC アプライアンスパターンと、それを通るルーティングが必要です。対称ルーティングと HA を考慮して設計し、リージョン障害ドメインと潜在的なスループットのボトルネックを検討します。インラインデバイスは障害発生時の影響範囲 (blast radius) を拡大させるため、該当する場合はマネージドインスタンスグループとヘルスチェック付きルートフェイルオーバーパターンをデプロイします。

インシデント対応プラクティス:

• ログをセキュリティプロジェクトに一元化し、突然の拒否の急増、新しい高優先度ルールの作成、または Cloud Armor のレート制限トリガーに対する検出を構築します。調査には BigQuery または SIEM 統合を使用します。
• 最小権限の IAM を徹底します。共有 VPC でファイアウォールポリシーを変更するには Network Admin では不十分で、Security Admin が必要です。ネットワークチームとセキュリティチームの間で職務を分離します。
• 緊急時の SSH アクセスが必要で、キーが事前にプロビジョニングされていない場合、IAM とインスタンスメタデータの設定で許可されていれば、Cloud Shell から

undefined

を使用して、インスタンスメタデータを介してエフェメラルキーをプッシュします。

• 「ログがない」シナリオのトラブルシューティングでは、ルールと方向を確認し、暗黙の拒否はログに記録されないことを念頭に置き、より早い段階で一致した可能性のある階層型ポリシーをチェックします。

実践的な問題シナリオ

Contoso Retail は、Google Cloud 上で多層 Web プラットフォームを運用しています。フロントエンドのトラフィックはグローバル外部 HTTP(S) ロードバランサーによって処理され、アプリケーション VM は外部 IP なしで複数のリージョンで実行されています。Egress トラフィックは、Google API (BigQuery および Pub/Sub) を除き、サードパーティの NGFW を経由してヘアピンする必要があります。セキュリティチームは、組織全体のガードレール、パートナーパイロットのためのクライアント IP 許可リスト、そして悪意が疑われるクライアントをテストする際のリスクを最小限に抑えることを望んでいます。

アプローチ:

1. 階層的なガードレールの確立

   • env=public-entry というセキュアタグを持たない VM ターゲットへの 0.0.0.0/0 からのすべての ingress を拒否し、インターネットからの管理ポート (SSH, RDP) を拒否する、組織レベルの階層型ファイアウォールポリシーを作成します。
   • 理由: 安全でない公開をグローバルに停止します。タグに対する IAM の設定により、開発者はセキュアタグを自己割り当てできません。

2. ID を認識したワークロードのターゲティング

   • フロントエンド、アプリケーション、データベースの各層に個別のサービスアカウントを割り当てます。VPC レベルのファイアウォールルールでこれらのサービスアカウントを参照し、必要な East-West (東西) トラフィックのみを許可します (例: フロントエンド→アプリ tcp:443, アプリ→DB tcp:5432)。
   • 理由: ポリシーをワークロード ID に結びつけ、偶発的なタグの誤用を防ぎます。

3. 負荷分散されたバックエンドへの Ingress 許可

   • アプリケーション VM 上で、アプリのサービスアカウントをターゲットとし、送信元範囲を Google Front End (GFE) プロキシと Google ヘルスチェックの範囲に設定した、高優先度の ingress 許可ルールを作成し、ロギングを有効にします。
   • 理由: HTTP(S) L7 の場合、バックエンドは GFE とヘルスチェック IP からの接続のみを受け入れるべきです。クライアント IP 許可リストはエッジで適用されます。

4. Cloud Armor エッジポリシー

   • 外部 HTTP(S) ロードバランサーのバックエンドサービスに Cloud Armor ポリシーをアタッチします:
     • パートナーのクライアント IP 許可リストルールを追加します。
     • OWASP Top 10 に対する事前設定済み WAF ルールを有効にします。
     • クライアント IP をキーとし、控えめな閾値を設定したレート制限を構成します。
   • 理由: クライアント IP が可視であり、トラフィックが VPC に到達する前の段階で、クライアントの送信元制限とアプリケーション層の保護を適用します。

5. 適応型保護と安全なテスト

   • Adaptive Protection を有効にし、疑わしいクライアント IP に対する拒否ルールをプレビューモードで作成します。
   • 理由: プレビューモードにより、実際のユーザーに影響を与えることなく動作を検証できます。適用前にログでクライアントが悪意のあるものかを確認します。

6. Private Google Access を使用した Egress のセグメンテーション

   • サードパーティ NGFW への 0.0.0.0/0 ルートを維持します。Google API の VIP に対するカスタム静的ルートをデフォルトインターネットゲートウェイに追加し、サブネットで Private Google Access を有効にします。明示的な高優先度の egress 全拒否ルールを追加し、その後 NGFW ネクストホップと Google API への特定の許可ルールを追加し、ロギングを有効にします。
   • 理由: 一般的なインターネット Egress を NGFW 経由に強制する一方、BigQuery と Pub/Sub へは不要なヘアピンなしでプライベートに到達できるようにします。

7. NAT と外部 IP の制御

   • インターネットへの Egress が必要だが外部 IP を持たないインスタンスには Cloud NAT を使用します。NAT を使用しなければならないコンピューティングインスタンス上の外部 IP を監査し、削除します。
   • 理由: NAT のバイパスを防ぎ、単一の Egress 体制を維持します。

8. 検査とモニタリング

   • 各リージョンでアプリ層に対して Packet Mirroring を有効にし、アプリのサービスアカウントをターゲットとして、ミラーリングされたトラフィックをリージョン内の IDS コレクターに送信します。主要なルールに対して VPC フローログとファイアウォールルールのロギングを有効にします。Cloud Armor と VPC のログを中央のセキュリティプロジェクトと BigQuery にエクスポートします。
   • 理由: 経路上のレイテンシを発生させることなく、脅威ハンティングとパフォーマンスのベースライン化のための深い可視性を提供します。

9. インシデント対応可能な運用

   • Cloud Armor の拒否、ファイアウォールの拒否ログの急増、または階層型ポリシーの変更に対するアラートを構築します。制御された緊急アクセスのために、Cloud Shell の

undefined

を使用した緊急時の SSH 手順を文書化します。

• 理由: 進行中の不正利用を迅速に検出し、修正のための安全な運用パスを維持します。

10. 変更の安全性とロールバック
    • Cloud Armor の変更はプレビューでステージングしてから適用します。ファイアウォールの変更については、組織レベルのポリシーに反映させる前に、リスクの低い優先度とカナリアプロジェクトを使用します。
    • 理由: 強固な体制を維持しつつ、ポリシーの間違いによるグローバルな停止の可能性を最小限に抑えます。

← VPC アーキテクチャ、サブネット、アドレス計画 · すべてのドメイン · ハイブリッド接続、Cloud Router、BGP →

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

Googleを閲覧 →