ネットワークスペシャリスト 2017年 午後1 問01

解答の論理構成

1. ア
   • 問題文では「十分な安全性を確保できないとされるハッシュアルゴリズムであるMD5又はアを使用しない」と明示しています。
   • 現在“安全性が不十分”とされ、TLS 1.2以降で使用が推奨されないもう一つの代表的ハッシュは「SHA-1」です。
   • よって ア＝SHA-1 となります。
2. イ
   • 同じ箇所で「TLSプロトコルのバージョンイ以上を利用」とあります。
   • SHA-1を避けられる最小バージョンは「1.2」です。
   • したがって イ＝1.2 です。
3. ウ と エ
   • 問題文：「SSL/TLSのコネクション開設時に、クライアント側から送られるウメッセージと、サーバ側から返されるエメッセージの交換が行われる。」
   • SSL/TLSハンドシェイクで最初に送るのは “Client_Hello”、返すのは “Server_Hello” です。
   • よって
   – ウ＝Client_Hello
   – エ＝Server_Hello
4. オ
   • 問題文：「SSL-VPNの基本的な動作には、オポートフォワーディング、L2フォワーディングの3方式がある。」
   • 一般にSSL-VPNで3方式と言えば「リバースプロキシ方式・ポートフォワーディング方式・L2フォワーディング方式」です。
   • よって オ＝リバースプロキシ となります。

誤りやすいポイント

• SHA-256など“安全なハッシュ”を書いてしまう
  → 問題文は「使用しない」と言っているハッシュを尋ねています。
• TLS 1.3を記載
  → 「以上」を読んで最新を選びがちですが、最小バージョンを問う文脈です。
• “ClientHello”／“ServerHello” と大文字小文字を変えてしまう
  → 固有名詞は問題文と同じ形式「Client_Hello」「Server_Hello」で書く必要があります。
• 「ポータル方式」を入れてしまう
  → 問題文は“…ポートフォワーディング、L2フォワーディング”と続くため、残る1つは「リバースプロキシ方式」です。

FAQ

解答の論理構成

• 【問題文】では、暗号スイートの内訳について
  「その情報には、アプリケーション層の暗号化に使われる暗号アルゴリズム以外に、（I）2種類の暗号アルゴリズムと1種類のハッシュアルゴリズムが含まれる。」と述べています。
  つまり、暗号スイートには
  ①アプリケーションデータの暗号化アルゴリズム
  ②（I）に示された追加の「2種類の暗号アルゴリズム」
  ③（I）に示された「1種類のハッシュアルゴリズム」
  が含まれる構成です。
• TLSの標準的な暗号スイート構成を整理すると次の4要素に分かれます。
  1. 鍵交換アルゴリズム（例: RSA, Diffie-Hellmanなど）
  2. サーバ認証／クライアント認証アルゴリズム（例: RSA, ECDSAなど）
  3. データ暗号化アルゴリズム（例: AES, ChaCha20など）
  4. メッセージ認証コード（MAC）を生成するハッシュアルゴリズム（例: SHA-256など）
• このうち、③は問題文で「アプリケーション層の暗号化に使われる暗号アルゴリズム」として既に別扱いになっています。
  残る ①と②が「2種類の暗号アルゴリズム」、④が「1種類のハッシュアルゴリズム」に相当します。
• それぞれの“用途”をまとめると
  ・1つ目の暗号アルゴリズム：安全にセッション鍵を共有するための「鍵交換」
  ・2つ目の暗号アルゴリズム：認証局証明書と組み合わせてサーバ／クライアントを「認証」
  ・ハッシュアルゴリズム：改ざん検出のためMACを作る「メッセージ認証」

誤りやすいポイント

• 「ハッシュ＝暗号化」と勘違いし、用途を「暗号化」と答えてしまう。ハッシュは平文復元不可能であり“改ざん検出”が目的です。
• 鍵交換と認証を一緒にしてしまう。TLSでは鍵共有（RSA, DHなど）と証明書署名アルゴリズム（RSA, ECDSAなど）は独立要素です。
• 暗号スイートの4要素を3要素と誤認し、用途数が合わなくなる。

FAQ

