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

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

SKY(Tomoaki Sekiya)
に公開
Security
Google Cloud
networking
Shared VPC
intermediate
tech

第5回 はじめに: Shared VPCで『安全を量産する』

はじめに

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

ここまでで「セキュリティの地図」を敷き、リソース階層（第2回）→IAM 最小権限（第3回）→VPCとファイアウォール／外部IPゼロ運用（第4回） と、プロジェクト単体を安全に動かす基礎を固めてきました。
第5回 では、プロジェクトが増えても“同じ安全性をブレずに保つ”ための鍵、Shared VPC（共有VPC） に踏み込みます。

Shared VPC は、ネットワークを ホストプロジェクトに集約 し、各システムは サービスプロジェクトに分離 するモデルです。これにより、

  • ポリシーの一元適用 （ファイアウォール／Cloud NAT／PGA／PSC などの“共通ハブ化”）
  • IP計画の一貫性 （CIDR 競合や行き当たりばったりを防止）
  • 最小権限の徹底 （誰が“使うだけ”で、誰が“構成を変えられるか”を厳密に分離）
    を実現できます。結果として、運用の再現性・監査性・拡張性が大幅に向上します。

今回の読みどころ

  • プロジェクト増加で起きる“VPC乱立”と 何が困るのか を整理
  • Shared VPC の基本（ ホスト／サービス／共有サブネット の関係と責任分担）
  • 現場で使える 代表構成パターン（全社基盤／環境分離／部門分割）を長所短所つきで提示
  • 権限設計とガードレール （Network Admin/Network User の線引き、階層型FWやOrg Policyとの合わせ技、申請〜委譲フロー）

それでは、**Shared VPC で「安全を量産する設計」**を、実務の目線で組み立てていきましょう。

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

本編
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/9ad6777c0c01bd

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

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

5-1. プロジェクトが増えたときの課題：VPCが乱立する問題

要点

まずは30秒で「何が問題か」を掴みましょう。

  • VPCは「プロジェクト内の私設ネットワーク」。
  • プロジェクトが増えると、各チームがそれぞれVPCを作りがち。
  • バラバラに作ると、IPがぶつかる／つなぎ方が複雑／統制が効かない。
  • 次節の Shared VPC を使うと、中央で一元管理でき、乱立を防げます。

用語ガイド

初見でつまずきやすい言葉を、ここで一気に揃えます。本文はこの前提で読み進められます。

  • VPC（Virtual Private Cloud） ：プロジェクトごとの仮想ネットワーク。サブネットやルート、FW（ファイアウォール）を持つ“土台”。
  • CIDR ：IP帯の表記（例：10.10.0.0/16）。重複するとネットワーク同士が正しくつながらない。
  • VPC Peering ：VPCとVPCを直接つなぐ機能。ただし非推移（A–B・B–Cを結んでも、A–Cは自動で通らない）。
  • Shared VPC ： 中央のVPC（ホスト） にネットワークを集約し、各アプリは別プロジェクト（サービス） で動かす方式。中央のVPCをネットワーク管理権限をもった管理者が一元管理する。

症状：いつの間にか「VPCの乱立」

現場で実際に起きる“困りごと”の形を、イメージしやすく列挙します。

  • チームや案件ごとにプロジェクトが独立 → それぞれが独自VPCを作成
  • CIDR設計が場当たり的（/24を継ぎ足し、将来の拡張余白なし）
  • プロジェクト間連携が増え、VPC Peeringが蜘蛛の巣状に増殖
  • 監査や可観測性はプロジェクト単位で断片化、横断把握が困難

VPC-A:10.10.0.0/20：10.10.0.0 ～ 10.10.15.255
VPC-B:10.10.48.0/20：10.10.48.0 ～ 10.10.63.255 (VPC-Cに含まれる=競合)
VPC-C:10.10.32.0/19：10.10.32.0 ～ 10.10.63.255

