平成25年度 秋期 午後Ⅱ（旧試験）

本文の根拠

〔マルウェアの検出〕

不審と判断したファイルを削除したり，OS 上で稼働するアプリケーションの自動起動設定を変更したりした。

表1 注1

各アプリケーションの実行履歴は取得していない。

図3

OS 起動時にマルウェア P が自動実行されるような設定が，9 月 26 日 12:28 に追加されていた。

M さんは，マルウェア P の駆除を確認した後，不審と判断したファイルを削除し，OS 上で稼働するアプリケーションの自動起動設定を変更した。この二つが解答例の行動①・行動②である（順不同）。

X 氏の調査は，コピーしたハードディスクに残る痕跡を手掛かりに進められた。図3のとおり，マルウェア P の自動実行設定が追加された日時や，PDF ファイルを開いた日時が痕跡として使われている。ところが表1の注1のとおり，PC はアプリケーションの実行履歴を取得していないので，ファイルや設定に残る情報が数少ない手掛かりになる。それを削除したり変更したりすると，感染経路や感染時刻を示す証跡が消えてしまう。これが理由である。

字数は，行動①が 17 字，行動②が 29 字（制限は各 35 字），理由が 23 字（制限 30 字）である。行動は“何を（ファイル／自動起動設定）どうした”を，理由は“調査に必要な証跡が消える”点を書く。“新たなソフトウェアのインストールを確認した”など，調査を妨げない行動を挙げないこと。

本文の根拠

〔マルウェアの検出〕

ウイルス対策ソフト V がマルウェア P を検出し，正常に駆除したことを示すメッセージが表示されていた。

〔マルウェアの検出〕

K 主任は，M さんの PC は以前からマルウェア P に感染していた可能性があり，このまま放置すれば被害が拡大する可能性があると判断した。

図2

C&C サーバから指令を受けて，任意のシェルコマンドを実行できる。

マルウェア P そのものは，ウイルス対策ソフト V がすでに検出して駆除している。それでも LAN ケーブルを抜く理由は，ウイルス対策ソフト V がまだ検出できていない別のマルウェアが PC で動作している可能性があるからである。解答例は“未検出のマルウェアが動作している可能性があるから”である。

M さんの PC は以前から感染していた可能性があり，その間の挙動を本人も把握できていない。図2のように，マルウェア P の仲間は C&C サーバから指令を受けて任意のシェルコマンドを実行できるので，駆除の確認だけでは他のマルウェアが入っていないとは言い切れない。ケーブルを抜けば，こうした未検出のマルウェアが C&C サーバと通信したり，社内の他の機器へ被害を広げたりすることを止められる。

字数は 24 字で，制限の 30 字に収まる。“マルウェア P が動作しているから”と書くと，駆除済みという本文の事実と食い違う（採点講評も，この点を指摘している）。“未検出”の語を入れ，P とは別のものであることを示す。

採点講評（IPA）

設問1(2)は，正答率が低かった。マルウェアPについて解答した受験者が多かったが，本設問で問うている時点では，マルウェアP自体は検出・駆除済であることを把握してほしかった。

本文の根拠

〔本社に対する調査〕

M さんの PC における設定が，バックアップされているかどうかを確認した

図3

OS 起動時にマルウェア P が自動実行されるような設定が，9 月 26 日 12:28 に追加されていた。

表1 注1

各アプリケーションの実行履歴は取得していない。

設定のバックアップがあれば，それは感染前の OS の状態を表す。X 氏は，感染後の PC とそのバックアップを比べることで，何が変更されたのかを知ろうとした。解答例は“マルウェア感染前後におけるOSの状態の差分を確認するため”である。

図3のとおり，マルウェア P が OS 起動時に自動実行されるように追加した設定のような変更は，感染前の状態が分かれば差分として見つけやすい。PC にはアプリケーションの実行履歴がなく，感染後の状態だけから変更点を判断するしかない状況だったので，バックアップの有無が重要になる。A 社では設定のバックアップを取得していなかった。

