ネットワーク通信要件と通信マトリクスの書き方｜FW設計の手戻りを防ぐ鉄則

2026年9月20日2026年9月26日

レベル別記事一覧

▼▼▼まずはここからチェック！

【結論】通信要件一覧で手戻りを防ぐ4大鉄則

通信要件を定義する際、現場で絶対に外してはならない大原則は以下の4点です。

① ステートフル性を意識し「通信の開始方向（Initiator）」で定義する
FWは「行きのパケット」を許可すれば戻りは自動追跡されます。戻りパケットを通信一覧に重複記載して混乱させるのを防ぎます。
② IP・ポートの直書きを排除し「オブジェクト設計」と紐づける
ルール内に直接IPを書かず、必ず「アドレスオブジェクト」「サービスグループ」を定義して参照させます。
③ インターネット向け（Egress）の「Any許可」を廃止する
内部から外部への通信であっても、サーバセグメントは接続先FQDN/URLを限定し、C2通信や情報漏洩を遮断します。
④ すべての行に「用途・申請者・有効期限」を持たせる
「なぜこのポートを開けたのか」の文脈を記録し、誰にも消せない危険な「ゾンビルール」の増殖を断ち切ります。

なぜ開通試験で通信が通らないのか？通信要件定義で頻発する4大失敗

まずは、現場で通信が通らずトラブルになる「よくある落とし穴」を把握しておきましょう。原因がわかれば、設計書に何を盛り込むべきかが自ずと見えてきます。

「双方向通信」の誤解（ステートフルFW vs ステートレスACL）

よくある間違いとして、ポリシーがステートフルなのか、ステートレスなのか意識せずに設計してしまうことが挙げられます。

Webアクセスだから「クライアント ➔ サーバ」への通信と、「サーバ ➔ クライアント」への戻り通信の『両方』をポリシーに定義してしまうという失敗です。

ステートフルインスペクションFW（Palo Alto, FortiGate, Cisco Secure Firewall等）
クライアントからサーバへの「通信開始（SYN）」を許可すれば、FWがコネクション（セッション）を動的に記憶し、戻りのパケットは自動的に通過させます。設計書に戻り通信を書く必要はありません。
ステートレスACL（一般的なL3スイッチや一部ルータの標準ACL）
セッションを記憶しないため、行きだけでなく「戻りのパケット」も静的ルールとして明示的に許可しなければ通信が成立しません。

「この通信要件はステートフルFW向けなのか、L3スイッチのACL向けなのか」を意識せずに一覧を作ると、不要なルールが倍増したり、逆にL3スイッチで戻りパケットが破棄されて通信断に陥ったりします。

プロトコル仕様の理解不足（DNS・Active Directory・NTP）

アプリケーション担当者から「DNSとADとNTPの通信を開けてください」と依頼され、一般的なポート番号だけを開けて失敗するケースです。

DNS（ポート53）の落とし穴
「DNS＝UDP 53」と思い込みがちですが、ゾーン転送や512バイトを超える応答（EDNS0）、DNSSECではTCP 53も使用されます。UDPだけを開けていると、大規模パケットで突然名前解決がタイムアウトします。
Active Directoryの動的RPCポート
ドメイン参加やグループポリシー適用では、LDAP（TCP/UDP 389）やKerberos（TCP/UDP 88）、SMB（TCP 445）だけでなく、RPC動的ポート（TCP 49152〜65535）が使われます。これを把握していないと「通信要件通りに開けたのにドメインに参加できない」という事態に陥ります。
NTP（UDP 123）の送信元ポート
一般的なクライアントは送信元ポートにエフェメラルポートを使いますが、一部のOSや機器では「送信元ポートもUDP 123」で通信を送信します。ポートの指定方向（送信元か宛先か）を間違えると通信が成立しません。

NAT適用前後のIPアドレス不一致（変換前IP vs 変換後IP）

社内LANとクラウド（AWS/Azure）の接続や、DMZ上のWebサーバをインターネット公開する際、NAT（Network Address Translation）が介在します。

ここで問題になるのが、「FWのセキュリティポリシーで指定するIPは、NAT変換前なのか、変換後なのか」という点です。

