電算システム 有志Publicationへの投稿
🛡️

Blog series Google Cloud セキュアな土台作り: 第4回

SKY(Tomoaki Sekiya)
に公開
Security
Google Cloud
basic
VPC
firewall
tech

第4回 プロジェクトの門番！VPCとファイアウォール基本の「キ」

はじめに

お疲れ様です。SKYこと関谷です。

クラウドの安全な“土台づくり”を一緒に進める本シリーズ、第4回では VPC（Virtual Private Cloud）とファイアウォール を取り上げます。VPCはプロジェクト専用のプライベート空間、ファイアウォールはその出入口を守る門番。ここを正しく設計できるかが、以降のすべてのセキュリティ施策の効き目を左右します。
長文となりますが、どうぞお付き合いください。

まず軽く前回までを振り返ります。

  • 第1回：セキュリティの全体像と「責任共有モデル」を整理し、多層防御やゼロトラストの考え方を押さえました。
  • 第2回：組織／フォルダ／プロジェクトのリソース階層と、将来を見据えたフォルダ・命名ルールで“土台（Landing Zone）”を設計しました。
  • 第3回：IAMの最小権限、グループ運用、サービスアカウントの勘所を確認し、「誰が何をできるか」をコントロールしました。

そのうえで本記事では、ネットワーク面の“守り”を強化します。具体的には――

  • VPC設計の基本（サブネット/リージョン設計、デフォルトVPCを避ける理由、推奨命名の考え方）
  • ファイアウォールのベストプラクティス（“まず拒否、必要最小限だけ許可”、優先度設計、ネットワークタグ活用）
  • 外部IPなしでの安全な通信（Private Google Access と Private Service Connect 、Cloud NAT の使い分け）

ブログシリーズその他の執筆

本編

https://zenn.dev/densan_techblog/articles/f40922222f37c5
https://zenn.dev/densan_techblog/articles/c34cac120413ee
https://zenn.dev/densan_techblog/articles/80b24bbc018cca

番外編
https://zenn.dev/densan_techblog/articles/cc0ee6113a11bb

第３回では紹介しなかった関連機能の説明です

4-1. VPCネットワークの基本：プロジェクト専用のプライベート空間

まずは“地図”を持つ：VPCの役割

  • VPC（Virtual Private Cloud） は、プロジェクトごとに用意する“仮想ネットワークの土台”。
  • グローバルなリソース として1つのVPCの中に、リージョン単位のサブネット を並べて使います。
  • VMやコンテナなどのリソースはサブネット内の 内部IP で通信し、必要に応じて 外部IP（必須ではない） でインターネットと通信します。
  • 通信の入り口は VPCファイアウォール で制御（詳細は次節）。

図A：VPCの構造（リージョンとサブネットの関係）
図A：VPCの構造（リージョンとサブネットの関係）

自動モードは卒業しよう：カスタムVPC一択

  • 自動モードVPC（default VPC含む） は、全リージョンにまたがるサブネットと広い初期ルールが自動で作成され、開放的かつIP競合の温床に。
  • カスタムモードVPCなら、使うリージョンだけにサブネットを定義し、自社IP計画に沿ったCIDRを割り当てられます。
  • ベストプラクティス：
    • 新規は必ずカスタムVPCで作る。
    • 既存のdefaultネットワークは早期に削除を検討（削除前に依存の棚卸し）。
    • 以降の拡張（Peering/VPN/Interconnect/Shared VPC）を見据え、重複しないIP計画を用意。

失敗しないIP設計のコツ

  • 上位から下位へ：まず“VPC全体のアドレス帯”を確保→リージョンごと→環境（prod/stg/dev）ごと→用途（web/app/db）ごとに段階的に細分化。
  • 余白を残す ：将来の拡張を見込み、各リージョンに /16～/20程度の余白 を確保。
  • 重複禁止 ：将来の VPC Peering・ハイブリッド接続 で詰む最大要因は CIDR衝突 。既存オンプレや他クラウドも含めた“全社IP台帳”で一元管理。
  • GKE/Serverlessも想定：GKEの Secondary Range（Pod/Service） やServerless VPC Access用の コネクタ用サブネット も最初から予約しておく。

