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

本文の根拠

表 相手端末確認

相手端末確認（正規利用者へのaの防止，及び誤接続の防止）

表 (ア)

(ア) SSL 通信によるクライアント認証（専用 PC 又はベンダ PC にbを設定する。）

表 伝送データの漏えい

伝送データの漏えい（cによる漏えい）の防止

a は，相手端末確認で防ぐものを問う。相手端末確認は，通信相手が正規の端末であることを確かめる項目なので，防ぐ対象は正規の利用者を装う“なりすまし”である。

b は，(ア) の SSL クライアント認証で専用 PC 又はベンダ PC に設定するもの。クライアント認証では，端末側が自分の身元を示す証明書をサーバに提示するので，設定するのは“クライアント証明書”である。c は，ネットワーク上を流れる資料ファイル（伝送データ）の漏えいを問う。実装方法の欄に“SSL 通信による通信の暗号化”とあり，暗号化で防ぐ漏えいは通信路上で内容を読み取られる“盗聴”である。

字数はいずれも 10 字以内で，解答例は a が 5 字，b が 9 字，c が 2 字。a と取り違えやすいのは“改ざん”だが，(ア) と (イ) は相手が本物かを確かめる実装であり，内容の書換えを防ぐ手段ではない。

本文の根拠

案 1 の説明

案 1 では，資料ファイルを各 SI ベンダ専用の Web サーバ上にアップロードしておき

案 2 の説明

各 SI ベンダの複数の保守担当者は，ベンダ PC からインターネット経由で共用 Web サーバにアクセスし，各 SI ベンダ専用のディレクトリ上にある資料ファイルをダウンロードする。

冒頭

A 社の保守担当者は，取得した資料データを，B 社，C 社，D 社及びその他の企業に開示することが禁止されている。

指摘 1 は，表の (ウ)（Web サーバにおけるディレクトリに対するアクセス制御）に関するものである。案 1 では SI ベンダごとに専用の Web サーバがあり，サーバが別なので他社の資料ファイルには届かない。案 2 では Web サーバが共用で，各社の資料ファイルは同じサーバのディレクトリで分けて置かれているだけなので，アクセス制御ルールを設計しないと他社のファイルが見えてしまう。

本文は，資料データを他社に開示することを秘密保持契約で禁じている。共用 Web サーバでは，ディレクトリのアクセス制御がそのまま秘密保持契約を守る手段になる。

解答例は“WebサーバがSIベンダ間で共用されるから”の 21 字（25 字以内）。案 1 との違いを踏まえる指定なので，“共用”の語が要る。

本文の根拠

案 2 の説明

各 SI ベンダ専用のディレクトリ上にある資料ファイルをダウンロードする。

冒頭

A 社の保守担当者は，取得した資料データを，B 社，C 社，D 社及びその他の企業に開示することが禁止されている。

禁止すべきアクセスは，他社の資料データを他社の保守担当者が見ることである。案 2 の共用 Web サーバには全 SI ベンダの資料ファイルがあり，各社の保守担当者は自社専用のディレクトリの資料ファイルだけをダウンロードできればよい。

そこで，アクセス対象は“各SIベンダ専用のディレクトリ”（その SI ベンダ以外から見て他社のもの），アクセス元の利用者は“ほかのSIベンダの保守担当者”になる。本文の秘密保持契約の例（A 社の保守担当者が B 社，C 社，D 社に開示することの禁止）と同じ関係を，アクセス制御ルールの言葉に直した答えである。

字数は各 20 字以内で，解答例は 15 字と 14 字。対象だけ“資料ファイル”と書くと，ディレクトリ単位で制御するという案 2 の実装から外れる。

本文の根拠

指摘 2

(エ)に関して，通信ログの取得と保存だけでなく，運用担当者と保守担当者が行った作業の内容を事後確認する必要がある。

図 3 (6)

運用担当者が，作業報告書に，作業日時，運用担当者の氏名，保守担当者の所属と氏名，資料データの内容，資料ファイルのファイル名を記録する。

表 (エ)

(エ) Web サーバにおける，通信ログの取得及び保存

事後確認は，運用担当者と保守担当者が実際に行った作業が，記録上の作業と合っているかを確かめることである。Web サーバに残るのは(エ)の“通信ログ”，人が書き残すのは図 3 (6) の“作業報告書”なので，この二つを突き合わせる。