図A：VPCの乱立（各プロジェクトで勝手にVPC作成）

なぜ起こるか：構造的な原因

「悪意がなくても起こる」理由を、組織と設計の観点で分解します。

  • 「プロジェクト＝管理境界」という性質：各チームが独立して完結しやすい
  • 初期は少人数・少規模で、短期の俊敏さを優先 → 長期の集約設計が後回し
  • **ネットワークの共通部品（NAT/PGA/PSC/Firewalls）**が無く、各自が都度構築
  • 権限設計が未整備で、Network Admin 権限を広く配布 → 各所で自由にVPC新設

何が困るか：具体的なリスク

全体を俯瞰できるよう、短期と中長期を分けて“見える化”します。

表：リスク表

観点 典型症状 リスク（短期） リスク（中長期） 監査・検知の例
IP設計 CIDR重複・余白不足 連携ブロック、再設計工数 ハイブリッド/Peering拡張が詰む 失敗ルート/重複CIDR検出
接続 Peering が多数・複雑 伝搬漏れ/到達性不具合 経路のブラックボックス化 到達性テスト失敗率上昇
セキュリティ FWポリシーがバラバラ 設定抜け・広い許可混入 統制不能、監査指摘 ルール差分の逸脱検知
監査/運用 ログ・設定が分散 横断調査に時間 インシデント時の初動遅延 監査ログの欠損/分散
コスト 共通機能を都度構築 重複費用 運用負債の固定化 リソース重複率の悪化

“接続の複雑化”の実態：点と点をむりやり結ぶ

ネットワークで誤解しやすいポイントを、図で直感的に理解します。

  • 開発A ⇄ 共通B ⇄ 分析C … のような 多対多連携 が後から増える
  • VPC Peering は非推移 のため、中継用の道 が増える
  • VPC間に 個別の許可・ルート・名前解決 が必要となり、保守コストが逓増

図B：個別VPC間のPeering接続増加の課題

早期に現れる“危険信号”（チェック項目）

“軽症のうちに手を打つ” ための早期サインです。5つの問いでセルフチェックしましょう。

  • VPC数 > プロジェクト数 （一部でVPCを乱立させていないか）
  • 同一リージョンに /24 を乱立 （拡張余白が無い）
  • Peeringの数が二桁 （設計の限界サイン）
  • Cloud NAT/PGA/PSC/Firewall が 各プロジェクトでバラバラ
  • Network Admin を 広く配布 （設計者以外もVPC新設可能）

章のまとめ

本章では下記のことを解説しました。

  • VPCの乱立は 偶然 ではなく、構造的に起こる
  • 問題は単なるIPの器ではなく、ポリシー・出口・監査の一貫性が失われる こと
  • Shared VPC により、ネットワークの中央集約（ホスト） と アプリの分離（サービス） を進め、 “共通部品のハブ化” （NAT/PGA/PSC/Firewall/Logging）で 統制と再現性 を取り戻す

代表的な質問と回答

Q1. 「CIDRがぶつかる」とは？
A. 例として 10.10.0.0/16 を本社で使っていて、別チームが独断で同じ帯を使ったVPCを作ると、ルーティングが矛盾し、VPC間やオンプレ接続で通信できない事態が起きます。

Q2. Peeringを増やせば解決しないのか？
A. 一時的にはつながりますが、非推移のため組み合わせ爆発が起こりやすく、運用が破綻します。

Q3. どう防げばいい？
A. 次節で扱う Shared VPC を使い、ネットワークを中央（ホスト）に集約して、各アプリは別プロジェクト（サービス）へ分離するのが定石です。IP台帳の一元管理や共通の出口（Cloud NAT / PGA / PSC）、共通FWポリシーで統制が効きます。

5-2. 解決策としての Shared VPC — “ネットワークを中央で、アプリは個々で”

要点