字数は 28 字で，制限の 30 字に収まる。“バックアップがあるか確認する”のような行為の言い換えではなく，“感染前後の OS の状態を比べる（差分）”という目的を書く。

本文の根拠

図6 8行目

Received: from [IP アドレス B.B.B.B] by gateway.freefree-web-mail.com via HTTP;

図6 2行目

with SMTP id r1K879qP001459 for <M-san@honsha.A-sha.co.jp>;

下線③

Web メールを利用してメールを送信した

答えは 8 行目である。Received ヘッダは，メールを中継するサーバが受け取るたびに，既存の行の上に付け足していく（RFC 5321 の 3.7.2 は，中継する側が Received 行を先頭に付け足し，既存の行は変更しないと定めている）。したがって図6では，行番号の大きい8行目が最初の経路，1行目が最後の経路にあたる。

1〜2行目と4〜6行目は，サーバ間が SMTP（with SMTP）で受け渡された記録である。これに対し8行目は，IP アドレス B.B.B.B のクライアントから gateway.freefree-web-mail.com へ via HTTP で受け取った記録であり，メールサーバに SMTP で届けたのではなく，ブラウザなどから HTTP で送信したことを示す。これが“Web メールを利用してメールを送信した”と判断する根拠である。

10行目の From 行は L さんの名前を騙った差出人の表示にすぎず，送信手段の根拠にはならない。12行目の Date 行や，17〜18行目の Content-Type などの行も，送信手段を示さない。行番号で答える設問なので，“8”とだけ書く。

本文の根拠

図7

http://C.C.C.C/config.bin への GET リクエスト

図7

当該サーバは稼働していないようであった。

a は 80 である。図7のログに現れる C.C.C.C への通信は，どれも http:// で始まる URL への GET・POST リクエストである。http の URL でポート番号が書かれていないときの既定のポートは TCP の 80 番である（RFC 9110 の 4.2.1）。上記の URL と同じ IP アドレスの 80 番ポートに，ブラウザで接続を試みたことになる。

下線④は，そのアクセスで得られるレスポンスを問う。本文は“当該サーバは稼働していないようであった”と書いている。解答群のうち 404 Not Found（RFC 9110 の 15.5.5）と 503 Service Unavailable（同 15.6.4）は，どちらも HTTP サーバが動作して返すステータスコードであり，204 No Content も同様にサーバが返す応答である。サーバが稼働していなければ HTTP の応答自体が返らないので，エの“レスポンスなし”が最も適切である。

記号を選ぶ設問である。ウの 503 を選びがちだが，503 は“サーバが今は要求を処理できない”ことを示すサーバからの応答であり，稼働していないサーバからは届かない。

本文の根拠

会話

PC から C&C サーバへの方向だけで HTTP リクエストが発生します。

図2

C&C サーバから指令を受けて，任意のシェルコマンドを実行できる。

会話

FW やプロキシを導入していても，インターネットから社内の PC を操作されてしまいますね。

HTTP は，クライアントがリクエストを送り，サーバがそれに対するレスポンスを返す仕組みである。マルウェア P は PC から C&C サーバへ HTTP リクエストを送る（図7の POST リクエストが5分おきに出る）だけで，C&C サーバは PC へ接続を始めない。それでも C&C サーバは，リクエストに対するレスポンスの中に指令を入れて返せば，PC に指令を届けられる。解答例は“HTTPレスポンス”である。

この方式では，FW が“社内から外へ”の通信を許可し，プロキシが PC からのリクエストを中継する限り，指令を含むレスポンスが戻ってくる。だから，インターネットからの通信を FW で制限していても，攻撃者は PC を操作できる。

字数は 9 字で，制限の 10 字に収まる。“HTTP リクエスト”と答えない（本文がすでに“HTTP リクエストが発生します”と書いていて，指令は逆向きの流れにある）。

本文の根拠

図10

9 月 25 日 14:10 に，N さんの PC から次の二つの URL にアクセスしていた

図10