作業報告書には作業日時，氏名，資料ファイルのファイル名が記録され，通信ログにはアップロードやダウンロードの履歴が残る。双方を照合すれば，報告書にない操作や，操作の無い報告が分かる。

字数は各 7 字以内で，解答例は“通信ログ”（4 字）と“作業報告書”（5 字）。“Web サーバのログ”のように長くすると 7 字を超える。

本文の根拠

図 3 (2)

複数の運用担当者が利用者 ID を共有する。

図 3 (3)

SI ベンダごとに，一つの利用者 ID を割り当てておく。

図 3 (6)

運用担当者の氏名，保守担当者の所属と氏名

作業報告書には運用担当者と保守担当者の氏名が書かれるが，通信ログに残るのは利用者 ID だけである。図 3 のとおり運用担当者は ID を共有し，保守担当者も SI ベンダごとに一つの ID なので，突き合わせても個人は特定できない。

事後確認を確実にするには，運用担当者と保守担当者のそれぞれに，個人ごとに異なる利用者 ID を割り当てる。これで通信ログの ID から作業した個人が分かり，作業報告書の氏名と対応づけられる。

解答例は“運用担当者と保守担当者それぞれの個人に異なる利用者IDを割り当てておく。”の 36 字（40 字以内）。講評は，利用者 ID の共用が特権の悪用を容易にし，インシデント時の追跡調査を難しくする点を再認識してほしいとしている。

採点講評（IPA）

設問3(2)は，正答率が低かった。作業報告書には運用担当者と保守担当者の氏名が記載され，個人が特定可能であるのに対して，通信ログに記録される運用担当者の利用者ID及び保守担当者の利用者IDは，共用されているので，作業報告書と通信ログの突合せにおいて，個人が特定できないという点に気づいてほしかった。システムの運用・保守において利用者IDを共用すると，特権の悪用が容易になり，かつ，インシデントが発生した場合の追跡調査が困難になってしまうことを再認識してほしい。

本文の根拠

図 3 (6)

運用担当者が，作業報告書に，作業日時，運用担当者の氏名，保守担当者の所属と氏名，資料データの内容，資料ファイルのファイル名を記録する。

図 3 (1)

資料ファイルには，作成のたびに異なる一意なファイル名を割り当てる。

指摘 2

通信ログとして取得するデータ項目の明確化が必要である。

通信ログは，作業報告書と突き合わせる材料になる。作業報告書にあるのは作業日時，氏名，ファイル名なので，通信ログにも，いつ（日時），だれが（利用者 ID），どのファイルを（ファイル名）の三つが要る。

利用者 ID は(2)の修正で個人ごとになり，氏名と対応づけられる。ファイル名は図 3 (1) で作成のたびに一意に割り当てるので，同じ名前の別ファイルと取り違えることがない。

各 7 字以内で，解答例は“日時”（2 字），“利用者ID”（5 字），“ファイル名”（5 字）。三つの項目は順序を問われていない。

本文の根拠

図 1 の凡例

専用 PC：Z 社が貸与する拡張保守サービス専用 PC，ベンダ PC：各 SI ベンダが所有及び管理する PC。

表 (ア)

(ア) SSL 通信によるクライアント認証（専用 PC 又はベンダ PC にbを設定する。）

指摘 3

案 2 の場合，(ア)及び(イ)に関して，各 SI ベンダの情報セキュリティポリシと矛盾していないことを確認する必要がある。

案 1 の専用 PC は Z 社が貸与するので Z 社が管理するが，案 2 のベンダ PC は SI ベンダが所有して管理する。(ア) のクライアント認証ではベンダ PC にクライアント証明書を設定する必要があり，(イ) ではブラウザに Web サーバのブックマークを登録する必要がある。

これらは各 SI ベンダが管理する PC への設定なので，SI ベンダのセキュリティポリシに反しないかを確かめる必要がある。講評は，企業間接続では各企業の管理範囲を明確にした上で，各社間のセキュリティポリシの整合性を確認する必要があるとしている。

解答例は“各SIベンダが所有するベンダPCへの設定が必要だから”の 26 字（30 字以内）。“ベンダ PC を SI ベンダが所有する”点と“設定が必要”の二つを入れる。

採点講評（IPA）