「Shared VPC」のポイントを選びましょう。

  • Shared VPC は、 ネットワーク資産（VPC/サブネット/出口）を“ホストプロジェクト”に集約 し、
    アプリは“サービスプロジェクト”で分離 して動かす仕組み。
  • ねらいは、 一貫したポリシー・IP計画・出口管理 を 中央で 保ちつつ、 各チームの開発は自律的 に進めること。
  • 本回でのポイントは、 “中央（共通） と “個別（チーム）” の境界線を正しく引くことです。

ホスト／サービス／共有サブネットの基本構造

それぞれの関係をイメージしましょう。

図C：Shared VPC の全体像（ホストがネットワークを持ち、サービスが使う）

  • ホストプロジェクト ：VPC、 共有サブネット 、 出口（Cloud NAT） 、 Google向け私設接続（PGA/PSC） 、 FW/ログ など “共通部品”の家 。
  • サービスプロジェクト ：アプリやジョブをデプロイする 居室 。 自前でVPCは持たず 、ホストのサブネットを “借りて” 使う。
  • 権限の分離 ：ネットワークを 変えられる人 と、ネットワークを 使うだけの人 を分けるのが Shared VPC の根幹。

役割と権限の線引き（最小権限が崩れない設計）

“誰がどこまでできるか”を先に決めることは非常に重要になります。

対象 主な責務 代表ロール（例） 説明（実務の落とし穴も添えて）
中央ネットワーク運用（ホスト側） 共有サブネットの作成・管理、FW/ルート、NAT/PGA/PSCの共通ハブ、ログ集約 Network Admin, Security Admin やりすぎ権限の配布禁止 。一括変更の影響が広いので 申請フロー 必須。
アプリ運用（サービス側） VM/GKE/Runの作成・更新、LB/NEGのバックエンド構成、必要最小限のFW適用 Compute Admin（限定的）, Network User compute.networkUser の付与範囲は“使うサブネットだけ” に。ホスト全体へ広げない。
監査・可視化 監査ログの横断収集、逸脱検知、コストの横断把握 閲覧系ロール＋監査固有権限 Shared VPCは “見える化の前提” 。まずログの行き先を決め、欠損をゼロに 。

メリット（なぜ Shared VPC が効くのか）

“何が嬉しいか”を技術と運用の両面から解説します。

  1. IP計画の一貫性
  • サブネットはホストで集中管理＝CIDR重複を未然に防止。
  • 追加時も台帳とポリシーに沿って増設できる。
  1. セキュリティポリシーの一元適用
  • FWルール／階層型FW／Org Policyを同じ基準で適用。
  • 外部IP“ゼロ”運用、PGA/PSCやCloud NATと組み合わせて出口を細く保てる。
  1. 運用・監査の可視化
  • Firewall/NAT/アクセスのログを共通で集約→横断で追跡しやすい。
  • 逸脱検知（広い許可、想定外の出口）が早期に分かる。
  1. チームの自律性を確保
  • ネットワークは中央で守りつつ、デプロイやスケールは各チームの裁量で素早く。
  • “共通部品”に乗せることで、環境ごとの差異が減る。

Shared VPC と代表ユースケース

どんな場面でベストフィットするか。

  • 全社ネットワーク基盤 ：共通の NAT / PGA / PSC を 一か所に 置き、各事業のサービスプロジェクトが 借りて使う 。
  • 環境分離 ：host-prod と host-nonprod を分け、 事故の波及 と 変更渋滞 を最小化。
  • サーバレス&GKE連携 ： Serverless VPC Access のサブネットをホストで供出、 GKE は二次範囲（Pods/Services） を計画的に割り当て。

図D：環境分離の例（本番と非本番でホストを分ける）

入口・出口・観測の“共通ハブ化”

