ネットワークスペシャリストー過去問挑戦　平成30年午後Ⅱ問1ー

こんにちは、こじろうです。

この記事では、N/Wスペシャリスト平成30年午後Ⅱ問1に挑戦していきたいと思います。

参考：N/Wスペシャリスト平成30年午後Ⅱ問1過去問

別記事のネットワークエンジニアのススメでも紹介しましたが、文系SEからするとシステムエンジニアよりもネットワークエンジニアになった方が良いキャリアを気づかる可能性があります。

僕自身も、プログラマ➡システムエンジニア➡ITコンサルタントとキャリアチェンジしてきましたが、所々、ネットワークエンジニアとして活動し、成果を出すことに成功してきました。

文系SEのみなさまにも是非、ネットワークの知識を蓄えて頂きたく、IPAが主催しているネットワークエンジニアの資格試験について、僕なりの解答方法と、IPAが公表している模範解答を紹介していきたいと思います。

設問を解き始める前の前提

詳細は以下の記事を読んで頂きたいのですが、過去問に挑戦する前に頭に入れておいて欲しいことが2つあります。参考：【文系SE】ネットワークスペシャリストー解答時のフレームワークー

それでは、いってみましょう！！😃

問題文を読みながら僕が考えていった内容

TLSには情報を[空欄ア]する機能、情報の改ざんを[空欄イ]する機能、及び通信相手を[空欄ウ]する機能がある

設問1⑴ですが、
TLSは

といった機能を搭載しています。

模範解答は
ア：暗号化
イ：検知
ウ：認証
でした。

機能間の[空欄エ]コネクションの確立要求…

設問1⑴ですが、
クライアントサーバ間でのコネクションといったら、大体TCPかHTTPの問題です。

模範解答は’TCP’でした。

下線部①通信装置内のFWを使った対策

設問1⑵ですが、問題文を読んでいくと’侵入、及びなりすましを防ぐ’だとか、’TCPコネクション…’といった記載があります。

設問が漠然としているときほど、どういう状況を想定していて、目的は何なのか？を見極める必要があります。

まず、この場合における侵入やなりすましとは、どういう状況が考えられるのか？

この場合のなりすましとは、顧客の工場以外のN/Wからのアクセススルしてくる人が、顧客の工場からのアクセスと偽ってX社のNWにアクセスしてくることでしょう。

これを防ぐには、通信における送信元を絞る(この場合、顧客の工場NWに配置される、X社が運用保守対象としている機器)ことが挙げられます。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

正直、①をやられてしまうとX社への侵入を防ぐのはかなり厳しいですが、下線部の直前に利用するプロトコルに関する記載(設問そのものなのでプロトコル名は空欄ですが…)もあるので、このプロトコル(TCP)を解答に含めるべきでしょう。

模範解答は’X社が運用保守を行う機器から、X社FWの方向に確立されるTCPコネクションだけを許可する。’でした。

下線部②TLSの機能を使ったデバイス及びエッジサーバーに関する対策