Palo Alto
原則として「宛先IPはNAT変換前（グローバルIP）、ゾーンは変換後の宛先ゾーン（DMZ）」を指定する
FortiGate
ポリシー内で「仮想IP（VIP）」を指定し、変換後IPとNAT設定を統合的に扱う
Cisco ASA / Secure Firewall
バージョンやモードによって変換前（Real IP）を指定する

要件一覧に書かれているIPが「NAT前」なのか「NAT後」なのかが明記されていないと、設定投入時にエンジニアが誤認し、開通試験で必ずパケットがドロップします。

目的不明な「恒久Anyルール」の残骸

トラブル発生時に「とりあえず通信を通すため」に一時的に追加した permit any any。

プロジェクトが終了したあとも「怖くて誰も削除できないルール」として放置され、数年後には誰も管理できないセキュリティホールと化します。

通信要件一覧（通信パラメータシート）の必須記載項目と設計ルール

トラブルを防ぐために、通信要件一覧（通信パラメータシート）には何を記載すべきでしょうか。実務で必須となる「10大基本項目」と設計フォーマットを解説します。

通信要件一覧に必須の「10大基本項目」

Excelやスプレッドシートで通信要件台帳を作成する場合、以下の10項目を1レコード（1行）として定義します。

#	項目名	記載例	役割と設計ポイント
1	通信管理ID	`POL-0010`	変更管理・チケット管理と紐づける一意の連番
2	送信元ゾーン (From)	`Trust`	通信が発生するセキュリティ境界（拠点、VLAN群）
3	送信元IP / オブジェクト	`10.10.20.0/24`	CIDRまたはアドレスオブジェクト名（例: `GRP_Client_PC`）
4	宛先ゾーン (To)	`DMZ`	通信が到達する終端ゾーン
5	宛先IP / オブジェクト	`10.10.10.11`	接続先端末・サーバのIPまたはオブジェクト名
6	サービス (プロトコル/ポート)	`TCP / 443`	プロトコル種別と「宛先」ポート番号
7	アクション	`Permit (許可)`	通信の許可（Permit/Allow）または拒否（Deny/Drop）
8	ログ取得	`Enable (有効)`	セキュリティ監視・監査に必要なログを出力するか否か
9	業務用途・通信目的	`社内Webシステム閲覧`	「なぜこの通信が必要なのか」を日本語で明確に記載
10	申請者・有効期限	`情シス部 (恒久)`	管理責任部門とルールのライフサイクル（期限）

⚠️ ポート番号は「宛先ポート」を書く

初心者が最も混乱するのがポートの方向です。特別な要件（送信元ポートが固定されるNTPなど）を除き、通信要件一覧に書くポート番号は「宛先ポート（通信を受け付けるサーバ側のポート）」を指します。

送信元ポートはOSが自動で払い出すエフェメラルポート（1024〜65535）であるため、原則として指定しません。

「通信マトリクス」と「通信一覧（リスト形式）」の使い分け

設計現場では「通信マトリクス」と「通信一覧」という言葉が混同されがちですが、役割が明確に異なります。

通信マトリクス（総当たり表形式）
縦軸に「送信元ゾーン/セグメント」、横軸に「宛先ゾーン/セグメント」を取り、交点に「○（全許可）」「△（個別要件のみ許可）」「×（全面遮断）」をプロットした俯瞰図。
　👉 経営層やセキュリティ監査担当への「全体方針説明」に最適。
通信一覧（リスト形式）
前述の10項目を1行ずつ定義した詳細台帳。
　👉 FWやルータの実機にConfigを投入・自動生成するための「実装台帳」。

実務では、まず「通信マトリクス」でシステム全体のセキュリティポリシー（例: DMZから内部LANへの通信は原則×とする等）を合意し、その後に「通信一覧（リスト形式）」で個別のポートやIPを定義していくという2段階のアプローチが最も手戻りを防げます。

【実務サンプル】通信要件一覧パラメータシート

実務でそのまま使えるパラメータシートのサンプルです。