出入口を Shared VPC で 一括 管理します。

  • 入口 ：External/Internal LB、 GFE/HC 許可レンジ 、 IAP の“正しい入口”を 標準化 。
  • 出口 ： Cloud NAT の固定送信元IP＋ 宛先ホワイトリスト で 最小エグレス を維持。
  • Google向け私設接続 ： PGA / PSC（Google APIs） で 外部IP無し を徹底。
  • 観測 ：Firewall/NAT/Load Balancer の ログ必須化 と 集約先の標準 を定める。

図E：共有ハブ（NAT/PGA/PSC/Logging）に“一本化”する

よくある設計ミス

“しくじり先生”にならない為に、”先にできない様にしておく”が近道です。

  • compute.networkUser をホスト全体に付与 ：本来“使えるサブネットだけ”に限定するロール。
  • 中央FWより前で個別例外を量産 ：例外は 期限付き ・ 根拠ログ付き に。
  • ログの行き先未定 ：あとから集約は難しい。最初に集約先（プロジェクト/バケット/テーブル）を決める 。
  • GKE/Serverless VPC のアドレス計画不足 ： 二次範囲（Pods/Services） や Serverless VPC Accessサブネット を 先に確保 。
  • ホスト一本で全部抱える ： 本番/非本番 や リージョン で ホストを分割 し、変更渋滞を回避。

チェックリスト

導入プロジェクトの “Go” 判定に使えます。

  • ホスト/サービスの役割とロール を文書化し、誰が何を変えられるか を明確にした
  • 共有サブネット の命名・IP計画（将来拡張の余白／重複禁止）を決定した
  • Cloud NAT / PGA / PSC / IAP / LB の 標準パターン を定義した
  • Firewall／階層型FW／Org Policy の ガードレール を適用した
  • ログ集約 （Firewall/NAT/LB/管理操作）と アラート の行き先を決めた
  • GKE/Serverless の前提（Secondary/Serverless Access） を設計に織り込んだ
  • 例外申請→期限自動クローズ の運用フローを用意した

章のまとめ

これから実際にどう組むかをまとめます。

  • Shared VPC は、中央（ネットワーク） と 個別（アプリ） の責務を分離し、一貫したセキュリティと運用再現性 をもたらす設計。
  • 入口・出口・観測を 共通ハブ化 し、権限は 最小限 で委譲するのが肝。

5-3. 【具体的な方法】Shared VPC の代表的な構成パターン

要点

本章のポイントを記載します。

  • Shared VPC は「 ネットワーク＝中央（ホスト） 」「 アプリ＝各プロジェクト（サービス） 」。
  • 代表パターンは 全社共通基盤型 ／ 環境分離型（prod と nonprod でホスト分割） ／ 部門分割型（事業部ごと） の三つ。
  • 迷ったらまず 環境分離型 （prod/nonprod を分ける）から始め、必要に応じて部門ごとにホストを増やすのが定番です。

パターンA： 全社共通基盤型 （ホスト1つに全社が相乗り）

最小コストでクイックに始められます。小規模から始める時に向いています。

概要

  • ホストプロジェクト：1 （共通ネットワーク中枢）
  • サービスプロジェクト：複数 （各チーム／各システム）
  • 共通部品 （Cloud NAT / PGA / PSC / ログ集約 / FW）を“1か所”に集約

長所／短所（サマリ）

  • ✅ 共通部品を一度作れば 全チームが再利用 、運用コストが低い
  • ✅ ガバナンス一元化 （FW・出口・ログが揃う）
  • ⚠️ 変更渋滞 が起きやすい（ホストの変更申請が集中）
  • ⚠️ 事故時に 影響範囲が広い （prod/nonprod が同居だと特に）

図F：全社共通基盤型の全体像

パターンB： 環境分離型 （prod と nonprod でホストを分割）

実運用の負荷を減らす主流のパターンです。迷ったらひとまずこちらを選択する。

概要

  • ホストプロジェクト：2 （host-prod と host-nonprod）
  • 本番と非本番で ネットワーク中枢を分離 し、変更／事故の相互影響を低減
  • サービスプロジェクトは、それぞれの 環境に対応 するホストからサブネットを“借りる”