9 月 25 日 14:11 に，http://C.C.C.C/config.bin に GET リクエストを送信していた。

図11 レスポンス1

<html><head></head><body><applet archive="exploit.jar" code="exploit.class" width="1" height="1"></applet></body></html>

X 氏は，N さんの PC 上で，感染のきっかけになった操作以降のファイルを調べたかった。図10では，9月25日14:10 に D.D.D.D の exploit.jar と exploit.class にアクセスし，その1分後の14:11 から C.C.C.C への通信（config.bin の GET，gate.php の POST）が始まっている。図11のとおり，D.D.D.D のページは Java アプレットとして exploit.jar と exploit.class を読み込ませる内容である。感染の起点はこの 14:10 の D.D.D.D へのアクセスである。解答例は“9月25日14:10”である。

14:11 としないのは，C.C.C.C への通信はすでに感染した後の動作であり，14:10 のアクセスの分のファイルが調査の範囲から外れてしまうからである。

日時なので字数制限は無い。“9月25日14:10”と，月日と時刻の両方を書く。

本文の根拠

図13

IP：192.168.1.254 MAC：e

会話

このような手口だと，f を利用してネットワークを構築していても盗聴されてしまいますね。

図12

OA-LAN 1 は L2SW で構成されており

d はア（ARP スプーフィング）である。図13は，L さんの PC の ARP テーブルで IP アドレス 192.168.1.254 に対応する MAC アドレスが e になっていることを示す。192.168.1.254 は L3SW の OA-LAN 1 側のインタフェースの IP アドレスで，通常は L3SW の MAC アドレスが入る。ARP は IP アドレスをイーサネットの MAC アドレスに対応づける仕組みで（RFC 826），受信した ARP パケットの送信元情報で，すでにある表の項目を上書きする。偽の ARP 応答で 192.168.1.254 の MAC アドレスを書き換えれば，L さんの PC は L3SW 宛ての通信を別の機器に送ってしまう。

f は，K 主任の言う“このような手口でも盗聴されてしまう”機器で，ウの L2SW である。図12の OA-LAN 1 は L2SW でできており，L2SW は宛先の MAC アドレスを見てフレームを転送するので，宛先 MAC アドレスを偽って自分宛てに送らせるこの手口なら，L2SW のネットワークでも盗聴できる。リピータやタップは，盗聴自体は容易な機器であって，この手口を要さない。

記号で答える設問である。IP スプーフィング（イ）は送信元 IP アドレスを偽る別の手口であり，MITB（エ）はブラウザ内で動作するマルウェアによる攻撃である。

本文の根拠

図12

N さんの PC（IP：192.168.1.2，MAC：xx:xx:xx:aa:bb:22）

図12

IP：192.168.1.254，MAC：xx:xx:xx:aa:bb:99

図13

IP：192.168.1.254 MAC：e

盗聴が成立しているときの L さんの PC の ARP テーブルでは，192.168.1.254 に，本来の L3SW の MAC アドレス（xx:xx:xx:aa:bb:99）ではなく，盗聴者である N さんの PC の MAC アドレスが入っている。図12から N さんの PC の MAC アドレスは xx:xx:xx:aa:bb:22 と読み取れるので，これが e の答えである。

図13の2行目に IP アドレス 192.168.1.2（N さんの PC 自身）の行が（略）として並んでいる点も，N さんの PC の MAC アドレスを答えると見当づける手掛かりになる。

17 字の英数字の MAC アドレスで，字数制限は無い。bb:22 と bb:99 の取り違えに注意する。N さんの PC は IP が 192.168.1.2，MAC の末尾が 22 である。

本文の根拠

図12

OA-LAN 1（192.168.1.0/24）

図12

L さんの PC（IP：192.168.1.1，MAC：xx:xx:xx:aa:bb:11）

図12

PC（IP：192.168.1.3，MAC：xx:xx:xx:aa:bb:33）〜PC（IP：192.168.1.253，MAC：xx:xx:xx:aa:bb:55）