設問4は，正答率が低かった。クライアントPCが，案1ではZ社から各SIベンダに貸与される専用PCであるのに対して，案2では各SIベンダが所有するベンダPCを利用する点が大きく異なることに気づいてほしかった。企業間接続においては，各企業の管理範囲を明確にした上で，各社間のセキュリティポリシの整合性を確認する必要があることに注意してほしい。

本文の根拠

冒頭

休職者については，セキュリティの観点からすべてのサブシステムについて，アカウント管理者が利用者 ID（以下，UID という）を利用停止に変更することになっている。

図 状態遷移

“状態：有効”から，アカウント管理者による無効化，又は利用されない期間が 100 日を超えたで“状態：無効”（不許可，表示メッセージなし）に遷移する。“状態：無効”から，アカウント管理者による有効化で“状態：有効”に遷移する。

表 休職

休職：－，“a”に変更，属性値（休職フラグ）の設定。

状態値は“仮パスワード”“有効”“無効”“一時利用停止”の四つである。休職は，アカウント管理者が UID を利用停止に変更する人事イベントで，ログインを認めない状態になる。ログインを認めない状態のうち“一時利用停止”はパスワードの連続誤りで自動的に入る状態なので，休職には当たらない。図で，アカウント管理者の操作で入る状態は“無効”であり，a は“無効”になる。

復職は，休職の逆に当たる。図では“無効”からアカウント管理者による有効化で“有効”に戻る遷移があるので，b は“有効”である。“仮パスワード”に戻すと，パスワードの再設定が必要になってしまう。

ここは図中の字句を用いる指定の設問で，言い換えず“無効”“有効”と書く。

本文の根拠

〔従業員の UID 管理〕(ウ)

パスワードを設定するまでは，各サブシステムを利用することはできない。

図 状態遷移

発行（黒丸）から“状態：仮パスワード”（ログインの認可はc，表示メッセージは“d”）に遷移する。

図 状態遷移

状態における各サブシステムに対するログインの認可

c は，仮パスワードの状態でのログインの認可を問う。(ウ)に“パスワードを設定するまでは，各サブシステムを利用することはできない”とあるので，認可は“不許可”である。図では“一時利用停止”と“無効”も“不許可”，“有効”は“許可”と書かれている。

d は，この状態の利用者に表示するメッセージである。一時利用停止の状態では“一時利用停止中です。…アカウント管理者に連絡してください。”と，次にとるべき行動が表示される。同じように，仮パスワードの状態では利用者がするべきことは，(ウ)のとおりパスワードの設定なので，“パスワードを設定してください。”となる。

字数は c が 5 字以内（解答例は 3 字），d が 20 字以内（解答例は 15 字）。d の末尾の句点まで解答例に含まれる。

本文の根拠

〔従業員の UID 管理〕(エ)

“一時利用停止”の状態は，24 時間後に自動的に解除される。

図 状態遷移

“状態：一時利用停止”から“状態：有効”へ戻る遷移があり，その遷移にはeが付いている。

図で，“有効”と“一時利用停止”は二方向の矢印で結ばれ，“有効”から“一時利用停止”へはパスワードを 5 回連続して間違えたときに遷移する。逆向きの遷移の条件が e である。(エ)に，“一時利用停止”の状態は 24 時間後に自動的に解除されるとあるので，条件は“24時間を超えた”となる。

自動で解除された後の状態は“有効”なので，パスワードの初期化はされていない。初期化が必要になるのは，緊急に利用したい場合にアカウント管理者に依頼するとき（図では“アカウント管理者による初期化”で“仮パスワード”へ遷移）である。

15 字以内で，解答例は“24時間を超えた”（8 字）。図の他の遷移の言い方（“72 時間を超えた”“100 日を超えた”）に合わせた書き方になっている。

本文の根拠

〔派遣社員の UID 管理〕

第 2 案は，UID の発行申請時に設定する①属性を追加して，UID 管理システムが毎日その値を点検して自動的に UID を削除する運用である。

〔派遣社員の UID 管理〕

契約開始日は月初日，満了日は月末日に限定すること，有期限の期間契約とすること，及び自動継続契約は行わないことが決められており，これらは，契約管理部によって厳格に確認されている。

第 2 案は，発行申請の時点で，その UID をいつ削除するかの情報を設定しておく。UID 管理システムは毎日その値を点検し，期日になった UID を自動で削除する。契約は有期限で自動継続が無く，満了日が決まっているので，申請時に満了日を属性にできる。