長所／短所（サマリ）

  • ✅ 変更渋滞の解消 （nonprod 側で先に検証→反映）
  • ✅ 事故の波及を遮断 （prod の安全性を高めやすい）
  • ⚠️ 共通部品を環境ごとに二重化 （管理対象がやや増える）
  • ⚠️ 環境間の横断通信（例：stg→prod）は 明示のコントロール が必要

図G：環境分離型（prod / nonprod でホスト分割）

パターンC： 部門分割型（事業部ごとにホストを分ける）

大規模組織で“独立性”と“責任分界”を強めたいときに選択する。

概要

  • ホストプロジェクト：複数（部門ごと）
  • 事業部／領域ごとにホストを分割し、 IP計画やFW方針 の裁量を各部門に委譲
  • 共通基盤チームは 最小限のガードレール （Org Policy／階層型FW／アドレス台帳）に集中

長所／短所（サマリ）

  • ✅ スケールしやすい （部門単位で自律運用）
  • ✅ 変更速度が上がる （各部門の意思決定で即反映）
  • ⚠️ 横断統制の難易度上昇 （方針ドリフトの監視が必須）
  • ⚠️ 共通設計のばらつき （命名・ログ集約先・出口設計の標準が崩れやすい）

図H：部門分割型（部門ごとにホスト分散＋中央ガードレール）

3パターン比較（選定の観点）

パターンと適用材料を一覧にすると下記の様になります。

観点 全社共通基盤型 環境分離型 部門分割型
初期整備コスト 最小 中 大
ガバナンス一貫性 高 高（環境内） 中（中央の基準次第）
変更渋滞の回避 低 中〜高 高
事故影響の局所化 低 高（prod隔離） 中（部門内で局所化）
スケーラビリティ 中 中〜高 高
向いている組織 小〜中規模 ほぼ全般 大規模・事業多角化

実装の“型”

まずは、下記のような項目を先に決定しておくことを推奨します。

  • 命名規則 ：host-{env|dept}、sub-{region}-{env}-{tier}、svc-{system}-{env}
  • 権限 ：compute.networkUser は “使う共有サブネットだけ” にスコープ限定。ネットワーク定義を変える権限は ホスト側に限定 。
  • 共通ハブ ：Cloud NAT（固定送信元IP）、PGA/PSC、IAP/正しいLB入口、 Firewall/階層型FW を ホストに集約 。
  • ログ ：Firewall/NAT/LB/管理操作は 欠損ゼロ で集約（フォーマット・保存期間・参照権限を標準化）。
  • アドレス計画 ： 余白（/16〜/20単位） を確保。 GKE二次範囲 と Serverless VPC Access 用サブネットは 先行確保 。
  • 例外運用 ：期限付き・承認必須・ 自動クローズ （IaC＋タイマー）を標準化。

よくある落とし穴

  • prod と nonprod を同居 ：本番の変更窓が狭まり、 渋滞 と 事故波及 の温床に。→ 環境分離型 へ
  • ホスト全体に networkUser 付与 ：サービス側が“どの共有サブネットでも”使えてしまう。→ 必要サブネットに限定 。
  • ログ集約が後回し ：横断調査が不能に。→ 最初に行き先と保持期間を決定 。
  • GKE/Serverless のアドレス不足 ：二次範囲や Serverless VPC Access 帯の後付けで再設計に。→ 先行設計
  • Peering前提の設計 ：Shared VPC で 同一VPC内 に寄せて 非推移問題を回避 。

導入チェックリスト

  • パターン（A/B/C）の 採用理由 と 将来の拡張方針 を文書化した
  • 命名・権限・ログ・出口設計 の標準を合意し、テナントに配布した
  • IP台帳 に Shared Subnet / GKE 二次範囲 / Serverless VPC Access 帯を登録した
  • 例外申請→期限自動クローズ を IaC と合わせて用意した
  • ステージングで 展開→検証→本番反映 の手順を回し、 ロールバック を準備した

