平成24年度 秋期 午後Ⅰ（旧試験）

本文の根拠

〔インターネット Web サイトのサービス向上策の検討〕

を利用する HTML ファイル群をブラウザがダウンロードして実行すると，非同期的又は同期的に Web サーバにアクセスし，そのレスポンスデータを用いて Web ページを更新することができる。

〔インターネット Web サイトのサービス向上策の検討〕

FQDN，プロトコル又はポート番号のいずれかが，ダウンロードしたものと異なる URI にはアクセスできず

a は，Ajax で“非同期的又は同期的に Web サーバにアクセスし，そのレスポンスデータを用いて Web ページを更新する”ために HTML ファイル群が利用するものである。解答群の中でこの働きをもつのは XMLHttpRequest（エ）で，ブラウザのスクリプトから HTTP リクエストを発行するための API である。b は，“FQDN，プロトコル又はポート番号のいずれかが，ダウンロードしたものと異なる URI にはアクセスできず”という制限をかけるポリシである。RFC 6454 は，オリジンを（スキーム，ホスト，ポート）の三つ組と定め，三つ組が全て同じときだけ同一オリジンとしている。本文の“3 要素”はこの三つ組に当たり，ポリシの名は Same-Origin（ウ）である。

本文は a の制限を受けるために，JSONP を使って“上記の 3 要素のいずれかが異なる URI からでもデータを取得する”方法を検討している。つまり b は，a によるアクセスの範囲を制限するポリシでなければならない。

この設問は記号で答える。誤りの選択肢は，APT（ア）が標的型攻撃の呼び名，ATM（イ）が現金自動預払機あるいは通信方式の名，アノニマス（オ）が匿名を指す語，プライバシ（カ）は個人情報の取扱いの考え方で，いずれも，ブラウザがアクセス先の URI の 3 要素を制限する話ではない。講評は，a の正答率は高く，b の正答率が低かったと述べている。a の語は知っていても，b のブラウザ側の制限まで知らない受験者が多かった。

採点講評（IPA）

設問1のaについては正答率が高かったが，bについては，正答率が低かった。XMLHttpRequestという用語は知っていても，その制限までは知らない受験者が多いようだった。是非，最新のブラウザの仕組みを知っておいてほしい。

本文の根拠

〔A 社のインターネット Web サイトの概要〕

会員サイトは個人情報を扱うことから，①サーバ認証による HTTPS を採用し，その上でのフォームを用いた利用者認証を行っている。

〔A 社のインターネット Web サイトの概要〕

利用者 ID とパスワードによる利用者認証が求められ，認証に成功すると，会員サイトにアクセスできるようになる。

下線①の方式は，サーバ認証だけを行う HTTPS で通信路を暗号化し，利用者の認証は利用者 ID とパスワードをフォームから入力して行う。SSL のクライアント認証は，利用者側もクライアント証明書を提示して認証する方式なので，会員一人ひとりに証明書を発行し，会員が自分のブラウザに導入する必要がある。

本文の会員は“事前に登録した会員”で，手軽に注文できることを売りにしている。証明書の発行と導入を会員に求めないで済むことが，下線①の方式の利点であり，解答例は“利用者がクライアント証明書を用意する必要がない。”とする。講評も，サーバ認証ではサーバ証明書だけを用意すればよいのに対し，クライアント認証では利用者ごとに証明書の管理が必要になることに気付いてほしかったと述べている。

25 字以内の指定に対し，解答例は 24 字。“安全である”“手軽である”のように抽象的に書くのではなく，クライアント認証と比べて何が不要になるかを書く。

採点講評（IPA）

設問2は正答率が低かった。HTTPS通信において，サーバ認証の場合，サーバだけの認証であるので，サーバ証明書だけを用意すればよいのに対して，クライアント認証の場合，相互認証であるので，利用者ごとにクライアント証明書の管理が必要となることに気がついてほしかった。

本文の根拠

〔セキュリティに関する検討〕

ポイント表示サービスの仕組みの場合， c から送られる d が，会員の個人情報を含む。

図 1

(4) JSONP 型データ（図 3）が，会員の利用者 ID（user1）用に動的に生成され，ブラウザに送られる（会員サイトからブラウザへ）。

図 1 の(4)で，JSONP 型データを生成してブラウザに送るのは会員サイトで，その中身は図 3 のとおり，氏名のほか誕生日・住所・電話番号を含む。したがって c は会員サイトである。e は，図 4 のステップ 1)で c にアクセスして d を取得する側，つまり悪意ある JSONP 呼出しスクリプトを実行する主体で，スクリプトは会員のブラウザ上で動くので“ブラウザ”になる。

攻撃者のサーバが直接会員サイトにアクセスするのではない点が要になる。悪意ある Web サイトにアクセスした会員のブラウザがスクリプトを実行し，会員サイトにアクセスして JSONP 型データを取得したうえで，個人情報を抽出して悪意ある Web サイトに転送する（図 4 のステップ 2））。

字数制限の無い設問なので，c は 5 字の“会員サイト”，e は 4 字の“ブラウザ”を答える。c を“一般サイト”とすると，図 1 の(4)の送信元を取り違えている。

本文の根拠

〔A 社のインターネット Web サイトの概要〕

クッキーの有効期限が切れるか，利用者がログアウトした後は，当該ブラウザから会員サイトにアクセスできなくなり，再び利用者認証を求められる。

図 1

(1) 会員サイトにログインした後，ブラウザから一般サイトのトップページにアクセスする。

