@KoheiKushida(Kohei Kushida)Team Energy Drinkin

クラウドセキュリティ#2 パケットで描くネットワークセキュリティの地図（Azure）

Posted at 2026-02-15

1.はじめに

ネットワークセキュリティというと、IP アドレスやポート番号、Firewall や WAF による制御を思い浮かべる方も多いのではないでしょうか。

一方で、「実際に流れる通信のどこまでをネットワークセキュリティで守れているのか」を正しく説明できる人は、意外と多くありません。

本記事では、実際に流れる通信に着目し、通信を構成する情報（＝パケット）を分解しながら、Azure におけるネットワークセキュリティの保護範囲と限界を構造的に整理します。

次のような方を主な対象としています。

Firewall / IDS・IPS / WAF の違いを説明できるようになりたい方
Azure のネットワークセキュリティ設計を任され始めた方

本記事は全て筆者個人で作成しています。
記載内容は筆者個人の見解であり、所属組織の公式な見解を示すものではありません。

本記事は Azure を例にしていますが、通信を構成する情報を軸にした整理の考え方は、オンプレミスや他クラウド（例：AWS）でも共通して活用できます。

なお、前回の記事では、ネットワークセキュリティと混同されやすい「アクセス制御」の整理を行っています。

2.本記事で扱う通信シナリオ

以降の章では、ファイルダウンロードを伴う Web 通信のシナリオを前提に話を進めます。

2-1.システム構成と通信内容

本シナリオでは、Azure 上に配置された 2 台の Azure VM 間で通信が行われます。

クライアント：Azure VM-A（以降、VM-A）
サーバ：Azure VM-B（以降、VM-B）
- VM-B 上では Web サービスが稼働
通信内容：VM-A から Web サービス（HTTPS）へアクセスし、特定ファイル（test.exe）をダウンロード

なお、今回の通信に含まれる主な情報は、以下の通りです。

項目	値	関連するリソース	この情報の役割
送信元 IP アドレス	192.168.1.100	VM-A	どこからの通信かを識別する
宛先 IP アドレス	192.168.2.100	VM-B	どこへ向かう通信かを識別する
プロトコル	TCP	通信全体	どのプロトコルの通信かを識別する
送信元ポート番号	52341	VM-A	どのポートでの通信かを識別する
宛先ポート番号	443	VM-B	どのポート宛の通信かを識別する
アクセス先（例：`FQDN/パス`）	`www.test.com/download`	VM-B （Web サービス）	アプリケーションの対象機能・操作を識別する
入力値	file=test.exe	VM-B （Web サービス）	アプリケーションに渡される処理内容を指定する
ファイル	test.exe	VM-B（Web サービス：送信） VM-A（受信）	通信の結果としてクライアントに返される実データ

これらの情報を図として整理したものが、次の全体イメージ図です。

3.パケットを構成する情報の整理

本章では、通信がどのような情報で構成されているのかを整理します。

3-1.通信は「パケット」単位でやり取り

ネットワーク上では、通信は「パケット」と呼ばれる単位でやり取りされます。

先ほどの全体イメージ図に、「パケット」という視点を重ねると、次のイメージになります。
以降の章では、赤枠内の「パケットに含まれる情報」に焦点を当てて整理します。

本記事では、便宜的に通信を構成する情報のまとまりを「パケット」と表現しています。
厳密には、レイヤー2 はフレーム、レイヤー3 はパケット、レイヤー4 はセグメント/データグラム、レイヤー7 はメッセージ/データ¹ですが、本記事では読者の皆さんに馴染みのある「パケット」という表現で統一しています。

3-2.パケットに含まれる情報の基本構造

パケットという情報のまとまりは、次の2つの要素から構成されています。

ヘッダー部
ペイロード部（以降、データ部）

以下は、パケットの基本構造を示したイメージ（以降、パケット図）です。

実際の通信では、どのレイヤーの視点で見るかによって、ヘッダー部・データ部の中身や境界は異なります²。