例：アドレス計画のひな形

VPC: corp-main
  asia-northeast1（東京）
    10.10.0.0/16
      prod-web      10.10.0.0/20
      prod-app      10.10.16.0/20
      prod-db       10.10.32.0/21
      prod-gke-pod  10.10.64.0/18   （Secondary）
      prod-gke-svc  10.10.128.0/20  （Secondary）
      svless-conn   10.10.160.0/23  （Serverless VPC Access）
  us-central1（アイオワ）
    10.20.0.0/16
      ...（同様に割当）

図B：良い例／悪い例（要点比較）
図B：良い例／悪い例（要点比較）

命名規則で“運用コスト”を下げる

  • 一貫した命名 は可視性と自動化の鍵。
  • 推奨フォーマット（例）
    • VPC：vpc-{org|dept}-{purpose} → vpc-corp-main
    • サブネット：sub-{region}-{env}-{tier} → sub-asia-northeast1-prod-web
    • ネットワークタグ：role-{tier} / env-{env} → role-web, env-prod
  • 命名要件：環境/リージョン/用途 を最低限含める。人が見ても 即座に配置が分かる こと。

“デフォルトVPC”を使わない理由

  • 広すぎる初期ファイアウォール（SSH/RDP許可、内部全許可など）を温存してしまう。
  • 全リージョン自動サブネット により、IP競合 や 不要リージョンの露出 が発生。
  • どのリソースが どの意図で配置 されたか追跡困難＝ 監査性の低下。

チェックリスト

  • default VPCの 使用停止/削除計画 を作成し、依存を棚卸しした
  • カスタムVPC で新規作成し、使うリージョンにだけ サブネットを作成した
  • IPアドレス計画 （オンプレ/他クラウド含む）を文書化し、重複なし を確認した
  • 命名規則 （VPC/サブネット/タグ）を決めて記録した
  • GKE/Serverless用の Secondary/コネクタ用サブネット を先行確保した
  • （次節への布石） ファイアウォールの初期方針 ＝“受信は原則拒否、必要だけ許可”を決めた
  • （後続で扱う）Private Google Access / Cloud NAT の採用方針を決め、外部IP“ゼロ”運用を基本にした

4-2. 通信制御の要：ファイアウォールの仕組み

“分散・ステートフル”が肝

  • VPCファイアウォール は、各VMインターフェース（NIC）に対して機能する 分散型 のネットワークファイアウォールです。
  • ステートフル に動作するため、許可済みの接続に対する 戻りのトラフィックは自動で許可 されます（双方向ルールを二重に作る必要はありません）。

ルールの構成要素

  1. 方向

    • Ingress（受信）：宛先＝対象VM（サブネット内）。送信元はCIDRやタグ/サービスアカウント等で指定。
    • Egress（送信）：送信元＝対象VM。宛先はCIDR等で指定。

  2. アクション

    • allow / deny のどちらか。denyは一致時に即ブロック。

  3. 優先度（priority）

    • 数値が小さいほど先に評価（例: 100 は 1000 より優先）。
    • 複数が一致する場合は、最優先の1本だけ が適用されます。
    • 同一優先度で allow/deny が競合するなら、deny が優先。

  4. 対象（targets）

    • ルールをどのVMに適用するか：
      • ネットワークタグ（role-web など）
      • サービスアカウント（vm-sa@project.iam.gserviceaccount.com など）
    • 推奨メモ：運用の堅牢性は サービスアカウント指定＞タグ指定。タグは付替え権限が広くなりがちで、意図せぬ“抜け道”になりやすい。

  5. マッチ条件

    • CIDR（IPv4/IPv6）、プロトコル（tcp/udp/icmp 等）、ポート（80/443/22 等）、サービスタグ（一部のヘルスチェック/ロードバランサ用）など。

  6. ロギング（任意）

    • ルール単位で Firewall Rules Logging をONにして、許可/拒否イベントを Cloud Logging へ出力可能。チューニング時の可視化に必須。