本章のまとめ

本章までは基本的な設計を解説しました。

  • 3パターンの核は、“中央で共通部品・方針を握る” ことと、**“サービス側の自律性を保つ”**ことの両立。

5-4. Shared VPC を導入する際の注意点（“壊れにくい運用”の作り方）

要点

「Shared VPC」 を“動かすだけ”から“安全に回し続ける”へ。失敗は設計より運用に潜みます。ここでは“壊れにくい”ルールと型を先に固めます。

  • 役割分離 ：ネットワークを 変えられる側（ホスト） と 使うだけの側（サービス） を明確化。
  • 最小権限 ：compute.networkUser は “必要な共有サブネットだけ” に付与。
  • ガードレール ：階層型FW／Org Policy／ログ集約を ホスト側で標準化 。
  • 変更は慎重に ：Shared VPC は 影響範囲が広い ため、申請→検証→段階反映→ロールバック を定型化。

1) 役割と権限の線引き（最小権限の徹底）

“誰がどこまでできるか”を文書で先に決定して、セキュリティインシデントの最小化につなげる。

項目 ホスト（中央運用） サービス（各アプリ） 初級者むけ補足
ネットワーク定義（VPC/共有サブネット/ルート/FW） 作成・変更 参照のみ 定義を変えるのは中央のみ。サービス側は“借りて使う”。
出口・入口（Cloud NAT / PGA / PSC / IAP / LB基準） 標準化・提供 標準に沿って利用 “共通ハブ”に乗せるほど安全性と再現性が高まる。
ロール付与 Network Admin/Security Admin（限定） Compute Admin（限定） / compute.networkUser（特定サブネットだけ） networkUser をホスト全体に付与しないことが最大ポイント。
ログ・監査 集約・可視化・逸脱検知 参照（必要範囲） ログ欠損＝事故時に見えない。最初に集約先を決める。

よくあるNG

  • compute.networkUser を ホスト全体 に付与 → 予期せぬサブネット利用が可能に。
  • サービス側が 独自NATや独自FW を勝手に作成 → 統制不能。

2) ガードレールの三本柱（入口・出口・監査を“中央で握る”）

Shared VPC の真価は、共通ハブ化にあります。

  1. 入口：正しい入り口を標準化

    • External/Internal LB、IAP、GFE/ヘルスチェック許可レンジを テンプレート化 。
    • 直SSH/RDP禁止 を徹底（IAP 経由＋踏み台不要の前提へ）。

  2. 出口：最小エグレス

    • Cloud NAT （固定送信元IP）＋ 宛先ホワイトリスト 。
    • Private Google Access（PGA）／Private Service Connect（PSC for Google APIs） で 外部IPなし 運用。

  3. 監査：見える化の前提づくり

    • Firewall/NAT/LB/管理操作ログを 欠損ゼロで集約 （保存場所・保持期間・閲覧権限を標準化）。
    • 逸脱（広すぎる許可、想定外の宛先）を 自動検知 。

図I：共通ハブ化の俯瞰（入口・出口・監査をホストで一括）

3) 変更が難しい前提での“安全な進め方”

Shared VPC のミスは影響が大きいため、最低限やっておくべき事があります。

  • 申請→レビュー→適用の三段階 ：影響範囲（利用サブネット／依存システム）を明記。
  • 検証は nonprod で先行 ：host-nonprod にまず適用し、観測（ログ/メトリクス） で無害を確認。
  • 段階反映 ：小さな変更単位で、本番へ 時間差 ロールアウト。
  • ロールバック常備 ：Terraform の plan/apply と state管理 、 差分の事前レビュー を運用に組み込む。
  • 変更ウィンドウ ：時間帯・影響系統の 明示ルール を持つ。

図J：ネットワーク変更の“安全運用”シーケンス

4) アドレス計画とサーバレス/GKEの“先行確保”