直感的な理解を最優先とし、パケット内の情報を筆者の視点で整理しています。
データ部を「識別データ」「入力データ」「実行データ」に分ける表現も、ネットワークセキュリティの役割と限界を捉えるための、本記事独自の整理です。

3-3.ヘッダー部に含まれる情報

ヘッダー部には、通信の送信元・宛先や種別を識別するための情報が含まれます。
主に次の情報が該当します。

IP ヘッダー（レイヤー3）

送信元 IP アドレス
宛先 IP アドレス
プロトコル

TCP / UDP ヘッダー（レイヤー4）

送信元ポート番号
宛先ポート番号

これらの情報は、「どこから」「どこへ」「どのプロトコル・ポートの通信として」届けるかを判断するために使われます。

今回のシナリオでは、VM-A（192.168.1.100）から VM-B（192.168.2.100）へ、TCP の 443 番ポート（HTTPS）宛の通信かどうかが、ここで区別されます。

3-4.データ部に含まれる情報

データ部には、通信の中身としてアプリケーションが実際に扱う情報が含まれます。
本記事では、データ部に含まれる情報を、次の3つに分けて整理します。

識別データ
入力データ
実行データ

それぞれの分類には、たとえば次のような情報が含まれます。

分類	含まれる情報の例	この分類で見ている観点
識別データ	URL（FQDN/パスなど）	アプリケーションのどの機能・操作を対象とした通信かを識別する情報
入力データ	クエリパラメータ、フォーム入力値、リクエストボディ	アプリケーションに渡され、処理内容を決める情報
実行データ	ダウンロードファイル（実行ファイル、ドキュメントなど）	通信の結果としてクライアント側に返される実データ

これらはレイヤー7 の視点で通信内容を捉えるための情報であり、通信が「どの機能・操作を対象とし」「どのような入力を受け取り」「何が返されるのか」を整理するために使います。

今回のシナリオでは、VM-A（192.168.1.100）から VM-B（192.168.2.100）の
TCP の 443 番ポート（HTTPS）宛の通信かどうかがヘッダー部で区別され、アクセス先が Web サービスであることや入力値やファイルの内容はデータ部（レイヤー7）で区別されます。

4.Azure ネットワークセキュリティと保護範囲の整理

前章で整理した「パケット図」を用いて、Azure が提供するネットワークセキュリティサービスが、パケット内のどの情報を参照し、制御や防御などをしているのかを整理します。

ここからは Azure を例に説明しますが、サービス名にとらわれず、ご自身の担当領域や利用している製品に置き換えて考えてみると、理解が進みやすいかもしれません。

4-1.NSG の保護範囲

まず確認するのが、Azure における最も基本的なネットワークセキュリティサービスである NSG（Network Security Group）です。

Azure の公式ドキュメントでは、レイヤー3 およびレイヤー4 のファイアウォールと説明されています。

ネットワークセキュリティグループは、サブネットまたはネットワークインターフェイスカード (NIC) レベルで適用するレイヤー 3 およびレイヤー 4 のファイアウォールです。

上記の説明を具体的な項目レベルで整理し、NSG が参照する情報をパケット図に当てはめると、次のとおりです。

項目	分類	レイヤー
送信元 IP アドレス	IP ヘッダー	3
宛先 IP アドレス	IP ヘッダー	3
プロトコル	IP ヘッダー	3
送信元ポート番号	TCP / UDP ヘッダー	4
宛先ポート番号	TCP / UDP ヘッダー	4

NSG はこれらの参照した情報をもとに、通信を許可するか、拒否するかを制御します。

一方で、データ部（レイヤー7）の情報は参照・制御の対象外です。
そのため、NSG ではデータ部を含めた通信全体を制御・保護することはできません。

この点が、NSG だけではネットワークセキュリティを完結できない理由です。

4-2.Azure Firewall の保護範囲

次に確認するのが、Azure においてネットワーク境界で通信を制御する中核的なネットワークセキュリティサービスである Azure Firewall です。

以降は、TLS 検査の有無によって Azure Firewall が参照・制御できる範囲を整理します。

4-2-1.TLS 検査なしの保護範囲