通信ID	Fromゾーン	送信元オブジェクト	Toゾーン	宛先オブジェクト	サービス	動作	ログ	用途・通信目的	申請者 / 期限
POL-0010	Trust	`GRP_Client_PC`	DMZ	`SV-WEB-01`	TCP / 443	Permit	Enable	勤怠管理システムWeb閲覧	人事総務部（恒久）
POL-0020	DMZ	`SV-WEB-01`	Trust	`SV-DB-01`	TCP / 3306	Permit	Enable	WebサーバからのDB照会	開発チーム（恒久）
POL-0030	Trust	`GRP_Client_PC`	Untrust	`Any`	TCP / 80, 443	Permit	Disable	一般Web閲覧（URLフィルタ併用）	情シス（恒久）
POL-0040	MGMT	`SV-ZABBIX-01`	ALL	`GRP_All_Nodes`	ICMP, UDP/161	Permit	Disable	死活監視およびSNMPポーリング	運用チーム（恒久）
POL-0050	Partner	`192.168.99.10`	Trust	`SV-STG-APP01`	TCP / 22	Permit	Enable	外部ベンダー環境構築作業	外部委託（2026/10/31迄）
POL-9999	ALL	`Any`	ALL	`Any`	Any	Deny	Enable	暗黙の拒否（未定義通信の遮断）	セキュリティ共通方針

ファイアウォール（FW）ポリシー設計：インバウンド・Egress統制の鉄則

通信要件を定義する際は、「セキュリティゾーン（境界）」の概念とトラフィックの方向性を厳密に区別する必要があります。

セキュリティゾーン設計の基本原則（Trust / Untrust / DMZ / MGMT）

一般的な企業ネットワークでは、最低でも以下の4つのゾーンを分離して設計します。

Untrust（外部・インターネット）： 信頼できない外部ネットワーク。
DMZ（公開非武装地帯）： 外部から直接アクセスを受ける公開サーバ群。
Trust（内部LAN・社内セグメント）： 従業員の端末や一般的な社内業務システム。
MGMT（運用管理セグメント）： NW機器の管理ポートや監視サーバ、踏み台サーバを収容。

この境界を越える通信には、以下の「基本防御モデル」を適用します。

Trust ➔ DMZ / Untrust: 必要な通信のみ許可（インスペクション・URLフィルタを適用）
Untrust ➔ DMZ: 公開Webサービス（80/443等）のみ限定許可
Untrust ➔ Trust: 全面拒否（Deny All）
DMZ ➔ Trust: 原則拒否。Web ➔ DBなど、業務上どうしても必要な通信のみ単一宛先・単一ポートで例外許可する

3-2. インターネット向け通信の統制とプロキシ/FQDN連携

見落とされがちなのが、社内やサーバからインターネットへ抜ける「アウトバウンド（Egress）通信」の制御です。

多くの現場で「外向け通信は全部 permit any any」という大雑把な設定がされがちですが、これは非常に危険です。

端末がマルウェアに感染した場合、外部のC2（コマンド＆コントロール）サーバと自由に通信できてしまい、情報漏洩やランサムウェアの水平展開を許してしまいます。

端末セグメント
ポート80/443であってもFWのURLフィルタリングやセキュアWebゲートウェイ（SWG）を経由させ、不正なカテゴリへのアクセスをブロックする。
サーバセグメント
原則としてインターネット直接通信は禁止。OSアップデートや外部API連携が必要なサーバのみ、宛先FQDNや特定グローバルIPに限定して許可する。

管理セグメントの隔離と踏み台設計

SSH（ポート22）やRDP（ポート3389）、HTTPSなどの機器管理通信は、すべてのセキュリティポリシーの中で最も厳密に管理すべき通信です。

一般端末から直接本番サーバやコアスイッチへの管理アクセスを許可してはいけません。

必ず「踏み台サーバ」を経由させ、踏み台サーバのIPからのみ管理ポートへのアクセスを許可するルールを要件一覧に明記します。

監査（ISMS・Pマーク・PCI DSS）に耐えうる運用・ライフサイクル管理

通信要件一覧は、作って終わりではありません。企業のセキュリティ監査で「このポートが開いている論理的な理由を説明してください」と問われた際、即答できる仕組みを組み込んでおく必要があります。

ルール命名規則（Rule Name）の標準化

FWのポリシー一覧画面を見たときに、ひと目で役割がわかるよう命名規則を統一します。

【推奨フォーマット】