設問1⑶ですが、TLSの主な役割は、データの暗号化による盗難の防止と、サーバ(クライアント証明書)を用いた認証機能の提供(なりすましの防止)にあります。(参考：https://www.sslcerts.jp/)

この設問では、顧客の工場内にあるデバイスやエッジサーバからX社向けの通信における、侵入やなりすましの防止by TLSに問われているので、なりすましの防止について回答するべきです。

また、TLSのではサーバ証明書を用いて、アクセスするサーバが確かに意図したアクセス先であることを確認する、という例が多いのですが、今回認証したいのはサーバではなくアクセス元の機器(つまりクライアント)なので、扱う証明書はクライアント証明書にして、解答を作成するべきです。

と、まぁ色々書きましたが、僕は思いっきり暗号化に関する解答を書いてしまいましたが…

模範解答は’クライアント証明書を配布して、クライアント認証を行う。’でした。

下線部③ PUBLISHを受信した受信者はメッセージ処理を始める前に送信者にPUBRECを送信し、その応答であるPUBRELを受信してからメッセージの処理を開始する

設問2⑵ですが、メッセージの受信者が、なぜPUBLISHを受け、自分自身はPUBRECを返せているのにメッセージの処理をすぐに始めないのか、という設問です。

下線部の2行前に、’TCPコネクションが切断された時のために～’とあるが、この点を考慮する必要があります。

もし、PUBRECのメッセージが送信者に届く前にTCPコネクションが切断されたら、どうなるのでしょうか？

ここで、先ほどの’TCPコネクションが切断～’と共に、注目しなければならない問題文があります。

それは図3の注2、’メッセージの処理を開始した以降に受信したPUBLISHはパケットIDの重複に関わらず新しいパケットとみなす。’です。

今回の問題では、送信側は、QoSのレベルが2の場合、自分が送ったメッセージが確かに宛先へ到着したか確認できるまでは、メッセージを再送すると、問題文に書かれていますね。

つまり、受信者側がPUBRECを返すまでは、送信者は一度送付したメッセージを何度も再送してくるわけです。

この状態で、受信者側が、自分自身が受信確認(PUBREC)を返す前にメッセージの処理を始めてしまうと何が起きるのでしょうか。

メッセージを処理しているときに、同じIDのメッセージが来て、同じ処理を何度も何度も繰り返すことになりますね。

これが、受信側がPUBRECの返答であるPUBRELが車でメッセージの処理を実施しない理由ですね。

僕は’メッセージ再送による受信者側での処理の繰り返しを防ぐ。’と書きましたが、模範解答は’メッセージの再送を防ぐ’でした。

あらかじめ[空欄オ]を交換サーバに送信し、トピック名が[空欄カ]のPUBLISHが送信されるようにするPUBLISH送信中に[空欄キ]が電源段なとで非稼働となった場合は、そのPUBLISHは[空欄ク]のなかに保存され…これは[空欄ケ]及びエッジサーバは安定した稼働が見込めるからである

設問2の⑶ですが、これは問題文の流れから問われている処理シーケンスを一つ一つ追っていかないと回答できません。

大前提として、各デバイスは自分の情報を交換サーバを介して業務サーバやエッジサーバへ送り、自分達に異常がないことを知ってもらおうとしている、ということを当た目に入れておく必要がある。

模範解答は
オ：SUBSCRIBE
カ：config/Di
キ：デバイスDi
ク：交換サーバ
ケ：業務サーバ
でした。

[空欄コ]は同一拠点に設置されている必要がある

設問2の⑷ですが、ネットワークの問題という余地は、問題文に文字で書かれている内容が図ではどこに書かれているか見つけられるか？という問題です。

図5には3つ機器(業務サーバ、交換サーバ、デバイス)が登場していますが、図1いおいて、これら3つの内、同じ拠点に配置されているのはどれとどれでしょうか？

業務サーバと交換サーバですね。

この2つが同じ拠点にある前提で、図5の処理時間のグラフが作成されているわけなので、もし業務サーバと交換サーバが別々の場所においてあったら、t1やt2の時間が変わってくるでしょう。

WebAPへの情報要求は[空欄サ]サーバにリダイレクト…

図6において認可Web APへの情報要求はどこに記載されているかというと、(Ⅰ)の’情報要求’の箇所(1行目)を見ると、次の行で’リダイレクト応答’とありますね。

‘リダイレクトじゃなくて単に返信が来てるだけじゃん’と、試験を受験した時の僕は思ってしまいましたが、これはリダイレクトの通信ではなく、’僕は要求を付けつけますが、あくまで受け付けるだけで許可や承認する作業は他のサーバへお任せします。いいですね？’というメッセージであり、リダイレクトの処理はここでは行っていないのです。

そして、問題文には’～リダイレクトされる。認可応答では～’とあるため、このリダイレクト処理のあとは認可応答処理が走ることが分かります。

となると、’情報要求➡リダイレクト応答➡どこかへリダイレクト➡認可応答’という順番で処理がなされること、そして図6のⅠにおいて’認可応答’が(b)認可応答が4行目(認可サーバ➡PCへの通信)に書かれていることを考慮すると、リダイレクト先は認可サーバ以外考えられないでしょう。

[空欄シ]に認可コードが通知される

※更新中

[空欄ス]の有効期間内であれば…

※更新中

下線部④アクセストークンの有効期間を10分間、リフレッシュトークンの有効期間を60分と想定し、トークンの運用を確認した。

設問3の⑵だが、問題文に記載されているシーケンスに沿って、具体的なケースを想定してみましょう。

トークンの設定内容が途中で変わったら、今現在利用しているトークンも内容も即時、へんこうされるわけではありません。利用者が、次回認可サーバへトークン要求するときまでは、同トークン設定となります。

では、その次回とはいつなのか？

この設問では、リフレッシュトークン=60分有効というのが悩ましいところです。

なぜなら、トークンの有効期間が過ぎても、リフレッシュトークンが生きている60分以内であれば、トークの再取得(新しい設定がなされたトークン)は起きない、かな？となんとなく想像できてしまうから。

では実際にトークン利用中に設定内容が変更され、10経過してリフレッシュトークンを利用するとなったら、、、図6でいうと(Ⅲ)リフレッシュトークンだけが有効な場合に当てはまりますが、これをよくよく見ると、リフレッシュトークンを利用するときって、認可要求は発生しないものの、新しくトークンを取ってきているんですよね。。

なので、トークンの設定がサーバ側で変更されたら、ユーザは遅くとも10分後には、その新しいトークンを取得

図6中の[空欄セ]に含まれる認可コードが意図しない宛先に送信される可能性がある。

※更新中

これは、図6中の[空欄ソ]サーバにHTTPリクエストに含まれるURIと予め登録されている絶対URIが一致することを確認させる、という対策である。

※更新中

下線部⑤顧客向けのAPI利用ガイドラインには、この対策に必要な顧客への依頼内容を明記することにした。

設問3の⑶ですが、事前に登録しておきたいわけですから、事前に登録する情報を仕入れておく必要がありますね。

僕は’事前にアクセス元となるURIを伝達してもらう’と書きましたが、模範解答は’WebAPのURIを固定にし、絶対URLを事前に通知してもらう。’でした。

URIを固定にしてもらうというのは…理解はできるが、なぜそういった発想になるのか、ちょっと分からないです。

下線部⑥MQTTブリッジには、トピック名を予め定義しておき、そのトピック名のメッセージを交換サーバと送受信させる。

設問4の⑶だが、この問題において登場するトピック名は、図4記載のCondig/DiとStatus/Di、図7のConfidential/Diの3つであります。

また、記載のあるMQTTブリッジとはつまり交換サーバのことであり、この問題は’業務サーバと交換サーバ間をながれるトピックはどれは？’という問題なのです。

沿考えると、Confidential/Diはデバイスと顧客サーバ間を流れるトピックであるｋとが図7をみると明白なので、解答はその他の2つとなります。

設問2⑴について…

TCPのレベルで対応できない事象となると、より低い階層でのトラブルが考えられます。

低い階層と言っても、問題文を読んでいくと、ネットワーク層やデータリンク層関連で何か不備やリスク(例えばNATトラバーサルの設定がうまくいっていなくてアドレスの解決ができないetc)に関する記載がないです。

そうなると、トラブルのフレームワークとしては、H/Wの故障を疑うべきでなのでしょう。

模範解答では電源断となっているが、配線が切れる等も十分正答として扱われる可能性があります。

設問4⑴について…

前提として、NATルーターを介する通信はどこに向かうかというと、エッジサーバです。これは問題文を読んでいけば分かりますね。

こういったルーティングの問題は、宛先がどこか明確にすることが肝要です。

そうなると、NATルーターを介する通信パケットの送信元IPアドレスはNATルータ-P’になるし、宛先IPアドレスは当然エッジサーバPとなります。

設問4⑵について…

図8中の顧客FWについて、Xシステムとの接続のために新たに認可が必要になる通信とありますが、FWの問題は、まずは対象の通信の送信元と宛先、ルーティングテーブルを確認した上で、どの要素でフィルタリングをするべきか(もしくは解除するべきか)を考えていきます。

王道はIPアドレスでのフィルタリングですが、この問題の場合、IPアドレスレベルでの通信はNATによって確立されています。

となると、次に考えるべきはポートでですね。

設問4⑷について…

※更新中

図7～9中の顧客サーバを1台追加する場合、Xシステム側で必要となる対応を2つ挙げ、、

要はルーティングの設定が必要なわけなので、宛先の設定(NAT)とFWの設定。

ネットワークの勉強をして良かったなーと思うこと

ITコンサルタントとしての現場において、プロジェクト内でトラブルシューティングやシステムインフラ設計において最も頼られる存在になり、安定した案件・プロジェクトアサインが実現できるようになりました。
参考：コンサルファームでアベイラブルになったら

文系SEであっても、こういった知識があると一目置かれた存在になれますし、キャリアアップの一助になります。

実際、僕はプログラマ➡SE(ネットワークエンジニア)➡ITコンサルタントとキャリアップしてきましたが、ITコンサルタントとして活動している今も本記事の様な技術的な部分を大事にしているため、’他のコンサルタントとは差別化された人材になれているな’と感じています。

本記事は技術的な内容でしたが、キャリアに関する情報をお探しの方はこちらも是非、ご覧ください。
参考：【文系 SE】ネットワークエンジニアのすすめ

それでは、Tchau◎

こじろう