平成23年度 特別試験 午後Ⅰ（旧試験）

本文の根拠

図 6

string::iterator readPoint = src.a();

図 6

string::iterator atEOL = src.b();

図 6

while(readPoint != atEOL){

図 6 は，文字列を指すイテレータ readPoint を 1 文字ずつ進めながら処理し，readPoint が atEOL に等しくなったら while を抜ける。したがって a には“先頭の文字を指すイテレータ”を返すメンバ関数，b には“終わりの位置を表すイテレータ”を返すメンバ関数が入る。

C++ の std::string（basic_string）では，begin() が先頭の文字へのイテレータを返し（ア），end() が最後の文字の次の位置へのイテレータを返す（ウ）。end() が返す位置は番兵として比較にだけ使い，参照してはならない（cppreference.com の std::basic_string::begin，end の説明）。図 6 の while の条件は readPoint != atEOL であり，ループの中では readPoint が指す文字だけを読むので，この使い方と合っている。

解答群の中で，図 6 の“先頭から終わりの位置まで走査する”処理に当たる組合せは begin と end だけである。a は begin（ア），b は end（ウ）で，a と b の記号を逆にしないよう注意する。

本文の根拠

図 3

なお，n の値は dst が指す文字列に書き込める最大バイト数とする。

図 4

dst[dstPos++] = '%';

図 4 の関数が値を書き込むのは，14 行目，18 行目，20 行目，22 行目，26 行目の dst[…] である。dst は呼出し側が用意した領域を指す引数で，図 3 のとおり書き込める最大バイト数は n と決められている。この n を超えて dst[dstPos++] に書き込むと，領域の外のメモリを書き換えるので，バッファオーバフローが起きるのは dst が指す領域である。

フラグ変数が書き換わったという本文の記述は，dst の領域の隣にフラグ変数が置かれていたことによる結果であり，オーバフローが発生する場所そのものではない。src は読み出しだけに使われ，srcPos や dstPos，x は int や char のローカル変数で，書込み先ではない。

20 字以内で，図 4 中の変数名を使うことが求められている。解答例は“dstが指し示す領域”の 10 字で，“dst が指す領域”のように，変数名 dst を使って領域を特定する。

本文の根拠

図 4

while(src[srcPos] != '\0' && dstPos < n){

図 4

dst[dstPos++] = '%';

図 4

dst[dstPos++] = x <= 9 ? x + '0' : x - 10 + 'A';

6 行目の while は dstPos < n の間だけ副文を実行する。副文のうち，エンコードしない場合は dst に 1 バイトを書くだけだが，エンコードする場合（else 側）は '%' と 16 進 2 桁の合計 3 バイトを続けて書き込む（18，20，22 行目）。そして書込みの前には，領域に残りがあるかどうかを確かめていない。

そのため，残りが n - dstPos で表されるとき，残りが 3 バイト未満（2 バイト以下）の時点でエンコードすべき文字が来ると，3 バイトを書き込む途中で n を超え，オーバフローが起きる。残りが 1 バイトのときに while の条件は真になるので，この状態でも副文に入る点が見落としやすい。

60 字以内なので，解答例は 48 字。“残りが 2 バイト以下”と“エンコードすべき文字があった場合”の二つの要素を両方入れる。dstPos < n という while の条件だけを書き写すと，エンコードで 3 バイト書くことに触れていないので条件として足りない。

本文の根拠

〔関数の仕様変更〕

図 4 のソースコードでは文字列を配列として取り扱っていたので領域の境界をプログラムで管理する必要があったが，図 6 のソースコードでは c ので，バッファオーバフローが発生することはなくなった。

図 6

dst.push_back(*(readPoint++));

図 4 は dst を char のポインタ，つまり配列として受け取り，領域の大きさを n で別に渡して dstPos < n と照合する必要があった。図 6 には n に当たる引数も，書込み位置を数える変数もなく，dst は string 型で，書込みは push_back で行い，ループの終わりも atEOL との比較だけである。

つまり，文字列の長さや領域の確保・拡張は string クラス（標準ライブラリの処理系）に任せており，領域の境界をプログラム側で管理しなくてよい。これが，図 4 にあって図 6 に無い“技術的理由”である。

60 字以内で，解答例は 43 字。“string クラスとして扱っている”だけでなく，“領域の境界は処理系が管理する”という，管理の主体まで書く。

採点講評（IPA）

設問3は，正答率が低かった。図6では領域の境界をプログラムで管理する必要がないことは問題中の記述から読み取れる。その上で，なぜ必要がないのか，代わりにどのような仕組みで管理するのかという点を具体的に解答してほしかった。これは類似の脆弱性を回避するために重要な点であり，確実に理解しておいてほしい。

本文の根拠

図 7

文字列を格納するための d の使用を禁止する。

図 7

配列又はポインタに添字を指定して書込みを行う場合，e を毎回実施する。

図 7

引数としてポインタを受け取った場合，添字指定での f は禁止する。

d：2 の項目に“オブジェクトを生成する場合，できる限り標準 C++ライブラリで定義されたクラスを使用する”とあるのと対になる規定で，文字列の取扱いでは，図 6 のように string クラスを使うことにして，文字列を格納する“文字型の配列”（char の配列）の使用を禁止する。

e：配列やポインタへ添字で書き込む場合は，図 4 の dst[dstPos++] のように，書込み位置が領域の大きさ（n）を超えないかを確かめなければならない。この確認が“上限チェック”で，書込みのたびに行う（毎回実施する）。

f：引数でポインタを受け取った関数は，指す領域の大きさをポインタだけからは知れないので，図 3 のように大きさ n を別に渡す必要がある。そのような領域へ添字を指定して値を“代入”する（図 4 の dst[dstPos++] = …）のを禁止すれば，同様の問題が防げる。各 8 字以内で，解答例は d が 6 字，e が 6 字，f が 2 字。

採点講評（IPA）

設問4では，開発標準ルールの具体的な記述を問うた。プログラム開発では，脆弱性対策だけでなく品質確保の面からも，開発標準ルールを決めることは重要である。具体的な開発標準ルールなどを参考に学習してほしい。

本文の根拠

図 1 (2)

旧バージョンのライセンス保持者だけに許諾される a ライセンスが提供される場合もある。

図 1 (3)

正規のライセンス料のほかに，b 金や訴訟費用を請求される場合もある。

図 1 (3)

許諾ライセンス数を超えるインストールなどが c 法に違反すると指摘された事例もある。

a：学校などの教育機関の利用者だけに許諾されるアカデミックライセンスと並べて，“旧バージョンのライセンス保持者だけに許諾される”ライセンスが挙げられている。旧バージョンの保持者が新しいバージョンへ移行するときのライセンスなので，“アップグレード”が入る。

b：契約違反に問われたときに，正規のライセンス料のほかに訴訟費用と並べて請求される金は“損害賠償”金である。

c：海賊版の使用や許諾数を超えるインストールは，ソフトウェア（プログラム）の著作物を無断で複製する行為に当たる。プログラムの著作物は著作権法第 10 条第 1 項第 9 号に著作物の例として挙げられているので，違反するのは“著作権”法である。いずれも字数の指定は無く，解答例は a がアップグレード，b が損害賠償，c が著作権の 3 語。

本文の根拠

〔ライセンスの実態調査〕

ただし，ソフトウェアの使用数に比べて保有ライセンス数がかなり多い部門も存在していた。

〔ライセンスの実態調査〕

このようなライセンスの中には，他部門が購入を予定しているものも含まれていた。

各部門は，自部門が保有するライセンス数と自部門で使うソフトウェアの数だけを見るので，部門内の調査だけでは，自部門の余りが他の部門の不足を埋められるかどうかは分からない。全社の保有ライセンス一覧表と使用ソフトウェア一覧表を突き合わせて初めて，ある部門に余っているライセンスと，他部門が購入を予定しているソフトウェアが一致していることが分かる。

本文の調査結果では，使用数に比べて保有数がかなり多い部門があり，その中に他部門が購入を予定しているものが含まれていた。このような使われていないライセンスを部門の壁を越えて使えば，新規購入を減らせる。全社の調査から把握できるのは，この“遊休ライセンスを全社で有効に使える見込み”である。

25 字以内なので，解答例は 20 字。“ライセンスが不足している”“不正にインストールされている”のように，各部門の調査でも分かることを書かない。

採点講評（IPA）

設問2は，正答率が低かった。全社としての調査で初めて把握できる内容を解答してほしかったが，各部門の調査でも把握できるような誤った解答が散見された。

本文の根拠

〔ソフトウェア資産管理ツールの導入〕

①インストール情報が記録されないソフトウェアがある

表 1

PC 上でソフトウェアが実行されたときに，PC の OS が採取した実行情報を収集し，PC ごとの収集実行情報として管理サーバ上に保存する。

下線①のソフトウェアは，インストール時に OS へ識別情報が記録されないので，インストール情報を集めるだけでは見つからない。管理ツールには，これと別に，表 1 の実行情報収集機能がある。この機能は PC 上でソフトウェアが実行されたときに OS が採取する実行情報を収集する。

ソフトウェアは実行されれば，インストール情報の有無にかかわらず OS に実行情報が残る。さらにソフトウェア比較機能は，新しい収集実行情報をライセンス未登録とマークして警告を出すので（表 1），インストール情報に載らないソフトウェアも，実行情報から検出してライセンスの割当てを促せる。

40 字以内で，解答例は 28 字。“実行情報を収集するから”だけでなく，“インストール情報が存在しなくても”という前提を入れて，下線①の場合に検出できる理由として完結させる。

本文の根拠

〔管理ツールの活用〕

表 1 中の機能で，該当するセキュリティパッチの適用状況を把握できることが判明した。

表 1

PC 上のソフトウェアのインストール情報を定期的に収集し，PC ごとの収集インストール情報として管理サーバ上に保存する。

〔管理ツールの活用〕

インストール情報の一部として，ソフトウェアのバージョン（セキュリティパッチの情報を含む）を管理する機能がある。

表 1 のインストール情報収集機能は，PC ごとにソフトウェアのインストール情報を定期的に集めて管理サーバに保存する。本文のとおり，インストール情報にはバージョン（セキュリティパッチの情報を含む）が含まれる。

ウイルスは，あるソフトウェアに特定のセキュリティパッチを適用すれば感染しないものだったので，管理サーバ上のインストール情報から，そのパッチが含まれていない PC を抽出すれば，感染するおそれのある PC を事前に特定でき，適用を促せる。これが“管理ツールの機能の活用”に当たる。

45 字以内で，解答例は 38 字。“管理ツールで調べた”だけにとどめず，何を条件に PC を抽出するのか（特定のパッチが含まれていない）まで書く。

本文の根拠

〔管理ツールの活用〕

開発元のセキュリティパッチ提供が終了したソフトウェアの利用が問題になっているという記事を見た。

〔管理ツールの活用〕

開発元のセキュリティパッチ提供が終了したソフトウェアを抽出できるのではないか

開発元のセキュリティパッチの提供が終了したソフトウェアは，あとから脆弱性が見つかっても，開発元から修正が提供されない。その状態で使い続けると，脆弱性を悪用されても，パッチの適用という通常の対処ができない。

管理ツールでそのようなソフトウェアを抽出できれば，どの PC がそうしたソフトウェアを使っているかを把握でき，使い続けるリスクがある状況を認識して避ける手を打てる。つまり，“脆弱性が発見されても対処する手段がない”という状況を回避できることが，情報セキュリティの観点での意義である。

45 字以内で，解答例は 37 字。“新たな脆弱性が発見されたら速やかに対処できる”と書くのは誤りで，提供が終了していれば，脆弱性が見つかっても開発元のパッチは出ない（講評が指摘する誤答）。

採点講評（IPA）

設問4(2)は，正答率が低かった。セキュリティパッチの提供が終了したソフトウェアを抽出することの意義として，“新たな脆弱性が発見されたら速やかに対処できる”という解答も見られたが，脆弱性が発見されたとしても，開発元からセキュリティパッチは提供されない。このような危険な状況は，直ちに回避する必要がある。

本文の根拠

〔管理ツールの活用〕

PC を異動後の部門に持っていく場合には，使用ライセンス登録機能で，使用ライセンス情報の利用者所属部門を更新するとともに，業務内容の変更に伴って新たに必要となるソフトウェアがあれば PC にインストールし，使用ライセンス登録機能で使用ライセンス情報に追加登録する。

表 1

使用ライセンス情報，既存インストール情報，及び既存実行情報は削除又は更新することも可能である。

異動後の部門へ PC を持っていく場合の手順は，利用者所属部門の更新と，新たに必要なソフトウェアのインストール・使用ライセンス情報への追加登録だけで，業務内容の変更で要らなくなったソフトウェアの扱いが書かれていない。

そのまま使い続けると，不要なソフトウェアが PC に残り，使用ライセンス情報にも残る。そこで下線②の“PC 上で更に実施すべきこと”は，異動に伴い不要になったソフトウェアの削除（アンインストール）で，管理ツール上では対応する使用ライセンス情報を削除し，ライセンスを再び割り当てられる状態にする（表 1 のとおり，使用ライセンス情報は削除又は更新できる）。

30 字以内で，解答例は 23 字。問われているのは PC 上のことなので，管理ツール上の作業（使用ライセンス情報の削除）には触れない。

本文の根拠

〔管理ツール運用上の問題点の改善〕

管理ツール利用者が自分自身で利用するソフトウェアであっても保有ライセンス情報を登録できる一方，登録された保有ライセンスが購入されたライセンスであるかどうかを C 社では確認していない。

〔管理ツール運用上の問題点の改善〕

管理ツール利用者は，自分自身が利用するソフトウェアの保有ライセンス情報を登録できないようにする運用方針

現状では，ソフトウェアを使う本人が保有ライセンス情報を登録でき，しかも登録内容が実際に購入されたものかを確認していない。本文は，保有ライセンス情報を不正に登録されると，ライセンス管理がうまく機能しないおそれがあるとしている。

運用方針は，利用者が自分のソフトウェアの保有ライセンス情報を登録できないようにするものである。そうすると登録は利用者以外の第三者が行うことになり，利用する人と登録する人が別々になる。権限を分けて，互いにチェックが働く（相互けん制）仕組みになるので，不正な登録をしにくくなる。

30 字以内で，解答例は 26 字。“不正を防げるから”だけでは理由にならない。利用者と登録者が別であることによって，互いにけん制が働く点まで書く（講評の“権限分離”“相互けん制”）。

採点講評（IPA）

設問5は，正答率が低かった。権限の集中による不正行為を防ぐために，“権限分離”又は“相互けん制”という考え方に基づき，ソフトウェアの利用者以外の第三者が登録することを理解してほしかった。

本文の根拠

表 2 (ア)

情報を秘匿するための a

表 2 (ア)

情報は a していない。

表 2 の(ア)は，持出中に貸与 PC が盗まれる又は紛失するリスクで，有効と考えられる対策の一つが“情報を秘匿するための a”，実施状況が“情報は a していない”である。持ち出した PC が第三者の手に渡っても，中身を読めなくするための対策なので，情報を暗号化することが入る。

暗号化しておけば，PC 本体を失っても，保存された情報は鍵が無ければ読めない。ただし，貸与 PC の取扱方法に関する規定が無いことから分かるように，この対策は PC の持運び方（設問 2）の対策とは別に必要な，もう一つの対策である。

3 字以内なので，解答例は“暗号化”の 3 字。表 3 の a も同じ語が入る。“秘匿”“暗号”のような字数不足や不適切な語にしない。

本文の根拠

〔M における情報漏えい対策の検討〕

案 1，案 2 は，いずれも表 2 の(ア)及び(イ)のリスクを b することができる。

〔M における情報漏えい対策の検討〕

業務として特定顧客向けの業務情報を取り扱う以上，案 1 と案 2 のいずれであっても b することはできないので，c 策を取ること

案 1，案 2 は，貸与 PC を社外へ持ち出さず，業務情報も持ち出さない対策である。そのため，表 2 の(ア)（持出中の盗難・紛失）と(イ)（持出中のマルウェア感染）のリスクは，原因となる持出しそのものをやめることで発生させない。これはリスクの“回避”に当たり，b には回避が入る。

(ウ)の不正開示は，特定顧客向けの業務情報を顧客に開示する以上，開示すること自体をやめるわけにはいかず，回避できない。そこで，不正開示が起きる可能性や影響を小さくする“低減”策を取ることになり，c には低減が入る。組合せは b が回避，c が低減のイ。

ア・ウ・エは，b が移転や低減になっていたり，c が回避や移転になっていたりする。(ウ)は，案 2 でも上司の確認によって“低減”できるとされており（本文），c が回避ではない点でも確かめられる。

本文の根拠

表 2 (ア)

貸与 PC の安全な持運びに関する注意点の周知（この内容に下線①が付いている）

表 2 (ア)

持出中に貸与 PC が盗まれる又は紛失する。

下線①は，(ア)のリスク（持出中の貸与 PC の盗難・紛失）に対する対策としての“安全な持運びに関する注意点”である。盗まれる，なくすのは，PC から手や目を離したときに起こるので，注意点は PC を手元から離さないことになる。

本文は，この設問のリスクを，貸与 PC を社外へ持ち出すことを前提にしたものとして整理している（表 2 の(ア)の“持出中に”）。したがって“持ち出さない”という答えは，問われている持運びの注意点にならない。

15 字以内で，解答例は“移動中は肌身離さず持つ。”の 12 字。“具体的に”とあるので，“盗難に注意する”のような一般論でなく，“肌身離さず”のように行動を書く。講評は，持運び自体を禁止するという誤答を指摘している。

採点講評（IPA）

設問2は，正答率が低かった。PCの持運びに関する注意点を問うているにもかかわらず，持運び自体を禁止するといった誤った解答が散見された。設問で何が問われているのかを，落ち着いて把握するようにしてほしい。

本文の根拠

〔M における情報漏えい対策の検討〕

日常業務に利用している貸与 PC を持ち出していることで，万一，情報漏えい事故が発生すると被害が大きくなるおそれがある

〔M における情報漏えい対策の検討〕

営業担当者が業務情報を持ち出す必要をなくし，貸与 PC の社外への持出しも禁止することが情報漏えい対策として望ましいと考えた

M で営業担当者が持ち出す貸与 PC は，持出情報（顧客に見せる情報）だけを入れたものではなく，日常業務で使っている PC である。そのため，持ち出す必要のあった情報のほかにも，日常業務の業務情報がこの PC に入っている。

持出中にこの PC が盗まれる又は紛失すると，持出情報だけでなく，PC に入っていた他の業務情報まで漏えいする可能性がある。被害が大きくなるのはそのためで，下線②が，業務情報を持ち出す必要をなくし，貸与 PC の持出しも禁止する対策につながっている。

45 字以内で，解答例は 42 字。“持ち出す情報が多いから”のような量の話ではなく，“持出時に必要な情報以外の業務情報も”入っている点を明示する。

本文の根拠

図 1 案 2 (3)

E 社の営業担当者は，業務情報を当該顧客専用のディスク領域にアップロードした上で，当該顧客にダウンロードをしておくよう依頼する。

〔M における情報漏えい対策の検討〕

万一，公開 Web サーバが不正アクセスされても，業務情報が漏えいするリスクをできるだけ小さくするための運用上の対策

案 2 では業務情報を公開 Web サーバに置く。公開 Web サーバはインターネットから到達できるので，不正アクセスされる可能性がある。その場合に漏えいするリスクを小さくするには，業務情報が公開 Web サーバに置かれている時間を短くすればよい。

そこで，運用上の対策は，顧客を訪問する直前にアップロードし，顧客がダウンロードしたらすぐに削除することである。アップロードを前日などに行わず，ダウンロード後に消すので，サーバ上に情報がある間だけが危険にさらされる。

45 字以内で，解答例は 41 字。“直前にアップロード”と“ダウンロード後すぐに削除”の二点が要素。講評は，認証・アクセス制限や DMZ の設置を挙げた誤答に触れており，これらは不正アクセスを防ぐ方法で，不正アクセス後の被害を抑える運用ではない。

採点講評（IPA）

設問3(2)は，正答率が高かったものの，認証やアクセス制限，DMZの設置によるWebサーバ自体の防御といった誤った解答が散見された。これらは，いずれも不正アクセスを防ぐための方法であり，設問で問われている不正アクセス後の被害の拡大防止には寄与しない。各種の対策がどのようなリスクに対して効果をもっているのかを，改めて確認しておいてほしい。

本文の根拠

〔M における情報漏えい対策の検討〕

アップロード時に故意又は過失で当該顧客向け業務情報を他社に開示するリスクがあるが

図 1 案 2 (1)

E 社の公開 Web サーバ上に，各顧客専用のディスク領域をあらかじめ作成しておく。

案 2 は，各顧客専用のディスク領域に業務情報をアップロードする方式で，顧客ごとに領域が分かれている。アップロード時の不正開示のリスクは，間違った顧客のディスク領域に，あるいは別の顧客向けの情報を，アップロードしてしまうことで起きる。

そのため，上司が確認すべきことは，アップロードしようとしている業務情報が，アップロード先の顧客向けの情報であることである。この確認があれば，リスクを低減できると本文は述べている。

35 字以内で，解答例は 28 字。“アップロード先が正しいか”だけでなく，“業務情報が当該顧客向けのものか”という情報の中身との対応を書く。

本文の根拠

〔対策案の見直し〕

案 2 では，(イ)のリスクに対する有効な対策を取ることが困難

表 3 (イ)

マルウェアに感染した私有 PC で持出情報を扱う。

表 3 (イ)

私有 PC におけるマルウェアの対策状況を定常的に把握できていない。

H（自宅での資料作成）では，持出手段に貸与 USB メモリがあり，従業員が私有 PC を使って業務情報にアクセスすることがある。案 2 は公開 Web サーバに業務情報を置き，ダウンロードして使う方式なので，H で使うと従業員が自宅の私有 PC に業務情報をダウンロードすることができる。

表 3 のとおり，私有 PC は，マルウェア対策の状況を把握できておらず，インストールできるソフトウェアの制限やセキュリティパッチの適用も徹底できていない。つまり，会社が管理していない，セキュリティ対策が十分でない可能性のある PC に業務情報が入ってしまい，(イ)のマルウェア感染のリスクに有効な対策が取れない。案 1 の専用端末なら，業務情報を端末に保存せず，私有 PC に置かない形にできる。

55 字以内で，解答例は 49 字。“私有 PC のセキュリティ対策が不十分”と“案 2 では業務情報をダウンロードできてしまう”の二点を，理由として一文にまとめる。

採点講評（IPA）

設問4は，正答率が低かった。マルウェア対策が困難な理由を問うたが，Webサーバへの感染拡大といったウイルス感染後の事象を述べた誤った解答が散見された。感染後に何が起こるかは，感染対策が困難であることとは直接の関係がないことを理解した上で解答してほしかった。

本文の根拠

表 1 V-2

S サイトからいったんログアウトした後に，再びログインせずに，URL を直接指定することで S サイトの会員個人の専用情報ページを閲覧できた。

〔セキュリティ対策の検討〕

V-2 の対策としては，ログアウト時に a 処理を実装します。

V-2 は，ログアウトしたのに，URL を直接指定するだけで会員の専用ページを閲覧できた問題である。ログアウト後もサーバ側で“ログイン済み”の状態が残っていて，その状態が使われていると考えられる。したがって対策は，ログアウト時にサーバ側のセッション情報を破棄する処理（ウ）である。

ア（クッキーにパスワードをセットする）は，パスワードを保存・送信する側を増やすだけで，ログイン状態を終わらせない。イ（再認証を行う）は，ログアウトの時点で行っても，その後の URL 直接指定による閲覧を防ぐ働きがない。エ（ログを採取する）は，閲覧の記録を残すだけで，閲覧自体を止められない。

解答群から選ぶ設問で字数制限は無いので，記号は“ウ”の 1 つだけを答える。選択肢は文の形が似ているので，“ログアウト時に行う処理”として意味が通るかを，V-2 の症状から確かめる。

本文の根拠

表 1 V-6

Web サーバへのコンテンツファイル転送時の通信を盗聴して，CNT-MGR のパスワードを窃取できた。

〔セキュリティ対策の検討〕

コンテンツファイル転送時の認証方法を FTP の認証ではなく SSH のパスワード認証に変更しようと思います。

V-6 は，転送時の通信を盗聴されてパスワードが盗まれた問題で，対策は転送を SSH（暗号化された通信路）の上で行うことである。SSH を使ったファイル転送には scp と sftp がある。OpenBSD の OpenSSH のマニュアルでは，scp は“ホスト間でファイルをコピーする”コマンドで認証と通信に ssh を使い，sftp は“暗号化された ssh の通信路の上であらゆる操作を行う”ファイル転送プログラムと説明されている。

従来の FTP の転送では，ftp コマンドを使う。これは，SSH による暗号化の対象ではないので，答えにならない。

5 字以内で，scp（3 字）と sftp（4 字）のどちらでもよい。解答例も“scp 又は sftp”と，別解が示されている。

本文の根拠

表 1 V-5

CNT-MGR のパスワードを推測して，Web サーバへの FTP 接続を何度か試行し，最終的に成功した。

〔セキュリティ対策の検討〕

SSH では，IP アドレス制限に頼らなくても，認証方式を b にすることによって，更にアクセス者を限定できます。

V-5 の問題は，パスワードを推測して何度も試すことで認証を突破されることである。K 課長は，N 社の担当者が N 社以外からもアクセスするので，アクセス元を IP アドレスで限定できないことを不安としている。

SSH のサーバは，認証方式ごとに許可するかどうかを設定できる（OpenSSH の sshd_config では，公開鍵認証 PubkeyAuthentication とパスワード認証 PasswordAuthentication を別に指定する）。認証方式を公開鍵認証にし，パスワード認証を許可しなければ，パスワードを推測する攻撃は成立しない。また，秘密鍵を持つ人だけがログインできるので，IP アドレスに頼らず，アクセスする人を限定できる。

10 字以内で，解答例は“公開鍵認証方式”の 7 字。講評も，パスワード認証の SSH はブルートフォース攻撃で危険性が高く，公開鍵認証の理解が不可欠だとしている。

採点講評（IPA）

設問1(3)は，正答率が低かった。パスワード認証方式のSSHは，活発なブルートフォース攻撃によって危険性が高くなっているので，公開鍵認証方式の理解が不可欠である。

本文の根拠

図 1

注記 FW ではドロップログ（通信を拒否したログ）だけを収集している。

〔セキュリティ対策の検討〕

外部向けの不要な通信を拒否するように FW のフィルタリングルール（以下，FW ルールという）を変更することを提案した。

G 氏が提案した FW ルールの変更は，外部向けの不要な通信を拒否するものである。FW ルールに違反してファイルを外部へ送信しようとする試みは，FW に拒否されることになるので，拒否された通信の記録が残る。

図 1 の注記のとおり，この FW が収集しているのはドロップログ（通信を拒否したログ）だけである。したがってシステム課の担当者は，このドロップログを，ログを保存するだけでなく，定期的に分析して，拒否された外部向けの通信に試みがないかを調べればよい。

35 字以内で，解答例は 30 字。講評は，ログを保存するという趣旨だけの誤答が多かったとしており，“分析する”と“拒否した通信（ドロップログ）”を両方入れる。

採点講評（IPA）

設問1(4)は，ログを保存するという趣旨だけの誤った解答が多く見受けられた。FWのドロップログを分析することで様々なインシデントやその予兆を検知できることを理解しておいてほしい。

本文の根拠

図 2

スクリプトファイルに対して，読取り，書込み及び実行が可能である。

〔ペネトレーションテストによる現状確認〕

R アプリのスクリプトには，DB への接続情報（DB 利用者 ID，パスワード），ビジネスロジック，及び画面表示処理が含まれている。

〔セキュリティ対策の検討〕

R アプリで鍵長 256 ビットの AES を使って，会員データを暗号化しようと考えています。その場合，暗号鍵は定数としてスクリプト内に定義します。

〔セキュリティ対策の検討〕

本来であればコンテンツファイルの確認のために新たに独立したテスト環境を構築し，N 社にはそのテスト環境にだけアクセスさせ，本番環境にはアクセスさせないようにすべきである

閲覧するための方法：図 2 のとおり，CNT-MGR はスクリプトファイルを読み取り，書き込み，実行できる。スクリプトには DB への接続情報が含まれ，K 課長の案では暗号鍵も定数としてスクリプト内に定義するので，N 社の担当者はこれらを読み取れる。これを使って，DB に接続して会員データを復号し表示するスクリプトを作成し，実行すれば，会員データを閲覧できる。

暫定対策の内容：テスト環境を用意するまで，N 社の担当者を本番環境に近づけない手段が要る。コンテンツファイルの保守にスクリプトファイルの読取り・書込み・実行は必要でないので，CNT-MGR からスクリプトファイルへのアクセス権限を全て削除すればよい。必要な権限だけを与える最小権限の考え方で，講評も，必要のないスクリプトファイルへのアクセス権限を付与するとリスクが増すとしている。

閲覧の方法は 50 字以内で解答例は 43 字，暫定対策は 40 字以内で解答例は 35 字。前者は“作成”と“実行”，後者は“全てのスクリプトファイル”と“アクセス権限の削除”が要素。

採点講評（IPA）

設問1(5)は，正答率が低かった。本来ならば必要のないスクリプトファイルへのアクセス権限を付与することでリスクは増大する。最小権限の原則を改めて意識してほしい。

本文の根拠

〔セキュリティ対策の検討〕

V-1 の対策のアカウントロックは一つの会員 ID に対するログイン試行を想定しているので，大量のほかの Web サイトの認証情報を悪用するログイン成功を防ぐことはできません。

〔セキュリティ対策の検討〕

多くの会員は，S サイトに登録しているメールアドレスとパスワードの組合せ（以下，認証情報という）と同じものを，ほかの Web サイトでも登録していると思われます。

下線④の攻撃は，ほかのサイトで盗まれた認証情報（メールアドレスとパスワードの組合せ）を使い，S サイトに次々とログインを試す。アカウントロックは一つの会員 ID に対する試行を想定しているため，大量の認証情報を使う試行には効かない（G 氏の説明）。

検知条件には，一つの会員 ID でなく，攻撃全体の特徴を使う必要がある。時間（一定時間内），アクセス元（同一 IP アドレス），回数（複数の会員 ID に対する試行が一定回数以上），結果（認証に失敗している）を組み合わせる。

60 字以内で，解答例は 51 字。講評は，時間・アクセス元・回数は書けているが，ログイン試行の結果（成功か失敗か）の条件が欠けた解答が多いとしている。結果を条件にしないと誤検知が大量に発生する。

採点講評（IPA）

設問2は，ログイン試行の時間，アクセス元，回数に関しては触れていたが，ログイン試行の結果（成功又は失敗）に関する条件が欠けている解答が多く見られた。結果に関する条件を明確にしないで検知しようとすると誤検知が大量に発生してしまうことを覚えておいてほしい。