Google Cloud
ネットワークセキュリティ
実践ガイド
VPC・ファイアウォール・IAM・IAP・ロードバランシング・Cloud Armor。 「なぜそうするのか」を理解したうえで、安全なネットワークを自分で設計・構築できるようになるための、初学者向けステップバイステップ解説です。
全体像 — このガイドで学ぶこと
クラウド上で動くアプリを安全に運用するには、「誰が・どこから・どのリソースに・どのポートで」アクセスできるかを厳密にコントロールする必要があります。Google Cloud では、この制御を複数のレイヤーで実現します。
| レイヤー | 役割 | 主なサービス |
|---|---|---|
| ネットワーク分離 | 環境を隔離し、通信境界を作る | VPC / サブネット |
| パケットフィルタ | IP・ポート単位で許可/拒否 | ファイアウォールルール |
| ID ベースアクセス | 「誰が」操作できるかを制御 | IAM / サービスアカウント |
| ゼロトラスト接続 | 外部 IP なしで安全に管理アクセス | Identity-Aware Proxy (IAP) |
| トラフィック分散 | 可用性とスケーラビリティ | ロードバランサ |
| エッジ防御 | L7 攻撃をバックエンド到達前に遮断 | Cloud Armor |
図 1-1 — 各サービスの連携。外部通信は必ず「エッジ → ファイアウォール → バックエンド」の順に通過する。
各レイヤーで「不要な通信を落とす」ことが、多層防御 (defense in depth) の基本です。1 か所が突破されても、次の層で止められる構成を目指します。
VPC ネットワークの基礎
2-1. VPC とは何か
VPC (Virtual Private Cloud) は、Google Cloud 上に作る論理的に隔離された仮想ネットワークです。物理データセンターを意識せず、IP 範囲・サブネット・ルーティング・ファイアウォールを自分で設計できます。
VPC は既定で「隔離されたプライベートネットワーク」です。異なる VPC 同士は、たとえ同じリージョンでも内部 IP では通信できません。この隔離こそがセキュリティの第一歩です。
2-2. 自動モード vs カスタムモード
| 項目 | 自動モード (Auto) | カスタムモード (Custom) |
|---|---|---|
| サブネット作成 | 全リージョンに自動生成 | 自分で必要な分だけ作成 |
| IP 範囲 | Google が自動割り当て | 自分で CIDR を指定 |
| 向いている用途 | 検証・学習 | 本番環境 |
| 制御の自由度 | 低い | 高い(推奨) |
本番環境ではカスタムモードを使います。サブネットを意図的に設計することで、IP の重複を防ぎ、リージョン配置を明示的に管理できます。
2-3. カスタム VPC を作る(コンソール / gcloud)
コンソールでの基本手順は次のとおりです。
| # | 操作 |
|---|---|
| 1 | ナビゲーションメニュー → VPC ネットワーク |
| 2 | VPC ネットワークを作成 をクリック |
| 3 | 名前を入力(例: privatenet) |
| 4 | サブネット作成モードで カスタム を選択 |
| 5 | サブネット名・リージョン・IPv4 範囲(例: 172.16.0.0/24)を指定 |
| 6 | 作成 をクリック |
# カスタムモードの VPC を作成gcloud compute networks create privatenet --subnet-mode=custom# サブネットを作成(リージョンと CIDR を明示)gcloud compute networks subnets create privatesubnet-1 \--network=privatenet \--region=us-central1 \--range=172.16.0.0/24
コンソールの「同等のコマンドライン」ボタンで、設定内容を作成前に gcloud コマンドとして確認できます。これを Infrastructure as Code (IaC) 化の出発点にすると再現性が高まります。
2-4. ネットワーク間の通信ルール — 3 原則
図 2-1 — 内部 IP での疎通可否。
| ケース | 内部 IP での疎通 | 理由 |
|---|---|---|
| 同じ VPC 内(別ゾーン・別リージョンでも可) | ✅ 可能 | VPC はグローバルリソース。内部通信が許可されている |
| 異なる VPC 間 | ❌ 不可 | VPC は既定で隔離される |
| 外部 IP 経由 | ファイアウォール次第 | ICMP/SSH を許可していれば疎通する |
異なる VPC 間で内部通信したい場合は VPC ピアリング または Cloud VPN を別途設定します。「同じリージョンだから通信できるはず」という思い込みは事故のもとです。
2-5. 複数ネットワークインターフェース(マルチ NIC)
1 台の VM に複数の NIC を持たせ、複数の VPC に同時接続できます(インスタンスタイプにより最大 8 個)。ただしデフォルトルートは primary インターフェース (eth0) のみに紐づきます。直接接続されたサブネット以外への通信は、すべて eth0 から出ていきます。
ip route# 出力例: default via 172.16.0.1 dev eth0 ← デフォルトは eth0 のみ
マルチ NIC は便利ですが、ルーティングを理解しないと「なぜか通信できない」事態に陥ります。使う前に「VPC ピアリングで十分ではないか」を必ず検討しましょう。
ファイアウォールルールの設計
3-1. ルールの構成要素
| 要素 | 説明 | 例 |
|---|---|---|
| 方向 (Direction) | Ingress(受信)/ Egress(送信) | Ingress |
| アクション | allow / deny | allow |
| ターゲット | ルールを適用する VM | ネットワークタグ web-server |
| ソースフィルタ | 通信元の指定 | 0.0.0.0/0 |
| プロトコル/ポート | 許可する通信種別 | tcp:80, icmp |
| 優先度 (Priority) | 数値が小さいほど優先 | 1000 |
3-2. ネットワークタグ — 粒度の高い制御の鍵
ネットワークタグは VM に付ける「ラベル」です。ファイアウォールのターゲットをタグで指定すると、そのタグを持つ VM だけにルールが適用されます。「全インスタンスに適用」を避けてタグで絞ることで、最小権限の原則を実現できます。
図 3-1 — web-server タグを持つ blue だけが HTTP 公開され、タグのない green には届かない。
3-3. 良い例 / 悪い例
gcloud compute firewall-rules create bad-ssh \--direction=INGRESS --action=allow \--rules=tcp:22 --source-ranges=0.0.0.0/0
gcloud compute firewall-rules create allow-ssh-from-iap \--direction=INGRESS --action=allow \--rules=tcp:22 \--source-ranges=35.235.240.0/20 \--target-tags=allow-iap-ssh
| 観点 | 悪い例 | 良い例 |
|---|---|---|
| ソース範囲 | 0.0.0.0/0(全世界) | 35.235.240.0/20(IAP のみ) |
| ターゲット | 全 VM | 特定タグの VM のみ |
| 攻撃面 | 非常に広い | 最小限 |
ソース範囲はできる限り狭くします。Google も公式に default-allow-ssh / default-allow-rdp(全 IP から SSH/RDP を許可するデフォルトルール)の削除・無効化を推奨しています。
3-4. 暗黙のルール
| ルール | 内容 | 優先度 |
|---|---|---|
| implied allow egress | 全送信トラフィックを許可 | 65535 |
| implied deny ingress | 全受信トラフィックを拒否 | 65535 |
何も設定しなければ外部からの受信はすべてブロックされます。あなたが作る allow ルールは「この拒否の上に穴を開ける」行為です。だからこそ、開ける穴は最小限にすべきなのです。
IAM とサービスアカウント — 最小権限の原則
4-1. なぜサービスアカウントを使うのか
サービスアカウントは、人間ではなくアプリケーションや VM が使う特別な Google アカウントです。
VM が Google Cloud API を操作する際、個人ユーザーの権限を使うのは危険です。サービスアカウントに「必要なロールだけ」を割り当てることで、最小権限の原則 (principle of least privilege) を守れます。
4-2. ネットワーク管理向けの 2 つのロール
| ロール | できること | できないこと |
|---|---|---|
| Compute Network Admin | ネットワーク・サブネット・ルートの作成/変更/削除、ファイアウォールの閲覧 | ファイアウォールの変更/削除、SSL 証明書の管理 |
| Compute Security Admin | ファイアウォール・SSL 証明書の作成/変更/削除 | ネットワークリソース全般の管理は対象外 |
図 4-1 — ロールごとの権限差。ファイアウォールの削除は Security Admin のみ。
ネットワーク構成を作る人と、セキュリティルール(ファイアウォール)を管理する人を分けることで、「1 人の権限が大きすぎる」リスクを減らせます。これが separation of duties です。
4-3. サービスアカウント運用の注意点
| 方法 | セキュリティ | 推奨度 |
|---|---|---|
| JSON キーをダウンロードして配布 | キー漏洩リスクが高い | ⚠️ 非推奨 |
| VM にサービスアカウントを直接アタッチ | キーレス・自動ローテーション | ✅ 推奨 |
| Workload Identity (GKE) | キーレス | ✅ 推奨 |
サービスアカウントキー (JSON) は可能な限り発行しないでください。VM には作成時にサービスアカウントを直接アタッチし、必要なロールを付与する方式が安全です。
IAP — 踏み台サーバーを排除する安全なアクセス
5-1. IAP TCP フォワーディングとは
Identity-Aware Proxy (IAP) TCP フォワーディングは、暗号化トンネルを通じて SSH・RDP などの TCP トラフィックを VM に転送する仕組みです。
VM に外部 IP を付けずに安全な管理アクセスを実現します。従来必要だった踏み台サーバー (bastion) や VPN を不要にできるのが最大の利点です。
図 5-1 — IAP は接続時に「認証 → 認可 → コンテキスト認識 → 監査」の 4 機能を実行する。
5-2. IAP を有効にする 3 ステップ
図 5-2 — IAP 有効化の流れ。
Step 1 · API の有効化
ナビゲーションメニュー → API とサービス → ライブラリ → 「Cloud Identity-Aware Proxy API」を有効化。
Step 2 · ファイアウォールルールの作成
IAP は固定の IP 範囲 35.235.240.0/20 からアクセスします。この範囲からの SSH (22) / RDP (3389) を許可します。
gcloud compute firewall-rules create allow-ingress-from-iap \--direction=INGRESS \--action=allow \--rules=tcp:22,tcp:3389 \--source-ranges=35.235.240.0/20
35.235.240.0/20 は IAP が TCP フォワーディングに使う全 IP を含む範囲です。これだけを許可すれば「IAP 経由のアクセスだけ」を受け入れられます(IPv6 VM の場合は 2600:2d00:1:7::/64)。
Step 3 · IAM ロールの付与
セキュリティ → Identity-Aware Proxy → 「SSH and TCP Resources」タブで対象 VM を選択し、接続を許可したいユーザー/サービスアカウントにCloud IAP > IAP-Secured Tunnel User ロールを付与します。
5-3. トンネルを使った接続
# SSH(外部 IP がなければ自動的に IAP トンネルを使用)gcloud compute ssh linux-iap --tunnel-through-iap# RDP 用にローカルポートへトンネルを張るgcloud compute start-iap-tunnel windows-iap 3389 \--local-host-port=localhost:0 \--zone=us-central1-a# → "Listening on port [XXXX]" 表示後、RDP で localhost:XXXX に接続
外部 IP を持たない VM へは IAP を標準のアクセス手段にします。--tunnel-through-iap を明示すれば常に IAP 経由を保証できます。Chrome Enterprise Premium のアクセスレベルと組み合わせると、端末状態に基づくコンテキスト認識アクセスでゼロトラストを強化できます。
外部 Application Load Balancer と Cloud Armor
6-1. グローバル外部 Application Load Balancer の仕組み
グローバル外部 Application Load Balancer (L7) は、ユーザートラフィックを Google エッジ (PoP) で受け取り、プライベート光ファイバーバックボーン経由で最も近い健全なバックエンドへルーティングします。
世界中のユーザーに対し、1 つのグローバル IP で低遅延・高可用性のアクセスを提供できます。
図 6-1 — 単一 IP で受け、最寄りの健全なバックエンドへ。高負荷時は別リージョンへオーバーフロー。
6-2. 構成要素
| コンポーネント | 役割 |
|---|---|
| 転送ルール / フロントエンド | グローバル IP・ポート・プロトコルを定義 |
| バックエンドサービス | トラフィック分散方法とヘルスチェックを管理 |
| インスタンステンプレート | VM の設計図(マシンタイプ・イメージ・起動スクリプト) |
| マネージドインスタンスグループ (MIG) | 同一構成 VM の集合。自動スケール・自己修復 |
| ヘルスチェック | 健全なインスタンスだけにトラフィックを送る |
6-3. 必須のファイアウォールルール 2 つ
gcloud compute firewall-rules create default-allow-http \--network=default --action=allow --direction=ingress \--rules=tcp:80 \--source-ranges=35.191.0.0/16,130.211.0.0/22 \--target-tags=http-server
gcloud compute firewall-rules create default-allow-health-check \--network=default --action=allow --direction=ingress \--rules=tcp \--source-ranges=130.211.0.0/22,35.191.0.0/16 \--target-tags=http-server
ヘルスチェックのプローブは 130.211.0.0/22 と 35.191.0.0/16 から来ます。この 2 範囲を許可しないとバックエンドが unhealthy と判定され、トラフィックが一切流れません。LB トラブルの大半はこの設定漏れが原因です。プロキシ型の Application Load Balancer ではバックエンドが受け取るのはユーザー IP ではなく Google の上記フロントエンド範囲からのトラフィックなので、0.0.0.0/0 の全開放は不要です。リージョン外部 ALB の場合はこれに加えてプロキシ専用サブネットの範囲も許可してください。
6-4. 負荷分散モード
| 分散モード | 判定基準 | 設定例 |
|---|---|---|
| Rate(レート) | 1 秒あたりのリクエスト数 (RPS) | 最大 50 RPS/インスタンス |
| Utilization(使用率) | CPU 使用率 | 最大 80% |
通常は「最寄りのバックエンド」へ送られますが、負荷が非常に高くなると別リージョンへオーバーフローします。これがクロスリージョンのフェイルオーバーと耐障害性を実現します。
6-5. Cloud Armor — エッジでの防御
Cloud Armor は、Google エッジで L7 フィルタリングと IP 制御を行うサービスです。
悪意あるトラフィック(L7 フラッドなど)を、VPC やバックエンドに到達する前にエッジで遮断します。バックエンドのリソースを消費させません。
| 設定項目 | 値(拒否リスト例) |
|---|---|
| ポリシー名 | denylist-siege |
| デフォルトルール | Allow(許可) |
| 追加ルール条件 | 攻撃元 IP(例: 203.0.113.10/32) |
| アクション | Deny(拒否) |
| レスポンスコード | 403 (Forbidden) |
| 優先度 | 1000 |
| ターゲット | バックエンドサービス(http-backend) |
図 6-2 — 攻撃元はエッジで 403 遮断、正常ユーザーは通過。
防御は 2 通り。(1) デフォルト Allow + 攻撃元を拒否リスト化、(2) デフォルト Deny + 許可 IP だけを許可リスト化。よりセキュアなのは (2) の許可リスト方式です。Cloud Armor のログを有効にすれば、いつ・どの IP がブロックされたかを追跡できます。
内部ロードバランサ (ILB)
7-1. ILB とは
内部ロードバランサ (ILB) は、TCP/UDP トラフィックをプライベートネットワーク内の VM へ分散するリージョナルサービスです。
「インターネットには公開したくないが、内部サービスからは高可用に使いたい」リソース(マイクロサービス・API・DB など)に、単一の安定したプライベート IP を提供します。
図 7-1 — 単一プライベート IP で、複数ゾーンのバックエンドへ分散。
7-2. 外部 LB との違い
| 項目 | 外部 Application LB | 内部 LB (passthrough) |
|---|---|---|
| スコープ | グローバル | リージョナル |
| 公開範囲 | インターネット | VPC 内部のみ |
| IP | 外部グローバル IP | 内部プライベート IP |
| レイヤー | L7 (HTTP/HTTPS) | L4 (TCP/UDP) |
| 主な用途 | 公開 Web アプリ | 内部マイクロサービス |
7-3. 高可用性のための配置設計
ILB はリージョナルサービスなので、複数ゾーンにバックエンドを配置することがゾーン障害への耐性を生みます。ヘルスチェックのファイアウォール範囲は外部 LB と同じく 130.211.0.0/22 と 35.191.0.0/16 を許可し、バックエンドへの HTTP は VPC の CIDR(例: 10.10.0.0/16)からのみ許可します。
ILB のバックエンド VM には外部 IP を付けない(External IPv4 Address: None)ようにします。内部サービスはインターネットに露出させないのが原則です。
総合演習 — セキュアなネットワークを設計する
ここまでの知識を統合した「あるべき構成」を考えます。題材は「公開 Web アプリ (juice-shop) を持つ小規模サイトのセキュリティ強化」です。
8-1. 要件
| # | 要件 |
|---|---|
| 1 | 踏み台 (bastion) は公開 IP を持たない |
| 2 | bastion への SSH は IAP 経由のみ |
| 3 | アプリサーバーへの SSH は bastion 経由のみ |
| 4 | アプリサーバーへは HTTP だけを世界に公開 |
8-2. アクセス経路の設計
図 8-1 — 管理アクセスは IAP → bastion → app の一方向。公開は HTTP だけ。
8-3. 必要なファイアウォールルール(タグ設計)
| ルール | 方向 | 許可 | ソース | ターゲットタグ |
|---|---|---|---|---|
| IAP からの SSH | Ingress | tcp:22 | 35.235.240.0/20 | ssh-iap (bastion) |
| 世界への HTTP | Ingress | tcp:80 | 0.0.0.0/0 | http (juice-shop) |
| bastion からの内部 SSH | Ingress | tcp:22 | 管理サブネットの CIDR | ssh-internal (juice-shop) |
8-4. 設計の要点
図 8-2 — セキュア化の手順。
ソース範囲は必ず最小限に。「とりあえず 0.0.0.0/0」は SSH では絶対に避け、SSH は IAP 範囲か管理サブネットの CIDR に限定します。HTTP だけは公開サービスの性質上 0.0.0.0/0 が妥当ですが、それ以外のポートは公開しません。
gcloud compute ssh や IAP トンネルで接続できないときは --troubleshoot フラグを付けると、ファイアウォール・IAM・ネットワーク到達性を自動診断してくれます。
ベストプラクティス チェックリスト
ネットワーク設計
- 本番ではカスタムモード VPC を使い、サブネットを意図的に設計する
- サブネットの CIDR は重複させない(特にマルチ NIC や VPC ピアリングで必須)
- 異なる VPC 間通信は VPC ピアリング / VPN で明示的に設定する
ファイアウォール
- ソース範囲は最小限にする(
0.0.0.0/0を SSH/RDP に使わない) - ターゲットはネットワークタグで絞り、「全インスタンス」適用を避ける
default-allow-ssh/default-allow-rdpのデフォルトルールは削除/無効化する- LB 利用時は
130.211.0.0/22と35.191.0.0/16からのヘルスチェックを許可する
アクセス制御
- 外部 IP なしの VM へは IAP TCP フォワーディングでアクセスする
- IAP は
35.235.240.0/20のみを許可するファイアウォールと組み合わせる - IAP-Secured Tunnel User ロールは VM/プロジェクト単位で最小限に付与する
- 可能なら Chrome Enterprise Premium のアクセスレベルでコンテキスト認識アクセスを追加する
IAM / サービスアカウント
- 最小権限の原則に従い、必要なロールだけを付与する
- ネットワーク管理とセキュリティ管理のロールを分離する(職務分掌)
- サービスアカウントキー (JSON) の発行を避け、VM への直接アタッチを使う
ロードバランシング / エッジ防御
- バックエンドは複数ゾーン/リージョンに配置して可用性を確保する
- 内部サービスのバックエンド VM には外部 IP を付けない
- Cloud Armor は可能なら「デフォルト Deny + 許可リスト」方式にする
- Cloud Armor とヘルスチェックのログを有効にして可観測性を確保する
参考ソース(公式ドキュメント URL)
Identity-Aware Proxy (IAP)
VPC ネットワーク / ファイアウォール
IAM / サービスアカウント
ロードバランシング
Cloud Armor
スキルバッジ(元ラボ)
- Build a Secure Google Cloud Network ↗cloudskillsboost.google
- 関連コース (skills.google/654) ↗skills.google