まずは、TLS 検査なし³の場合です。

Azure の公式ドキュメント（1・2）では、レイヤー3 およびレイヤー4 に加えて、完全修飾ドメイン名（FQDN）を含む情報で通信を制御できるファイアウォールと説明されています。

Azure Firewall は、ネットワークエッジと、ハブスポークネットワークや仮想 WAN などの一般的なネットワークトポロジで使用できます。

Azure Firewall の機能セットには、次のものが含まれます。

強力なレイヤー 3、レイヤー 4、完全修飾ドメイン名 (FQDN) ネットワーク規則。

Web カテゴリを使用すると、管理者は、ギャンブルやソーシャルメディアなど、特定のカテゴリの Web サイトへのユーザーアクセスを許可または拒否できます。

上記の説明を具体的な項目レベルで整理し、Azure Firewall が参照する情報をパケット図に当てはめると、次のとおりです。

項目	分類	レイヤー
送信元 IP アドレス	IP ヘッダー	3
宛先 IP アドレス	IP ヘッダー	3
プロトコル	IP ヘッダー	3
送信元ポート番号	TCP / UDP ヘッダー	4
宛先ポート番号	TCP / UDP ヘッダー	4
アクセス先（FQDN）	識別データ	7

Azure Firewall は、これらの参照した情報をもとに、通信を許可するか、拒否するかを制御します。

NSG と比較すると、データ部（レイヤー7）の識別データであるアクセス先の FQDN も基準として通信を制御できる点が特徴です。

Web カテゴリは、Microsoft が用途・性質ごとに分類した Web サイト情報をもとに、カテゴリ単位で複数の Web サイトへの通信を一括で許可・拒否できる仕組みです。

アクセス先⁴の分類に基づいて制御されるため、本記事ではデータ部（レイヤー7）の識別データとして位置づけています。

4-2-2.TLS 検査ありの保護範囲

次に、TLS 検査あり³の場合です。

Azure の（公式ドキュメント）では、暗号化された通信も含めて、通信を制御できるファイアウォールと説明されています。

TLS 検査がないと、Azure Firewall は暗号化された TLS トンネル内のデータを表示できず、保護機能が制限されます。ただし、Azure Firewall Premium は TLS 接続を終了して検査し、HTTPS での悪意のあるアクティビティを検出、アラート、軽減します。

上記の説明を具体的な項目レベルで整理し、Azure Firewall が参照する情報をパケット図に当てはめると、次のとおりです。

項目	分類	レイヤー
送信元 IP アドレス	IP ヘッダー	3
宛先 IP アドレス	IP ヘッダー	3
プロトコル	IP ヘッダー	3
送信元ポート番号	TCP / UDP ヘッダー	4
宛先ポート番号	TCP / UDP ヘッダー	4
アクセス先（URL）	識別データ	7
入力値	入力データ（通信データ）	7

TLS 検査ありの場合、これらの参照した情報をもとに、通信を許可するか、拒否するかを制御します。

データ部（レイヤー7）の FQDN に加えて、パスを含む URL 全体の識別データや、通信に含まれる入力値といった入力データも、制御の判断材料として利用できます⁵。

TLS 検査により参照可能となった入力データは、Azure Firewall では通信データとして評価し、既知の悪意あるパターンなどの照合に用いられます。

マルウェアに感染したクライアントから外部（C&C サーバ）へ送信される不審な通信
通信内容の特徴やパターンに基づく異常な挙動など

4-3.IDS / IPS の保護範囲

次に確認するのが、通信を構成する複数の情報や通信の流れを踏まえて、不正な兆候を検知・防御する考え方である IDS / IPS です。

本記事では、Azure における IDS / IPS の代表例として、Azure Firewall Premium で利用できる侵入検知・防御機能（IDPS）を前提に整理します⁶⁷。

Azure の公式ドキュメントでは、Azure Firewall Premium が侵入検知および防御の仕組み（IDPS）を含むファイアウォールとして説明されています。

