平成30年度秋期 ネットワークスペシャリスト 午後Ⅱ 問1

問1　ネットワークシステムの設計に関する次の記述を読んで，設問1～4に答えよ。 機械メーカのX社は，顧客に販売した機械の運用・保守と，機械が稼働している顧客の工場の自動化支援に関する新事業を拡大しようとしている。 機械は工作装置及び通信装置の2種類である。工作装置には，センサ，アクチュエータなどを制御する機構（以下，デバイスという），及びレイヤ2スイッチが内蔵されている。通信装置は，デバイスをインターネットに接続するための機器で，エッジサーバ，ファイアウォール及びレイヤ3スイッチが内蔵されている。 X社の情報システム部は，新事業用のサービス基盤システム（以下，Xシステムという）を計画中である。情報システム部に所属するネットワーク担当のWさんが，Xシステムの構想について，検討を行っている。 〔Xシステムの構想〕 Xシステムは，X社が運用・保守を行う顧客の工場内の機器，X社内のサーバ，及びそれらを接続するためのネットワーク機器から構成されている。 Xシステムの導入構成例を図1に示す。 図1　Xシステムの導入構成例（抜粋） 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に示す。 表1　MQTTコントロールパケットの種別（抜粋） MQTTを使ったメッセージ交換方式の通信シーケンス例を図2に示す。 図2中の通信シーケンスでは，配信元から複数の配信先へメッセージが配信されている。通信シーケンスの説明を次に示す。 ・クライアントは，サーバのTCPポート8883番にアクセスし，TCPコネクションを確立する。このTCPコネクションは，メッセージ交換の間は常に維持される。 ・クライアントはCONNECTを送信し，サーバはCONNACKを返信する。 ・配信先となるクライアントは，サーバにSUBSCRIBEを送信し，購読対象のメッセージを，トピック名を使って通知する。サーバはクライアントにSUBACKを返信し，購読要求を受け付けたことを通知する。 ・配信元クライアントは，PUBLISHを使ってサーバにメッセージを送信する。 ・メッセージを受信したサーバは，PUBLISHに含まれるトピック名について購読要求を受け付けている全てのクライアントに，そのメッセージを送信する。 PUBLISHを使ったメッセージ送信では，QoSレベルを使って送達確認手順を指定する。QoSレベルとメッセージ送信の通信シーケンスを図3に示す。 図3　QoSレベルとメッセージ送信の通信シーケンス 図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　Xシステムのメッセージ交換 図4の説明を次に示す。 ・項番1では，デバイスDiは，あらかじめ【オ】を交換サーバに送信し，トピック名が【カ】のPUBLISHが送信されるようにする。 ・項番1では，QoSレベルとして2が使用されている。交換サーバからデバイスDiへのPUBLISH送信中に【キ】が電源断などで非稼働になった場合，そのPUBLISHは，【ク】の中に保存され，稼働再開後に再送される。 ・項番2では，QoSレベルとして0が使用されている。これは，【ケ】及びエッジサーバは安定した稼働が見込めるからである。 Wさんは，1台の業務サーバが6、000台のデバイスの設定を変更する場合の送信時間（T）を概算した。 WさんがTの概算に用いた通信シーケンスを図5に示す。 図5　WさんがTの概算に用いた通信シーケンス 図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　XシステムのAPIアクセスの通信シーケンス 図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に，それぞれ示す。 図7　将来構想で追加されるXシステムのメッセージ交換例 図8　Wさんが考えた将来構想におけるネットワーク構成案（抜粋） 図8に示すように，Wさんは，NATルータを使って，顧客ネットワークとXシステムを接続する案を考えた。NATルータは，1：1静的双方向NATとして動作させ，図8中のNATルータ-PとNATルータ-P’を利用して，宛先IPアドレスと送信元IPアドレスの両方を変換させる。 Wさんが考えた将来構想におけるメッセージの流れを図9に示す。 図9　Wさんが考えた将来構想におけるメッセージの流れ 図9の説明を次に示す。 ・顧客サーバにMQTTクライアント機能を，エッジサーバにMQTTサーバ機能をそれぞれ実装し，顧客サーバとエッジサーバ間でメッセージ交換を行う。 ・エッジサーバのMQTTサーバ機能は，通常のMQTTサーバ機能に加えて，メッセージをほかのMQTTサーバと送受する機能（以下，MQTTブリッジという）をもつ。Xシステムのデバイスは複数の機器とTCPコネクションを確立できないので，このMQTTブリッジを利用する。 ・⑥MQTTブリッジには，トピック名をあらかじめ定義しておき，そのトピック名のメッセージを交換サーバと送受信させる。 Wさんは，図7～9を使って，ネットワークの動作について検討し，将来構想への対応が可能であると判断した。 Wさんは，以上の検討結果を上司に報告した。X社の情報システム部は，Xシステム構想を実現するためのプロジェクトを発足させた。 設問1　〔ネットワークセキュリティ対策〕について，（1）～（3）に答えよ。 （1）本文中の【ア】～【エ】に入れる適切な字句を答えよ。 （2）本文中の下線①の対策を，50字以内で述べよ。 （3）本文中の下線②の対策を，30字以内で述べよ。 設問2　〔MQTTを使ったメッセージ交換方式〕について，（1）～（4）に答えよ。 （1）図3中のQoSレベルが0の場合のメッセージ送信について，TCPの再送機能だけではメッセージの消失が防げないのはどのような場合か。45字以内で具体的に答えよ。 （2）本文中の下線③について，PUBRELを受信するまで，メッセージの処理を保留する目的を，20字以内で述べよ。 （3）本文中の【オ】～【ケ】に入れる適切な字句を答えよ。 （4）本文中の【コ】に入れる適切な機器名を全て答えよ。 設問3　〔APIにアクセスする顧客サーバの管理〕について，（1）～（3）に答えよ。 （1）本文中の【サ】～【ソ】に入れる適切な字句を答えよ。 （2）本文中の下線④について，提供するAPIの範囲を変更する場合，変更が有効になるのは，X社がアクセストークンを変更してから最長で何分後かを答えよ。 （3）本文中の下線⑤について，顧客への依頼内容を，40字以内で述べよ。 設問4　〔エッジサーバを活用する将来構想〕について，（1）～（4）に答えよ。 （1）図8中のNATルータについて，顧客ネットワークからXシステムの方向の通信におけるアドレス変換の内容を，60字以内で具体的に述べよ。 （2）図8中の顧客FWについて，Xシステムとの接続のために，新たに許可が必要になる通信を40字以内で答えよ。 （3）本文中の下線⑥について，定義するトピック名を全て答えよ。 （4）図7～9中の顧客サーバを1台追加する場合，Xシステム側で必要となる対応を二つ挙げ，それぞれ30字以内で述べよ。