問1 ネットワークシステムの設計
ネットワークシステムの設計に関する次の記述を読んで，設問1〜4に答えよ。
機械メーカの X 社は，顧客に販売した機械の運用・保守と，機械が稼働している顧客の工場の自動化支援に関する新事業を拡大しようとしている。
機械は工作装置及び通信装置の 2 種類である。工作装置には，センサ，アクチュエータなどを制御する機構（以下，デバイスという），及びレイヤ 2 スイッチが内蔵されている。通信装置は，デバイスをインターネットに接続するための機器で，エッジサーバ，ファイアウォール及びレイヤ 3 スイッチが内蔵されている。
X 社の情報システム部は，新事業用のサービス基盤システム（以下，X システムという）を計画中である。情報システム部に所属するネットワーク担当の W さんが，X システムの構想について，検討を行っている。
〔X システムの構想〕
X システムは，X 社が運用・保守を行う顧客の工場内の機器，X 社内のサーバ，及びそれらを接続するためのネットワーク機器から構成されている。
X システムの導入構成例を図1に示す。
X システムの業務アプリケーションプログラムは，エッジサーバと業務サーバ上で動作する。これらのサーバとデバイスは，デバイスの運用・保守に関する情報を，自動的に交換する。この情報交換に関する説明を次に示す。
- 工作装置と通信装置を接続し，顧客の工場内に X システム専用のネットワークを構成する。顧客ネットワークは利用しない。
- publish/subscribe 型のメッセージ通信プロトコル MQTT（Message Queuing Telemetry Transport）を使って，交換サーバを介して，デバイス，エッジサーバ及び業務サーバの間でメッセージを交換する。
- デバイス，エッジサーバ及び業務サーバに MQTT クライアント機能を，交換サーバに MQTT サーバ機能をそれぞれ実装する。
業務サーバは，顧客向けに API（Application Programming Interface）を提供する。顧客は，インターネット経由で API にアクセスし，デバイスの運用・保守に関する情報を参照する。この API に関する説明を次に示す。
- X 社の業務サーバと認可サーバに HTTP サーバ機能をそれぞれ実装する。
- 顧客は，顧客サーバに，API アクセス用の Web アプリケーション（以下，WebAP という）と HTTP サーバ機能を実装する。
- 顧客は，PC の Web ブラウザを使い，顧客サーバを経由して，API にアクセスする。
- X 社の認可サーバは，顧客サーバから API へのアクセスを認可する。
W さんは，上司から，X システムの構想に関する四つの技術検討を指示されている。四つの技術検討項目を次に示す。
- ネットワークセキュリティ対策
- MQTT を使ったメッセージ交換方式
- API にアクセスする顧客サーバの管理
- エッジサーバを活用する将来構想
〔ネットワークセキュリティ対策〕
X システムは，インターネット及び顧客の工場内の X システム専用のネットワークを利用するので，これらの X 社外の通信区間に関するネットワークセキュリティ対策が必要となる。W さんが検討したネットワークセキュリティ対策を次に示す。
- 情報の漏えい及び改ざん対策のために TLS を利用する。TLS には，情報を ［ ア ］ する機能，情報の改ざんを ［ イ ］ する機能，及び通信相手を ［ ウ ］ する機能がある。
- 工場内の機器と X 社内の機器との通信は，いずれもクライアントサーバ型の通信であり，機器間の ［ エ ］ コネクションの確立要求は，工場から X 社の方向に行われる。それを踏まえて，次の侵入及びなりすまし対策を採用する。
- − X 社に設置された FW を使った対策
- − ①通信装置内の FW を使った対策
- − ② TLS の機能を使った，デバイス及びエッジサーバに関する対策
〔MQTT を使ったメッセージ交換方式〕
W さんは，MQTT を使ったメッセージ交換方式を調査した。
このメッセージ交換方式では，固定ヘッダ，可変ヘッダ及びペイロードから構成された MQTT コントロールパケットを使う。MQTT コントロールパケットの種別を表1に示す。
MQTT を使ったメッセージ交換方式の通信シーケンス例を図2に示す。
図 2 中の通信シーケンスでは，配信元から複数の配信先へメッセージが配信されている。通信シーケンスの説明を次に示す。
- クライアントは，サーバの TCP ポート 8883 番にアクセスし，TCP コネクションを確立する。この TCP コネクションは，メッセージ交換の間は常に維持される。
- クライアントは CONNECT を送信し，サーバは CONNACK を返信する。
- 配信先となるクライアントは，サーバに SUBSCRIBE を送信し，購読対象のメッセージを，トピック名を使って通知する。サーバはクライアントに SUBACK を返信し，購読要求を受け付けたことを通知する。
- 配信元クライアントは，PUBLISH を使ってサーバにメッセージを送信する。
- メッセージを受信したサーバは，PUBLISH に含まれるトピック名について購読要求を受け付けている全てのクライアントに，そのメッセージを送信する。
PUBLISH を使ったメッセージ送信では，QoS レベルを使って送達確認手順を指定する。QoS レベルとメッセージ送信の通信シーケンスを図3に示す。
図3中の通信シーケンスの説明を次に示す。
- QoS レベルが 0 の場合，MQTT 層における PUBLISH の送達確認は行わない。TCP 層による送達確認だけが行われる。
- QoS レベルが 2 の場合，MQTT 層においても PUBLISH の送達確認が行われる。MQTT 層の送達確認の説明を次に示す。
- − TCP コネクションが切断された場合のために，PUBLISH 及び PUBREL は送信者によって保存され，送信者から受信者への再送に利用される。
- − ③ PUBLISH を受信した受信者は，メッセージの処理を始める前に送信者に PUBREC を送信し，その応答である PUBREL を受信してからメッセージの処理を開始する。
- − PUBREL を送信した送信者は，その応答である PUBCOMP を受信してから，メッセージ送信を完了する。
次に W さんは，X システムの 2 種類のメッセージ交換について，トピック名，QoS レベル，及び配信元と配信先を整理した。
X システムのメッセージ交換を図4に示す。
図4の説明を次に示す。
- 項番 1 では，デバイス Di は，あらかじめ ［ オ ］ を交換サーバに送信し，トピック名が ［ カ ］ の PUBLISH が送信されるようにする。
- 項番 1 では，QoS レベルとして 2 が使用されている。交換サーバからデバイス Di への PUBLISH 送信中に ［ キ ］ が電源断などで非稼働になった場合，その PUBLISH は，［ ク ］ の中に保存され，稼働再開後に再送される。
- 項番 2 では，QoS レベルとして 0 が使用されている。これは，［ ケ ］ 及びエッジサーバは安定した稼働が見込めるからである。
W さんは，1 台の業務サーバが 6,000 台のデバイスの設定を変更する場合の送信時間（T）を概算した。
W さんが T の概算に用いた通信シーケンスを図5に示す。
図 5 中の装置の処理時間を無視し，図 5 中の t1 及び t2 は，それぞれの装置間の RTT（Round Trip Time）の 2 倍に等しいとし，LAN の RTT を 20 ミリ秒，WAN の RTT を 200 ミリ秒とすると，T は次のように概算できる。
T ＝ m × t1 ＋ t2 ＝ 6,000 × 2 × 20 ＋ 2 × 200（ミリ秒）≒ 4（分）
この概算を基に，W さんは，次のように報告することにした。
- TCP コネクションが正常であれば，全デバイスへの設定情報の送信は 4 分間程度で完了する。
- ただし，図 1 に示すように，［ コ ］ は同一拠点に設置されている必要がある。
〔API にアクセスする顧客サーバの管理〕
W さんは，顧客サーバからの API アクセスに関する検討を行った。
X システムでは，認可サーバを使って，顧客サーバからの API アクセスを認可する。契約及びサービス仕様の変更が顧客ごとに発生するので，それらを前提とした認可の仕組みが必要になる。W さんは，認可コード，アクセストークン，及びリフレッシュトークンを使った，認可の仕組みを採用することにした。
X システムの API アクセスの通信シーケンスを図6に示す。
図 6 中の（Ⅰ）に示すように，有効なトークンがない場合，Web ブラウザから WebAP への情報要求は，［ サ ］ サーバにリダイレクトされる。認可応答では，認可要求で通知された URI を用いたリダイレクトによって，［ シ ］ に認可コードが通知される。続いて，認可コードを用いたトークン要求とトークン応答が行われ，WebAP はアクセストークンとリフレッシュトークンを獲得する。
図 6 中の（Ⅰ）〜（Ⅲ）に示すように，業務サーバへの情報要求には，アクセストークンが用いられる。アクセストークンには，アクセス可能な API と有効期間に関する情報が含まれており，業務サーバはそれらの情報からアクセスの可否を決める。アクセストークンの有効期間を過ぎた場合でも，［ ス ］ の有効期間内であれば，利用者の確認を行わずに，新しいアクセストークンが発行される。
X システムでは，顧客ごとに異なるアクセストークンを定義し，認可サーバに格納しておく。ある顧客に提供する API の範囲が変わる場合，X 社は認可サーバのアクセストークンを変更する。W さんは，④アクセストークンの有効期間を 10 分間，リフレッシュトークンの有効期間を 60 分間と想定し，トークンの運用を確認した。
図 6 の通信シーケンスでは，図 6 中の“(a) 認可要求”の redirect_uri パラメタが書き換えられ，図 6 中の ［ セ ］ に含まれる認可コードが意図しない宛先に送信される可能性がある。W さんは，その対策として“redirect_uri パラメタの確認”を行うことにした。これは，図 6 中の ［ ソ ］ サーバに，HTTP リクエストに含まれる URI とあらかじめ登録されている絶対 URI が一致することを確認させる，という対策である。⑤顧客向けの API 利用ガイドラインには，この対策に必要な顧客への依頼内容を明記することにした。
〔エッジサーバを活用する将来構想〕
図 4 中のメッセージ交換では，X 社内の交換サーバを利用するので，顧客の企業秘密を含むような設定情報及び稼働情報（以下，これらを内部情報という）は，対象外としている。しかし，内部情報についても図 4 と同様にメッセージ交換を行いたい顧客も多い。X 社では，エッジサーバを活用して，内部情報も X システムに取り込む将来構想をもっている。
顧客サーバが一つの場合について，将来構想で追加される X システムのメッセージ交換例を図 7 に，W さんが考えた将来構想におけるネットワーク構成案を図 8 に，それぞれ示す。
図 8 に示すように，W さんは，NAT ルータを使って，顧客ネットワークと X システムを接続する案を考えた。NAT ルータは，1：1 静的双方向 NAT として動作させ，図 8 中の NAT ルータ-P と NAT ルータ-P’ を利用して，宛先 IP アドレスと送信元 IP アドレスの両方を変換させる。
W さんが考えた将来構想におけるメッセージの流れを図 9 に示す。
図 9 の説明を次に示す。
- 顧客サーバに MQTT クライアント機能を，エッジサーバに MQTT サーバ機能をそれぞれ実装し，顧客サーバとエッジサーバ間でメッセージ交換を行う。
- エッジサーバの MQTT サーバ機能は，通常の MQTT サーバ機能に加えて，メッセージをほかの MQTT サーバと送受信する機能（以下，MQTT ブリッジという）をもつ。X システムのデバイスは複数の機器と TCP コネクションを確立できないので，この MQTT ブリッジを利用する。
- ⑥ MQTT ブリッジには，トピック名をあらかじめ定義しておき，そのトピック名のメッセージを交換サーバと送受信させる。
W さんは，図 7〜9 を使って，ネットワークの動作について検討し，将来構想への対応が可能であると判断した。
W さんは，以上の検討結果を上司に報告した。X 社の情報システム部は，X システム構想を実現するためのプロジェクトを発足させた。
出題趣旨（IPA）
センサ，アクチュエータなどが情報ネットワークに接続され，企業間にまたがった情報システムが構築されている。そのような分野に応用されることを目的とした，様々なネットワークの規格化も進んでいる。本問では，製造業のスマート化の基盤となるネットワークシステムの設計を題材にした。その中で，以前から広く用いられている，“Webコンピューティング”に関する知識と設計能力を前提にして，比較的新しい“メッセージ通信プロトコルMQTT”と“Webサービスの連携に用いる仕組み”に関して，本文の記述を理解し，それらを情報システムに応用できるネットワーク技術の能力を問う。
設問と解答例
本文中の ［ ア ］ 〜 ［ エ ］ に入れる適切な字句を答えよ。
〔ア〕解答例
- 暗号化
〔イ〕解答例
- 検知
〔ウ〕解答例
- 認証
〔エ〕解答例
- TCP
解説
本文の根拠
〔ネットワークセキュリティ対策〕
情報の漏えい及び改ざん対策のために TLS を利用する。TLS には，情報を ［ ア ］ する機能，情報の改ざんを ［ イ ］ する機能，及び通信相手を ［ ウ ］ する機能がある。
〔ネットワークセキュリティ対策〕
工場内の機器と X 社内の機器との通信は，いずれもクライアントサーバ型の通信であり，機器間の ［ エ ］ コネクションの確立要求は，工場から X 社の方向に行われる。
〔MQTT を使ったメッセージ交換方式〕
クライアントは，サーバの TCP ポート 8883 番にアクセスし，TCP コネクションを確立する。
ア〜ウ：TLS（RFC 8446 など）が提供するのは，共通鍵暗号によるデータの暗号化（漏えい対策），メッセージ認証符号などによる改ざんの検知，証明書を使った通信相手の認証の三つである。本文は「漏えい及び改ざん対策」と「通信相手を」と書き分けているので，アは暗号化，イは検知，ウは認証になる。エ：TLS は TCP の上で動き，MQTT のクライアントは交換サーバの TCP ポート 8883 番にコネクションを張る。コネクションの確立要求（SYN）を出す向きが問われているので，エは TCP である。
本文の〔MQTT を使ったメッセージ交換方式〕に「TCP ポート 8883 番にアクセスし，TCP コネクションを確立する」とあり，工場側の MQTT クライアント（デバイス，エッジサーバ）から X 社の交換サーバへ向かうことが分かる。
間違えやすい点。イを「防止」とすると誤りである。TLS は改ざんそのものを防げず，改ざんされたことを受信側が検知して破棄する。エを「MQTT」「TLS」とすると，「コネクションの確立要求」という TCP の用語と合わない。
本文中の下線①の対策を，50 字以内で述べよ。
解答例
- X社が運用・保守を行う機器からX社FWの方向に確立されるTCPコネクションだけを許可する。
解説
本文の根拠
〔ネットワークセキュリティ対策〕
工場内の機器と X 社内の機器との通信は，いずれもクライアントサーバ型の通信であり，機器間の ［ エ ］ コネクションの確立要求は，工場から X 社の方向に行われる。それを踏まえて，次の侵入及びなりすまし対策を採用する。
〔ネットワークセキュリティ対策〕
①通信装置内の FW を使った対策
図1
通信装置（網掛け）の中には L3SW，FW，エッジサーバがあり，各工作装置の L2SW が L3SW に接続し，L3SW にエッジサーバと FW が接続し，FW がインターネットに接続している。
通信装置内の FW は，工場の X システム専用ネットワークとインターネットの境界にある。工場と X 社の通信は，必ず工場側の機器（デバイス，エッジサーバ）がクライアントとなって X 社に向けて TCP コネクションを張る。逆向き，つまりインターネット側から工場内へコネクションを張る必要は無い。そこで，X 社が運用・保守を行う機器から X 社の FW の方向に確立される TCP コネクションだけを許可し，それ以外（インターネットからの接続要求など）を拒否すれば，外部からの侵入を防げる。ステートフルインスペクションの FW なら，許可したコネクションの戻りのパケットは自動的に通す。
根拠は「確立要求は，工場から X 社の方向に行われる。それを踏まえて」の一文で，下線①はこの向きの制限を FW で実現する対策である。
字数の詰め方（50字）。「どの機器から」「どこへ向けて」「TCP コネクションだけを許可」の三つを残す。解答例は「X 社が運用・保守を行う機器から X 社 FW の方向に確立される TCP コネクションだけを許可する。」である。採点講評のとおり図1には FW が三つある（通信装置内の FW，顧客 FW，X 社の FW）。宛先を「顧客 FW」や単に「インターネット」とせず，X 社 FW と書く。
採点講評（IPA）
設問1は，ネットワークセキュリティについて問うた。設問の中では設問１(2)の正答率が低かった。導入構成例（図1）では，インターネットを介した二つの拠点に，三つのファイアウォールが設置されている。Xシステムに関する記述を正しく理解し，注意深く解答してほしい。
本文中の下線②の対策を，30 字以内で述べよ。
解答例
- クライアント証明書を配布してクライアント認証を行う。
解説
本文の根拠
〔ネットワークセキュリティ対策〕
② TLS の機能を使った，デバイス及びエッジサーバに関する対策
〔ネットワークセキュリティ対策〕
それを踏まえて，次の侵入及びなりすまし対策を採用する。
〔X システムの構想〕
デバイス，エッジサーバ及び業務サーバに MQTT クライアント機能を，交換サーバに MQTT サーバ機能をそれぞれ実装する。
TLS の通常の使い方では，サーバがサーバ証明書を示し，クライアントがサーバを認証する。TLS にはこれに加えて，サーバがクライアントに証明書を要求して（CertificateRequest）クライアントを認証する仕組みがある。デバイスとエッジサーバは TLS のクライアントなので，それぞれにクライアント証明書を配布しておき，交換サーバがクライアント認証を行えば，X 社が配布した証明書を持たない機器がデバイスやエッジサーバになりすまして接続することを防げる。
本文は下線②を「なりすまし対策」の一つとして挙げ，対象を「デバイス及びエッジサーバ」としている。この二つは MQTT クライアントであり，接続先の交換サーバから見てなりすましを見破る必要がある相手である。
字数の詰め方（30字）。「クライアント証明書を配布して」と「クライアント認証を行う」を残す。解答例は「クライアント証明書を配布してクライアント認証を行う。」である。「サーバ証明書を検証する」では，デバイス側が交換サーバを確かめるだけで，デバイスやエッジサーバのなりすましは防げない。
図 3 中の QoS レベルが 0 の場合のメッセージ送信について，TCP の再送機能だけではメッセージの消失が防げないのはどのような場合か。45 字以内で具体的に答えよ。
解答例
- TCPの送信処理中に，デバイスの電源断などでTCPコネクションが開放された場合
解説
本文の根拠
〔MQTT を使ったメッセージ交換方式〕
QoS レベルが 0 の場合，MQTT 層における PUBLISH の送達確認は行わない。TCP 層による送達確認だけが行われる。
〔MQTT を使ったメッセージ交換方式〕
TCP コネクションが切断された場合のために，PUBLISH 及び PUBREL は送信者によって保存され，送信者から受信者への再送に利用される。
図4
項番2：全てのデバイス Di（i=1，2，…，m）から，業務サーバ及び同じ工場のエッジサーバに対して，稼働情報を定期的に送信する。
TCP の再送は，一つのコネクションの中で失われたセグメントを送り直す仕組みである。コネクションそのものが途中で開放されると，送信バッファに残っていたデータや届いていないデータは再送されずに失われる。QoS レベル 0 では MQTT 層は PUBLISH を保存しないので，再接続後に送り直すこともできない。したがって，TCP の送信処理中に，デバイスの電源断などで TCP コネクションが開放された場合にメッセージが消失する。
本文は QoS レベル 2 の説明で「TCP コネクションが切断された場合のために，PUBLISH 及び PUBREL は送信者によって保存され」と書いている。裏を返せば，保存しない QoS レベル 0 はコネクション切断に弱い。図4 の項番2 では送信者がデバイスなので，デバイスの電源断が具体例になる。
字数の詰め方（45字）。「TCP の送信処理中」「電源断など」「TCP コネクションが開放された」の三つを残す。解答例は「TCP の送信処理中に，デバイスの電源断などで TCP コネクションが開放された場合」である。「パケットが失われた場合」だけでは TCP の再送で回復できるので答えにならない。
本文中の下線③について，PUBREL を受信するまで，メッセージの処理を保留する目的を，20 字以内で述べよ。
解答例
- メッセージの重複を防止する。
解説
本文の根拠
〔MQTT を使ったメッセージ交換方式〕
③ PUBLISH を受信した受信者は，メッセージの処理を始める前に送信者に PUBREC を送信し，その応答である PUBREL を受信してからメッセージの処理を開始する。
〔MQTT を使ったメッセージ交換方式〕
TCP コネクションが切断された場合のために，PUBLISH 及び PUBREL は送信者によって保存され，送信者から受信者への再送に利用される。
図3
注記2：QoS レベルが2の場合，受信者は，メッセージの処理を開始した以降に受信した PUBLISH は，パケット ID の重複にかかわらず新しいパケットとみなす。
送信者は PUBREC を受け取るまで PUBLISH を保存し，コネクションが切れれば再送する。そのため受信者には同じ PUBLISH（同じパケット ID）が二度届くことがある。受信者は PUBREL を受け取るまでメッセージの処理を始めずに PUBLISH を保存しておき，その間に同じパケット ID の PUBLISH が届けば重複として扱う。PUBREL は「送信者はもう PUBLISH を再送しない」ことの合図なので，それを受けてから処理すれば，同じメッセージを二度処理することが無い。MQTT の QoS 2 が「ちょうど1回（exactly once）」の配信と呼ばれるのはこのためである。
図3 の注記2 が要点である。処理を開始した後に届いた PUBLISH は，パケット ID が同じでも新しいパケットとみなされる。処理開始を PUBREL の後まで遅らせるのは，再送された古い PUBLISH が処理開始後に届く可能性を無くすためである。
字数の詰め方（20字）。目的だけを書く。解答例は「メッセージの重複を防止する。」である。「メッセージの消失を防ぐ」は PUBLISH の保存と再送の目的であり，処理を保留する目的ではない。
採点講評（IPA）
設問2は，MQTTについて問うた。通信プロトコルに関する設問2(3)の正答率は高かったが，QoSレベルに関する設問2(2)の正答率は低かった。MQTTのQoSレベルの考え方は，メッセージ交換の重要な概念の一つである。通信シーケンス（図3）をもう一度よく読み，その仕組みを理解しておいてほしい。
本文中の ［ オ ］ 〜 ［ ケ ］ に入れる適切な字句を答えよ。
〔オ〕解答例
- SUBSCRIBE
〔カ〕解答例
- config/Di
〔キ〕解答例
- デバイスDi
〔ク〕解答例
- 交換サーバ
〔ケ〕解答例
- 業務サーバ
解説
本文の根拠
〔MQTT を使ったメッセージ交換方式〕
項番 1 では，デバイス Di は，あらかじめ ［ オ ］ を交換サーバに送信し，トピック名が ［ カ ］ の PUBLISH が送信されるようにする。
〔MQTT を使ったメッセージ交換方式〕
項番 1 では，QoS レベルとして 2 が使用されている。交換サーバからデバイス Di への PUBLISH 送信中に ［ キ ］ が電源断などで非稼働になった場合，その PUBLISH は，［ ク ］ の中に保存され，稼働再開後に再送される。
〔MQTT を使ったメッセージ交換方式〕
項番 2 では，QoS レベルとして 0 が使用されている。これは，［ ケ ］ 及びエッジサーバは安定した稼働が見込めるからである。
図4
項番1：業務サーバから，特定のデバイス Di に対して，設定情報を送信する。経路は業務サーバ→交換サーバ→デバイス Di。QoS レベル 2，トピック名 config/Di，メッセージはデバイス Di の設定情報。
オ・カ：配信先のクライアントは，SUBSCRIBE で購読するトピック名をサーバに通知しておく。項番1 の配信先はデバイス Di，トピック名は config/Di なので，オは SUBSCRIBE，カは config/Di である。キ・ク：交換サーバからデバイス Di への PUBLISH では，送信者が交換サーバ，受信者がデバイス Di である。受信者のデバイス Di が電源断で止まると，送信者の交換サーバが保存しておいた PUBLISH を，デバイスの稼働再開後に再送する。ケ：項番2 の配信先（受信者）は業務サーバとエッジサーバである。これらが安定して稼働するので，MQTT 層の送達確認を省いた QoS レベル 0 で足りる。
本文の「PUBLISH 及び PUBREL は送信者によって保存され，送信者から受信者への再送に利用される」から，保存先は送信者，つまり交換サーバと決まる。
間違えやすい点。クを「デバイス Di」とすると，受信者側の保存と取り違えている。ケは「送信者」ではなく受信者の側を答える。項番2 の送信者であるデバイスが不安定でも，稼働情報は定期的に送り直されるので，失われても次の送信で補える。
採点講評（IPA）
設問2は，MQTTについて問うた。通信プロトコルに関する設問2(3)の正答率は高かったが，QoSレベルに関する設問2(2)の正答率は低かった。MQTTのQoSレベルの考え方は，メッセージ交換の重要な概念の一つである。通信シーケンス（図3）をもう一度よく読み，その仕組みを理解しておいてほしい。
本文中の ［ コ ］ に入れる適切な機器名を全て答えよ。
〔コ〕解答例
- 業務サーバ，交換サーバ
解説
本文の根拠
〔MQTT を使ったメッセージ交換方式〕
図 5 中の装置の処理時間を無視し，図 5 中の t1 及び t2 は，それぞれの装置間の RTT（Round Trip Time）の 2 倍に等しいとし，LAN の RTT を 20 ミリ秒，WAN の RTT を 200 ミリ秒とすると，T は次のように概算できる。
〔MQTT を使ったメッセージ交換方式〕
T ＝ m × t1 ＋ t2 ＝ 6,000 × 2 × 20 ＋ 2 × 200（ミリ秒）≒ 4（分）
〔MQTT を使ったメッセージ交換方式〕
ただし，図 1 に示すように，［ コ ］ は同一拠点に設置されている必要がある。
概算式で t1（業務サーバから交換サーバへの1通ぶん）は 2 × 20 ミリ秒，つまり LAN の RTT で計算している。t2（交換サーバからデバイスへ）は 2 × 200 ミリ秒で WAN の RTT である。業務サーバと交換サーバの間が LAN であることを前提にした概算なので，この二つは同一拠点（図1 の X 社内）に置く必要がある。
検算。m × t1 ＝ 6,000 × 40 ミリ秒 ＝ 240,000 ミリ秒 ＝ 240 秒 ＝ 4 分，t2 ＝ 400 ミリ秒で，T は約 4 分 0.4 秒になり，本文の「≒ 4（分）」と合う。もし業務サーバと交換サーバの間が WAN なら，t1 は 400 ミリ秒になり，m × t1 は 2,400 秒（40 分）に延びる。
間違えやすい点。設問は「全て」答えよと求めているので，業務サーバと交換サーバの二つを挙げる。デバイスは WAN の向こうにあるので含めない。
本文中の ［ サ ］ 〜 ［ ソ ］ に入れる適切な字句を答えよ。
〔サ〕解答例
- 認可
〔シ〕解答例
- WebAP
〔ス〕解答例
- リフレッシュトークン
〔セ〕解答例
- 認可応答
〔ソ〕解答例
- 認可
解説
本文の根拠
〔API にアクセスする顧客サーバの管理〕
図 6 中の（Ⅰ）に示すように，有効なトークンがない場合，Web ブラウザから WebAP への情報要求は，［ サ ］ サーバにリダイレクトされる。認可応答では，認可要求で通知された URI を用いたリダイレクトによって，［ シ ］ に認可コードが通知される。
〔API にアクセスする顧客サーバの管理〕
アクセストークンの有効期間を過ぎた場合でも，［ ス ］ の有効期間内であれば，利用者の確認を行わずに，新しいアクセストークンが発行される。
〔API にアクセスする顧客サーバの管理〕
図 6 の通信シーケンスでは，図 6 中の“(a) 認可要求”の redirect_uri パラメタが書き換えられ，図 6 中の ［ セ ］ に含まれる認可コードが意図しない宛先に送信される可能性がある。
〔API にアクセスする顧客サーバの管理〕
これは，図 6 中の ［ ソ ］ サーバに，HTTP リクエストに含まれる URI とあらかじめ登録されている絶対 URI が一致することを確認させる，という対策である。
図6
(b) 認可応答は「HTTP/1.1 302 Found Location:【WebAP の URI】?code=【認可コード】」。
図6 の仕組みは OAuth 2.0 の認可コードグラント（RFC 6749）である。サ：WebAP のリダイレクト応答を受けたブラウザは，(a) 認可要求を認可サーバに送る。シ：認可サーバは 302 Found で Location に「WebAP の URI?code=認可コード」を返すので，ブラウザがそこへアクセスし，認可コードは WebAP に届く。ス：（Ⅲ）のとおり，アクセストークンが無効でもリフレッシュトークンが有効なら，WebAP が認可サーバに要求して新しいアクセストークンを得られる。セ：認可コードが入っているのは (b) 認可応答の Location である。redirect_uri が書き換えられると，この Location が攻撃者の URI になる。ソ：URI を受け取って認可コードを発行する認可サーバに，登録済みの絶対 URI と一致するかを確かめさせる。
図6 の (a)〜(d) の中身が手掛かりになる。(a) で redirect_uri を送り，(b) の Location がその URI を使い，(c) でも redirect_uri を送っている。
間違えやすい点。採点講評のとおり，シを「PC」「Web ブラウザ」とする誤りが多かった。認可コードはブラウザを経由するが，リダイレクト先として受け取るのは WebAP である。セを「(c) トークン要求」とすると，WebAP から認可サーバへの通信になり，意図しない宛先には送られない。
採点講評（IPA）
設問3は，APIアクセス認可の仕組みについて問うた。この仕組みは“The OAuth 2.0 Authorization Framework（RFC6749）”に記述があり，広く利用されている。認可のプロセスでは，二つのトークンとともに，URIが固定されたWebAPが重要な役割を担う。設問では，それらの知識を前提とせずに通信シーケンスから解答を導くようにした。正答率は比較的高かったが，リダイレクトに関する通信シーケンスを正しく理解していない誤答が散見された（設問3(1)シ）。リダイレクトは，Webサービスの基本的概念の一つであり，よく理解しておいてほしい。
本文中の下線④について，提供する API の範囲を変更する場合，変更が有効になるのは，X 社がアクセストークンを変更してから最長で何分後かを答えよ。
解答例
- 10
解説
本文の根拠
〔API にアクセスする顧客サーバの管理〕
X システムでは，顧客ごとに異なるアクセストークンを定義し，認可サーバに格納しておく。ある顧客に提供する API の範囲が変わる場合，X 社は認可サーバのアクセストークンを変更する。
〔API にアクセスする顧客サーバの管理〕
④アクセストークンの有効期間を 10 分間，リフレッシュトークンの有効期間を 60 分間と想定し，トークンの運用を確認した
〔API にアクセスする顧客サーバの管理〕
アクセストークンには，アクセス可能な API と有効期間に関する情報が含まれており，業務サーバはそれらの情報からアクセスの可否を決める。
X 社が認可サーバのアクセストークンを変更しても，すでに WebAP に発行されている古いアクセストークンは有効期間が切れるまで使われ続ける。業務サーバはトークンに含まれる情報でアクセスの可否を決めるので，その間は古い API の範囲が適用される。最悪の場合は，変更の直前に発行されたアクセストークンで，これが最長 10 分間有効である。有効期間が切れると，WebAP はリフレッシュトークンで新しいアクセストークンを要求し，認可サーバは変更後の内容のアクセストークンを発行する。したがって最長 10 分後に変更が有効になる。
本文の「アクセス可能な API と有効期間に関する情報が含まれており」が，古いトークンでも期限内は通ることの根拠である。
間違えやすい点。60 分（リフレッシュトークンの有効期間）や 70 分（両者の和）とするのは誤りである。リフレッシュトークンで発行される新しいアクセストークンは，認可サーバが変更後の内容で作るので，リフレッシュトークンが古くても影響しない。
採点講評（IPA）
設問3は，APIアクセス認可の仕組みについて問うた。この仕組みは“The OAuth 2.0 Authorization Framework（RFC6749）”に記述があり，広く利用されている。認可のプロセスでは，二つのトークンとともに，URIが固定されたWebAPが重要な役割を担う。設問では，それらの知識を前提とせずに通信シーケンスから解答を導くようにした。正答率は比較的高かったが，リダイレクトに関する通信シーケンスを正しく理解していない誤答が散見された（設問3(1)シ）。リダイレクトは，Webサービスの基本的概念の一つであり，よく理解しておいてほしい。
本文中の下線⑤について，顧客への依頼内容を，40 字以内で述べよ。
解答例
- WebAPのURIを固定にし，絶対URIを事前に通知してもらう。
解説
本文の根拠
〔API にアクセスする顧客サーバの管理〕
W さんは，その対策として“redirect_uri パラメタの確認”を行うことにした。これは，図 6 中の ［ ソ ］ サーバに，HTTP リクエストに含まれる URI とあらかじめ登録されている絶対 URI が一致することを確認させる，という対策である。
〔API にアクセスする顧客サーバの管理〕
⑤顧客向けの API 利用ガイドラインには，この対策に必要な顧客への依頼内容を明記することにした。
〔X システムの構想〕
顧客は，顧客サーバに，API アクセス用の Web アプリケーション（以下，WebAP という）と HTTP サーバ機能を実装する。
認可サーバが redirect_uri を「あらかじめ登録されている絶対 URI」と照合するには，その URI が変わらないこと，そして X 社が事前に知っていることが必要である。WebAP は顧客が自分の顧客サーバに作るので，URI を決めるのは顧客である。そこで顧客に，WebAP の URI を固定にし，その絶対 URI を事前に X 社へ通知してもらうよう依頼する。OAuth 2.0（RFC 6749）でも，クライアントはリダイレクト先の URI を認可サーバに登録しておくことが求められている。
本文の「あらかじめ登録されている絶対 URI」と，WebAP を顧客が実装するという構想の記述を合わせると，登録のための情報が顧客からしか得られないことが分かる。
字数の詰め方（40字）。「URI を固定にする」と「絶対 URI を事前に通知してもらう」の二つを残す。解答例は「Web AP の URI を固定にし，絶対 URI を事前に通知してもらう。」である。通知だけでは URI が後で変わると照合に失敗するので，固定にすることも書く。
採点講評（IPA）
設問3は，APIアクセス認可の仕組みについて問うた。この仕組みは“The OAuth 2.0 Authorization Framework（RFC6749）”に記述があり，広く利用されている。認可のプロセスでは，二つのトークンとともに，URIが固定されたWebAPが重要な役割を担う。設問では，それらの知識を前提とせずに通信シーケンスから解答を導くようにした。正答率は比較的高かったが，リダイレクトに関する通信シーケンスを正しく理解していない誤答が散見された（設問3(1)シ）。リダイレクトは，Webサービスの基本的概念の一つであり，よく理解しておいてほしい。
図 8 中の NAT ルータについて，顧客ネットワークから X システムの方向の通信におけるアドレス変換の内容を，60 字以内で具体的に述べよ。
解答例
- 送信元IPアドレスをNATルータ-Pに，宛先IPアドレスをエッジサーバ-Pに，それぞれ変換する。
解説
本文の根拠
〔エッジサーバを活用する将来構想〕
NAT ルータは，1：1 静的双方向 NAT として動作させ，図 8 中の NAT ルータ-P と NAT ルータ-P’ を利用して，宛先 IP アドレスと送信元 IP アドレスの両方を変換させる。
〔エッジサーバを活用する将来構想〕
顧客サーバに MQTT クライアント機能を，エッジサーバに MQTT サーバ機能をそれぞれ実装し，顧客サーバとエッジサーバ間でメッセージ交換を行う。
図8
凡例：ddd-P は X システムにおける，機器 ddd のプライベート IP アドレス。ddd-P’ は顧客ネットワークにおける，機器 ddd のプライベート IP アドレス。
顧客サーバ（MQTT クライアント）はエッジサーバ（MQTT サーバ）に接続する。顧客ネットワークからは，エッジサーバは NAT ルータ-P’ に見える。つまり顧客サーバが送るパケットは，送信元が顧客サーバ-P’，宛先が NAT ルータ-P’ である。NAT ルータはこれを X システム側へ転送するとき，宛先 IP アドレスをエッジサーバ-P に，送信元 IP アドレスを NAT ルータ-P に変換する。1：1 静的双方向 NAT なので，戻りのパケットは逆の変換を受ける。
両方を変換するのは，二つのネットワークがそれぞれ独自のプライベートアドレスを使っているからである。送信元を NAT ルータ-P にしておけば，エッジサーバは顧客ネットワークの経路を知らなくても NAT ルータに応答を返せる。
字数の詰め方（60字）。送信元と宛先それぞれの「変換後のアドレス」を図8 の名前で書く。解答例は「送信元 IP アドレスを NAT ルータ-P に，宛先 IP アドレスをエッジサーバ-P に，それぞれ変換する。」である。
採点講評（IPA）
設問4は，ネットワークシステムの拡張性について問うた。顧客ネットワーク側のMQTTクライアントを接続する際の考慮点について出題している。設問をよく読み，メッセージ交換システムが有する拡張性と，NATを用いて運用主体が異なる二つのネットワークを接続した際の制約について，それぞれ理解した上で解答してほしい。
図 8 中の顧客 FW について，X システムとの接続のために，新たに許可が必要になる通信を 40 字以内で答えよ。
解答例
- 顧客サーバ-P’からNATルータ-P’のポート8883番への通信
解説
本文の根拠
図8
NAT ルータは顧客ネットワーク（破線の枠）の境界に置かれ，顧客ネットワーク側の IP アドレス NAT ルータ-P’ で顧客 FW につながる。
図8
顧客ネットワークでは，PC（複数）と顧客サーバ（IP アドレスは顧客サーバ-P’）が L2SW に接続し，L2SW が顧客 FW に接続し，顧客 FW がインターネットに接続する。
〔MQTT を使ったメッセージ交換方式〕
クライアントは，サーバの TCP ポート 8883 番にアクセスし，TCP コネクションを確立する。
図8 では，顧客サーバから NAT ルータへの経路は L2SW，顧客 FW を通る。顧客サーバは MQTT クライアントとしてエッジサーバの MQTT サーバ機能に接続するので，顧客 FW には，顧客サーバ-P’ から NAT ルータ-P’（顧客ネットワークから見たエッジサーバ）の TCP ポート 8883 番への通信を許可する必要がある。コネクションは顧客サーバから張るので，逆向きの新しい接続を許可する必要は無い。
宛先は顧客ネットワークのアドレス体系で書く点に注意する。顧客 FW を通る時点ではまだ NAT されていないので，宛先はエッジサーバ-P ではなく NAT ルータ-P’ である。
字数の詰め方（40字）。送信元，宛先，ポート番号の三つを残す。解答例は「顧客サーバ-P’ から NAT ルータ-P’ のポート 8883 番への通信」である。
採点講評（IPA）
設問4は，ネットワークシステムの拡張性について問うた。顧客ネットワーク側のMQTTクライアントを接続する際の考慮点について出題している。設問をよく読み，メッセージ交換システムが有する拡張性と，NATを用いて運用主体が異なる二つのネットワークを接続した際の制約について，それぞれ理解した上で解答してほしい。
本文中の下線⑥について，定義するトピック名を全て答えよ。
解答例
- config/Di，status/Di
解説
本文の根拠
〔エッジサーバを活用する将来構想〕
エッジサーバの MQTT サーバ機能は，通常の MQTT サーバ機能に加えて，メッセージをほかの MQTT サーバと送受信する機能（以下，MQTT ブリッジという）をもつ。X システムのデバイスは複数の機器と TCP コネクションを確立できないので，この MQTT ブリッジを利用する。
〔エッジサーバを活用する将来構想〕
⑥ MQTT ブリッジには，トピック名をあらかじめ定義しておき，そのトピック名のメッセージを交換サーバと送受信させる
〔エッジサーバを活用する将来構想〕
図 4 中のメッセージ交換では，X 社内の交換サーバを利用するので，顧客の企業秘密を含むような設定情報及び稼働情報（以下，これらを内部情報という）は，対象外としている。
将来構想では，デバイスは一つの TCP コネクションしか張れないので，接続先をエッジサーバの MQTT サーバ機能に変える。すると，図4 のメッセージ（設定情報 config/Di と稼働情報 status/Di）は，エッジサーバを経由して交換サーバとやり取りしなければならない。そのため MQTT ブリッジに config/Di（交換サーバからデバイスへ）と status/Di（デバイスから交換サーバへ）を定義し，交換サーバと送受信させる。
一方，図7 の Confidential/Di は内部情報であり，本文のとおり X 社内の交換サーバを通さないことが前提である。ブリッジに定義すると交換サーバへ流れてしまうので，定義しない。
間違えやすい点。設問は「全て」答えよとしている。status/Di だけ（デバイスから上がる向き）では，業務サーバからの設定情報がデバイスに届かなくなる。
採点講評（IPA）
設問4は，ネットワークシステムの拡張性について問うた。顧客ネットワーク側のMQTTクライアントを接続する際の考慮点について出題している。設問をよく読み，メッセージ交換システムが有する拡張性と，NATを用いて運用主体が異なる二つのネットワークを接続した際の制約について，それぞれ理解した上で解答してほしい。
図 7〜9 中の顧客サーバを 1 台追加する場合，X システム側で必要となる対応を二つ挙げ，それぞれ 30 字以内で述べよ。
〔①〕解答例
- 1：1静的双方向NATの設定をNATルータに追加する。
〔②〕解答例
- 通信を許可するルールを通信装置内のFWに追加する。
解説
本文の根拠
〔エッジサーバを活用する将来構想〕
NAT ルータは，1：1 静的双方向 NAT として動作させ，図 8 中の NAT ルータ-P と NAT ルータ-P’ を利用して，宛先 IP アドレスと送信元 IP アドレスの両方を変換させる。
〔ネットワークセキュリティ対策〕
①通信装置内の FW を使った対策
図8
FW にはもう一つの接続があり，FW 側の IP アドレスが FW-P で，その先に NAT ルータがつながる。NAT ルータの FW 側の IP アドレスが NAT ルータ-P である。
1：1 静的双方向 NAT は，一つの内側アドレスと一つの外側アドレスを固定で対応付ける。顧客サーバが1台増えると，その顧客サーバ-P’ を X システム側のどのアドレスに変換するかという対応付けが新たに必要になるので，NAT ルータに 1：1 静的双方向 NAT の設定を追加する。変換後の送信元アドレスが新しくなるので，NAT ルータとエッジサーバの間にある通信装置内の FW にも，その送信元からの通信を許可するルールを追加する。
図8 では NAT ルータの先が通信装置内の FW（FW-P 側）につながり，エッジサーバへの通信はこの FW を通る。下線①のとおり，この FW は許可した通信だけを通す対策をとっている。
字数の詰め方（各30字）。「何の設定を」「どの機器に追加するか」を書く。解答例は「1：1 静的双方向 NAT の設定を NAT ルータに追加する。」と「通信を許可するルールを通信装置内の FW に追加する。」である。顧客 FW の設定は顧客側の作業なので，設問の「X システム側」には入らない。
採点講評（IPA）
設問4は，ネットワークシステムの拡張性について問うた。顧客ネットワーク側のMQTTクライアントを接続する際の考慮点について出題している。設問をよく読み，メッセージ交換システムが有する拡張性と，NATを用いて運用主体が異なる二つのネットワークを接続した際の制約について，それぞれ理解した上で解答してほしい。
出典：平成30年度 秋期 ネットワークスペシャリスト試験 午後Ⅱ 問1（表記を一部改変）