ポイント表示サービスの JSONP 型データは，ブラウザが会員サイトにログインした状態のとき，“会員の利用者 ID（user1）用に動的に生成”される。悪意ある Web サイトのスクリプトから会員サイトへの JSONP 呼出しが行われても，ブラウザが会員サイトにログインしたままで，クッキーが有効なら，会員サイトは正規のリクエストと同様にデータを返す。逆に，本文は“クッキーの有効期限が切れるか，利用者がログアウトした後は，当該ブラウザから会員サイトにアクセスできなくなり”と書いており，ログインしていなければ個人情報は渡らない。

したがって下線②の条件は，悪意ある JSONP 呼出しスクリプトを実行するブラウザが，会員サイトにログインした状態であること。解答例は“悪意あるJSONP呼出しスクリプトを実行するブラウザが，会員サイトにログインした状態である場合”の 47 字（50 字以内）。

“本文に即して”という指定なので，ログインとクッキーの有効期限という本文の語を使って書く。“脆弱性がある場合”のような一般論では条件にならない。

本文の根拠

図 3

putUserData({name:"user1", thisMonthPoint:39, totalPoint:1221, birth:"1978/3/15", address:"user1 の住所", telephone:"029-xxx-yyyy"});

〔セキュリティに関する検討〕

ポイント表示サービスの仕組みの場合， c から送られる d が，会員の個人情報を含む。

c から送られ，会員の個人情報を含み，図 4 のステップ 2)で個人情報を抽出される対象は，図 3 に示された“JSONP型データ”である。図 3 は，表示に使う氏名・ポイントのほかに，誕生日・住所・電話番号まで含んでいる。表示に不要な個人情報も同じデータに入っているので，これを取得されると個人情報が漏えいする。

“具体的に”という指定は，“データ”“情報”のような広い語では足りないという意味で，本文・図中で使われている名称の“JSONP型データ”と書けばよい。

10 字以内に対し，解答例は 9 字。“個人情報”のように中身で書くと，“c から送られる d”というデータそのものの名前にならない。

本文の根拠

図 5

リクエストの HTTP ヘッダに埋め込んである認証情報を確認する。認証情報とは，そのリクエストが f からのアクセスであることを確認できるものである。

〔セキュリティに関する検討〕

一般サイトで“トップページへのアクセスのリクエストが f からのアクセス”という情報が必要になる。

図 5 の(1)は，JSONP 型データを送る前にリクエストが正規のものであることを確認する対策で，確認に使う認証情報とは，そのリクエストが“認証された利用者”からのものであることを確認できるものである。ポイント表示サービスの場合，会員サイトは，一般サイトのトップページにアクセスした利用者が会員サイトで認証済みであることを知る必要があり，そのために一般サイトで“トップページへのアクセスのリクエストが認証された利用者からのアクセス”という情報が必要になる。

本文は，一般サイトと会員サイトの運用管理会社が違うので実現方法の検討に期間を要するとして，この対策を見送っている。講評も，攻撃を防ぐには，トップページへのアクセスの際，正規に認証されていることを一般サイト側に知らせる仕組みが必要だと述べている。

10 字以内に対し，解答例は 8 字。“会員”だけでは，ログイン済みかどうかが読み取れない。

採点講評（IPA）

設問4(1)は，正答率が低かった。この問題は，攻撃に対する一般的な対策方針に基づき安全なポイント表示サービスを設計する問題であった。攻撃を防ぐためには，トップページへのアクセスの際，正規に認証されていることを一般サイト側に知らせる仕組みが必要であることに気がついてほしかった。

本文の根拠

〔セキュリティに関する検討〕

A 社の Web サイトは様々な環境の利用者を想定していることから，Referer ヘッダの情報がサーバに g というケースもあり得るので

図 5

JSONP 型データをリクエストする直前に特定のページにアクセスしていたことを Referer ヘッダで確認する。

図 5 の(2)は，Referer ヘッダに特定のページが入っていることを確認して正規のリクエストと判断する対策である。ところが本文は，A 社の Web サイトは“様々な環境の利用者を想定している”ので，Referer ヘッダの情報がサーバに届かないケースもあり得て，その場合は正規のリクエストか否かを区別できないと述べている。g に入る語は，Referer ヘッダの情報がサーバに“送信されない”である。

Referer ヘッダの情報を前提にすると，情報が無いリクエストを正規とも不正とも区別できず，サービスを実現できない利用者が出る。そのため，この対策も見送られている。

10 字以内に対し，解答例は 6 字。“ない”だけでは，サーバに届かない（送信されない）という意味が出ない。

本文の根拠

表 3 の前の段落

続いて，E 課長は，①営業部の F 部長にヒアリングを行い，ログから不審な利用者 ID を抽出するための条件（以下，モニタリング条件という）を検討し，表 3 にまとめた。

表 3 条件 2

1 週間で，8000 番台の機能の利用成功回数が 50 回を超えた利用者 ID

表 1 から分かるのは，どのイベントでどの項目のログが取れているかまでで，業務で個人情報にどれだけアクセスするのかは分からない。条件 2 の“50 回”のように，不審な利用と業務目的の利用との境目になる値は，業務の実態を知る営業部の F 部長にヒアリングしなければ決められない。ヒアリングを行わなかった場合に表 3 を作る上で不足する情報は，個人情報へのアクセス頻度の上限のような，業務で必要になるアクセスの具体的な値である。

本文では，表 3 の条件でログを分析してもどの条件にも合致する利用者 ID が見つからず，後に新サービスの担当者が毎週 200 回近くアクセスして条件 2 に該当している。業務の実態が変わると，業務上必要なアクセス頻度も変わることがこの流れから分かる。

25 字以内に対し，解答例は 24 字。“業務の情報”のような言い方では何が足りないのかが伝わらないので，アクセス頻度の上限という具体的な内容まで書く。

採点講評（IPA）