解答の論理構成

1. まず、問題文はSSL-VPNの動作方式に関して
   「SSL-VPNの基本的な動作には、オポートフォワーディング、L2フォワーディングの3方式がある。」
   と述べ、下線（II）で「H社の場合はL2フォワーディング方式が望ましい」としています。
2. L2フォワーディング方式は、レイヤ2（Ethernetフレーム）をそのままトンネルで中継するため、上位レイヤでどのようなプロトコルが流れても透過的に扱えます。
3. H社が構築する顧客システムの性質について問題文は
   「顧客システムは、様々なサーバ機器、OS、ミドルウェアなどを組み合わせて構築され、利用されるプロトコルも様々である。」
   と明記しています。
4. 「様々なプロトコル」が流れるネットワークを安全にリモートから扱うには、特定のポートだけを転送するオポートフォワーディングでは対応しきれません。プロトコルが増えるたびに転送設定を追加する手間や、未知プロトコルが通過できないリスクが残るためです。
5. したがって、L2フォワーディング方式を選択した根拠は「顧客システムのプロトコルが多様」という一点に集約され、設問の模範解答「顧客システムは、様々なプロトコルを利用している。」となります。

誤りやすいポイント

• 「開発LANと顧客LANを同一VLANに見せる必要があるから」と理由付けする誤答。必要なのは“プロトコル透過性”でありVLAN統合は本質ではありません。
• SSL-VPN装置の機能差（例えばクライアントレス／インストール型）に着目してしまい、レイヤ選択の論点から外れるケース。
• 「ポート数が多い＝L2を選ぶ」と短絡的に覚えるミス。ポートの多寡ではなく“種類が未知・多様”であることが決定打です。

FAQ

解答の導き方

1. 設問が問う内容を確認します。本文にある「（III）接続時の認証に応じて、PCに適切なIPアドレスを割り当てる」という記述は、SSL-VPNの接続時に認証されたユーザごとにPCへIPアドレスを付与する動作を指しています。
2. 次に、どの方式でVPNが動作するかを確認します。本文に「（II）H社の場合はL2フォワーディング方式が望ましい」とあるため、H社はL2フォワーディングで運用することが前提です。さらにL2方式の記述にある「PCとSSL-VPN装置間のSSL/TLS接続トンネル上で、レイヤ2の中継を行う」という点が重要です。
3. L2フォワーディングでは、トンネルはレイヤ2（イーサネットフレーム）を中継します。クライアント側ではこのトンネルの終端として仮想的なネットワークインタフェース（vNICなど）が作成され、VPN経由の通信はその仮想インタフェースを通じて送受信されます。図2に「NIC・vNIC → PC」と示されていることから、PC側に物理NICと並んでVPN用の仮想インタフェース（vNIC）が存在することが確認できます。
4. また本文のIPプール指定「10.100.k.1～10.100.k.200」はVPN接続PC用のアドレス群であり、認証されたユーザに対してこのプールからIPが割り当てられることが明示されています。VPNで割り当てられるIPは、実際にVPNトンネル上の送受信に使われるインタフェースに設定されなければ意味がありません。
5. 以上より、認証に応じて割り当てられるIPアドレスは、図2でVPNトンネルの終端となる仮想インタフェースである「vNIC」に設定されます。

誤りやすいポイント

• 物理NICに割り当てられると誤解する：VPN用のIPはVPNトンネルを終端するインタフェースに設定されるため、物理NICではなくvNIC（仮想インタフェース）が正しい場合が多いです。
• IPプール表記を勝手に /24表記に直す：本文では「10.100.k.1～10.100.k.200」と明示されているので、これを「10.100.k.0/24」と置き換えると誤りになります。
• L3側（VLAN201やL3SWのインタフェース）に割り当てられると考える：VLAN201等はネットワーク側のサブネットやルータ側インタフェースであり、クライアント自身が使用するIPはクライアント側のインタフェース（vNIC）に設定されます。
• L2とL3の違いを混同する：L2フォワーディングでは仮想のブリッジ接続（vNIC/tap）が、L3トンネルではトンネル用のインタフェース（tun）が用いられる点を押さえておく必要があります。