ARP スプーフィングで盗聴できるのは，偽の ARP 応答を受け取る，同じ OA-LAN 1（192.168.1.0/24）に接続された PC の通信である。図12の OA-LAN 1 には，L さんの PC（192.168.1.1），N さんの PC（192.168.1.2），192.168.1.3〜192.168.1.253 の PC，L3SW のインタフェース（192.168.1.254）が接続されている。

このうち N さんの PC は盗聴する側なので，除く。L3SW の 192.168.1.254 も，N さんの PC が成りすます相手なので，除く。残る 192.168.1.1 と 192.168.1.3〜192.168.1.253 が，盗聴が成立するパケットの送信元である。解答例は“192.168.1.1，192.168.1.3～192.168.1.253”である。

ネットワークアドレスやブロードキャストアドレスを範囲に含めないこと。また，192.168.2.0/24 の OA-LAN 2 の PC は，L3SW を介して別のネットワークにいるので範囲に含まれない。

本文の根拠

表2 項番3

システム B を利用するとき，ブラウザで Java アプレットを実行するために利用

〔対策の検討〕

JRE はアップデート前に準備が必要です

JRE は，システム B を利用するときにブラウザで Java アプレットを実行するために使われている。新しいバージョンに更新したとたんに，システム B のアプレットが動かなくなる可能性がある。K 主任は“すぐに最新バージョンにアップデートできない”と O 部長に確認されている。更新の前に，最新バージョンの JRE でシステム B が正常に動作するかを確かめておく準備が必要である。解答例は“JREの最新バージョンにおけるシステムBの正常動作を確認すること”である。

PDF 閲覧ソフト W は，更新しても業務への影響が小さいと K 主任が述べているので，すぐに更新できる。JRE だけが，利用する業務システムとの組合せが問題になる。

字数は 32 字で，制限の 40 字に収まる。“更新する”や“バックアップをとる”ではなく，“最新バージョンの JRE で，システム B が正常に動作することを確認する”ことを書く。

本文の根拠

表3 項番1

HTTP リクエストの任意のヘッダのフィルタリング（現状は無効）

図11 リクエスト2

User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_21

図11 リクエスト1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

〔対策の検討〕

Java を必要とするケースは限られていますので

プロキシと UTM には，HTTP リクエストの任意のヘッダをフィルタリングする機能があるが，現状は無効である。User-Agent ヘッダはリクエストを送るクライアントに関する情報を示す（RFC 9110 の 10.1.5）。図11で，ブラウザが送ったリクエスト1の User-Agent は“MSIE 6.0”だが，JRE（Java）が exploit.jar を取りにいったリクエスト2と3の User-Agent には“Java/1.6.0_21”が付いている。そこで User-Agent の内容に“Java”が含まれるリクエストを，プロキシと UTM でフィルタリングすれば，JRE から外部へ出る Java の通信を止められる。解答例は“User-Agentヘッダの内容に文字列“Java”が含まれるリクエストをフィルタリングする。”である。

Java を必要とするのはシステム B などに限られるので，この対策による影響は小さい。表3のブラックリスト方式では，D.D.D.D のような新しい不正サイトの IP アドレスや URL が載っていなければ止められないが，ヘッダの内容によるフィルタリングなら，未知のサイトからの攻撃にも効く。

字数は 47 字で，制限の 55 字に収まる。ヘッダの名前（User-Agent）と，条件（文字列 Java を含む），動作（フィルタリング）の三つを入れる。

本文の根拠

表3 項番1

利用者認証機能（現状は無効）

図2

ブラウザのプロキシ設定を参照する。

〔対策の検討〕

マルウェア P も含め，多くのマルウェアと C&C サーバ間の通信には，HTTP が利用されています。

プロキシには利用者認証機能があるが，現状は無効である。これを有効にすると，利用者の認証を通らないリクエストはインターネットへ出られなくなる。マルウェア P はブラウザのプロキシ設定を参照してプロキシ経由で C&C サーバへ接続するので，利用者の認証情報を持たない状態で，プロキシに阻まれる。解答例は“プロキシで利用者の認証を有効にする。”である。