設問1は，全体的に正答率が高かった。システムが採取しているログとモニタリングの要件を基に，機械処理可能なモニタリング条件を決定していく手順は，おおむね理解されているようであった。

本文の根拠

表 2 エ

無権限者が，自分の利用者 ID を用いて，個人情報へのアクセスを試みる。

表 1 注 1)

利用権限のない機能もメニューに表示される。選択しても利用できず，ログが取得される。

表 1 注記 1

個人情報にアクセスする機能の機能番号は，8000 番台である。

条件 4 は，表 2 のエ（無権限者が個人情報へのアクセスを試みる）に対応する。無権限者は個人情報にアクセスする権限をもたないので，個人情報にアクセスする機能（8000 番台）を選んでも利用できず，表 1 の“ログインとログアウト以外の機能の利用失敗”のログが残る。機能番号は 8000 番台，結果は失敗(0)である。

表 1 の注 1)は，利用権限のない機能もメニューに表示されると書いており，無権限者が個人情報の機能を選べば失敗のログが取れることを裏付けている。無権限者による試みは 1 回でも不審とすべきなので，条件 1 のような“3 回以上”ではなく，“1 回以上”とする。

解答例は“8000番台の機能の利用失敗回数が1回以上”の 21 字（25 字以内）。“利用失敗”だけでは 7000 番台の集計機能の失敗も含まれてしまうので，機能番号の範囲まで書く。

採点講評（IPA）

設問1は，全体的に正答率が高かった。システムが採取しているログとモニタリングの要件を基に，機械処理可能なモニタリング条件を決定していく手順は，おおむね理解されているようであった。

本文の根拠

図 1 手順 2

利用者 ID が B システムに登録されていない場合は，関係するログに記録されている端末 ID をもつ端末を貸与されている従業員を，調査の対象とする

表 1

ログイン失敗：日付，時刻，機能番号(0001)，端末 ID，ログインしようとした利用者 ID，失敗(0)。

利用者 ID が B システムに登録されていないのは，推測した利用者 ID でログインを試みた場合（表 2 のア）である。表 1 で，利用者 ID が登録されているとは限らないのは“ログイン失敗”のログだけで，取得する情報が“ログインしようとした利用者 ID”になっている。他のイベントの利用者 ID は，ログインに成功した利用者のものなので登録されている。

登録されていない利用者 ID のログには，端末 ID が記録されているので，その端末を貸与されている従業員を調査の対象にできる。

表 1 のイベントから選ぶ設問で字数制限は無い。解答例は“ログイン失敗”。“ログイン成功”と書くと，ログイン成功で記録される利用者 ID は有権限者・無権限者のどちらでも登録済みであることを見落としている。

採点講評（IPA）

設問1は，全体的に正答率が高かった。システムが採取しているログとモニタリングの要件を基に，機械処理可能なモニタリング条件を決定していく手順は，おおむね理解されているようであった。

本文の根拠

〔モニタリングの実施〕

D 部長は，③モニタリングの実施を社内に通達するよう指示した。

〔モニタリングの実施〕

④モニタリング条件はセキュリティ上の懸念から開示しないよう指示した。

モニタリングの実施を通達すると，従業員は自分のアクセスが監視されていることを知る。条件そのものは開示されないが，個人情報の持出しや不審なアクセスは見つかるかもしれないと意識するので，悪意ある行動を思いとどまらせる効果がある。内部の者による不正は，発覚するリスクが高いと感じさせることで抑えられる。

本文は，モニタリングを“個人情報漏えいにつながるような不審な利用がないか，その予兆も含めて”確認するプロセスと位置づけている。通達は，検知するだけでなく，不正を起こしにくくする働きをもたせるための指示である。

20 字以内に対し，解答例は 13 字。“不正を発見できる”と書くと，モニタリング自体の効果であり，通達の効果にならない。

採点講評（IPA）

設問2では，モニタリング条件の設定とその運用について出題した。条件を正確に記述している解答は少なかった。モニタリングを適切に実装・運用するためには，モニタリングの対象とするシステムの利用パターンを，モニタリング条件として正確に定義できる力が必要である。

本文の根拠

〔モニタリングの実施〕

④モニタリング条件はセキュリティ上の懸念から開示しないよう指示した。

表 3

1 週間で，22 時～翌日 6 時に 8000 番台の機能の利用成功回数が 1 回以上の利用者 ID

モニタリング条件は，“1 週間で 50 回を超えた”“22 時～翌日 6 時に 1 回以上”のように，不審な利用と判定する具体的な数値や時間帯を定めたものである。この条件が従業員に知られると，悪意ある者は条件に当てはまらない範囲に収めるようにして，個人情報へのアクセスを繰り返すことができる。解答例は，“モニタリング条件を回避するようにして悪意ある行動をとられること”。

通達（下線③）はモニタリングの実施を知らせて抑止効果を狙い，条件の開示（下線④）はそれと逆に，条件を回避する行動を助けてしまうため，条件だけは知らせないという分け方である。

40 字以内に対し，解答例は 31 字。“情報が漏れる”のように条件の中身と関係の無い一般論ではなく，条件を知った者がどう動くかまで書く。

採点講評（IPA）

設問2では，モニタリング条件の設定とその運用について出題した。条件を正確に記述している解答は少なかった。モニタリングを適切に実装・運用するためには，モニタリングの対象とするシステムの利用パターンを，モニタリング条件として正確に定義できる力が必要である。

本文の根拠

〔モニタリングの実施〕

4 名は，新サービスを行うために，1 人当たり毎週 200 回近く個人情報にアクセスすることになった。

〔モニタリングの実施〕

E 課長は，条件 2 の利用成功回数のしきい値を 50 回から 200 回に引き上げることを D 部長に提案した。