ネットワーク侵入検出および防止システム (IDPS) は、ネットワークの悪意のあるアクティビティを監視し、情報をログに記録して報告し、必要に応じてブロックします。

Azure Firewall Premium では、ネットワークトラフィックのバイトシーケンスやマルウェアによって使用される既知の悪意のある命令シーケンスなど、特定のパターンを識別することで、攻撃を迅速に検出するシグネチャベースの IDPS が提供されます。

これらの IDPS 署名は、アプリケーションレベルのトラフィックとネットワークレベルのトラフィック (レイヤー 3 から 7) の両方に適用されます。

上記の説明を踏まえると、NSG や Azure Firewall（IDPS 機能除く）のように、特定のヘッダー部（レイヤー3・レイヤー4）やデータ部（レイヤー7）の項目単体を参照・制御する仕組みとは異なり、複数の通信情報やその前後関係を含めて評価する点が特徴です。

参照する情報をパケット図に当てはめると、次のとおりです。

「IDPS が利用し得る情報」であり、これらの項目を単体で判断することを意味するものではありません。

項目	分類	レイヤー
送信元 IP アドレス	IP ヘッダー	3
宛先 IP アドレス	IP ヘッダー	3
プロトコル	IP ヘッダー	3
送信元ポート番号	TCP / UDP ヘッダー	4
宛先ポート番号	TCP / UDP ヘッダー	4
アクセス先（URL）	識別データ	7
入力値	入力データ（通信データ）	7

Azure Firewall Premium で利用できる IDPS により、通信を構成する複数の情報やその流れを組み合わせながら、不正な通信の検知・防御が行われています。

ここまで見ると、データ部（レイヤー7）の実行データを除くパケット内の多くの情報は、ネットワークセキュリティサービスの組み合わせによって参照・制御できているように見えます。

ただし、あくまで「通信データに基づいた制御」ができている状態に留まります。
レイヤー7 における「Web アプリケーションデータに基づいた制御」という、別の重要な視点も存在します。

次の節（4-4）では、この領域を整理します。

4-4.Azure WAF の保護範囲

次に確認するのが、同じデータ部（レイヤー7）であっても、Azure Firewall とは異なる視点で通信を防御するネットワークセキュリティサービスである Azure WAF⁸ です。

Azure の公式ドキュメント（1・2）では、HTTP / HTTPS トラフィックを対象に、Web アプリケーションを保護する仕組みと説明されています。

Azure Web Application Firewall は、一般的な悪用や脆弱性から Web アプリケーションを一元的に保護します。
このサービスでは受信フィルター処理をサポートし、HTTP および HTTPS トラフィックのみが対象となります。
また、ほとんどのチェックはペイロードに基づくため、TLS 終端が必要です。

HTTP / HTTPS 通信では、クライアントから送信されるリクエストに、URL、パラメータ、入力値など、Web アプリケーションに渡される情報が含まれます。

Azure WAF は HTTPS の場合、TLS 終端後の平文 HTTP リクエストを主な検査対象とします。

上記の説明を具体的な項目レベルで整理し、Azure WAF が参照する情報をパケット図に当てはめると、次のとおりです。

データ部（レイヤー7）では、実際には多くの情報がやり取りされますが、本記事では Azure WAF の役割を説明するため、代表的な要素を抜粋して整理しています。

項目	分類	レイヤー	具体例
URL	識別データ	7	`https://www.test.com/download`
クエリパラメータ	入力データ	7	`id=123`、`search=test`、`page=2`
フォーム入力値	入力データ	7	ユーザー名、メールアドレス、検索キーワード
リクエストボディ	入力データ	7	JSON、XML、POST データ
HTTP ヘッダー	識別データ・入力データの両方に関係	7	`Host`、`User-Agent`、`Cookie`

入力データを通信データとして扱う Azure Firewall や IDPS とは異なり、Web アプリケーションデータとして評価する点が特徴です。
具体的には、SQL インジェクションやクロスサイトスクリプティング（XSS）などの攻撃⁹を防ぐことができます。