暗黙ルールと“デフォルト”の違い

  • 暗黙ルール（各VPC共通）
    • Ingress（Google Cloud 外 -> Google Cloud、Google の言い方では"上り"）：暗黙の 拒否（Allowが無い通信は入ってこない）。
    • Egress（Google Cloud -> Google Cloud 外、Google の言い方では"下り"）：暗黙の 許可（必要に応じて明示のEgress deny/allowで縛る）。
  • default VPCの初期ルール は広めに開いており、本シリーズでは 採用非推奨（詳細は前節 4-1 を参照）。

評価の流れ

  1. 対象VMに届く（または出る）パケットの 方向 を判定（Ingress/Egress）。
  2. 同じ方向・同じVPCで 対象に合致 する候補ルールを集める（タグ/SA/ネットワーク一致）。
  3. 優先度の小さい順 に評価し、最初に一致したルールのアクションを適用。
  4. 一致が無い場合は 暗黙ルール へ（Ingressは拒否／Egressは許可）。

図C：評価フロー（どのルールが適用される？
図C：評価フロー（どのルールが適用される？）

タグ運用 vs サービスアカウント運用

  • ネットワークタグ
    • メリット：スケールアウト時にタグを付けるだけで ルールを自動適用。
    • 注意点：タグ付与権限が広いと、不適切な付替えで意図せぬ開放 が起こりうる。命名規則・付与プロセスを標準化する。
  • サービスアカウント（SA）
    • メリット：権限付与の審査性 が高く、変更管理もしやすい。役割＝権限＝通信範囲 を一貫させやすい。
    • ベストプラクティス： “対象VM＝このSA” で括り、タグは補助（可視化・グルーピング）として使う。

図D：対象指定のベストプラクティス（SA主・タグ従）
図D：対象指定のベストプラクティス（SA主・タグ従）

図E：典型構成（LB背後のWebと管理アクセス）
図E：典型構成（LB背後のWebと管理アクセス）

  • 要点：公開は LB入口1点集中 ／VMは GFE・HCのみ許可。管理は IAP経由で直SSH/RDPを廃止。

ログで“効いているか”を確かめる

  • Firewall Rules Logging をONにし、許可・拒否のヒット状況 をダッシュボード化。
  • 代表的な使い所：
    • 初期展開後のサニティチェック（想定外の許可/拒否がないか）。
    • 優先度調整時の回帰確認（緩めたらどこが通ったか、厳しくしたら何が落ちたか）。
    • インシデント時のトレース（どの入口から、どの宛先へ通ったか）。

ありがちな落とし穴

  • 0.0.0.0/0 への広いIngress許可 ：緊急対応で開けて、そのまま放置しがち。期間限定＋社内IPに限定 か、LB/IAP越し に置き換える。
  • 優先度設計ミス：広いallow（priority 1000）が先に当たり、後段のdeny（priority 2000）が“死にルール”に。denyは小さな数値 で上に。
  • 対象の指定漏れ ：タグやSAを付け忘れ、ルール適用外 に。デプロイ時のポリシーチェック（CI/CD）で強制する。
  • Egress無制限 ：暗黙許可に甘えがち。宛先CIDR/ポートの制限、Cloud NATの固定送信元IP ＋ 送信先側の許可リスト で出口を締める。

チェックリスト

  • Ingressは原則拒否、例外のみallowの方針を明文化した
  • 優先度表（小さい数値＝厳しいルール） を作成し、チームで共有した
  • 対象の指定方法 は“SAを主／タグを従”で運用方針を決めた
  • 主要ルールに Firewall Rules Logging を有効化し、ダッシュボードを用意した
  • 一時開放の 期限運用（チケット＋自動クローズ）を整備した
  • Egress制御方針（必要宛先のみ許可、NATの固定IP化）を決めた

4-3. 【具体的な方法】鉄壁なファイアウォールルールの考え方