表 3 条件 2

1 週間で，8000 番台の機能の利用成功回数が 50 回を超えた利用者 ID

しきい値を 50 回から 200 回に引き上げると，条件 2 は“1 週間で 200 回を超えた”利用者 ID を抽出することになり，抽出されなくなるのは，新サービス担当の 4 名の毎週 200 回近いアクセスだけでなく，週に 50 回を超え 200 回以下のアクセスの全てである。有権限者のうち，新サービスの担当者以外が，その範囲の頻度で業務目的外に個人情報にアクセスしても検出されない。

本文の“字句を用いて”という指定に沿って，“新サービス担当の 4 名以外の従業員”“1 週間で 50 回を超えて 200 回以下”“個人情報へのアクセス”を入れる。解答例は“新サービス担当の4名以外の従業員が1週間で50回を超えて200回以下の頻度で個人情報へのアクセスを行った場合”の 54 字（60 字以内）。

“200 回以下”のように範囲の上限も書く。“条件を超える頻度で”だけでは，どの従業員のどの頻度が見逃されるのかが分からない。

採点講評（IPA）

設問2では，モニタリング条件の設定とその運用について出題した。条件を正確に記述している解答は少なかった。モニタリングを適切に実装・運用するためには，モニタリングの対象とするシステムの利用パターンを，モニタリング条件として正確に定義できる力が必要である。

本文の根拠

表 4

条件 2′：b，かつ，8000 番台の機能の利用成功回数が前の週に比べて 2 倍以上の利用者 ID，イ。

表 3 条件 2

1 週間で，8000 番台の機能の利用成功回数が 50 回を超えた利用者 ID

条件 2′は，条件 2（利用成功回数が 50 回を超えた）に，“前の週に比べて 2 倍以上”という変化の条件を加えたものである。毎週 200 回近くアクセスする新サービスの担当者は，毎週同じ頻度なので“2 倍以上”に当たらず，抽出されなくなる。一方，しきい値を 200 回にする案とは違って，週に 50 回を超えていれば，業務で急にアクセスを増やした者は抽出される。

そのため b には，元の条件 2 の“1週間で，8000番台の機能の利用成功が50回を超え”という，頻度の下限を入れる。“超え”で終わるのは，後ろに“かつ，…2 倍以上の”と続くためである。解答例は 26 字（30 字以内）。

“50 回”の数値と“8000 番台の機能の利用成功”を落とさない。“アクセスが多い”のような書き方では，機械処理が可能な条件にならない。

採点講評（IPA）

設問2では，モニタリング条件の設定とその運用について出題した。条件を正確に記述している解答は少なかった。モニタリングを適切に実装・運用するためには，モニタリングの対象とするシステムの利用パターンを，モニタリング条件として正確に定義できる力が必要である。

本文の根拠

〔モニタリングの実施〕

営業部の業務は今後も変化していくと考えられる。今回は，ヒアリングの実施件数が急増したことでモニタリング条件を見直すことになったが，モニタリング条件の見直しをせずにいると，モニタリングが有効に機能しなくなったり，非効率になったりすることがある

表 3 の前の段落

続いて，E 課長は，①営業部の F 部長にヒアリングを行い

本文は，条件を見直さないと，モニタリングが有効に機能しなくなったり，非効率になったりすると述べている。業務の変化に気付いて条件を見直すには，業務の実態を知る営業部の部長から，業務内容の変化を継続的に聞く必要がある。表 3 を作るときのヒアリング（下線①）を，一度で終わらせず定期的に行い，変化があれば条件を見直す。

今回は 4 名の異動をきっかけにヒアリングの件数が急増してから見直したが，施策は，こうした変化に後追いにならないようにするものである。講評も，モニタリング条件の見直しに利用部門が協力する点に言及している解答は少なかったと述べている。

50 字以内に対し，解答例は 48 字。“定期的に”“営業部の部長”“ヒアリング”“条件の見直し”の 4 点を入れる。“ログを分析する”だけでは，条件の見直しという施策にならない。

採点講評（IPA）

設問3では，モニタリングの有効性と効率性を維持するための施策について出題した。モニタリング条件の見直しに利用部門が協力する点について言及している解答は少なかった。

本文の根拠

図 3

Received: from smtp.y-sha.co.jp (unknown [80.◎◎.◇◇.☆☆])

図 3

for <a-kun@z-sha.co.jp>; Fri, 27 Jan 2012 9:37:58 +0100 (CET)

〔不審なメールへの対応〕

なお，Y 社は，メールサーバを含む情報システムを国内で運用している。

図 3 の Received ヘッダは，メールを受けたサーバが自分の側から見た相手を書き足していくものである。Z 社の MX1 が付けた行は，送信元を“smtp.y-sha.co.jp (unknown [80.◎◎.◇◇.☆☆])”としており，DNS で IP アドレスから名前を引けず（unknown），しかもその IP アドレスは 80 で始まっている。Y 社の情報システムは国内で運用されているはずなのに，メールサーバのアドレスが Y 社のものではなく，DNS 参照も unknown になっている点が不審で，a はウである。

もう一つは日時の書き方で，Y 社の最初の行は“+0100 (CET)”と，日本標準時の +0900 (JST) ではない海外のタイムゾーンになっている。国内で運用しているはずのサーバのタイムゾーンが海外になっている点が不審で，b はアである。本文は，b について“経由するサーバの設定が必ずしも正しいとは限らない”と書いており，サーバのタイムゾーンの設定は管理者次第であることとも合う。

この設問は記号で答える。イは Y 社と Z 社の間に中継サーバを経由した記録が無いと言うが，ヘッダには Y 社内の mail と smtp，Z 社の mx1 と mx2 の行がある。エは Z 社側の NAT 変換を言うが，ヘッダにはそのような記録は無い。講評は，選択問題にもかかわらず正答率が低かったと述べている。