後から枯渇して詰む前に、余裕 と 二次範囲 を先に用意しておく。

  • IP余白の確保 ：/16〜/20 単位で将来の拡張を見込む。
  • GKE ： Secondary Range（Pods/Services） を ホスト側で予約 。
  • Serverless VPC Access ：専用サブネットを ホストで提供 （/28〜/24 余白計画）。
  • 名前解決（DNS） ：PSC（Google APIs）を使う場合は *.googleapis.com の 上書き ルールを標準化。

IAM × Shared VPC：典型ロール設計

ロールは“少なく・固定化”が原則。人ではなく グループ単位 で付与する。

ロール 付与対象 スコープ ポイント
roles/compute.networkAdmin ネットワーク中央運用チーム ホスト 共有サブネット／ルート／NAT／FW を集中管理。
roles/compute.securityAdmin セキュリティ運用 ホスト FW/SSLポリシー等の変更権限を分離。
roles/compute.networkUser 各サービスチーム 該当共有サブネットのみ ここを広げない。プロジェクト全体・ホスト全体はNG。
roles/compute.admin（限定） サービス運用 サービスPJ VM/GKE/Run のライフサイクル。ネットワーク定義は触らない。

よくある落とし穴と回避策

  • ホスト一本に prod / nonprod 同居 → 変更渋滞＆波及拡大： 環境分離 で緩和。
  • networkUser をホスト全体に付与 → 横断利用が可能に： 共有サブネット単位 へ限定。
  • ログの行き先未定 → 事故時に追跡不能： 最初に集約先と保持期間を決定 。
  • 自前NATの乱立 → 統制不能＆出口不明： Cloud NAT（固定送信元IP） へ集約。
  • DNS無計画（PSC時） → Google APIs への経路が外へ： 上書きルール標準化 。

チェックリスト

これらをチェックしましょう。“壊れにくい”導入の基礎が整っています。

  • 役割分離 （誰が定義を変え、誰が使うか）を文書化した
  • networkUser のスコープ を「必要サブネットのみ」に限定した
  • 入口・出口・監査の共通ハブ （LB/IAP、Cloud NAT＋PGA/PSC、Logging）を標準化した
  • nonprod→prod の段階反映 と ロールバック手順 を IaC とセットで整備した
  • IP余白／GKE二次範囲／Serverless VPC Access 帯 を先行確保した
  • DNS上書き（PSC利用時） と FW/Org Policy のガードレールを適用した
  • ログ欠損ゼロ （Firewall/NAT/LB/管理操作）を確認し、逸脱検知ルールを用意した

章のまとめ

  • Shared VPC を 安全に回し続ける には、 役割分離・最小権限・共通ハブ化 の三点を“運用の型”に落とすことが不可欠。
  • 変更は nonprod 先行→段階反映 、 ロールバック常備 で“壊れない”流れを作る。

5-5. まとめ

プロジェクトが増えると各チームでVPCが個別に作られ、CIDRの重複や VPC Peering の複雑化、ルールやログの分散により統制・監査が難しくなります。
対策としては、Shared VPC によりネットワークをホスト側に集約し、サービス側は共有サブネットを“借りて”利用します。入口（LB/IAP）・出口（Cloud NAT＋PGA/PSC）・監査（ログ）を共通ハブ化し、権限は最小限（networkUser は必要サブネットのみ）に絞るのが要点です。
構成は全社共通／環境分離／部門分割が基本 で、まずは 環境分離から始める と無理がありません。

次回は、これらを支える 組織レベルのガードレール（ポリシー）設計 へと進み、危険な設定を未然に抑止する方法を整理します。

5-6. 参照情報

Shared VPC（中核）

VPC・接続の基礎

入口（Ingress）

出口（Egress）・Google API への私設接続

サーバレス/GKE とアドレス計画

ファイアウォールと監査・可視化

IAM ロール（最小権限の前提）

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

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

Discussion