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

GCPのファイアウォール、結局どっちを使えばいいの？「ターゲットタグ」と「サービスアカウント」の境界線

こんにちは！クラウドの深淵を覗き込みながら、日々インフラの最適化に励んでいるSREです。

GCPでネットワークを構築し始めると、必ず一度はぶつかる壁があります。それが「ファイアウォールルールを誰に適用するか」という問題です。GCPには ターゲットタグ（ネットワークタグ） と サービスアカウント という2つの指定方法がありますが、これ、正直どっちを使えばいいのか迷いますよね。

今日は、小難しいネットワークの理屈は一旦横に置いて、身近な「郵便配達」に例えながら、この2つの違いと使い分けを徹底解説していきます。一歩ずつ理解していきましょう！

—

1. 郵便配達でイメージする「ターゲットタグ」と「サービスアカウント」

ファイアウォールとは、いわば「マンションの入り口にある警備員さん」です。警備員さんは「この荷物（パケット）を誰に渡すべきか」をチェックします。

ターゲットタグは「マンションのドアに貼ったシール」

ターゲットタグは、仮想マシン（VM）という「部屋のドア」に、「Webサーバー用」「DBサーバー用」といったシールをペタッと貼るようなものです。

メリット: シンプルです。警備員さんは「Webサーバーのシールが貼ってある部屋なら通していいんだな」と瞬時に判断できます。
デメリット: 誰でもシールを剥がしたり貼ったりできるため、セキュリティの境界線が少し曖昧になりがちです。

サービスアカウントは「身分証明書（社員証）」

一方、サービスアカウントは、VMが首から下げている「厳格な社員証」です。

メリット: GCPのIAM（権限管理）と連動しているため、非常にセキュアです。「この部署の人間（サービスアカウント）しか入ってはいけない」という制限が、クラウドの根幹レベルで守られます。
デメリット: 少し設定が複雑で、タグに比べると直感的ではありません。

—

2. なぜ「サービスアカウント」が推奨されるのか？

現場でよくあるのが、「Webサーバーのタグを間違えてDBサーバーに貼っちゃった！」というヒューマンエラーです。ネットワークタグはVMの設定画面から誰でも簡単に書き換えられてしまうため、大規模な組織になればなるほど事故の元になります。

サービスアカウントを使った制御であれば、IAMの権限がない限りそのVMの「身分」を変えることはできません。「守るべき境界線を物理的に動かせないようにする」という観点から、現代のSREとしてはサービスアカウントベースの制御を強くおすすめしています。

—

3. 実践！設定の書き方を見てみよう

実際に gcloud コマンドで設定する場合のイメージを見てみましょう。

ターゲットタグを使う場合

# 「web-server」というタグを持つVMに対して、80番ポートを許可する
gcloud compute firewall-rules create allow-http \
    --direction=INGRESS \
    --priority=1000 \
    --network=default \
    --action=ALLOW \
    --rules=tcp:80 \
    --target-tags=web-server  # ここでタグを指定

サービスアカウントを使う場合

# 「web-sa@project-id.iam.gserviceaccount.com」というアカウントを持つVMに許可
gcloud compute firewall-rules create allow-http-sa \
    --direction=INGRESS \
    --priority=1000 \
    --network=default \
    --action=ALLOW \
    --rules=tcp:80 \
    --target-service-accounts=web-sa@project-id.iam.gserviceaccount.com # アカウントを指定

—

4. 現場での使い分け、黄金のルール

駆け出しエンジニアの皆さんが現場で迷わないための、「使い分けの指針」をまとめておきます。

1. 基本は「サービスアカウント」で制御する

本番環境や、セキュリティ要件が厳しいシステムでは、必ずサービスアカウントを使いましょう。VMが乗っ取られた際の被害範囲の特定や制限が圧倒的に楽になります。

2. 一時的な検証や小規模な環境なら「ターゲットタグ」もアリ

「今すぐテストしたい」「まだ環境が小さい」という場合は、タグの方が管理が楽です。プロトタイプ開発のスピードを落とさないことも、SREとしては大切な視点です。

3. 絶対に混ぜないこと！

同じファイアウォールルールの中で、タグとサービスアカウントを混在させるのは避けましょう。「どっちが優先されて許可されたんだっけ？」というトラブルシューティングの地獄を見ることになります。プロジェクト全体でどちらを使うか、最初に決めておくのが鉄則です。

—

最後に：クラウドは「仕組み」で守るもの

ネットワークタグもサービスアカウントも、結局は「正しい通信を許可し、怪しい通信を遮断する」ためのツールに過ぎません。

大切なのは、「誰がそのネットワーク設定を操作できるのか」という権限管理まで含めて考えることです。タグは手軽ですが、その手軽さが時としてリスクになります。まずは小さな環境から、サービスアカウントによる制御を試してみてください。

「あ、このパケットはあのサービスアカウント宛てだから通していいんだな」と、クラウドの背後で流れるデータに想いを馳せられるようになれば、あなたも立派なインフラエンジニアの仲間入りです！

これからも、クラウドという広大な海を一緒に楽しく冒険していきましょう。次回の記事では、この通信をさらにセキュアにする VPC Service Controls について深掘りしていきます。お楽しみに！