ネットワークスペシャリスト 2018年 午後1 問01
SaaSの導入に関する次の記述を読んで、設問1〜3に答えよ。
F社は、本社と四つの営業所を拠点として事業を展開している中堅商社である。本社を中心としたハブアンドスポーク構成のIPsec VPNを使って、本社と営業所を接続している。営業所からインターネットへの通信は、全て本社を経由させている。
現在F社で利用しているグループウェア機能は、電子メール、スケジューラ、ファイル共有などである。このうち電子メールは社外との連絡にも利用している。
このたびF社では、グループウェアサーバの老朽化に伴い、グループウェアサーバを廃止し、グループウェア機能をもつG社SaaSを導入することにした。また、G社SaaSの導入に合わせたセキュリティ対策を講じることにした。
〔F社の現行ネットワーク構成とG社SaaS導入に合わせたセキュリティ対策〕
F社の現行ネットワーク構成を、図1に示す。

・プロキシサーバ及びグループウェアサーバは、本社DMZに設置されている。
・L3SWでは、次のように静的経路設定を行っている。
- デフォルトルートのネクストホップをFWに設定している。
- 各営業所への経路のネクストホップを本社のIPsecルータに設定している。
・社内PCからインターネットへは、Webアクセスだけが許可されており、プロキシサーバを経由して通信を行っている。
一般に、プロキシには、アプロキシとイプロキシがある。F社のプロキシのようにアプロキシは、社内に対して、アクセス先URLのログ取得や、外部サーバのコンテンツをキャッシュして使用帯域を削減する目的で用いられる。一方、イプロキシは、外部から公開サーバのオリジナルコンテンツに直接アクセスさせないことによる改ざん防止、キャッシュによる応答速度の向上、及び複数のサーバでの負荷分散を行う目的で用いられる。
G社SaaSの導入に合わせて、インターネットへのWebアクセスについてのセキュリティ対策を検討した。検討結果を次に示す。
・G社SaaSとの通信は、HTTPSによって暗号化する。
・出張先のPCから直接G社SaaSを利用できるようにするために、G社SaaSでは送信元IPアドレスの制限を行わない。
・G社SaaS導入に合わせてセキュリティ強化を行うために、プロキシサーバで次のログを取得する。
- アクセス先URLと利用者ID
- G社SaaSのファイルアップロード/ダウンロードのログと利用者ID
・社内PCからインターネットへのWebアクセスでは①プロキシサーバにおいて認証を行う。
〔G社SaaSの試用〕
F社は、G社SaaSの本格導入に先立って、本社と一つの営業所を対象に少数ライセンスでG社SaaSを試用し、システムの利便性と性能を確認することにした。試用に先立ち、G社SaaS以外のアクセス先について、プロキシサーバでHTTPSのアクセスログを確認したところ、②アクセス先のホスト名は記録されていたが、URLは記録されていなかった。そこで、アクセス先のURLを把握するために、プロキシサーバで暗号化通信を一旦復号し、必要な処理を行った上で再度暗号化した。しかし、社内PCでエラーメッセージ“証明書が信頼できない”が表示されたので、社内PCにウをインストールして解決した。
G社SaaSを試用した結果、次の事実が判明した。
・G社SaaSにアクセスした際にプロキシサーバを通過するセッション数を実測したところ、スケジューラにアクセスする1人当たりのセッション数が大幅に増加した。
・複数人が同時に大容量のファイルをG社SaaSに転送している間、本社のFWを経由するインターネット接続回線のスループットが低下した。
このまま全社でG社SaaSの利用を開始すると、プロキシサーバの処理可能セッション数の超過、インターネット接続回線の帯域不足が予想された。
〔SD-WANルータの導入〕
F社は、G社SaaSの試用で判明した問題を解決するために、IPsecルータの代わりにSD-WAN(Software-Defined WAN)ルータを使用することにした。
SD-WANルータを使用したネットワーク構成案を、図2に示す。
(1) SD-WANルータの概要
今回使用する予定のSD-WANルータは、SDN〔Software-Defined Networking〕によって制御されるIPsecルータである。SDNは、利用者の通信トラフィックを転送するデータプレーンと、通信装置を集中制御する エ プレーンから構成されており、エ プレーンのソフトウェアでデータ転送を制御する方式である。
F社が導入するSD-WANルータの仕様を次に示す。
・SD-WANルータの設定は、SD-WANコントローラによって集中制御される。
・SD-WANルータのWAN側には、インターネットに接続するインタフェースだけでなく、ほかのSD-WANルータに接続するIPsec VPNの論理インタフェースがある。
(2) SD-WANルータを用いたときの通信
図2の説明を次に示す。
・社内PCからG社SaaSへのWebアクセスは、プロキシサーバを経由せず各SD-WANルータを経由する。
・社内PCからG社SaaS以外のインターネットへのWebアクセスは、プロキシサーバを経由する。
・L3SWにプロキシサーバへの静的経路情報を追加する。
・営業所と本社間の通信は、SD-WANルータ間でIPsecによって暗号化する。
・本社の社内PCからG社SaaSへの通信について、③G社SaaSのIPアドレスが変更された場合でもその都度L3SWを設定しなくても済むように、L3SWの静的経路情報を設定変更する。
(3) SD-WANルータの運用
G社はSaaSに必要なサーバを随時追加している。G社SaaSが利用しているIPアドレスブロックの更新があるたびに、F社はSD-WANルータの設定を変更する必要がある。F社は、G社SaaSのIPアドレスブロックの更新を、RSS〔Really Simple Syndication〕を利用して知ることができる。
F社は、RSS配信されたIPアドレスブロックを検知するツールを作成して、自動的にツールから オ に指示を行い、全社のSD-WANルータの設定を変更することにした。さらに、社内PCから参照する④プロキシ自動設定ファイルを作成することにした。
(4) G社SaaSアクセスログの取得
G社SaaSへのアクセスログは、⑤プロキシサーバからではなく、G社SaaSのAPIにアクセスして取得することにした。
F社は、G社SaaSの本格導入に向けてSD-WANルータを利用したネットワークの構築プロジェクトを立ち上げた。
設問1:〔F社の現行ネットワーク構成とG社SaaS導入に合わせたセキュリティ対策〕について、(1)、(2)に答えよ。
問題文を見る(1)本文中のア、イに入れる適切な字句を答えよ。
模範解答
ア:フォワード
イ:リバース
解説
解答の論理構成
- 問題文では、プロキシを二種類に分類しています。
引用:「一般に、プロキシには、アプロキシとイプロキシがある。」 - それぞれの役割が記述されています。
・引用:「F社のプロキシのようにアプロキシは、社内に対して、アクセス先URLのログ取得や、外部サーバのコンテンツをキャッシュして使用帯域を削減する目的で用いられる。」
・引用:「一方、イプロキシは、外部から公開サーバのオリジナルコンテンツに直接アクセスさせないことによる改ざん防止、キャッシュによる応答速度の向上、及び複数のサーバでの負荷分散を行う目的で用いられる。」 - 「社内→外部」(クライアント側)で利用し、URLログ取得や帯域削減を狙うのはforward proxyの典型的用途です。
- 「外部→社内公開サーバ」(サーバ側)で利用し、改ざん防止・高速化・負荷分散を狙うのはreverse proxyの典型的用途です。
- 以上より、
・ア=フォワード
・イ=リバース
が妥当となります。
誤りやすいポイント
- 「キャッシュ」をキーワードにして安易にリバースと決めつけると失点します。問題文はキャッシュ機能を両者に言及しているため、向き(社内↔外部)で判断する必要があります。
- 「改ざん防止」「負荷分散」はWebサーバ保護の文脈=リバースproxyを示す定番表現ですが、これをforwardと誤読しがちです。
- 社内の利用者認証やURLログ取得を行う装置はforward proxyが担うという基本を忘れると混乱します。
FAQ
Q: forward proxyは必ずしもキャッシュを行いますか?
A: キャッシュ機能を持つことが多いですが必須ではありません。ログ取得・アクセス制御・帯域制御などの機能のみを担う場合もあります。
A: キャッシュ機能を持つことが多いですが必須ではありません。ログ取得・アクセス制御・帯域制御などの機能のみを担う場合もあります。
Q: reverse proxyとロードバランサの違いは何ですか?
A: reverse proxyは一台でキャッシュ・SSL終端・負荷分散など複数機能を担うことがあります。ロードバランサは基本的にトラフィック分散に特化した装置ですが、実装によってreverse proxy機能を兼ねることもあります。
A: reverse proxyは一台でキャッシュ・SSL終端・負荷分散など複数機能を担うことがあります。ロードバランサは基本的にトラフィック分散に特化した装置ですが、実装によってreverse proxy機能を兼ねることもあります。
Q: forward proxyがないとHTTPSのURLログは取得できませんか?
A: エンドポイントにSSL/TLS復号機能がない場合、HTTPSの中身は見えません。問題文のようにforward proxyで復号(SSLインスペクション)を行うことでURLまで取得できます。
A: エンドポイントにSSL/TLS復号機能がない場合、HTTPSの中身は見えません。問題文のようにforward proxyで復号(SSLインスペクション)を行うことでURLまで取得できます。
関連キーワード: forward proxy, reverse proxy, ログ取得, SSLインスペクション, キャッシュ
設問1:〔F社の現行ネットワーク構成とG社SaaS導入に合わせたセキュリティ対策〕について、(1)、(2)に答えよ。
問題文を見る(2)本文中の下線①について、プロキシサーバで認証を行うことによってアクセスログに付加できる情報を答えよ。
模範解答
利用者 ID
解説
解答の論理構成
- 【問題文】には、プロキシサーバで “①プロキシサーバにおいて認証を行う” とあります。認証を行う目的は、通信主体を特定することです。
- その具体的なログ取得対象として、同じ段落に “プロキシサーバで次のログを取得する。
- アクセス先URLと利用者ID
- G社SaaSのファイルアップロード/ダウンロードのログと利用者ID” と明記されています。 - 認証により付加できるのは、通信した個人を示す情報であり、【問題文】に繰り返し登場する “利用者ID” です。
- したがって、下線①で認証を行うことによってアクセスログに付加できる情報は「利用者ID」となります。
誤りやすいポイント
- 「アクセス先URL」や「端末のIPアドレス」を答えてしまう。URLは認証有無に関係なく取得でき、IPアドレスはネットワーク層情報であって認証とは無関係です。
- 「氏名」や「部署名」など、人間がわかりやすい属性を連想してしまう。ログに直接付加されるのは認証結果として得られる識別子(利用者ID)であり、属性情報は別管理です。
- “プロキシで認証=社外向けサーバを保護” と早合点し、WAFや証明書関連キーワードを挙げてしまう。設問はあくまでログ項目を問うています。
FAQ
Q: 認証方式は何を想定していますか?
A: 【問題文】に方式の指定はありませんが、一般的にはNTLM、Kerberos、LDAP over SSLなどの社内認証基盤連携が考えられます。方式にかかわらずログに残るキー情報は「利用者ID」です。
A: 【問題文】に方式の指定はありませんが、一般的にはNTLM、Kerberos、LDAP over SSLなどの社内認証基盤連携が考えられます。方式にかかわらずログに残るキー情報は「利用者ID」です。
Q: 利用者ID以外にログへ付加すると有効な情報はありますか?
A: 端末名やMACアドレスなども補助的に有用ですが、設問は “認証を行うことによって” 付加できる情報を尋ねているため、認証結果として得られる「利用者ID」が正答です。
A: 端末名やMACアドレスなども補助的に有用ですが、設問は “認証を行うことによって” 付加できる情報を尋ねているため、認証結果として得られる「利用者ID」が正答です。
Q: HTTPS通信の場合でも利用者IDを記録できますか?
A: はい。認証はプロキシとの間で行います。HTTP CONNECT後に暗号化されても、プロキシ側でセッションを保持しているため、誰の通信かを把握して「利用者ID」をログに付記できます。
A: はい。認証はプロキシとの間で行います。HTTP CONNECT後に暗号化されても、プロキシ側でセッションを保持しているため、誰の通信かを把握して「利用者ID」をログに付記できます。
関連キーワード: 認証プロキシ, アクセスログ, ユーザ識別, ログ管理
設問2:〔G社SaaSの試用〕について、(1)、(2)に答えよ。
問題文を見る(1)本文中の下線②について、HTTPSでアクセスするためのHTTPプロトコルのメソッド名を答えよ。また、このメソッドを用いる場合、社内に侵入したマルウェアによる通信(ただし、HTTPS以外の通信)を遮断するためのプロキシサーバでの対策を、30字以内で述べよ。
模範解答
メソッド名:CONNECTメソッド
対策:HTTPS以外のポートのCONNECTを拒否する。
解説
解答の論理構成
- ②では「アクセス先のホスト名は記録されていたが、URLは記録されていなかった」とあります。これはTLSで暗号化されたHTTPSのため、プロキシサーバはURLパスを見られず、ホスト名のみをCONNECTで把握している状況を示しています。
- HTTPSをプロキシ経由で利用する際、ブラウザはHTTPプロキシに対しトンネル確立要求を出します。その際に用いるHTTPメソッドが「CONNECT」です。
- 社内に侵入したマルウェアがCONNECTを悪用して任意ポートへトンネルを張ると、HTTPS以外のプロトコルも通過してしまいます。よって対策は「HTTPS以外のポートのCONNECTを拒否する」となります。これにより443など必要最小限のポートだけがトンネル可能となり、他プロトコルを遮断できます。
誤りやすいポイント
- 「GETやPOSTも暗号化されるからHTTPSのメソッドだ」と思い込み、CONNECTを挙げられない。
- 対策としてURLフィルタやファイアウォール設定を答えてしまい、プロキシでのCONNECT制御という趣旨から外れる。
- 「443以外のHTTPを遮断する」と書いてしまい、CONNECTメソッドを介したトンネリングが対象である点を漏らす。
FAQ
Q: CONNECTを使わずにHTTPSを通す方法はありますか?
A: 透過プロキシやSSL/TLSブリッジ構成などがありますが、本問は明示的プロキシを前提としているためCONNECTが必須です。
A: 透過プロキシやSSL/TLSブリッジ構成などがありますが、本問は明示的プロキシを前提としているためCONNECTが必須です。
Q: 443以外に許可が必要なケースは?
A: WebDAVなど特定用途で8443等を利用する場合があります。その際も必要なポートだけを明示的に許可し、それ以外は拒否する運用が推奨されます。
A: WebDAVなど特定用途で8443等を利用する場合があります。その際も必要なポートだけを明示的に許可し、それ以外は拒否する運用が推奨されます。
Q: CONNECTを拒否するとブラウザはどうなりますか?
A: 指定ポートへのトンネルが張れずTLSハンドシェイクが開始できないため、ユーザ側には「接続できません」などのエラーが表示されます。
A: 指定ポートへのトンネルが張れずTLSハンドシェイクが開始できないため、ユーザ側には「接続できません」などのエラーが表示されます。
関連キーワード: HTTPS, HTTPメソッド, プロキシ制御, トンネリング, マルウェア対策
設問2:〔G社SaaSの試用〕について、(1)、(2)に答えよ。
問題文を見る(2)本文中のウに入れる適切な字句を、20字以内で答えよ。
模範解答
ウ:プロキシサーバのルート証明書
解説
解答の論理構成
- 【問題文】では、HTTPSのアクセス内容を把握するために「プロキシサーバで暗号化通信を一旦復号し、必要な処理を行った上で再度暗号化」したと記載されています。
- その結果、「社内PCでエラーメッセージ“証明書が信頼できない”が表示された」とあります。これは、プロキシサーバが自ら発行したサーバ証明書で再暗号化(いわゆるSSL/TLSインスペクション)したため、OSやブラウザが “未知の認証局” と判断した状況です。
- 通常、HTTPS通信を復号・再暗号化するプロキシは自己署名の認証局(CA)になり、各PCにそのCA証明書を信頼させる必要があります。
- 【問題文】は「社内PCにウをインストールして解決した」と述べており、信頼性エラーの解消措置=プロキシCAを信頼ストアに追加したことを意味します。
- 以上から、ウ には「プロキシサーバのルート証明書」が入るのが最も整合的です。
誤りやすいポイント
- 「サーバ証明書」と混同しやすい
インストールするのは個々のサイト用サーバ証明書ではなく、その上位にある「自社プロキシが発行するルートCA証明書」です。 - 「中間証明書」を想起してしまう
ルートCA証明書を信頼ストアに登録すれば、中間証明書は自動取得されるケースが多く、設問の主語はあくまで “ルート” です。 - 「公開CAの証明書」と勘違い
公開CAは既にOSに格納済みであり、問題のエラーは “社内プロキシが独自に発行した証明書” をブラウザが信頼できなかったことが原因です。
FAQ
Q: ルート証明書をインストールする際の推奨手順はありますか?
A: グループポリシーやMDMを用いて企業ポリシーとして一括配布・自動信頼させる方法が一般的です。手動配布は管理漏れやバージョン差異の原因になります。
A: グループポリシーやMDMを用いて企業ポリシーとして一括配布・自動信頼させる方法が一般的です。手動配布は管理漏れやバージョン差異の原因になります。
Q: プロキシでHTTPSを復号することはセキュリティ上問題ではないでしょうか?
A: 内部脅威対策やログ取得目的で許容されるケースがありますが、プライバシー懸念や暗号強度低下を招く場合もあるため、対象サイトや部門を限定し、運用手順を明確化することが重要です。
A: 内部脅威対策やログ取得目的で許容されるケースがありますが、プライバシー懸念や暗号強度低下を招く場合もあるため、対象サイトや部門を限定し、運用手順を明確化することが重要です。
Q: 社外PCで同じプロキシを使わせたい場合はどうすればよいですか?
A: VPN接続時にプロキシを自動設定し、同時にルートCA証明書を配布・信頼させるスクリプトやMDMポリシーを適用する方法が一般的です。
A: VPN接続時にプロキシを自動設定し、同時にルートCA証明書を配布・信頼させるスクリプトやMDMポリシーを適用する方法が一般的です。
関連キーワード: HTTPS復号, ルートCA証明書, TLSインスペクション, プロキシ認証, 信頼ストア
設問3:〔SD-WANルータの導入〕について、(1)〜(5)に答えよ。
問題文を見る(1)本文中のエに入れる適切な字句を答えよ。
模範解答
エ:コントロール
解説
解答の論理構成
- 【問題文】には
“SDNは、利用者の通信トラフィックを転送するデータプレーンと、通信装置を集中制御する エ プレーンから構成されており、エ プレーンのソフトウェアでデータ転送を制御する方式である。”
とあります。 - SDNの基本構造は「データプレーン」と「コントロールプレーン」の2層に分離され、ネットワーク機器の転送制御を集中管理するのが「コントロールプレーン」です。
- よって、エ に入る語は「コントロール」が正答となります。
誤りやすいポイント
- 「管理」を意味するために “マネジメント” と誤記するケースがありますが、SDN用語としては “コントロールプレーン” が正しいです。
- データプレーンと混同し「フォワーディング」「トラフィック」などを入れてしまうミスが見られます。
- “プレーン” を省き “コントロールセンター” などと機能名を書いてしまうと配点対象外になります。
FAQ
Q: コントロールプレーンとデータプレーンの違いは何ですか?
A: データプレーンがパケット転送そのものを行うのに対し、コントロールプレーンはルーティングや経路選択など転送ルールを集中管理・配信します。
A: データプレーンがパケット転送そのものを行うのに対し、コントロールプレーンはルーティングや経路選択など転送ルールを集中管理・配信します。
Q: SD-WANがSDNを採用するメリットは?
A: 拠点ルータ設定をSD-WANコントローラで集中制御でき、IPアドレス変更や新規ポリシの配布を迅速に自動化できます。
A: 拠点ルータ設定をSD-WANコントローラで集中制御でき、IPアドレス変更や新規ポリシの配布を迅速に自動化できます。
Q: コントロールプレーン障害時は通信が止まりますか?
A: 既に適用済みの転送ルールはデータプレーンに残るため即停止はしませんが、新規経路変更やポリシ更新ができなくなります。
A: 既に適用済みの転送ルールはデータプレーンに残るため即停止はしませんが、新規経路変更やポリシ更新ができなくなります。
関連キーワード: SDN, コントロールプレーン, データプレーン, 集中制御, SD-WAN
設問3:〔SD-WANルータの導入〕について、(1)〜(5)に答えよ。
問題文を見る(2)本文中の下線③について、設定変更後の静的経路情報を、35字以内で答えよ。
模範解答
ネクストホップがSD-WANルータとなるデフォルトルート
解説
解答の論理構成
-
現状の経路設定
- 【問題文】には「L3SWでは、次のように静的経路設定を行っている。- デフォルトルートのネクストホップをFWに設定している。」とあります。
- つまり従来は “行先が社内外いずれでもマッチしないパケット” をすべてFWに転送していました。
-
SD-WANルータ導入後の要件整理
- ③の下線指示では「G社SaaSのIPアドレスが変更された場合でもその都度L3SWを設定しなくても済むように」と要求されています。
- SaaS側のアドレスレンジは「G社はSaaSに必要なサーバを随時追加している。」ため固定できません。
-
要件を満たす経路の考え方
- もし “G社SaaS宛” という個別エントリをL3SWに登録すると、IPアドレスブロックが増減するたびに追随が必要になり、③の要件を満たせません。
- そこで「特定の宛先だけではなく、行先がどこでもSD-WANルータに渡す」という包括的な経路(=デフォルトルート)をSD-WANルータ向けに置くのが最小構成になります。
-
新しいデフォルトルートのネクストホップ
- SD-WANルータは「社内PCからG社SaaSへのWebアクセスは、プロキシサーバを経由せず各SD-WANルータを経由する。」という動作を実現する唯一の出口装置です。
- したがって “ネクストホップ=SD-WANルータ” のデフォルトルートを設定すれば、SaaSへの通信は常にSD-WANルータに届き、アドレスが変わってもL3SWの再設定は不要になります。
-
まとめ
- 以上より、L3SWは「ネクストホップがSD-WANルータとなるデフォルトルート」だけを静的に持てば③の条件を満たします。
誤りやすいポイント
- 「SaaS宛だけを経路追加すれば良い」と思い込み、個別のプレフィックスを登録してしまう。これではIP変更のたびに変更作業が発生します。
- 従来のFW向けデフォルトルートを残したままにし、経路選択が意図せずFW側へ向かうケース。SD-WANルータ経由を優先させるにはメトリック調整かデフォルトルートの置き換えが必要です。
- 「プロキシ経由通信」と「直接インターネット通信」の切り分けをPACファイル任せにする点を忘れ、経路だけで制御できると誤解する。
FAQ
Q: 既存のFWは完全に不要になるのですか?
A: いいえ。非SaaSサイトへのWeb接続は「社内PCからG社SaaS以外のインターネットへのWebアクセスは、プロキシサーバを経由する。」とある通り、FW/プロキシ経由で継続利用します。
A: いいえ。非SaaSサイトへのWeb接続は「社内PCからG社SaaS以外のインターネットへのWebアクセスは、プロキシサーバを経由する。」とある通り、FW/プロキシ経由で継続利用します。
Q: SD-WANコントローラがダウンした場合、デフォルトルートはどうなりますか?
A: デフォルトルートはL3SWに静的に設定するため、コントローラ停止中でも経路自体は残ります。ただしSD-WANルータ側で新規トンネル確立などが行えなくなる可能性があります。
A: デフォルトルートはL3SWに静的に設定するため、コントローラ停止中でも経路自体は残ります。ただしSD-WANルータ側で新規トンネル確立などが行えなくなる可能性があります。
Q: G社SaaSのログ取得はどこで行うのですか?
A: 【問題文】の (4) に「⑤プロキシサーバからではなく、G社SaaSのAPIにアクセスして取得する」と記載されており、今後はSaaSから直接ダウンロードします。
A: 【問題文】の (4) に「⑤プロキシサーバからではなく、G社SaaSのAPIにアクセスして取得する」と記載されており、今後はSaaSから直接ダウンロードします。
関連キーワード: デフォルトルート, ネクストホップ, 静的経路, SD-WAN, PACファイル
設問3:〔SD-WANルータの導入〕について、(1)〜(5)に答えよ。
問題文を見る(3)本文中のオに入れる適切な字句を、図2中の機器名で答えよ。
模範解答
オ:SD-WANコントローラ
解説
解答の論理構成
-
【問題文】には、「F社は、RSS配信されたIPアドレスブロックを検知するツールを作成して、自動的にツールから オ に指示を行い、全社のSD-WANルータの設定を変更することにした。」とあります。
➔ ツールが指示を送る相手は、“全社のSD-WANルータの設定を変更”できる装置である必要があります。 -
同じ段落より少し前の仕様説明に「・SD-WANルータの設定は、SD-WANコントローラによって集中制御される。」と明示されています。
➔ SD-WANコントローラがSD-WANルータ設定の集中管理者であるとわかります。 -
したがって、「ツールから指示を行い、全社のSD-WANルータの設定を変更」する相手、すなわち オ に入る機器名は、図2にも登場する「SD-WANコントローラ」が唯一の適切解となります。
-
以上より、オ=「SD-WANコントローラ」と結論付けられます。
誤りやすいポイント
- 「SD-WANルータ」と誤答するケース
⇒ 問題文では“ルータの設定を変更する”側が オ であり、設定される対象ではありません。 - 「FW」や「L3SW」と取り違えるケース
⇒ ファイアウォールやレイヤ3スイッチはSD-WANルータの設定を集中制御する役割を持たないことを思い出しましょう。 - 図2の機器ラベルを見落とし、本文の記述だけで推測してしまうケース
⇒ 図2に「SD-WANコントローラ」が明示されている点を必ず確認しましょう。
FAQ
Q: ツールが直接SD-WANルータへ設定投入してはいけないのですか?
A: SD-WANの特徴は「集中制御」です。設定の一元化を保つため、ツールはまず「SD-WANコントローラ」に指示を送り、コントローラが全ルータへ反映させる設計になっています。
A: SD-WANの特徴は「集中制御」です。設定の一元化を保つため、ツールはまず「SD-WANコントローラ」に指示を送り、コントローラが全ルータへ反映させる設計になっています。
Q: 「SDNコントローラ」と書いても正解になりますか?
A: 設問は「図2中の機器名で答えよ」と指示しています。図2のラベルは「SD-WANコントローラ」なので、その表記が要求されます。
A: 設問は「図2中の機器名で答えよ」と指示しています。図2のラベルは「SD-WANコントローラ」なので、その表記が要求されます。
Q: RSSで配信される情報を取り込む理由は何ですか?
A: G社SaaSのIPアドレスブロックが更新されるたびにSD-WANルータの経路設定を自動更新するためです。これにより最新のアドレス変更に追随できます。
A: G社SaaSのIPアドレスブロックが更新されるたびにSD-WANルータの経路設定を自動更新するためです。これにより最新のアドレス変更に追随できます。
関連キーワード: SDN, 集中制御, ルーティング, VPN, 自動化
設問3:〔SD-WANルータの導入〕について、(1)〜(5)に答えよ。
問題文を見る(4)本文中の下線④について、このファイルを作成することによってプロキシから除外する通信を、20字以内で答えよ。
模範解答
G社SaaSへのHTTPS通信
解説
解答の論理構成
- 本文の前提
(2) の説明に「社内PCからG社SaaSへのWebアクセスは、プロキシサーバを経由せず各SD-WANルータを経由する。」とあります。 - 逆に「社内PCからG社SaaS以外のインターネットへのWebアクセスは、プロキシサーバを経由する。」とも記載されています。
- したがって、④「プロキシ自動設定ファイル」は、上記2行目の“以外”ではなく1行目の通信、すなわち「G社SaaSへのWebアクセス」をプロキシから除外させる目的で作成されます。
- さらに (2) では「G社SaaSとの通信は、HTTPSによって暗号化する。」と定義されているため、除外対象の具体的なプロトコルはHTTPSです。
- 以上より、プロキシから除外する通信は「G社SaaSへのHTTPS通信」と導けます。
誤りやすいポイント
- 「RSSで取得」「APIでログ収集」などの記載に気を取られ、④の目的を見落とす。
- “G社SaaS以外”を除外対象と誤読し、全インターネット通信を直通させると解釈してしまう。
- プロトコルを明示せず「G社SaaSへの通信」とだけ答え、要件の暗号化 (HTTPS) を落とす。
FAQ
Q: PACファイル(プロキシ自動設定ファイル)はどこで参照されますか?
A: 本文にある通り「社内PCから参照」され、ブラウザが通信経路を都度判断します。
A: 本文にある通り「社内PCから参照」され、ブラウザが通信経路を都度判断します。
Q: なぜHTTPSと分かるのですか?
A: 「G社SaaSとの通信は、HTTPSによって暗号化する。」との明記があるためです。
A: 「G社SaaSとの通信は、HTTPSによって暗号化する。」との明記があるためです。
Q: PACファイルに複数ドメインを記述する場合の管理方法は?
A: 本文では「RSS配信されたIPアドレスブロックを検知するツール」で自動更新し、SD-WANコントローラ設定と合わせて一元管理すると示唆されています。
A: 本文では「RSS配信されたIPアドレスブロックを検知するツール」で自動更新し、SD-WANコントローラ設定と合わせて一元管理すると示唆されています。
関連キーワード: PACファイル, HTTPS, プロキシサーバ, SD-WAN
設問3:〔SD-WANルータの導入〕について、(1)〜(5)に答えよ。
問題文を見る(5)本文中の下線⑤について、G社SaaSのAPI経由で取得する理由を二つ挙げ、それぞれ40字以内で述べよ。
模範解答
①:社内PCからG社SaaSへのアクセスがプロキシサーバを経由しなくなるから
②:出張先のPCからG社SaaSへのアクセスが記録されるから
解説
解答の論理構成
-
まず本文には、SD-WANルータ導入後の通信経路として
「社内PCからG社SaaSへのWebアクセスは、プロキシサーバを経由せず各SD-WANルータを経由する。」
と明記されています。従来ログを保管していたプロキシサーバをバイパスするため、社内PCの利用状況はプロキシサーバでは捕捉できません。したがって、下線⑤のとおり「プロキシサーバからではなく、G社SaaSのAPIにアクセスして取得」する必要があります。 -
さらにG社SaaSについては
「出張先のPCから直接G社SaaSを利用できるようにするために、G社SaaSでは送信元IPアドレスの制限を行わない。」
とあるように、社外ネットワークから直接アクセスするケースが存在します。出張先PCの通信は企業ネットワークにもプロキシサーバにも到達しないため、API連携でSaaS側に保存されるログを取得しなければ行動を追跡できません。 -
以上より、APIでログを取得する主な理由は
・「社内PCからG社SaaSへのアクセスがプロキシサーバを経由しなくなる」
・「出張先PCなど社外端末のアクセスも記録できる」
の二点に整理でき、模範解答①②が導かれます。
誤りやすいポイント
- SD-WANルータを経由するだけで「FWで全てのログが捕捉できる」と誤解しやすい。FWで記録できるのは接続先IPなどのヘッダ情報が中心で、ユーザIDなどアプリ層のログはSaaS側APIが必要。
- 「プロキシ自動設定ファイル」を導入するのでプロキシログも残ると思い込みがち。自動設定ファイルは宛先によってプロキシを使い分けるため、SaaS宛通信は依然としてバイパスされる。
- 「送信元IPアドレスの制限を行わない」= セキュリティが弱いからこそプロキシログが要る、と短絡的に考えてしまう。ここでは可視化の観点が問われている。
FAQ
Q: APIで取得できるログには何が含まれますか?
A: 本文で例示された「アクセス先URLと利用者ID」「ファイルアップロード/ダウンロードのログと利用者ID」など、SaaSで内部的に保管される詳細な操作履歴が取得できます。
A: 本文で例示された「アクセス先URLと利用者ID」「ファイルアップロード/ダウンロードのログと利用者ID」など、SaaSで内部的に保管される詳細な操作履歴が取得できます。
Q: プロキシサーバを経由しない通信を完全に遮断する方法はありますか?
A: SD-WANのポリシーで強制的にプロキシを通す経路を設定できますが、本問では帯域・セッション数の課題解消を優先し、SaaS直行経路を採用しています。
A: SD-WANのポリシーで強制的にプロキシを通す経路を設定できますが、本問では帯域・セッション数の課題解消を優先し、SaaS直行経路を採用しています。
Q: 出張先PCのログもAPIで取得すると、社内外で重複記録になりませんか?
A: 直行経路の場合は重複しません。SaaS APIから一元的にダウンロードすることで、社内PC・出張先PCのアクセスを同じフォーマットで統合できます。
A: 直行経路の場合は重複しません。SaaS APIから一元的にダウンロードすることで、社内PC・出張先PCのアクセスを同じフォーマットで統合できます。
関連キーワード: SD-WAN, API連携, プロキシバイパス, ログ管理, SaaSセキュリティ