そのため追加する属性は，UID 削除予定日（又は契約満了予定日，アカウント終了予定日）である。解答例にはこの三つが“又は”で並んでおり，どれを書いてもよい。削除の時期を決める日付であることが分かる書き方にし，“契約期間”のような期日が一つに決まらない書き方は避ける。

15 字以内で，解答例は 8 字，7 字，10 字。

本文の根拠

〔従業員の UID 管理〕(3)

許容無使用期間は 100 日とする。

〔派遣社員の UID 管理〕

第 1 案は，“無効”状態にある UID を，情報システム部が毎月初日に一括削除する運用である。

〔派遣社員の UID 管理〕

契約開始日は月初日，満了日は月末日に限定すること

第 1 案では，契約が満了しても UID は使われなくなるだけで，100 日（許容無使用期間）使われないことで初めて“無効”になる。“無効”になった UID は，次の月初日に一括削除される。

満了日は月末日なので，例えば 1 月 31 日に満了して最終の利用も同日なら，100 日を超える 5 月 12 日に“無効”になり，次の月初日の 6 月 1 日に削除される。満了日から削除まで約 4 か月である。最終の利用が満了日より前なら，無効になる日がそれだけ早まり，削除はその後の最初の月初日になる。

解答例は 4 で，月数を整数で答える設問なので単位は付けない。100 日の経過に加えて，削除が次の月初日まで待たされる分を数に入れる。

本文の根拠

〔派遣社員の UID 管理〕

契約満了時の削除申請には利用してもらえないだろうとの意見が出た。

〔派遣社員の UID 管理〕

派遣社員に関する契約は，各事業部が主体的に行っているが，契約開始時には，契約管理部の承認を得ている。

〔派遣社員の UID 管理〕

派遣社員の契約では契約満了前に契約解除となるケース（以下，満了前解除ケースという）がまれに発生する

満了日が決まっている契約満了は，発行時の削除予定日で自動削除できる。解除は予定外に起こるので，削除予定日が当てにならない。各事業部は，業務上必要なときの発行申請には UID 管理システムを使っても，削除の申請には使わないだろうとされているので，事業部任せにはできない。

契約に関与する部署のうち，契約開始時に承認を行い，契約内容を厳格に確認している契約管理部が，解除も確認できる立場にある。契約管理部が解除を確認して UID の削除依頼を行えば，現場任せにせず削除できる。

解答例は“契約管理部が，契約解除を確認し，UID削除依頼を行う。”の 27 字（35 字以内）。講評は，現場任せでは ID 削除が進まない状況設定なのに，現場に任せる誤答が多かったとしている。

採点講評（IPA）

設問2は，状況設定を理解した上で，契約が終了した派遣社員のIDを確実に削除するための工夫を問うたが，設問2(3)の正答率は低かった。現場任せではID削除が進まないという状況設定にもかかわらず，現場に任せるという誤った解答が散見された。問題文をよく読み，状況設定に注意して，実務的に解答をしてほしい。

本文の根拠

〔従業員の UID 管理〕(5)

UID のパスワードを連続して 5 回間違えた場合，状態値を“一時利用停止”にする。

〔従業員の UID 管理〕(エ)

緊急に利用しなければならない場合は，アカウント管理者の通常勤務時間内であれば，アカウント管理者にファックス，電話などの何らかの方法でコンタクトし，初期化依頼する。依頼を受けたアカウント管理者は，直ちにパスワードを初期化し，依頼者が指定する方法で仮パスワードを連絡する。

〔派遣社員の UID 管理〕

何者かがなりすまして他者の UID のパスワードを不正取得できるリスク

他者の UID のパスワードを不正に取得する筋道は次のとおり。攻撃者が他人の UID に誤ったパスワードを 5 回連続で入力し，その UID を“一時利用停止”にする。次に，利用者本人を装って，アカウント管理者に初期化を依頼する。(エ)では，依頼の方法は“何らかの方法”，仮パスワードの連絡は“依頼者が指定する方法”なので，アカウント管理者は依頼者が本人かを確認せず，仮パスワードが攻撃者に渡る。

答えるべき要素は，“他人の UID のパスワードを 5 回連続して間違え一時利用停止状態にする”ことと，“アカウント管理者にパスワードの初期化を依頼する”ことの二つである。講評は，正答に近いが解答すべきポイントを一部省略した解答が見られたとして，必要条件を漏らさないことを求めている。

