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

システム構築の最終フェーズである結合テストや、深夜のカットオーバー作業中、こんなトラブルに直面したことはないでしょうか？

「サーバもスイッチも疎通確認できたのに、アプリの通信だけがFWで弾かれて通らない……！」
「急遽FWのログを調べたら、想定外のポート番号が使われていて緊急設定変更……」
「とりあえずその場をしのぐために permit any any を入れて、そのまま本番稼働してしまった……」

インフラ現場で最も胃が痛くなるこうした手戻りやトラブルは、機器の故障ではなく、上流工程における「通信要件の定義不足・認識齟齬」が根本原因です。

ファイアウォール（FW）やL3スイッチのアクセス制御リスト（ACL）は、設定を1行間違えるだけで業務停止や重大なセキュリティインシデントに直結します。

18年以上の現場経験の中でも、深夜のカットオーバーで最も冷や汗をかいたのが「通信要件の漏れによる通信断」でした。

某社の大規模更改プロジェクトで、Active DirectoryのRPC動的ポートの考慮が漏れており、本番切り戻し寸前まで追い詰められたことがあります。

原因の9割は機器の不具合ではなく、戻りパケットの誤解やプロトコル仕様の確認不足といった「上流の定義ミス」です。

本記事では、開通試験での手戻りをゼロにし、セキュリティ監査（ISMSやPマーク）にも胸を張って提出できる「通信要件一覧（通信マトリクス）」の正しい設計・作成手順を徹底解説します。

通信要件マトリクスやFWパラメータシートは、ネットワーク詳細設計における重要ドキュメントのひとつです。

「構成図からパラメータ、試験仕様書まで、設計書全体の網羅的な目次構成や作成フローを知りたい」という方は、まず以下の親記事をご覧ください。

【結論】通信要件一覧で手戻りを防ぐ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つのゾーンを分離して設計します。

1. Untrust（外部・インターネット）： 信頼できない外部ネットワーク。
2. DMZ（公開非武装地帯）： 外部から直接アクセスを受ける公開サーバ群。
3. Trust（内部LAN・社内セグメント）： 従業員の端末や一般的な社内業務システム。
4. 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つのルールを運用設計に組み込みます。

1. 期間限定ルールの必須期限設定
   構築作業中やシステム移行期間だけ開ける通信には、通信要件一覧に必ず「有効期限（例: 2026/10/31迄）」を記載する。
   最新のFW（FortiGateやPalo Alto等）では、ルール自体にスケジュール（自動失効日時）を設定可能です。
2. 年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）」が定義されているか	□

最後に：通信要件一覧は「インフラとアプリを結ぶ信頼の契約書」

ネットワークエンジニアにとって、FWやACLの設計は「最も気を使う、プレッシャーのかかる作業」の筆頭です。

ひとつのポートの開け忘れでアプリケーションのリリースが遅延し、逆にひとつのポートの開けすぎが原因で不正アクセスの侵入経路を作ってしまう。その狭間で悩むことも多いはずです。

しかし、丁寧かつ論理的に作られた通信要件一覧は、あなた自身とあなたのチームを守る最強の盾になります。

「なぜこのポートが開いているのか」
「この通信は誰の責任で許可されたものなのか」
「万が一の障害時、どこから切り分けるべきなのか」

すべてがこの一覧に記されていれば、深夜のトラブルシューティングでも迷うことはありませんし、数年後のセキュリティ監査でも堂々と説明することができます。

まずは、直近のプロジェクトで「通信の開始方向（Initiator）を揃える」「オブジェクト管理を徹底する」という小さなルール決めから実践してみてください。手戻りのない、美しく堅牢なネットワークインフラを共に作り上げていきましょう！