[FromZone]_[ToZone]_[用途/システム略称]_[Seq]

例: Trust_DMZ_WebAccess_010（社内PCからDMZ Webサーバへのアクセス）
例: MGMT_Core_SNMP_020（監視サーバからコアスイッチへのSNMP収集）
例: Partner_Trust_SSH-Temp_099（一時的な外部ベンダー作業用ルール）

オブジェクト管理（IP/ポートのグループ化）の鉄則

ポリシーの送信元・宛先欄に、192.168.10.11 のような生のIPアドレスを直接入力してはいけません。

必ず「アドレスオブジェクト」や「アドレスグループ」を作成してルールに紐づけます。

メリット①：可読性の向上
10.10.20.15 と書かれているより、SV_ActiveDirectory_01 と表示されている方が直感的に意図を把握できる。
メリット②：メンテナンス性の劇的向上
Webサーバが2台から3台に増設された際、通信ポリシー自体を編集する必要がありません。
オブジェクトグループ（GRP_Web_Servers）に新しいIPを1つ追加するだけで、関連するすべてのFWポリシーに一括適用されます。

「ゾンビルール」を撲滅する有効期限と棚卸し

通信要件の形骸化を防ぐため、以下の2つのルールを運用設計に組み込みます。

期間限定ルールの必須期限設定
構築作業中やシステム移行期間だけ開ける通信には、通信要件一覧に必ず「有効期限（例: 2026/10/31迄）」を記載する。
最新のFW（FortiGateやPalo Alto等）では、ルール自体にスケジュール（自動失効日時）を設定可能です。
年1回のヒットカウント棚卸し
FW機器の機能で、各ルールの「ヒットカウント（パケットが合致した回数）」を確認します。
過去半年〜1年間でヒットカウントが「0」のルールは、すでに不要になったシステムの残骸（ゾンビルール）です。申請部門へヒアリングを行い、段階的に無効化・削除を進めます。

【実務テンプレート】通信マトリクス・通信要件一覧Excelの作り方

実務で通信要件一覧をExcelで管理する場合、以下の4シート構成で作成することを強く推奨します。

入力規則と条件付き書式で「表記ゆれ」「入力漏れ」を根絶する

手動入力による表記ミスを防ぐため、Excelの標準機能をフル活用しましょう。

「データの入力規則（リスト）」の設定:
- Fromゾーン / Toゾーン：Sheet 4のマスタからプルダウン選択させる（「Trust」「社内LAN」といった表記ゆれを防止）
- プロトコル：TCP, UDP, ICMP, IP から選択
- アクション：Permit, Deny から選択
- ログ取得：Enable, Disable から選択
「条件付き書式」による入力漏れ警告:
- 通信IDが入力されている行で、「用途」や「申請者」がブランクの場合、セルを薄い赤色でハイライトする数式（=AND($A2<>"",$I2="")）を設定。

まとめと次のステップ（設計書シリーズへの展開）

通信要件一覧（通信マトリクス）は、ネットワークの結線やIPアドレスといった「物理・論理の土台」の上に敷かれる、システムの命綱となるドキュメントです。

【実務用】通信要件一覧・FWパラメータ設計チェックリスト

設計レビューや実機設定の前に、以下の項目を最終チェックしてください。

カテゴリ	チェック項目	確認
通信方向	ステートフルFWにおいて、戻りパケットを誤って別ルールとして重複定義していないか	□
ポート指定	指定しているポート番号は「宛先ポート（サーバ側待受ポート）」になっているか	□
プロトコル	DNS（TCP53の要否）やNTP、AD動的RPCなどの特殊なプロトコル仕様を考慮しているか	□
オブジェクト	ポリシーにIPやポートを直書きせず、オブジェクト化して関連付けているか	□
Egress統制	サーバセグメントから外部への通信が、安易な「Any/Any許可」になっていないか	□
特権管理	SSHやRDPなどの管理通信は、踏み台サーバや管理セグメント経由に限定されているか	□
ライフサイクル	一時的なテスト通信や移行作業用通信に、明確な「失効期限」が設定されているか	□
暗黙の拒否	パラメータの最下行に「すべての未定義通信を拒否・ログ出力する（Deny All）」が定義されているか	□