解答例は 57 字（65 字以内）。“5 回連続して間違え”と“初期化を依頼”のどちらも落とさずに収める。

採点講評（IPA）

設問3は，状況設定からセキュリティホールを探す問いだった。多くの受験者が正答には近かったが，解答すべきポイントを一部省略してしまった解答が見受けられた。必要条件を漏らさず解答するよう心がけてほしい。

本文の根拠

〔従業員の UID 管理〕(エ)

アカウント管理者にファックス，電話などの何らかの方法でコンタクトし，初期化依頼する。

〔従業員の UID 管理〕(エ)

依頼を受けたアカウント管理者は，直ちにパスワードを初期化し，依頼者が指定する方法で仮パスワードを連絡する。

設問 3 の抜け穴は，初期化の依頼が本人からのものか確認されない点と，仮パスワードが依頼者の指定する宛先に渡る点にある。それぞれに手続を決めれば塞げる。

解答例は二つあり，“パスワード初期化依頼の際には，上司からメールで依頼する。”は依頼者が本人であることを上司を介して確かめる手続，“仮パスワードの連絡は，あらかじめ登録された電話番号だけに限定する。”は仮パスワードの渡し先を本人の連絡先に限る手続である。どちらを書いてもよい。

解答例は 28 字と 33 字（40 字以内）。講評は，あいまいな表現や，手続によって達成したい目的の記述が散見されたとして，具体的な手続を書くよう求めている。“本人確認を行う”だけでは手続にならない。

採点講評（IPA）

設問4は，設問3のセキュリティホールを回避する具体的な手続を問うた。あいまいな表現や，その手続によって達成したい目的の記述が散見された。情報セキュリティスペシャリストの重要な役割は，セキュリティ対策を具体的に検討し実施することなので，実践的な対策を解答してほしい。

本文の根拠

〔WAF による対策の検討〕

販売システムを利用する上で必要な通信（以下，正常な通信という）を WAF が攻撃として検知してしまうことで，利用者が販売システムを利用できなくならないよう，まずは a を減らすための検証期間を設けます。

〔WAF による対策の検討〕

検証期間には，攻撃を検知しても通信の遮断は行わず，WAF 設定と Web アプリケーション設定のチューニングを行い，a が十分に減少した段階で，攻撃の遮断を開始します。

a は，正常な通信を WAF が攻撃として検知してしまう誤りである。検知するべきでないものを検知する誤りなので，エのフォールスポジティブ（偽陽性）が当たる。検証期間に遮断しないのは，この誤りで利用者が販売システムを使えなくなることを避けるためである。

ほかの語は，ア フェールセーフは故障時に安全な側へ動作する設計，イ フェールソフトは一部が故障しても機能を落として動作を続ける設計で，検知の誤りを表す語ではない。ウ フォールスネガティブ（偽陰性）は攻撃を見逃す誤りで，本文でこちらは“攻撃がシグネチャに一致しなかった場合には，その攻撃を見逃してしまう”と別に述べられている。

記号で答える設問なので，字数の詰め方は要らない。偽陽性と偽陰性は，何を何と判定したかを“正常な通信を攻撃と判定”と言い換えて取り違えない。

本文の根拠

図 2 (5)

FW は，パケットのヘッダ情報によってアクセスを制御するパケットフィルタリング型である。

図 2 (6)

ログイン時にミドルウェアがセッション ID を生成し，これをクッキーとして利用者のブラウザに格納することによってセッション管理を実現している。

表 シグネチャ

HTTP による通信をシグネチャと比較し，一致した場合には攻撃として検知する。

セッション ID は，クッキーとして HTTP の通信の中身に入れてやり取りされる。パケットフィルタリング型の FW が見るのはパケットのヘッダ情報だけなので，アドレスやポート番号などが条件に合えば通し，通信の中身にあるセッション ID の値が正しいか偽造されたかは判別できない。

WAF は，表のとおり HTTP の通信をシグネチャと比較する機能をもつ。FW と違い，通信の中身を見て検査する装置である。

解答例は“FWはパケットのヘッダ情報だけでアクセスを制御するから”の 27 字（30 字以内）。FW の種類（パケットフィルタリング型）と，ヘッダ情報だけを見ることの二つが入っている。

本文の根拠

図 3

セッション ID は，利用者のログイン ID，ログインを行った年月日及び時刻の情報を基に生成される。

表 クッキーの暗号化機能