採点講評（IPA）

設問1ではメールヘッダから読み取れる内容について出題した。選択問題にもかかわらず，正答率は低かった。普段から電子メールが届く経路がメールヘッダにどのように記録されるかを理解しておいてほしい。

本文の根拠

〔メールアドレスの偽装と対策〕の会話

受信側のメールサーバが， c 中の SMTP の d コマンドの引数で指定されたアイデンティティのうちドメイン名の部分を基に，DNS サーバに問合せを行い，SMTP 接続元の IP アドレスと比較します。

図 3

Return-Path: <b-shi@y-sha.co.jp>

SMTP では，メールは“エンベロープ”と“内容（ヘッダとボディ）”に分かれる（RFC 5321 2.3.1）。エンベロープは SMTP のコマンドで送られる送信者・受信者のアドレスで，内容は DATA で送られる。送信ドメイン認証の SPF は，エンベロープの送信者アドレスが指す MAIL FROM のドメインを基に DNS の SPF レコードを引き，接続元の IP アドレスが許可されたものかを検証する（RFC 7208）。したがって c はメールエンベロープ（オ），d は MAIL FROM（イ）。

図 3 の From のように，メールの内容（ヘッダ・ボディ）に書かれた送信者アドレスは，エンベロープの MAIL FROM とは別に書かれているので，SPF の検証の対象は MAIL FROM の側になる。

この設問は記号で答える。RCPT TO（ウ）は受信者の指定，VRFY（エ）はアドレスの確認，EXPN（ア）はメーリングリストの展開に使うコマンドで，いずれも送信者のドメインを検証する情報にならない。メールボディ（カ）は，エンベロープではなく内容の側である。講評は，(1)の正答率は高かったと述べている。

採点講評（IPA）

設問2では送信ドメイン認証技術のSPF（Sender Policy Framework）について出題した。(1)は正答率が高かったが，(2)は正答率が低かった。SPFのような標準的な技術については，何を基準にしているか，何をどのように確認しているか基本事項を理解しておいてほしい。

本文の根拠

図 2 FW

社内とインターネットとの間の通信には，グローバル IP アドレス z.y.x.1 を NAT アドレスとして使用する。

図 2 FW

MX1 とインターネットとの間のメール転送

図 4

z-sha.co.jp. IN TXT "v=spf1 +ip4:e -all"

図 4 の TXT レコードは SPF レコードで，“v=spf1”が SPF のバージョン，“+ip4:”はその IPv4 アドレスからの送信を許可（pass）し，“-all”は上に挙げたもの以外を全て不許可（fail）にすることを表す（RFC 7208）。SPF レコードは DNS の TXT レコードとして公開される。e には，Z 社のメールを送信するサーバが，インターネット側から見えるアドレスを入れる。

Z 社の社外とのメール転送は，図 2 のとおり MX1 だけが行い，社内とインターネットとの通信には“グローバル IP アドレス z.y.x.1 を NAT アドレスとして使用する”。受信側の SMTP 接続元の IP アドレスは，MX1 の私的アドレスではなく，NAT 後の z.y.x.1 になるので，e は z.y.x.1。

図 1〜3 から選ぶ設問で字数制限は無い。図 3 の □□.△△.○○.▽▽ のように伏せ字になったアドレスと取り違えないよう，図 2 の NAT アドレスの記述を探す。当社のメールサーバの設定変更が不要なのは，この DNS の登録だけで済むためである。

採点講評（IPA）

設問2では送信ドメイン認証技術のSPF（Sender Policy Framework）について出題した。(1)は正答率が高かったが，(2)は正答率が低かった。SPFのような標準的な技術については，何を基準にしているか，何をどのように確認しているか基本事項を理解しておいてほしい。

本文の根拠

〔メールアドレスの偽装と対策〕

そのメールには添付ファイルはなかったが，本文に社外サイトへのリンクが記入されていた。A 君がリンクをたどったところ，やはり心当たりのない社外サイトであった。

〔標的型攻撃への対策〕

今回の Y 社情報システム部からの問合せメールについては，①A 君の対応は不適切でした。

A 君は，Y 社情報システム部からの問合せメールに添付されていたメールを開いたところ，本文に書かれた社外サイトへのリンクをたどってしまっている。本文は，その社外サイトを“心当たりのない”ものと書いており，不審なメールの中のリンクをたどることは，ウイルスに感染させるサイトなどに誘導される危険がある。S 主任は“Y 社からの問合せなので油断したのかもしれません”と述べている。

添付されていたメールを不用意に開いた点以外という指定なので，リンクをたどった点だけを答える。解答例は“メール中の社外サイトのリンクをたどった”の 19 字（20 字以内）。

“セキュリティデスクに報告しなかった”とは書かない。本文は，A 君はこの事態をセキュリティデスクに通報したと述べている。講評は，(1)の正答率は高かったと述べている。

採点講評（IPA）

設問3では標的型攻撃について出題した。(1)の正答率は高かったが，(3)，(4)の正答率は低かった。(4)では，現在，一般的な製品になっているWebフィルタを利用する対策の記述を期待したが，正答率は低かった。

設問3(1)，(3)は，問題文中に記述されている内容を落ち着いて読めば，正解を導けるはずである。設問3(2)，(4)は，それぞれ問題文中に記述されている状況での対策を問うているので，問題文中の背景をしっかり理解して正解を導きだしてほしい。IPAが公開して“安全なウェブサイトの作り方”で扱っているように脆弱性を作りこまない根本的な対策を確実にすることだけではなく，攻撃による影響を軽減する保険的対策も有効なことを，区別して理解してほしい。

