通信要件を整理するときに見るポイント
「拠点Aから拠点Bの業務Webを使えるようにしたい」
この依頼を受けたら、まず業務で必要な通信と、申請・設定に使う条件を結び付けて整理します。送信元、宛先、宛先ポートを入口に、通信を始める側、NAT、往復の経路、確認する担当者まで書き出します。
端末と相手側で見えるIPが変わる構成や、名前解決・認証の通信が必要な構成があります。関係者が同じ条件を見て確認できる形にすると、申請から疎通確認まで進めやすくなります。
この記事では、Firewall申請、VPN接続、システム連携に向けた通信要件の整理を扱います。対象は、ネットワークの基礎知識があり、実務で「何を、誰に、どこまで確認するか」に迷う方です。
持ち帰れる成果物は、次の3点です。
通信要件整理シート：必要な通信と設定の前提をそろえる。
未確認事項・担当分担シート：確認する内容、担当者、期限を決める。
申請・設定への引き渡しチェックリスト：情報の確定状況と、次へ進む条件を確かめる。
第1〜2章は整理の考え方、第3章以降はNAT・戻り経路の判断、記入欄、引き渡しまでの記入例を掲載します。
例はIPv4を中心に説明します。製品別コマンドやVPNの暗号・認証方式の詳細は、担当者が設計資料と製品資料で確認する範囲です。本文中の構成、IPアドレス、担当名、回答はすべて架空の教材例です。
第1章 通信要件を整理すると、申請・設定が進めやすくなる
最初に、業務の目的と通信の単位をそろえる
通信要件は、「誰が、何のために、どの相手へ、どの通信を行うか」から整理します。業務の言葉を残したうえで、申請・設定に使える条件へ具体化していきます。
画面表示、ログイン、ファイル取得で、接続先や通信を始める機器が変われば、必要な通信も分かれます。
例えば、まず次のように記録します。
業務目的：拠点Aの検証端末で、拠点Bの業務Webにログインし、帳票を取得する。
対象端末：10.10.1.25の1台。
利用先：portal.example.com。
利用期間：検証開始日から5営業日。
成功条件：指定のテスト用アカウントでログインし、対象帳票を取得できる。
宛先IP、プロトコル、NAT、戻り経路は、仕様書や担当者の回答で補います。
通信には「R01」のような通信IDを付けます。同じIDを3つの成果物で使うと、要件、確認事項、引き渡し判断を対応付けられます。
確認済みの情報と、これから確認する情報を並べる
分かっている情報を記録し、未確認事項には確認先を添えます。これが、要件をそろえるための出発点です。
申請者は業務目的、NW担当者は通過機器やNATなど、それぞれが持つ情報を集めるためです。
例えば、宛先ポートが未確認なら、次のように書きます。
確認事項：業務Webで使うプロトコルと宛先ポート。
現在の情報：利用者はブラウザでアクセスする予定。
確認先：アプリ担当。
確定に使う情報：アプリ仕様書の通信一覧と担当者の回答。
3つの成果物で、次の作業へつなぐ
要件を集め、未確認事項を担当者へ確認し、回答を反映してから引き渡します。例えばNAT後IPが分かったら、要件シートと対向側へ渡す許可対象を更新し、チェックリストで引き渡しを判断します。
各成果物の主な記入項目は、次のとおりです。
要件シート：通信ID、目的、送受信の条件、NAT、往復経路、期間、成功条件。
未確認事項シート：確認事項、現在の情報、状態、根拠、担当者、期限、回答、反映先。
チェックリスト：要件の充足、各担当の確認、残件、引き渡し可否、判断者・日付。
第2章 最初に集める情報と、担当者へ確認する情報
申請者は「何をしたいか」と「対象」を具体化する
最初に、業務目的、利用者、対象端末、利用先、利用期間、成功条件を集めます。既存の資料があれば、資料名と版も添えます。
送信元が1台か端末群かによって、調べる対象や範囲が変わるためです。
例えば「経理部の端末」なら、端末一覧や対象セグメントを確認します。DHCPでIPが変わる場合は識別方法をNW担当者と決め、業務の対象と設定のアドレス範囲を対応付けます。
役割の目安は次のとおりです。実際の担当範囲は、現場の運用体制に合わせて調整してください。
担当：申請者
主に確認する情報：業務目的、利用者、利用期間、成功条件
担当：アプリ・サーバ担当
主に確認する情報：接続先、待ち受け、認証、付随通信
担当：NW・対向側担当
主に確認する情報：NAT、経路、制御点、VPNの対象範囲
プロトコルと宛先ポートを組にして記録する
TCPやUDPなどのプロトコルと、宛先ポートを別々の欄に記録します。説明中は「TCP/443」のように組で表記すると読みやすくなります。
TCPとUDPでは異なる通信になるためです。HTTPSの方式も確認します。HTTP/3はHTTPのバージョン3を指し、QUICという通信方式を通じてUDPを使います。「3」はバージョン番号、「TCP/443」の「443」はポート番号を表します。[S6]
例えば、今回の教材では、アプリ仕様書でHTTPSのTCP/443利用が確認された設定とします。ICMPの確認を追加する場合は、プロトコルと必要なタイプ・コードを整理します。ICMPはTCP・UDPのポート欄とは分けて扱います。[S9]
送信元ポートは、クライアントが一時的に選ぶ場合があります。固定値を使う仕様や、応答を個別に許可する制御がある場合は、必要な範囲と根拠を担当者に確認します。
FQDNとIPアドレスには、確認した条件を添える
FQDNは、portal.example.comのようなホストを指定する名前です。FQDNを使う通信では、名前とIPアドレスに加え、誰がどこで名前解決するかを記録します。
DNSの応答は確認条件によって変わる場合があり、そのときの結果として残します。FWのFQDNオブジェクト（名前を基にIPを扱う設定項目）の更新方法も、製品仕様に照らして確認します。[S10]
例えば、次のように記録します。
FQDN：portal.example.com。
名前解決する機器：拠点Aの端末。
DNSサーバ：10.10.1.53。
確認結果：172.16.20.10。
確認条件：対象端末から指定DNSへ問い合わせ、確認日時を記録。
運用上の扱い：宛先は検証期間中固定。変更時は要件を再確認する。
SaaSなど接続先が変わるサービスでは、提供元の公開する接続要件や変更案内も確認します。IPv6の利用がある環境では、AAAAレコード、IPv6の経路・制御も別途整理します。
業務を支える通信も、必要性を確認する
DNS、認証、外部API、監視などは、誰がどこへ接続するかを確認して整理します。業務Webへの通信と関連付け、それぞれに通信IDを付けると管理しやすくなります。
例えば、端末からDNSサーバへ問い合わせる通信と、Webサーバから認証サーバへ接続する通信では、送信元も確認先も異なります。従来型のDNSを利用する場合はUDP/53とTCP/53を確認し、DoHなどを使う場合はその方式の要件を整理します。[S5]
証明書の失効確認なども、接続先やクライアントの仕様に応じて要否を確認します。必要性が確定した通信を、申請対象または既存利用として明記します。
ここまでの情報が集まったら、「通信開始側」「NAT」「戻り経路」を整理します。有料部分では、この整理を進める具体的な記入欄と判断例を紹介します。