Web アプリケーションがブラウザに対してクッキーを発行した際，クッキーの値を暗号化して引き渡す。ブラウザからクッキーを受信した際，値を復号して，Web アプリケーションに引き渡す。

図 3 の脆弱性は，ログイン ID と日時から生成されるセッション ID を第三者が推定できることである。クッキーの暗号化機能を使うと，ブラウザに渡るのは暗号化された値になり，ブラウザからクッキーを受け取った WAF は復号してから Web アプリケーションに渡す。

攻撃者がセッション ID の平文を推定できても，WAF が暗号化した後の値（暗号文）を推定して作ることは困難なので，偽造したセッション ID を送っても，復号した結果が有効なセッション ID にならない。このため，脆弱性を悪用した攻撃が成り立たなくなる。講評も，この点への注目を求めている。

解答例は“復号後に有効なセッションIDとなる暗号文を攻撃者が生成できないから”の 33 字（40 字以内）。“推定できないから”だけでは，平文を推定できても暗号文を作れないことが表せない。

採点講評（IPA）

設問3(1)は，正答率が低かった。悪意のある第三者が，ミドルウェアが発行するセッションIDを推定できた場合にも，WAFによって暗号化された後の値を推定することは困難である点に注目して解答してほしかった。

本文の根拠

〔WAF による対策の検討〕

クッキーの暗号化では，クッキーに属性を付与している場合であっても，その属性の効果を維持できるように考慮されています

表 クッキーの暗号化機能

クッキーの値を暗号化して引き渡す。

WAF が暗号化するのはクッキーの値（session_id= の右側）だけで，属性は暗号化しない。secure 属性は暗号化された通信路でだけクッキーを送らせる指定，path 属性はクッキーを送る対象のパスを限る指定で，ブラウザが読んで動作を決めるため，暗号化すると効果が失われる。

Q 氏の“属性の効果を維持できるように考慮されています”はこのことを指す。よって，値だけを☆☆に変え，secure と path=/874045/ はそのまま残したウが正解である。ア は secure が落ちている，イとエは path の値まで暗号化されている。

解答群から記号で答える設問。クッキーの値と属性を区別する知識があれば選べる。講評は，クッキーについての基本的な知識を理解しておくよう求めている。

採点講評（IPA）

設問3(2)は，選択肢形式であるにもかかわらず正答率が低かった。クッキーへの不適切な属性付与によるセキュリティ事故を防止するためにも，クッキーについての基本的な知識を理解しておいてほしい。

本文の根拠

〔WAF による対策の検討〕

ブラウザに格納されるクッキーが暗号化されたものになることから，Web アプリケーションによっては，動作に異常が生じる場合があります

表 クッキーの暗号化機能

ブラウザからクッキーを受信した際，値を復号して，Web アプリケーションに引き渡す。

ブラウザに格納されるクッキーは暗号化された値で，復号するのは WAF である。だから，ブラウザ（クライアント）上でクッキーの値を使う場合は，暗号化された文字列しか読めず，元の値を前提とした処理が正しく動かない。

また，クッキーが WAF を経由しない別の Web サーバへ送られる場合も，その Web サーバに復号する仕組みが無いので，暗号化された値のまま届いて処理できない。二つの解答例のどちらを書いてもよい。

解答例は“クッキーがクライアント上で参照される場合”の 20 字と，“クッキーがWAFを経由しない別のWebサーバへ送信される場合”の 30 字（いずれも 30 字以内）。“どのように用いられる場合か”という問いに合わせ，クッキーの用途で答える。

本文の根拠

表 シグネチャによる通信検査機能

シグネチャには，脆弱性を悪用する攻撃に含まれる可能性の高い文字列が定義されている。

〔WAF による対策の検討〕

正常な通信が攻撃と検知された場合であっても，不用意に，そのシグネチャを無効化するべきではありません

〔WAF による対策の検討〕

Web アプリケーションは，できるだけ脆弱性を除去して運用することが重要ですね。

シグネチャは，脆弱性を悪用する攻撃に含まれる文字列を定義したものなので，無効化するとその攻撃に対する防御が失われる。無効化しても問題ないのは，そのシグネチャが対象とする脆弱性が，Web アプリケーションにもミドルウェアにも無い場合である。

そこで，無効化するシグネチャが定義している攻撃の対象となる脆弱性が，Web アプリケーションやミドルウェアに存在しないことを確認する。本文が不用意に無効化するべきでないとしているのは，脆弱性が残っていれば，攻撃を見逃すことになるからである。