本文の根拠

〔標的型攻撃への対策〕

(C)感染した PC 及びサーバのアクセス権を入手して情報収集を行います。このとき，ウイルスの活動によって異常なトラフィックが発生したり，PC 又はサーバが異常な振る舞いをしたりすることもあります。

図 1

L3SW は内部 LAN と社内 LAN に接続される。

下線②の(C)は，感染した PC やサーバが情報収集を行う段階である。S 主任は“ウイルスの活動によって異常なトラフィックが発生したり，PC 又はサーバが異常な振る舞いをしたりすることもあります”と述べており，この異常を検知する仕組みが監視強化になる。PC が接続されるのは社内 LAN なので，社内 LAN 上にネットワークのトラフィックを監視するシステム（ネットワークモニタ）を置き，トラフィックの急激な増加を監視する。

解答例は，システムの名称“ネットワークモニタ”（9 字），設置場所“社内LAN上”（6 字），監視すべき事象“トラフィックの急激な増加”（12 字）。

名称と設置場所は 10 字以内，事象は 15 字以内。“監視ソフト”のような名称では，ネットワークを見るのか PC を見るのかが分からないので，何を監視するシステムかが分かる名称にする。

採点講評（IPA）

設問3では標的型攻撃について出題した。(1)の正答率は高かったが，(3)，(4)の正答率は低かった。(4)では，現在，一般的な製品になっているWebフィルタを利用する対策の記述を期待したが，正答率は低かった。

設問3(1)，(3)は，問題文中に記述されている内容を落ち着いて読めば，正解を導けるはずである。設問3(2)，(4)は，それぞれ問題文中に記述されている状況での対策を問うているので，問題文中の背景をしっかり理解して正解を導きだしてほしい。IPAが公開して“安全なウェブサイトの作り方”で扱っているように脆弱性を作りこまない根本的な対策を確実にすることだけではなく，攻撃による影響を軽減する保険的対策も有効なことを，区別して理解してほしい。

本文の根拠

図 2 FW

社内とインターネットとの間の通信は次の 3 種類だけを許可する。

図 2 FW

PC から PRX 経由のインターネット上の Web サイトへのアクセス

図 2 FW

MX1 とインターネットとの間のメール転送

下線③は，“当社のネットワーク設定で既に遮断できる”バックドア通信である。バックドア通信とは，感染した PC が収集した情報などを，攻撃者にネットワーク経由で送る通信をいう。図 2 の FW は，社内とインターネットとの間で，PC から PRX 経由の Web アクセス，MX1 とインターネットとの間のメール転送，PRX 及び MX1 からインターネットへの DNS 通信の 3 種類だけを許可している。PC や PRX 以外のサーバから直接インターネットに出ていく通信は，この 3 種類に当たらないので遮断される。

解答例は“FWはPRXとMX1からだけインターネットとの通信を許可している。”の 33 字（40 字以内）。図 1 中の機器名（FW，PRX，MX1）を二つ以上入れる必要がある。

“PC から直接のインターネット接続を禁止している”のように機器名が一つだけでは，二つ以上用いるという条件を満たさない。講評は，(3)の正答率は低く，問題文中の内容を落ち着いて読めば正解を導けると述べている。

採点講評（IPA）

設問3では標的型攻撃について出題した。(1)の正答率は高かったが，(3)，(4)の正答率は低かった。(4)では，現在，一般的な製品になっているWebフィルタを利用する対策の記述を期待したが，正答率は低かった。

設問3(1)，(3)は，問題文中に記述されている内容を落ち着いて読めば，正解を導けるはずである。設問3(2)，(4)は，それぞれ問題文中に記述されている状況での対策を問うているので，問題文中の背景をしっかり理解して正解を導きだしてほしい。IPAが公開して“安全なウェブサイトの作り方”で扱っているように脆弱性を作りこまない根本的な対策を確実にすることだけではなく，攻撃による影響を軽減する保険的対策も有効なことを，区別して理解してほしい。

本文の根拠

〔標的型攻撃への対策〕

しかし，例えば，ウイルスが Web アクセスの通信パターンを模倣して行う通信については，現在のところ防げません。

図 2 PRX

PC からインターネットへの Web アクセスを中継する。

ウイルスが Web アクセスの通信パターンを模倣すると，FW の許可する“PC から PRX 経由の Web アクセス”として通ってしまい，現在の設定では防げない。この通信は PRX（プロキシサーバ）を経由するので，PRX で通信先を確認すれば止められる。通信先が信用できるかをシグネチャで判断する Web フィルタ（URL フィルタ）を PRX に導入し，不審な通信先との通信を遮断する。

解答例は“通信先が信用できるかをシグネチャで判断するWebフィルタをPRXに導入する。”の 38 字（40 字以内）。講評は，現在は一般的な製品になっている Web フィルタを利用する対策の記述を期待したが，正答率は低かったと述べている。

PRX には，暗号化されていないファイルに対するウイルススキャンが既にあるので，“ウイルス対策ソフトの導入”と書くと現状と同じになる。導入する機器（PRX）と手段（Web フィルタ）を両方書く。

採点講評（IPA）

設問3では標的型攻撃について出題した。(1)の正答率は高かったが，(3)，(4)の正答率は低かった。(4)では，現在，一般的な製品になっているWebフィルタを利用する対策の記述を期待したが，正答率は低かった。

設問3(1)，(3)は，問題文中に記述されている内容を落ち着いて読めば，正解を導けるはずである。設問3(2)，(4)は，それぞれ問題文中に記述されている状況での対策を問うているので，問題文中の背景をしっかり理解して正解を導きだしてほしい。IPAが公開して“安全なウェブサイトの作り方”で扱っているように脆弱性を作りこまない根本的な対策を確実にすることだけではなく，攻撃による影響を軽減する保険的対策も有効なことを，区別して理解してほしい。