採点講評が述べるように，認証の方式やプロキシ製品の実装によって，マルウェアがブラウザの保存した認証情報を使うなどして通り抜けることもあり，万全の対策ではない。O 部長の“マルウェアがその対策をすり抜けてくる可能性も否定しきれない”という発言も，この点に当たる。

字数は 18 字で，制限の 25 字に収まる。“プロキシ”と“利用者の認証”の二つの語を入れる。“ホワイトリストにする”など，C&C サーバの宛先の側からの対策とは区別して答える。

採点講評（IPA）

設問4(3)は，正答率が低かった。プロキシサーバでの認証機能を用いる対策は，IPAが公開している“『標的型メール攻撃』対策に向けたシステム設計ガイド”内でも述べられている対策である。問題文中では，対策が万全ではない場合があることを記載しているが，実際のマルウェア対策を検討する上でも，各認証方式の違い，プロキシ製品やUTM製品における認証機能の実装の違い，また対策が有効なマルウェアの範囲についても理解して検討を進めてほしい。

本文の根拠

図12

N さんの PC（IP：192.168.1.2，MAC：xx:xx:xx:aa:bb:22）

図13

IP：192.168.1.254 MAC：e

〔対策の検討〕

PC 上のパーソナルファイアウォール機能を活用して，各 PC から他の機器への通信と，他の機器から各 PC への通信を，必要最小限に制限する

解答例は，設定を行う PC が N さんの PC，禁止する通信がインバウンド通信である。盗聴では，ARP スプーフィングにより L さんの PC が，192.168.1.254 宛てのフレームを N さんの PC の MAC アドレス宛てに送る。このフレームを受け取るのは N さんの PC であり，N さんの PC の側から見れば受信（インバウンド）の通信である。そこで N さんの PC のパーソナルファイアウォールでインバウンド通信を禁止すれば，L さんの PC から届く通信を受け取れなくなる。

L さんの PC で通信を禁止する方法もあり得るが，L さんの PC が行うべき通常のメールの送受信まで止めてしまうので，被害を受ける側の PC では適切でない。N さんの PC で禁止するのは，盗聴する側の通信に絞って止める方法である。アウトバウンドの禁止は，盗聴した内容を外へ送る通信を止める対策であって，盗聴そのものを止めない。

設定を行う PC と禁止する通信の二つの欄を，“NさんのPC”，“インバウンド通信”とそれぞれ答える。

本文の根拠

冒頭

スマートフォンから社内 Web サーバへのアクセスは認めないことにした。

案1 実現方式(2)

スマートフォンのメールクライアントからメールサーバにアクセスすることは禁止する。

案1 実現方式(1)

DMZ1 のネットワークセグメントの IP アドレスが割り当てられ，DMZ1 に接続されているのと同じように通信できる。

表4

DMZ1 → 社内 Web サーバ：HTTP。

表4

DMZ1 → メールサーバ：POP3。

案1では，スマートフォンもモバイル PC も VPN サーバ1に接続され，DMZ1 の IP アドレスが割り当てられて DMZ1 にいるのと同じように通信できる。表4のとおり FW2 は DMZ1 から社内 Web サーバ（HTTP，HTTP over TLS）とメールサーバ（POP3，SMTP）への通信を許可している。このため，スマートフォンから社内 Web サーバへのアクセス（機密情報があるので認めない）と，スマートフォンからメールサーバへのアクセス（メールクライアントでの利用は禁止，Web メールサーバ経由に限定）が技術的に可能になっている。これがアクセスの二つで，解答例は“スマートフォンから社内Webサーバへのアクセス”と“スマートフォンからメールサーバへのアクセス”である。