FAQ

解答の論理構成

1. 行き先ネットワークの同定
   表1の1行目は「宛先IPアドレス」が「202.y.44.0/28」です。問題文には
   「DMZのプロキシサーバを経由して行っている」「SSL-VPN装置の設置位置はDMZとL3SWの間とする」
   とあり、このプレフィックスはDMZを示します。したがって キ ＝ DMZ です。
2. 送信元ネットワークの同定
   顧客システム構築ネットワークや開発LANなど社内側のアドレスは「172.16.0.0/16」を含む内部LANとしてまとめられています（問題文冒頭の〔H社の現行ネットワーク〕参照）。よって表1の「送信元IPアドレス」が「172.16.0.0/16」と対応し、ク ＝ 172.16.0.0/16、カ ＝ 内部LAN となります。
3. インターネット側からDMZへのSSL-VPN接続
   表1の3行目は「プロトコル／宛先ポート」が「TCP/443」で、外部からDMZ内のSSL-VPN装置に到達させるルールです。問題文(1)「クライアント側から送られる…」及び検討結果(1)に
   「SSL-VPN装置から内部LANへの通信用に…」
   とあるとおり、装置のグローバルIPはDMZ内に配置されます。装置単体への通信なのでホストアドレス表記 /32が妥当で、ケ ＝ 202.y.44.2/32 です。
4. 方向の検証
   ・1行目：[カ]→[キ] は内部LANからDMZへの通信を許可するルール
   ・2行目：DMZ→インターネット（既定）
   ・3行目：インターネット→DMZ（SSL-VPN用）
   これらはDMZを境界として内外・外内の最低限の経路を開く設定と一致します。

誤りやすいポイント

• 「送信元／宛先」の向きの取り違え
  DMZから内部LANへの通信と勘違いすると [カ] と [キ] を逆に書いてしまいます。
• /28と /32の使い分け
  DMZセグメント全体へ許可する設定なのか、装置単体へ絞るのかを見落とすと「202.y.44.0/28」をそのまま [ケ] に書き込むミスが発生します。
• 172.16.0.0/16を「開発LAN」または「顧客システム構築ネットワーク」の一部と読み違える
  問題文では172.16.0.0/16を内部LAN全体のプレフィックスとしている点に注意が必要です。

FAQ

解答の導き方

1. 問われている条件を整理します。設問は「表2のアクセスリストを、インタフェースの入力方向に設定する」としています。表2の要点は次のとおりです。
   　・項番1は「禁止Any → 172.16.0.0/16」
   　・項番2は「許可Any → Any」
   　かつ「アクセスリストは、項番が小さい順に参照され、最初に該当したルールが適用される」という動作です。これらは、到達先が172.16.0.0/16のパケットを最優先で遮断し、それ以外は許可する設計であることを意味します。
2. 図2のインタフェースと保護対象を対応させます（図中表記を利用）。
   　・VLAN1　②　E社システム　サーバ機器　172.16.100.0/24
   　・VLAN2　③　F社システム　サーバ機器　172.16.101.0/24
   　・VLAN3　④　G社システム　サーバ機器　172.16.102.0/24
   　・VLAN201　⑤（SSL-VPN装置接続）
   　・VLAN101　⑥　開発LAN　172.16.10.0/24
   　（①はVLAN200：FW接続）
3. どのインタフェースにACLを置くべきかの論理です。表2は「到達先が172.16.0.0/16の通信を禁止する」ものであり、狙いは「開発LANから顧客システム構築ネットワークへの直接アクセス（SSL-VPNを経由しないアクセス）と、それ以外の不正な通信を禁止する」ことです。これを満たすには、到達先側で到達を遮断できる位置にACLを置くのが確実です。図2で到達先となるサーバ群は ②、③、④ に所在し、SSL-VPN経由の入口は ⑤（VLAN201）です。したがって、どのVLANから来た通信であっても「到達先が172.16.0.0/16であれば」そこで遮断できるように、これらのインタフェースの入力方向に表2を設定します。
4. ① と ⑥ を選ばない理由。
   　・①（VLAN200／FW接続）はDMZ／FW側の経路であり、内部VLAN間の不正な到達先制御（172.16.0.0/16の保護）を行う場所ではないため適切でない。DMZ／インターネット向けの制御はFW側で行う。
   　・⑥（開発LAN）は「送信元が開発LANのとき」に入ってくるパケットを制御する位置です。もし表2を ⑥ の入力にだけ置くと、開発LANからの直接アクセスは制御できますが、SSL-VPN経由や他の内部VLANからの不正アクセス（問題文の「それ以外の不正な通信」）を防げません。したがって不十分です。