NSG や Azure Firewall、IDPS による通信データに基づいた制御に、Azure WAF による Web アプリケーションデータに基づいた制御が加わることで、実行データを除くパケット情報を段階的に保護できます。

一方で、実行データやクライアント上での処理は、引き続き保護の対象外です。

4-5.Azure ネットワークセキュリティの総まとめ

ここまで、パケット図を軸に、Azure の各ネットワークセキュリティサービスが通信のどの情報に関与するのかを整理してきました。

これまでの内容を、パケットを構成する情報ごとに一覧化すると、次のようになります。

パケット内の情報	情報の位置	レイヤー	NSG	Azure Firewall	IDPS	Azure WAF
送信元 IP アドレス	ヘッダー部	3	○	○	△	―
宛先 IP アドレス	ヘッダー部	3	○	○	△	―
プロトコル	ヘッダー部	3	○	○	△	―
送信元ポート番号	ヘッダー部	4	○	○	△	―
宛先ポート番号	ヘッダー部	4	○	○	△	―
アクセス先（FQDN / URL）	データ部（識別データ）	7	―	○⁴	△	○
入力値（通信データ）	データ部（入力データ）	7	―	○¹⁰	△	―
入力値（Web アプリケーションデータ）	データ部（入力データ）	7	―	―	―	○
ファイル	データ部（実行データ）	7	―	―	―	―

凡例

○：判断材料として直接参照し、ルールやシグネチャに基づいて制御・防御を行います。
△：単体では判断材料とならないものの、通信の振る舞いやパターンを評価する過程で間接的に利用されます。
―：原則として参照されず、制御・防御の対象外です。

一覧表を見ると、Azure のネットワークセキュリティサービスが「どこまでを守るのか」と「どこから先は別レイヤーなのか」が自然に見えてきます。

ネットワークセキュリティは、主にヘッダー部と一部のデータ部を判断材料として、保護を行います。

一方で、通信の結果として返される実行データそのものは、ここでは直接の保護対象とはならず、他のセキュリティ分野で考慮する領域になります。

5.おわりに

本記事では、通信を構成する情報（＝パケット）分解し、Azure におけるネットワークセキュリティの保護範囲を整理しました。

整理した内容は、理解を深める参考情報としてまとめたものであり、実務ではすべての機能を利用することが正解とは限りません。
制約や導入コスト、運用負荷、守るべき資産の価値などを踏まえ、適切に選択することが重要です。

次回の記事（3/4）では、態勢管理と脅威保護を一つの軸に、個別の領域に閉じない視点から、セキュリティ全体の捉え方について整理を進めたいと思います。

ここまで読んでいただき、ありがとうございました。

We Are Hiring!

OSI 参照モデルにおける各レイヤーのデータ単位（参考）。
レイヤー7 のデータ単位は定義されておらず、本記事では便宜的に「メッセージ/データ」と表現しています。 ↩
IP および TCP ヘッダの厳密な構成については、対象リンクをご覧ください（参考1・2）。 ↩
TLS 検査なしは Standard、TLS 検査ありは Premium の SKU が前提です（参考）。 ↩ ↩²
Standard では FQDN、Premium では TLS 検査を前提に URL 全体の情報を参照します。 ↩ ↩²
TLS 検査により、TLS セッションを終端し、平文の HTTP リクエストを検査することで、URL 全体や入力値も参照できます。 ↩
Azure Firewall Premium での IDPS 機能のほか、Azure Marketplace のサードパーティ製 IDS / IPS などが選択できます（参考）。 ↩
IDPS は、通信内容の特徴やパターンを評価するため、データ部（レイヤー7）に含まれる入力データなども参照します。そのため、TLS 検査によって TLS セッションを終端し、通信内容を参照できる Azure Firewall Premium の利用が前提になります。 ↩
Azure WAF は単体のサービスではなく、Azure Application Gateway や Azure Front Door などの Azure サービスで利用できます（参考）。 ↩
Web アプリケーションに対する攻撃の概要は、対象リンクをご覧ください（参考）。 ↩
Premium での TLS 検査ありが前提になります。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up