原則は「拒否から設計する」

  • デフォルト思想：Ingress は 全面拒否 から出発し、必要な通信だけを 最小範囲で Allow。
  • 粒度：CIDR・ポート・プロトコル・対象（タグ/サービスアカウント）をできるだけ 絞り込む。
  • 入口の一本化：直接VMを開けず、ロードバランサ / IAP / Bastion（踏み台） など“正規の入り口”経由に寄せる。

図F：優先度の型と階層（deny を高優先度＝数値小）
図F：優先度の型と階層（deny を高優先度＝数値小）

役割別テンプレ（まずはこれだけで強い）

以下は“最小で堅い”構成に必要なルール例です。名前・優先度は一例。

A. 全面拒否（基礎）

ルール名 優先度 方向 対象 ソース/宛先 プロトコル/ポート アクション 目的
ingress-deny-all 1000 Ingress 全VM（またはenvタグ） 0.0.0.0/0 all deny 入口を閉じる初期線
egress-deny-all（任意） 1000 Egress role-private など 0.0.0.0/0 all deny 出口も最小化（後段で例外許可）

B. 管理アクセス（“直接SSH”をやめる）

  • 推奨：IAP over TCP を使い、VMは22番を開けない。
  • どうしても必要な場合だけ、社内固定IPからの22番 を短期で開放（後述の“時間限定”運用）。
ルール名 優先度 方向 対象 ソース/宛先 プロトコル/ポート アクション 目的
ingress-ssh-admin（暫定） 100 Ingress role-admin 管理拠点CIDR tcp:22 allow 緊急時のみ。期限付き運用
ingress-iap-tunnel 100 Ingress 管理対象VM（SA/タグ） IAPプロキシ範囲 tcp:22,tcp:3389 等 allow IAP経由の管理（推奨）

C. Webバックエンド（LBの背後に置く）

  • VMをインターネットへ直公開しない。External HTTP(S) LB のバックエンドに接続し、LB/ヘルスチェックからの流入だけ 通す。
ルール名 優先度 方向 対象 ソース/宛先 プロトコル/ポート アクション 目的
ingress-allow-lb-proxy 100 Ingress role-web LBプロキシ（GFE） tcp:80,443 allow LB経由のみ受付
ingress-allow-hc 100 Ingress role-web ヘルスチェック送信元 tcp:80,443 allow HC通過
ingress-deny-web-other 200 Ingress role-web 0.0.0.0/0 all deny 上記以外を拒否

D. Privateワークロード（外向きだけ必要）

  • 受信は 全面拒否 のまま、必要な外向き通信 だけを許可。NAT出口を 固定IP化 し、送信先側での許可リスト と合わせて二重に締める。
ルール名 優先度 方向 対象 ソース/宛先 プロトコル/ポート アクション 目的
egress-allow-updates 900 Egress role-app ベンダ更新サイトCIDR tcp:80,443 allow パッケージ更新等
egress-allow-apis 900 Egress role-app 先方APIのCIDR tcp:443 allow 業務API
egress-deny-rest 1000 Egress role-app 0.0.0.0/0 all deny 例外以外は遮断

図G：LB 背後の Web（入口ルールの型：Allow を最小、その他は Deny）
図G：LB 背後の Web（入口ルールの型：Allow を最小、その他は Deny）

対象の指定は「サービスアカウントをメイン、タグは補助」

  • サービスアカウント（SA）指定：ロール付与・変更の監査性が高く、“誰が使うVMか”で通信を括れる。
  • ネットワークタグ：役割の可視化 と 自動適用 に便利。命名規則（role-web/env-prod）を固定し、付与権限を絞る。
  • ハイブリッド：SAで厳格に対象を縛り、補助的にタグで“用途別の共通ルール”を適用。

優先度設計の型（迷ったらこれ）

  1. 100：一時的/緊急の厳格ルール（deny/allow問わず）
  2. 200–400：サービス固有の許可（LB・HC・社内管理CIDRなど）
  3. 900：広めの許可（出庫先ホワイトリスト等）
  4. 1000：全面deny（フェイルセーフ）