案2の対策は，図5と表5以降の記述から，二つに分かれる。一つは，DMZ2 を追加して VPN サーバ2と Web メールサーバを置き，スマートフォンとモバイル PC の通信経路を分離することである。もう一つは，FW4 でスマートフォンから社内 Web サーバ及びメールサーバへの通信を禁止することである。採点講評も，ファイアウォールのルールからスマートフォンとモバイル PC の用途ごとの通信経路を分離する必要があることを導いてほしかったと述べている。

字数は，アクセスが 23 字と 21 字（制限は各 25 字），対策が 43 字と 39 字（制限は各 50 字）である。アクセスは“何から何へ”を，対策は“経路の分離”と“FW4 での禁止”の二つを，一つずつ分けて書く。どちらか一方だけの解答にならないよう，二つの対策に分けて書き出す。

採点講評（IPA）

設問1(1)では，D社が認めていないアクセスを正しく識別できているのに，それを防ぐ対策を正確に記述できていない解答が多かった。ファイアウォールのルールから，モバイルPCとスマートフォンという二つの用途ごとに通信経路を分離する必要があることを導き出してほしかったが，どちらか一方の記述にとどまっている解答が多かった。また，ファイアウォールのルールとして，問題文中に記載されているWebメールサーバ及びVPNに関する条件を十分に理解していないと思われる解答も多かった。問題解決においては，対策が，与えられた条件を満たしているか，論理的な観点から検証する必要があることに注意してほしい。

本文の根拠

表3

Any → VPN サーバ1：L2TP over IPsec。

案1 実現方式(2)

Web メールサーバは，メールサーバに対してはメールクライアントとして動作し，スマートフォンに対してはアドレス帳とメールクライアントの機能を Web で提供する。

表4

DMZ1 → メールサーバ：POP3。

表4

DMZ1 → メールサーバ：SMTP。

FW3 は，図5でインターネットと DMZ2 の間にある。DMZ2 に置いた VPN サーバ2へスマートフォンが L2TP over IPsec で接続できるように，FW1 の表3の1行目（Any → VPN サーバ1）にならって，送信元 Any，宛先 VPN サーバ2，プロトコル L2TP over IPsec を許可する。解答例のとおり1つである。

FW4 は DMZ2 とサーバ LAN の間にある。スマートフォンは Web メールサーバにだけ接続でき，Web メールサーバがメールサーバに対してメールクライアントとして動作する。表4の DMZ1 → メールサーバの POP3・SMTP にならい，送信元 Web メールサーバ，宛先メールサーバで，プロトコル POP3 と SMTP の二つを許可する。

送信元を DMZ2 全体にすると，VPN サーバ2などからもメールサーバへの通信が通ってしまうので，送信元は Web メールサーバに絞る。採点講評は，ファイアウォールのルールとして Web メールサーバ及び VPN に関する条件の理解が不十分な解答が多かったと述べている。表4の記述形式（送信元・宛先・プロトコル）に合わせて書く。

本文の根拠

図2 6

盗難又は紛失の届出があった場合，VPN サーバ1の設定において当該利用者の VPN アカウントを停止する。

冒頭

VPN サーバに登録された利用者 ID とパスワード（以下，VPN 認証情報という）による利用者認証が行われる。

冒頭

全従業員にモバイル PC を1台ずつ貸与している。

案1では，スマートフォンの盗難・紛失のときに，VPN サーバ1でその利用者の VPN アカウントを停止する。ところが，従業員はモバイル PC でも同じ VPN サーバに，同じ VPN 認証情報でログインしている。そのため，アカウントを停止するとモバイル PC からも社内ネットワークに接続できなくなり，業務に支障が出る。これが問題である。

解決策は，スマートフォンとモバイル PC で別々の VPN アカウント（VPN 認証情報）を使うことである。スマートフォンのアカウントだけを停止すればよく，案2では VPN サーバ2をスマートフォン用に追加したことで，これを実現している。解答例は“スマートフォンで利用するVPNアカウントを，モバイルPCで利用するものと別に作成する。”である。

字数は，問題が 41 字，対策が 43 字で，どちらも制限の 50 字に収まる。問題は“アカウントを停止すると，モバイル PC が接続できなくなる”こと，対策は“アカウントを分ける”ことを書く。