本文の根拠

〔インシデントの発生〕

Web サーバプログラムで制限している最大同時セッション数が不足してイベント通知が発生したとの報告を受けた。

表 2 注記 1

ステータスが down のもの及びその 1 分後のものの抜粋。

〔暫定対策の実施〕

その脆弱性は，特定のデータを受信すると Web サーバの CPU リソースが一時的に枯渇するというものであった。

表 2 は，LB が down と判定した時刻だけを並べたもので，月曜日は 16 時まで求人情報の定期更新でアクセスが集中して最大同時セッション数が不足し，down と判定されるのが普通の日である。表 2 だけでは，down のうちどれが普段と異なる事象かが分からない。図 3 は Web サーバ群の CPU 使用率のグラフで，普段は 15〜50％ 程度で推移するところ，down の時刻の近くで 100％ 近くまで急上昇した箇所が見える。CPU 使用率を確認することで，普段と異なる事象が発生している時間帯が見極めやすくなるので，G 主任は図 3 に着目した。

図 3 の急上昇は，Web サーバ 1 で 11 時ごろ・15 時ごろ・19 時半ごろ，Web サーバ 2 で 19 時ごろにあり，表 2 の 11:01・15:05・19:23・18:51 の down と対応している。後で判明した脆弱性は CPU リソースが一時的に枯渇するものなので，この観点から絞り込める。

50 字以内に対し，解答例は 45 字。“絞り込んだ後に判明した結果”（CPU が枯渇していたこと）を書くのではなく，なぜ図 3 を見たか，という理由を書く。講評も，調査範囲を絞り込んだ後に判明した結果を述べる解答のように，設問の主旨を捉えていない解答が見られたと述べている。

採点講評（IPA）

設問1は，今回のようなインシデントでのログ調査では，LBのサービス稼働チェックログに加え，Webサーバ群のリソースグラフを確認することでログの調査範囲を絞り込むという手法は理解されているようであった。しかし，調査範囲を絞り込んだ後に判明した結果について述べられていた解答のように，設問の主旨を捉えていない解答も見られた。落ち着いて問題文を読んで解答してほしい。

本文の根拠

表 4

(1)：11:00:12，許可，TCP，△△.123.123.123，443，6,401,200。

表 3

(1)：11:00:12，Low，192.168.1.254，192.168.1.11，19212，8443。

表 3 の IDS の検知ログ(1)〜(6)は，LB から Web サーバへの通信（送信元 192.168.1.254）で，LB の内側なので，攻撃元の IP アドレスは見えない。検知時刻が同じ FW1 のログ（表 4）の送信元 IP アドレスを見ると，(1)(3)(5)(6)は全て△△.123.123.123 で，送信バイト数も 6,401,121〜6,401,220 と同程度の大きなデータである。一方，(2)と(4)は○○.1.1.1 と○○.1.1.2 で，301,201 と 305,121 バイトと小さい。

表 5・表 6 を見ると，(1)(3)(5)(6)に対応するアクセスのステータスコードは 500（エラー）で，Web サーバに CPU リソースの枯渇を起こしたのは，大きなデータを送り続けた△△.123.123.123 からの通信だと分かる。a は△△.123.123.123。

表 4 の中から選ぶ設問で字数制限は無い。○○.1.1.1・○○.1.1.2 は 300,000 バイトを少し超える程度の通常のアクセスで，遮断すると正規の利用者を止めてしまう。

本文の根拠

表 5 (3)

(3)：192.168.1.254，16:59:23，POST www.w-sha.co.jp/entry/touroku.php HTTP/1.1，200，305,071。

表 6 (1)

(1)：192.168.1.254，13:21:06，POST www.w-sha.co.jp/entry/touroku.php HTTP/1.1，200，301,143。

〔暫定対策の実施〕

IDS では，シグネチャ A の検知基準が，標準設定の“HTTP POST リクエストが 300,000 バイト以上”だった。

シグネチャ A の検知基準は“HTTP POST リクエストが 300,000 バイト以上”なので，業務で 300,000 バイトを少し超える POST があれば誤検知になる。表 3 の検知のうち，表 4 で送信バイト数が 301,201 と 305,121 だったのは(2) 13:21:06 と(4) 16:59:23 で，それぞれ Web サーバ 2 のアクセスログ（表 6 の(1)）と Web サーバ 1 のアクセスログ（表 5 の(3)）に対応する。

この二つのアクセスのステータスコードは 200（正常）で，受信バイト数も 301,143 と 305,071 の通常の大きさである。残りの表 5 の(1)(2)(4)と表 6 の(2)は，ステータスコードが 500 で受信バイト数が 6,401,xxx と大きく，攻撃によるものである。誤検知であると判断できるアクセスログは，表 5(3)と表 6(1)。

答え方は“表5(3)，表6(1)”と，表番号と項番の組合せで全て挙げる。1 つだけでは全て選んだことにならない。

本文の根拠

表 5 (3)

(3)：192.168.1.254，16:59:23，POST www.w-sha.co.jp/entry/touroku.php HTTP/1.1，200，305,071。

表 6 (2)

(2)：192.168.1.254，18:50:20，POST www.w-sha.co.jp/entry/touroku.php HTTP/1.1，500，6,401,181。

表 5(3)と表 6(1)は，Web サーバが POST リクエストを正常に処理しており，ステータスコードが 200 になっている。他の表 5・表 6 のアクセスログはステータスコードが 500 で，Web サーバが処理できなかったことを示している。IDS の検知ログに載っていても，Web サーバ側でステータスコードが 200 であれば，その通信は攻撃として成立していないので，誤検知と判断できる。