ログと検証：設定して終わりにしない

  • Firewall Rules Logging を 重要ルールで有効化。ヒット状況をダッシュボード化し、想定外の通過/遮断 を早期発見。
  • 段階適用：環境（dev → stg → prod）で同一ルールを順に入れ、ログで差分 を確認してから本番に反映。
  • アラート：deny多発・新規ポート出現・0.0.0.0/0向け大量通信などを アラート化。

一時開放は“時間で無効化”

  • 原則：広い許可（例：0.0.0.0/0 への 22/3389 許可 等）は 禁止。
  • やむなし時：
    • 期限を必須（例：2時間）。
    • 自動化（チケット発行→承認→作成→ スケジュール削除）。
    • 代替策：IAP / VPN / 一時踏み台（内部のみ許可）へ早期切替。

図H：一時開放のライフサイクル
図H：一時開放のライフサイクル

IaC とガードレール（運用を壊れにくく）

  • Infrastructure as Code（Terraform/Blueprints）で ルールの差分管理。PRレビューで“広い許可”を機械的に弾く。
  • 標準モジュール化：role-web 用・role-app 用など 再利用テンプレ 化。
  • 階層型ファイアウォール（必要に応じて）：組織/フォルダ単位で 共通deny を上書き不能にして 下位の過剰許可を抑止。

よくある抜け穴と対策

  • ヘルスチェックの許可漏れ：バックエンドが常時UNHEALTHYに。LB/HC専用の許可 を必ず分離して定義。
  • タグ未付与：想定VMにルールが当たらない。デプロイ時にタグ/SA付与を必須化。
  • Egressの野放し：マルウェア通信・情報漏えいの温床。NAT固定IP + 宛先ホワイトリスト で絞る。
  • 優先度の逆転：広いallowが上に来て denyが死ぬ。“denyは小さく、allowは大きく” を習慣化。

チェックリスト

  • Ingress は 全面拒否 から設計し、例外のみ Allow にした
  • IAP を採用し、直接SSH/RDP を原則廃止した
  • LB配下のバックエンドは、GFE/HCのみ許可 にした
  • Private系は Egress ホワイトリスト ＋ Cloud NAT の固定IP で出口制御した
  • 主要ルールに Firewall Rules Logging を有効化し、ダッシュボードとアラートを整備した
  • ルールは IaC で管理し、広い許可をレビューでブロック する仕組みにした
  • 一時開放は 期限＋自動クローズ を徹底した

4-4. 外部IPアドレスなしで安全に通信する方法

全体像：外部IP“ゼロ”で叶える2系統の外部接続

  • 目的：VMに外部IPを付けずに、
    1. GoogleのAPI/サービス へ到達（例：Cloud Storage、BigQuery、Artifact Registry など）
    2. 一般インターネット の必要最小限（OSアップデート、外部API）へ到達
  • 方法：
      1. は Private Google Access（PGA） または Private Service Connect（PSC for Google APIs）
      1. は Cloud NAT（送信専用・着信不可）
  • ねらい：攻撃面の最小化（パブリック露出なし） と 出口制御の明確化（どこへ出るかを可視化・制限）。

ここからは Mermaid 記法で図を表しています。間違えがあったら一報いただけると助かります。

図I：外部IPなしパターンのアクセス（PGA / PSC / Cloud NAT）

Private Google Access（PGA）：Googleサービスだけ“内側から”使う

  • 役割：内部IPのみのVMが、GoogleのAPI/サービスに限り 到達できるようにするサブネット設定。
  • 特徴：
    • サブネット単位で有効化（対象サブネット内のVMに効果）。
    • VMに外部IPが無くても、GoogleのAPI/サービスには到達可。
    • 一般インターネット先には到達できない（別途Cloud NATが必要）。
  • 設計ポイント：
    • 対象の明確化：PGAは“GoogleのAPI/サービスのみ”。OSアップデート等の一般サイトには 効かない。
    • DNS設計：*.googleapis.com への解決を社内ポリシーで管理（後述PSCと併用する場合は 専用のDNSルール を定義）。
    • Egress制御：ファイアウォールで「Google API宛てのみ許可」を徹底。
  • 使いどころ：GKEノード/バッチVMが Artifact Registry / Cloud Storage 等へアクセスするケースなど、“Googleだけ出たい” に最適。

