【実務・中級編】 VPCファイアウォールにおけるターゲットタグとサービスアカウントの使い分け – クラウドインフラと仮想化ネットワーク実践ガイド

GCPネットワークの「沼」を避ける：ファイアウォール設定で「ターゲットタグ」と「サービスアカウント」を使い分ける極意

現場で運用を続けていると、若手エンジニアから「ファイアウォール設定のターゲット、結局どっちを使えばいいんですか？」と相談されることがよくあります。

GCPのVPCファイアウォールは非常に柔軟ですが、その柔軟性ゆえに「誰が何にアクセスできるか」というポリシー管理が、気づけばスパゲッティ状態になっている現場をいくつも見てきました。今回は、ターゲットタグ（ネットワークタグ）とサービスアカウント、この2つの制御方式の決定的な違いと、プロが推奨する使い分け戦略を、泥臭い実体験を交えて解説します。

—

ターゲットタグとサービスアカウント：その「本質」の違い

まず、結論から言います。「タグはネットワークのレイヤーであり、サービスアカウントはアイデンティティのレイヤーである」。この認識がすべてです。

1. ターゲットタグ（Network Tags）の挙動

ターゲットタグは、Compute Engineインスタンスに付与する「ただの文字列」です。

メリット: 非常に軽量で、GCPの内部APIを叩かなくてもネットワーク層（L3/L4）ですぐに判定されるため、パフォーマンスに影響を与えにくいです。
デメリット: IAM制御が効きません。誰でもインスタンスにタグを追加・削除できる権限があれば、ファイアウォールを簡単に「回避」できてしまいます。これが最大のリスクです。

2. サービスアカウント（Service Accounts）の挙動

サービスアカウントによる指定は、GCPのIAMと密接に統合されています。

メリット: 「どのインスタンスか」ではなく「どのアイデンティティで動いているか」で制御します。IAM権限で管理されるため、タグのように「誰でも勝手に付け替えられる」心配がありません。
デメリット: わずかにオーバーヘッドがある（とはいえ現代のインフラでは誤差の範囲です）のと、インスタンス自体にサービスアカウントが割り当てられていないと機能しません。

—

実践：どちらを選ぶべきかの判断基準

実務で私が設計を行う際は、以下の基準で即断しています。

ターゲットタグを使うべき場面:
外部負荷分散（GCLB）のヘルスチェック用IP範囲の許可など、全インスタンスに共通のネットワークルールを適用する場合。
ネットワークスペシャリストが運用する、極めてシンプルな閉域網環境。

サービスアカウントを使うべき場面（強く推奨）:
Web APIサーバー、ワーカーノード、DBなど、役割（Role）ごとに通信を制限したい場合。
チームで運用しており、インフラの変更権限を分離したい場合。

—

設定の具体例：Terraformによる記述

インフラをコードで管理（IaC）する際、どのように記述が変わるか見てみましょう。

ターゲットタグによる指定

resource "google_compute_firewall" "allow_web" {
  name    = "allow-http-traffic"
  network = google_compute_network.main.name

  allow {
    protocol = "tcp"
    ports    = ["80", "443"]
  }

  # ターゲットタグを指定（管理が楽だが権限分離には不向き）
  target_tags = ["web-server"]
}

サービスアカウントによる指定

resource "google_compute_firewall" "allow_api" {
  name    = "allow-api-access"
  network = google_compute_network.main.name

  allow {
    protocol = "tcp"
    ports    = ["8080"]
  }

  # サービスアカウントメールアドレスで指定（IAM制御が効くため堅牢）
  target_service_accounts = ["api-worker@my-project.iam.gserviceaccount.com"]
}

—

トラブルシューティング：なぜ通信が遮断されるのか？

現場でよくあるのが、「タグを付けたのに通信できない！」という叫び声です。そんな時はまず、パケットの流れを疑います。

1. gcloud compute firewall-rules describe で優先度（priority）を確認:
数字が小さいほど優先されます。別のルールで「全拒否」が優先設定されていないかチェックしましょう。
2. Connectivity Tests を活用する:
GCPコンソールの「ネットワークインテリジェンスセンター」にある Connectivity Tests は神機能です。パケットがどのファイアウォールルールでドロップされたか、論理的に可視化してくれます。
3. サービスアカウントの疎通確認:
Pythonでサービスアカウントが正しく設定されているか確認する簡単なスクリプトです。

# インスタンス内でメタデータサーバーからSA情報を取得する例
import requests

def check_identity():
    url = "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"
    headers = {"Metadata-Flavor": "Google"}
    try:
        response = requests.get(url, headers=headers)
        print(f"Current Identity: {response.text}")
    except Exception as e:
        print(f"Error: {e}")

check_identity()

—

最後に：シニアからのアドバイス

「迷ったらサービスアカウント」――これが現代のGCP運用における正解です。

ターゲットタグは便利ですが、システムの規模が大きくなればなるほど、タグの管理は形骸化し、いつの間にか「このタグ、何のルールで付いてるんだっけ？」というデッドコードならぬ「デッドタグ」が溢れかえります。

サービスアカウントベースのフィルタリングは、最小権限の原則（Principle of Least Privilege）に基づいています。あなたのWeb APIやマイクロサービスを守るための強固な盾として、ぜひIAMの力を最大限に活用してください。

ネットワークは生き物です。設定を書き換えた後は、必ず curl や nmap で疎通確認を行い、ログ（VPC Flow Logs）を眺める癖をつけましょう。そこには必ず、答えが落ちています。