本文の根拠

表1

ディジタル署名が付与されたアプリケーションは，H 社の安全性審査を受けることができる。

表1

アプリケーションの安全性審査及び導入時のディジタル署名の検証は行われない。

表5

C15. アプリケーションの安全性審査。

表5の対策のうち，C15（アプリケーションの安全性審査）だけは，D 社の管理が及ばない。表1のとおり，スマートフォン A のアプリケーションの安全性審査は H 社が行い，審査に合格したものだけが H 社ストアから提供される。スマートフォン B のアプリケーションには，安全性審査自体が行われない。いずれも，審査を行うかどうか，内容と実施は D 社ではなく，H 社や提供元が決める。

C1〜C4（FW・IPS・要塞化・診断・VPN），C5〜C8（デバイス保護・認証・アカウント停止），C9〜C14（保存禁止・フィルタ・転送禁止・更新・改造禁止），C16（導入元の限定），C17（ウイルス対策ソフト）は，D 社の設定や規程，従業員への手続で実施できる。

記号で答える設問である。“C15”と書く。C16 は“導入できる場所を限定する”D 社の規程であり，審査は行わないので，混同しないこと。

本文の根拠

〔リモートアクセス環境の改善〕

スマートフォンの通信料金を節約するために，携帯電話網を介したデータ通信を無効化して，無線 LAN 経由でリモートアクセスを行っている従業員が多い。

下線③

携帯電話網を介したデータ通信を用いて，スマートフォン及び外部記憶媒体に保存したデータを消去するサービス

〔リモートアクセス環境の改善〕

E エージェントと E サーバは，互いに TCP/IP のプロトコルで通信することによって，次の機能を提供する。

下線③のサービスは，携帯電話網を介したデータ通信で消去の指示を届ける。スマートフォンが携帯電話網のデータ通信を無効にし，無線 LAN だけでインターネットに接続している状態では，その指示を受け取れず，データを消去できない。一方，製品 E の E エージェントと E サーバは TCP/IP で通信するので，無線 LAN 経由でインターネットに接続していても消去できる。解答例は“携帯電話網を介さずにインターネットに接続されている状態”である。

アンケートで，通信料金を節約するために携帯電話網のデータ通信を無効にして無線 LAN だけを使う従業員が多いと分かっている。これが，製品 E で統一すべき理由として Z 主任が図5を示しながら説明した内容に当たる。

字数は 27 字で，制限の 30 字に収まる。採点講評がいう“二つの条件”は，携帯電話網を介さないことと，インターネットに接続されていることで，解答例の一文が両方を含んでいる。“携帯電話網を使っていない”だけでは，インターネットにつながっていない場合も含んでしまう。

採点講評（IPA）

設問2(1)は，正答率が低かった。製品E，携帯電話事業者のサービスのそれぞれでのデータ消去に必要な条件の違いから，製品Eでないとデータ消去が行えない二つの条件を導き出してほしかったが，一方の条件の記述にとどまっている解答や，条件を正確に記述できていない解答が多かった。解答においては，与えられた条件を理解し，論理的に考えて解答を記述してほしい。

本文の根拠

表2 クラウドサービスの利用

一部の機種は，デフォルトの状態で自動同期機能が有効になっている。

冒頭

D 社の管理及び規程が及ばないサービス又はシステム，例えば，クラウドコンピューティングサービス（以下，クラウドサービスという）によって提供されるサービス，オンラインストレージサービス，ファイル共有システムなどを利用して保管することは禁止されている。

〔リモートアクセス環境の改善〕

スマートフォン利用手続にスマートフォンの設定について項目を追加すること