指定された“シグネチャ”と“脆弱性”の語を使った 55 字の解答例（60 字以内）。誤検知する通信が正常かの確認だけを書かず，脆弱性が無いことを確認する，と答える。

本文の根拠

図 2 (6)

ログイン画面以降は，ブラウザと Web サーバ間で SSL 通信が行われる。

〔WAF の導入〕

販売システムへの WAF の導入の際には，Web サーバへの負荷分散に WAF の負荷分散機能を利用することで，利用中の LB を WAF で置き換える方針とした。

表 SSL アクセラレーション機能

SSL 通信の暗号化と復号を行う。

WAF は図 1 の LB の位置に置かれ，ブラウザからの通信は WAF を通って Web サーバに届く。ブラウザと Web サーバ間の SSL 通信を WAF で終端せず，Web サーバまで暗号化したまま通すと，WAF は通信の中身を見られず，シグネチャによる検査も，クッキーの暗号化と復号も働かない。

そのため，WAF の SSL アクセラレーション機能で SSL 通信の暗号化と復号を行い，WAF で終端させる。WAF から Web サーバへは復号した通信が流れ，WAF が検査できる。講評も，SSL 暗号化されていると，シグネチャによる通信検査機能などが有効に動作しない点への気づきを求めている。

解答例は 49 字（55 字以内）。“SSL 暗号化されていると WAF が攻撃を検知できない”という因果を書く。

採点講評（IPA）

設問4は，正答率が低かった。問題文中のネットワーク構成では，ブラウザとWebサーバ間で通信がSSL暗号化されていると，シグネチャによる通信検査機能などWAFの機能が有効に動作しない点に気づいてほしかった。

本文の根拠

〔ホームページ制作部門の情報セキュリティに対する取組み〕

ホームページ制作部門の PC 及び共用 PC への a の適用を徹底するために，2 年前に検疫システムの導入を情報セキュリティ委員会に提案した

〔テストサーバ上のページ改ざん〕

アクセスが業務上必要でないと判断される URL を登録する b リスト方式の URL フィルタ

図 2 (2)

利用者 PC 上のアプリケーションの c 性を突いて不正プログラムに利用者 PC が感染する。

a は，検疫システムで適用を徹底するもので，“重大なaが公開されるたびに…適用の徹底を図ってきた”とあるので，セキュリティパッチである。表の (c) にも PC の OS 及びアプリケーションの更新状況の集中管理がある。

b は，アクセスしてはいけない URL を登録する方式なので“ブラック”リストである。登録した URL だけを遮断するので，登録されていない URL へのアクセスは通る。c は，アプリケーションの欠陥を突いて感染するので“脆弱”性。

字数は a が 10 字以内（解答例はセキュリティパッチの 9 字），b が 5 字以内（ブラックの 4 字），c が 5 字以内（脆弱の 2 字）。

本文の根拠

表 再発防止策

(a) U 社以外からのテストサーバへの FTP アクセス元 IP アドレスを制限する。

表 再発防止策

(c) PC の OS 及びアプリケーションの更新状況，並びにブラウザ及びウイルス対策ソフトの状況を集中管理する。

表 再発防止策

(e) テストサーバへのデータアップロードを FTP 以外の方法に変更する。

図 2 (4)

攻撃者は，送付されてきた FTP サーバの IP アドレスや FTP アカウントの ID とパスワードを使って，利用者が管理する Web サイトに侵入してページを改ざんしたり

(a) は，盗まれた FTP アカウントを使う攻撃者が U 社の外から入るのを止める策で，図 2 の (4)（盗んだ ID とパスワードでサイトに侵入して改ざんする）に効く。

(c) は，OS やアプリケーションを最新に保って脆弱性を突かれないようにする策なので，(2)（アプリケーションの脆弱性を突いて感染）。(d) の JavaScript の無効化は，改ざんされたサイトに埋め込まれた JavaScript によるリダイレクト（(1)）を防ぐので，ウは(1)。(e) の FTP 以外への変更は，FTP クライアントから ID とパスワードが盗まれる (3) と，その FTP アカウントで侵入される (4) の両方に効くので，エ，オは (3) と (4)。

解答例は ア(4)，イ(2)，ウ(1)，エ(3)，オ(4) で，エ，オは順不同。(b) は短期的対策で，(1)，(2)，(3) に対応すると表に書かれている。