誤りやすいポイント

• 「開発LAN（⑥）に置けばよい」と考える誤り：それでは開発LAN発のアクセスしか制御できず、他のソース（ほかのVLANやVPN経由）からの不正アクセスを防げません。
• 入力／出力の方向を混同する誤り：問題は「入力方向に設定する」と明示しているため、方向の取り違えで期待したタイミングでACLが評価されないことがあります。
• 表2と表3（VPN-PC用）の役割を混同する誤り：表2は「到達先が172.16.0.0/16の通信をブロックする」一般的な防御、表3は「VPN-PCに対して許可先を限定する」個別制御です。両者をどう配置・統合するかを実装段階で整理しないと、正当なVPN接続まで遮断してしまうおそれがあります。
• 機器の実装制限を考慮しない誤り：機種によっては同一インタフェースに複数のACLを同時に設定できない場合があるので、その場合はACLを統合する（先に許可ルールを置く等）必要があります。

FAQ

解答の論理構成

• 【問題文】には「顧客システム構築ネットワークは…顧客ごとに設け」られ、「開発LANから顧客システム構築ネットワークへの直接アクセス（SSL-VPNを経由しないアクセス）と、（V）それ以外の不正な通信を禁止する」とあります。
• ここで “それ以外” とは、同じ内部172.16.0.0/16の中で発生し得る不正通信の残りを指します。開発LANからの直接アクセスは既に列挙済みなので、残る可能性は「顧客Ａのネットワークから顧客Ｂのネットワークへ」という相互アクセスです。
• 顧客間のネットワークは “顧客システム構築ネットワーク” という共通名称でまとめられているため、禁止対象を本文の語句で表すと「顧客システム構築ネットワークから他社の顧客システム構築ネットワークへの通信」と整理できます。

誤りやすいポイント

• 「開発LAN関連だけを禁止」と早合点し、顧客間通信を見落とす。
• “他社” の代わりに “他拠点” など本文にない語を使い減点される。
• 「SSL-VPN経由の通信」まで禁止対象と誤解し、正当な経路を遮断してしまう。

FAQ

解答の論理構成

1. VPN-PCのトラフィックがL3SWに最初に入る場所を特定
   【問題文】の「PCから顧客システム構築ネットワークへのアクセス経路が『PC→SSL-VPN装置→VLAN201→顧客システム構築ネットワーク』となるように経路を設定する。」より、VPN-PCのパケットはSSL-VPN装置を出た後にL3SWのVLAN201へ流入します。
2. 表3 ACLの目的を確認
   【問題文】「表3のアクセスリストは、VPN-PCからの不正な通信を禁止する。」とあるため、VPN-PC由来のパケットをL3SWに入る瞬間で選別するのが最も効果的です。
3. ACLを“入力方向”で適用する指示
   小問説明に「アクセスリストはインタフェースの入力方向に設定するものとする。」とあるため、VLAN201へ到着するパケットを対象とします。
4. VLAN201に対応する番号を図2から読み取る
   図2のインタフェース番号は①〜⑥で示され、VLAN201が ⑥ であることが示されています。ゆえにACLを設定すべきインタフェースは ⑥ です。

誤りやすいポイント

• 「出力方向」にACLを設定してしまう
  指示は“入力方向”です。方向を誤るとVPN-PCからの不正通信を遮断できません。
• VLAN201とVLAN101の取り違え
  VPN-PCが入るのはVLAN201、開発LANはVLAN101です。番号の読み違いに注意しましょう。
• SSL-VPN装置側でのフィルタリングと勘違い
  問題は「L3SWに設定」と明示されています。装置側のポリシーでは解答になりません。

FAQ