Defense in Depth · 多層防御

Google Cloud
ネットワークセキュリティ
実践ガイド

VPC・ファイアウォール・IAM・IAP・ロードバランシング・Cloud Armor。 「なぜそうするのか」を理解したうえで、安全なネットワークを自分で設計・構築できるようになるための、初学者向けステップバイステップ解説です。

対象: ネットワーク/セキュリティ初学者形式: 10 セクション図解: Mermaid
01

全体像 — このガイドで学ぶこと

クラウド上で動くアプリを安全に運用するには、「誰が・どこから・どのリソースに・どのポートで」アクセスできるかを厳密にコントロールする必要があります。Google Cloud では、この制御を複数のレイヤーで実現します。

レイヤー役割主なサービス
ネットワーク分離環境を隔離し、通信境界を作るVPC / サブネット
パケットフィルタIP・ポート単位で許可/拒否ファイアウォールルール
ID ベースアクセス「誰が」操作できるかを制御IAM / サービスアカウント
ゼロトラスト接続外部 IP なしで安全に管理アクセスIdentity-Aware Proxy (IAP)
トラフィック分散可用性とスケーラビリティロードバランサ
エッジ防御L7 攻撃をバックエンド到達前に遮断Cloud Armor

図 1-1 — 各サービスの連携。外部通信は必ず「エッジ → ファイアウォール → バックエンド」の順に通過する。

読み方のヒント

各レイヤーで「不要な通信を落とす」ことが、多層防御 (defense in depth) の基本です。1 か所が突破されても、次の層で止められる構成を目指します。

02

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 ネットワーク
2VPC ネットワークを作成 をクリック
3名前を入力(例: privatenet
4サブネット作成モードで カスタム を選択
5サブネット名・リージョン・IPv4 範囲(例: 172.16.0.0/24)を指定
6作成 をクリック
gcloud — 同等のコマンド
# カスタムモードの 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
Tip · IaC への第一歩

コンソールの「同等のコマンドライン」ボタンで、設定内容を作成前に 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 から出ていきます。

マルチ NIC VM のルーティング確認
ip route
# 出力例: default via 172.16.0.1 dev eth0 ← デフォルトは eth0 のみ
落とし穴

マルチ NIC は便利ですが、ルーティングを理解しないと「なぜか通信できない」事態に陥ります。使う前に「VPC ピアリングで十分ではないか」を必ず検討しましょう。

03

ファイアウォールルールの設計

3-1. ルールの構成要素

要素説明
方向 (Direction)Ingress(受信)/ Egress(送信)Ingress
アクションallow / denyallow
ターゲットルールを適用する 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. 良い例 / 悪い例

悪い例 — 全 VM に全 IP から SSH を許可
gcloud compute firewall-rules create bad-ssh \
--direction=INGRESS --action=allow \
--rules=tcp:22 --source-ranges=0.0.0.0/0
良い例 — 特定タグの VM に IAP 範囲からだけ許可
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 ルールは「この拒否の上に穴を開ける」行為です。だからこそ、開ける穴は最小限にすべきなのです。

04

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 には作成時にサービスアカウントを直接アタッチし、必要なロールを付与する方式が安全です。

05

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) を許可します。

IAP 範囲のみ許可
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
なぜこの IP 範囲なのか

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 / RDP over IAP
# 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 のアクセスレベルと組み合わせると、端末状態に基づくコンテキスト認識アクセスでゼロトラストを強化できます。

06

外部 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 つ

1 — ロードバランサからの HTTP を許可
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
2 — Google のヘルスチェックを許可
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
超重要 · ヘルスチェックの IP 範囲

ヘルスチェックのプローブは 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 がブロックされたかを追跡できます。

07

内部ロードバランサ (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)ようにします。内部サービスはインターネットに露出させないのが原則です。

08

総合演習 — セキュアなネットワークを設計する

ここまでの知識を統合した「あるべき構成」を考えます。題材は「公開 Web アプリ (juice-shop) を持つ小規模サイトのセキュリティ強化」です。

8-1. 要件

#要件
1踏み台 (bastion) は公開 IP を持たない
2bastion への SSH は IAP 経由のみ
3アプリサーバーへの SSH は bastion 経由のみ
4アプリサーバーへは HTTP だけを世界に公開

8-2. アクセス経路の設計

図 8-1 — 管理アクセスは IAP → bastion → app の一方向。公開は HTTP だけ。

8-3. 必要なファイアウォールルール(タグ設計)

ルール方向許可ソースターゲットタグ
IAP からの SSHIngresstcp:2235.235.240.0/20ssh-iap (bastion)
世界への HTTPIngresstcp:800.0.0.0/0http (juice-shop)
bastion からの内部 SSHIngresstcp:22管理サブネットの CIDRssh-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・ネットワーク到達性を自動診断してくれます。

09

ベストプラクティス チェックリスト

ネットワーク設計

  • 本番ではカスタムモード 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 とヘルスチェックのログを有効にして可観測性を確保する
10

参考ソース(公式ドキュメント URL)