本文の根拠

〔ホームページ制作業務の流れ〕

U 社では，ホームページ制作部門からインターネットに向けた FTP アクセスは，プロキシサーバ経由だけに限定している。

図 1

U 社データセンタには，ルータと FW3 があり，その内側にプロキシサーバとメールサーバが接続されている。

ホームページ制作部門からインターネットに向けた FTP は，プロキシサーバ経由に限定されている。したがって，FTP 専用 PC 以外の社内からの FTP を制限する対策は，全部門の FTP が通るプロキシサーバで行えばよい。

各部門内は固定 IP アドレスなので，プロキシサーバで，FTP を許す接続元の IP アドレスを FTP 専用 PC のものだけにすれば，ほかの PC からの FTP は通らない。

サーバ名を図 1 から選ぶ設問で，解答例は“プロキシサーバ”（7 字）。

本文の根拠

〔ホームページ制作業務の流れ〕

また，共用 PC からは納品時に本番サーバにアップロードすることもある。

図 2 (3)

不正プログラムが，FTP サーバの IP アドレスや，FTP クライアントのパスワード保存機能から FTP アカウントの ID とパスワードを盗み出して，攻撃者のサーバに送付する。

〔テストサーバ上のページ改ざん〕

どの顧客に被害を与えたかを調査するよう指示があった。

共用 PC が感染していたので，被害の範囲は，共用 PC から FTP でアクセスしたサーバが対象になる。図 2 (3)(4) のとおり，感染した PC の FTP アカウントが盗まれ，攻撃者がそのアカウントでサイトを改ざんするからである。共用 PC は，テストサーバだけでなく納品時に本番サーバにもアップロードする。

そこで，一つ目は共用 PC から FTP アクセスしたサーバ（本番サーバとテストサーバ）を調べる。二つ目は，それらのサーバで改ざんがないかの調査を依頼する。講評は，被害のあった顧客の範囲が明確になる調査を求め，“ブラウザから直接ページにアクセスして試す”ような被害を広げかねない調査方法は誤りだとしている。

各 40 字以内で，解答例は 33 字と 31 字。①は調べる対象，②は改ざんの有無を確かめる依頼，と役割を分けて書く。

採点講評（IPA）

設問3(1)は，正答率が低かった。状況設定を理解して，被害があった顧客の範囲が明確になるような調査方法を解答してほしかった。“改ざんがないかブラウザから直接ページにアクセスして試す”といった，被害拡大につながりかねない危険な調査方法を解答している例が散見された。

本文の根拠

〔テストサーバ上のページ改ざん〕

アクセスが業務上必要でないと判断される URL を登録する b リスト方式の URL フィルタ

図 2 (1)

改ざんされた Web サイトにアクセスすると，トロイの木馬型の不正プログラムを送り込む Web サイト（以下，不正プログラム送り込みサイトという）に強制的にリダイレクトされる。

図 2 (4)

利用者が管理する Web サイトに侵入してページを改ざんしたり，不正プログラム送り込みサイトに作り変えたりする。

W 社の URL フィルタは，ブラックリスト方式なので，登録された URL だけを遮断する。W 社の利用者がテストサーバのページを開くと，埋め込まれた JavaScript で不正プログラム送り込みサイトにリダイレクトされ，それがブラックリストに登録されていたから遮断できた。

G 攻撃の被害が拡大すると，不正プログラム送り込みサイトが図 2 (4) のように増え，そのなかには，業務で利用する Web サイトに作り変えられたものも出てくる。業務で必要な Web サイトは URL フィルタにも登録できず，リダイレクトを遮断できない。

解答例は“不正プログラム送り込みサイトが業務で利用するWebサイトであり，URLフィルタでは遮断されない場合”の 49 字（55 字以内）。講評は，テストサーバが改ざんされて不正プログラム送り込みサイトになった場合のような，テストサーバの改ざん内容の説明に終わる解答が散見されたとしている。

採点講評（IPA）

設問3(2)は，正答率が低かった。G攻撃のシナリオから，テストサーバが改ざんされる条件を洗い出した上で，不正プログラム送り込みサイトが増えたときのURLフィルタの限界に注意して解答してほしかった。“テストサーバが改ざんされて不正プログラム送り込みサイトになった場合”など，テストサーバの改ざん内容を説明しようとする解答が散見された。