図J：PGAの論理経路

Private Service Connect（PSC for Google APIs）：完全プライベートIPでGoogle APIs

  • 役割：VPC内に 自分のプライベートIP で “Google APIs 専用エンドポイント” を作る方式。
  • メリット：
    • 宛先が VPC内のプライベートIP なので、インターネット経路を使わない アーキテクチャにできる。
    • ファイアウォールやルートで厳密制御 が可能（「そのIP以外は出さない」運用がやりやすい）。
    • VPC Service Controls 等の境界制御と相性が良い。
  • 設計ポイント：
    • DNSの上書き（Cloud DNS など）で *.googleapis.com をPSCエンドポイントのIPへ解決させる。
    • 可用性：リージョン内冗長／フォールトトレラントな設計を選ぶ。
    • PGAと比較：より厳格に“完全プライベート”を貫きたい／DNSで Google以外を遮断 したいときに有効。

図K：PSC（Google APIs）の論理構成とDNS上書き

Cloud NAT：一般インターネットの“送信専用ゲート”

  • 役割：内部IPのみのVMからの アウトバウンド通信 を、共有の 固定グローバルIP に変換してインターネットへ出す。
  • 着信は不可（= 入口リスクを持たない）。
  • 設計ポイント：
    • リージョン単位 にNATゲートウェイを作成（対象サブネット／ルーターを紐づけ）。
    • 固定グローバルIP を割り当て、送信元IPを一元管理（先方システムの許可リストに登録しやすい）。
    • 最小ポート数・スケール：トラフィック見積りに応じてポート確保方式（自動/手動）とログ有効化を設定。
    • Egressファイアウォール：宛先CIDR/ポートを ホワイトリスト で絞る。
  • 使いどころ：OS/パッケージ更新、外部SaaS/APIコールなど、“Google以外にも出たい” 場面。

図L：Cloud NATの論理構成（固定送信元IP）

比較表（早見表）

項目 Private Google Access (PGA) Private Service Connect (PSC for Google APIs) Cloud NAT
主目的 Google APIs/Services のみへ到達 Google APIs を VPC内IP で私設エンドポイント化 一般インターネットへの送信
経路 Google バックボーン経由 VPC内VIP → Google バックボーン 共有の固定グローバルIPでNAT
受信 なし なし なし（送信専用）
DNS要件 任意（PSC併用時に調整） 必須（*.googleapis.com をVIPへ上書き） 不要
使いどころ “Googleだけ出たい” 完全プライベート＋境界厳格化 OS更新・外部API 等

組み合わせの定石（パターン集）

パターンA：Googleのみへアクセス（最小構成）

  • PGA 有効化（サブネット）
  • Egress FW：Google API宛てのみ許可、他は拒否
  • Cloud NAT 不要（一般インターネットには出ない）

パターンB：Google + 一般サイト少し（アップデート等）

  • PGA + Cloud NAT（両方）
  • Egress FW：Google API + 既知アップデートサイト等の最低限のみ許可
  • Cloud NATの送信元IP固定 → 先方の 許可リスト 登録で二重に締める

パターンC：完全プライベートでGoogle APIs（より厳格）

  • PSC for Google APIs を作成
  • DNS上書きで *.googleapis.com を PSCのプライベートIP に解決
  • Egress FW：PSCのIP以外は拒否
  • （一般サイトが不要なら Cloud NATなし でOK）

パターンD：オンプレからもGoogleへ（ハイブリッド）

  • VPN/Interconnect 経由でVPCへ接続
  • オンプレからは PGA for on-prem または PSC for Google APIs を選択
  • オンプレFWで宛先を Google APIに限定

パターン対応表（要素の有無）