D 社は，業務データをクラウドサービスなど D 社の管理及び規程が及ばないものに保管することを禁止している。表2のとおり，スマートフォンには，電話帳・メール・文書ファイルなどを，利用者が意識しないままクラウドサービスのサーバへ定期的にコピーする自動同期機能がある。一部の機種ではこれが初期状態で有効なので，従業員が何もしなくても業務データが社外のクラウドサービスに送られ，業務データ取扱事項に違反してしまう。これが“仕様”である。解答例は“一部の機種では，デフォルト設定の状態で自動同期機能が有効になっている。”である（表2の文は“デフォルトの状態で”と書かれている）。

そこで，スマートフォン利用手続に追加する項目は，自動同期機能を無効にする設定を行うことである。その設定を製品 E の機能で監視する，というのが Z 主任のアドバイスである。解答例は“自動同期機能を無効にする。”である。

字数は，仕様が 35 字（制限 40 字），内容が 13 字（制限 20 字）である。“自動同期機能が”“デフォルトで有効”の二つを入れる。表2の機能そのものの説明にとどめず，違反の原因になる“初期状態で有効”の点を書く。

採点講評（IPA）

設問2(2)は，正答率が低かった。問題文中に記載されている条件から，原因となるスマートフォンの仕様を識別してほしかったが，原因となる仕様を，正しく識別できていない又は正確に記載できていない解答が多かった。要件や制約を抽出及び整理し，正確に記述する必要があることを再認識してほしい。

本文の根拠

〔リモートアクセス環境の改善〕

デバイス保護機能の設定及びスマートフォンの設定の監視と強制

〔リモートアクセス環境の改善〕

改造されたスマートフォンの検知

図6 1

製品 F が導入・設定されていることを，製品 E によって監視する。

図6 2

古い OS 又はアプリケーションを利用しているスマートフォン，若しくは安全性が疑わしいアプリケーションを導入しているスマートフォンを，製品 E によって検知する。

案2で従業員が行う対策は，次の六つである。C5（デバイス保護機能の設定），C12（最新の OS の利用），C13（最新のアプリケーションの利用），C14（改造の禁止），C16（H 社ストア・T 社ストア・携帯電話事業者の Web サイト以外からの導入の禁止），C17（ウイルス対策ソフトの導入・設定）。それぞれ製品 E の機能で情報システム部が監視できる。C5 はデバイス保護機能の設定の監視と強制，C14 は改造されたスマートフォンの検知，C12・C13 は OS・アプリケーションの名称とバージョンの取得，C16 は導入しているアプリケーションの取得，C17 は図6の1の製品 F の導入・設定の監視である。

C10（のぞき見防止フィルタ）は従業員が画面に貼るもので，製品 E の機能では確認できない。C9 は Web メールサーバの設定で，C8 は情報システム部が VPN アカウントを停止する対策であり，従業員の行う対策ではない。C11 の転送の禁止は従業員への規程であり，製品 E が監視する機能は挙げられていない。

全て選ぶ設問なので，“C5，C12，C13，C14，C16，C17”のように並べる。1つでも欠けると誤りになる。

本文の根拠

図6 5

当該従業員は，スマートフォン及び外部記憶媒体に保管された全データを消去する。

〔同意書の検討〕

D 社として，消去されるデータを具体的に示した上で従業員から事前に同意を得ておく必要がある

案1 利用手続

個人所有のスマートフォン A 又は B を業務に利用することを選択した従業員は

スマートフォンは従業員の個人所有で，電話帳・メール・画像などの個人のデータも入っている。製品 E によるデータ消去は，図6の5のとおり盗難又は紛失の届出があったときに，スマートフォン及び外部記憶媒体に保管された“全データ”を消去する。業務データだけでなく個人のデータも消えるので，D 社として，消去されるデータを具体的に示した上で，従業員の事前の同意を得ておく必要がある。解答例は“スマートフォンの盗難又は紛失の届出があったときに，従業員個人のデータも消去されること”である。

同意の対象は，いつ（盗難又は紛失の届出があったとき）と，何が（従業員個人のデータも）消去されるかの二つである。

字数は 42 字で，制限の 50 字に収まる。“全データが消去される”とだけ書かず，“個人のデータも消える”点，及び“盗難・紛失の届出があったとき”という条件を入れる。