解答例は“該当通信は，Webサーバのステータスコードが200であるから”の 30 字（35 字以内）。“受信バイト数が 300,000 バイト台だから”と書くと，検知基準そのもの（300,000 バイト以上）に当たる条件で，攻撃ではないと言えない。

ステータスコードの値と，それが何を示すかを書く。“アクセスが成功しているから”だけでは，表 5・表 6 の他のログとの違いが分からない。

本文の根拠

〔恒久対策の検討と運用強化〕

L2SW2 のトラフィックの代わりに L2SW1 のトラフィックを監視対象にすることによって，ネットワークアドレス変換前の

図 2 (7)

LB は，SSL アクセラレータ機能と負荷分散機能を提供しており，Web サーバの仮想 IP アドレスをもち，2 台の Web サーバにアクセスを負荷分散する。

表 3

(1)：11:00:12，Low，192.168.1.254，192.168.1.11，19212，8443。

IDS が L2SW2 を見ていると，LB の内側のトラフィックなので，表 3 のとおり送信元は LB の Web サーバ側 IP アドレス 192.168.1.254 になり，本当の攻撃元が分からない。L2SW1 を監視対象にすれば，LB の手前のトラフィックなので，ネットワークアドレス変換前の送信元 IP アドレスを確認できる。b は 10 字以内の“送信元IPアドレス”（9 字）。

ただし，LB は SSL アクセラレータ機能をもっているので，ブラウザと LB の間の通信は HTTPS（SSL）で暗号化され，L2SW1 の側では内容が見えない。IDS が https（SSL）の通信を監視するには，LB が保有している秘密鍵を使って復号する必要がある。c は“https”（5 字）又は“SSL”（3 字），d は“秘密鍵”（3 字）。

c，d は 5 字以内の指定なので，“HTTPS 通信”のような言い方は字数に収まらない。講評は，d の正答率が低かったと述べ，IDS 製品だけでなく WAF 製品でも秘密鍵を利用して HTTPS 通信を監視できるようになっているので，一般的な知識として理解してほしいと述べている。

採点講評（IPA）

設問3(1)は，ｄの正答率が低かった。IDS製品だけではなく，WAF製品でも秘密鍵を利用して，HTTPS通信を監視できるようになってきているので，一般的な知識として理解しておいてほしい。

本文の根拠

図 2 (2)

ブラウザからのアクセスについて，Web サーバプログラムが処理する最大同時セッション数は，Web サーバプログラムで 50 に制限している。

〔インシデントの発生〕

Web サーバプログラムで制限している最大同時セッション数が不足してイベント通知が発生したとの報告を受けた。

〔恒久対策の検討と運用強化〕

対処する必要がない場合でもイベント通知している。

下線③は，“対処する必要がない場合でもイベント通知している”ものを，対処が必要な場合だけにするために，Web サーバの設定を変更するという対策である。不要なイベント通知の原因は，月曜日の求人情報の定期更新のようにアクセスが集中する時間帯に，Web サーバプログラムで 50 に制限している最大同時セッション数が不足し，LB の稼働チェックのリクエストが 30 秒以内に処理されずに down と判定されることである。設定変更とは，この最大同時セッション数の見直しである。

本文は，H さんがイベント通知の原因を“最大同時セッション数が不足して”と報告したと書いており，リリース後にアクセス数が増加しているので，この設定の見直しを運用チーム内で検討していたとも述べている。

35 字以内に対し，解答例は 31 字。“アクセスの集中”だけでは原因の設定の話にならない。制限しているのが Web サーバプログラムであることまで書く。

本文の根拠

図 2 (2)

LB では，任意の HTTP ヘッダフィールドを追加可能であるが，現在は何も追加していない。追加した HTTP ヘッダフィールドは，全て Web サーバのアクセスログに出力可能である。

図 2 (7)

また，HTTP ヘッダフィールドとして X-Forwarded-For ヘッダフィールドを追加可能であるが，現在は利用していない。

表 5 (1)

(1)：192.168.1.254，11:00:12，POST www.w-sha.co.jp/entry/touroku.php HTTP/1.1，500，6,401,124。

FW1 のログ（表 4）には攻撃元の送信元 IP アドレスが残るが，Web サーバのアクセスログ（表 5，表 6）の送信元は LB の Web サーバ側 IP アドレス 192.168.1.254 で，攻撃元が分からない。LB は X-Forwarded-For ヘッダフィールドを追加でき，追加したヘッダフィールドは Web サーバのアクセスログに出力できる。LB に X-Forwarded-For ヘッダフィールドを追加させ（機器ウ），Web サーバ群でそのヘッダフィールドをアクセスログに出力する（機器オ）ように設定すれば，Web サーバのアクセスログから送信元の IP アドレスを確認でき，FW1 のログと突き合わせられる。

講評は，プロキシサーバや LB などを利用するシステム構成では，X-Forwarded-For ヘッダフィールドは送信元の IP アドレスを特定するために有効であることを，基本知識として理解してほしいと述べている。

設定内容は 40 字以内で，解答例は“X-Forwarded-Forヘッダフィールドの追加”が 26 字，“X-Forwarded-Forヘッダフィールドのアクセスログへの出力”が 34 字。どちらの機器に何をするかを分けて書く。“ログの出力内容を見直す”のような書き方では，どの機器の設定か分からない。

採点講評（IPA）

設問3(3)は，設定内容について正答率が低かった。プロキシサーバやLBなどを利用するシステム構成では，X-Forwarded-Forヘッダフィールドは，送信元のIPアドレスを特定するために有効であることを，基本知識として理解しておいてほしい。