パターン PGA PSC for Google APIs Cloud NAT DNS上書き 代表用途
A ✓ － － － Googleのみ
B ✓ － ✓ － Google + 一般少し
C － ✓ － ✓ 厳格な境界
D ✓/－ ✓/－ 任意 場合により ハイブリッド

参考フロー（最低限のステップ）

PGAルート（パターンA）

  1. 対象サブネットで Private Google Access を有効化
  2. Egressルール：Google API宛て以外を deny（段階的に導入）
  3. 動作テスト（Cloud Storage へのアクセス等）

PGA + NAT（パターンB）

  1. 上記に加え Cloud NAT を作成（固定グローバルIP）
  2. Egressルール：必要サイトのみ allow、最後に deny all
  3. 先方／外部サービスに 送信元IP（Cloud NATのIP） を登録

PSC（パターンC）

  1. PSCエンドポイント を作成（対象リージョン）
  2. DNS上書き：*.googleapis.com → PSCのIP
  3. Egressルール：PSCのIP以外を deny（Google以外への出口を消す）

ありがちな抜け穴と対策

  • 便宜的に外部IPを付与：スキャン・攻撃面が増大。→ 全面禁止を標準 に。例外は期限付き。
  • 自前NATインスタンス：スケール/冗長/保守の負債。→ Cloud NAT を使用。
  • Egress無制限：情報流出・マルウェアの踏み台に。→ 宛先ホワイトリスト ＋ NAT固定IP ＋ ログ/アラート。
  • DNS未設計（PSC時）：*.googleapis.com が外へ出てしまう。→ 必ずDNS上書き。
  • リージョン考慮漏れ：Cloud NATはリージョン単位。→ 各リージョンで作成 し、対象サブネットを明示。

チェックリスト

  • VMは外部IPなしを標準化し、例外は 申請＋期限 にした
  • PGA を必要サブネットで有効化し、Google APIのみ許可 のEgressポリシーを定義した
  • 一般サイトが必要な箇所は Cloud NAT（固定グローバルIP） を用意し、宛先ホワイトリスト で絞った
  • ログ（Firewall/NAT）を有効化し、不審な宛先・ポート をアラートにした
  • DNS設計（PSC利用時の *.googleapis.com 上書き、名前解決の可用性）を文書化した
  • ハイブリッド環境では オンプレ側FW と VPC側ルール の整合を確認した

4-5 まとめ

本回では、Google Cloudにおけるネットワークセキュリティの基礎となるVPCとファイアウォールについて、下記を解説し、セキュアなネットワークの土台を固めました。

  • プライベート空間であるVPCの設計思想として、デフォルト VPC を避け、カスタム VPC で必要なリソースだけを定義する重要性
  • 通信制御の要であるファイアウォールでは、「すべてを拒否し、必要な通信だけを最小限許可する」という基本アプローチ
  • ネットワークタグやサービスアカウントを用いた鉄壁なルール設定
  • VM に外部IPアドレスを付与せず、Private Google Access や Cloud NAT を活用して安全に外部と通信する

しかし、組織でプロジェクトの数が増えてくると、VPCが乱立し、管理が複雑化するという新たな課題が生まれます。
第５回は、この課題を解決し、ネットワーク管理を一元化するための強力なソリューション、「Shared VPC」の設計パターンを解説します。

4-6 参照情報（公式ドキュメント）

本章では、第4回の内容（VPC 構成、ファイアウォール、NEG と Cloud Load Balancing、Private Google Access／PSC、サーバレス各種エンドポイント連携）に直接ひもづくGoogle Cloud 公式ドキュメントのみ を掲載します。

VPC の基本と設計

ファイアウォール（セキュリティ ベストプラクティス）

NEG と Cloud Load Balancing

Private Google Access／Private Service Connect（Google APIs）

サーバレス各種エンドポイントと VPC 連携

ハイブリッド接続・エグレス

アクセス制御の強化（周辺機能）

IaC／Blueprint（再現性ある展開）

電算システム 有志
電算システム 有志Publication

株式会社電算システムのエンジニアを中心に情報発信をしている Publication です。各記事の内容は個人の意見であり、企業を代表するものではございません。

Discussion