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

本文の根拠

図 2

string query = "SELECT report FROM reports WHERE user = '" + user + "'";

図 2

query += " AND day = '" + day + "'";

図 1

user － 利用者画面からの入力を基に作成した営業社員名

SQL インジェクションは，利用者が入力した値が SQL 文の一部として解釈されることで起きる。図 2 では，SQL 文を表す変数 query に，文字列の連結（+）で user と day の値をそのまま埋め込んでいる。図 1 の仕様のとおり，user も day も“利用者画面からの入力を基に作成した”値なので，ここが原因になる。

コード上の変数名は多いが，SQL 文の組立てに使われているのは user と day の二つだけである。con はデータベースへの接続，stmt と res は文の実行と結果を扱うオブジェクトで，rep は SQL 文の実行後にデータベースから取り出した値であり，SQL 文の組立てには使われていない。

この設問は変数名を全て挙げる形なので，解答例は“user，day”と二つを並べる。一つだけでは不十分で，講評も(1)は比較対象もあって正答率が高かったとしている。

採点講評（IPA）

設問1のコード上から変数名を選択する問題では，(1)は比較対象もあり正答率は高かったが，(6)は正答率は低かった。(4)は代表的な脆弱性を解答群から選択する問題で正答率は高かったが，“コマンドインジェクション”という誤った解答が多かった。設問1の中ではプログラミング技法について複数出題したが，開発標準に関する経験が少ないためか，正確に記述できているものが少なかった。

本文の根拠

〔代表的な脆弱性への対策方法の確認〕

この対策は，a を用いて SQL 文を組み立てるというものである。

図 3

string query = "SELECT report FROM reports WHERE user = ? AND day = ?";

図 3 の SQL 文では，user と day の値が入る位置が“?”に置き換わっており，値は pstmt->setString(1, user) のように後から割り当てている。このように SQL 文の雛形に変数の位置を示す記号を置き，値は後から機械的に割り当てる技法がプレースホルダである。IPA の「安全なウェブサイトの作り方」は，SQL 文の組立てを全てプレースホルダで実装することを根本的解決としており，文字列連結のような組立てと違って SQL インジェクションの脆弱性を解消できると説明している。

本文は，この技法を用いて SQL 文を“組み立てる”と述べ，図 3 の PreparedStatement と prepareStatement がその実装に当たる。値を SQL 文の構文の一部ではなく単なる値として扱う点が，図 2 との違いである。

12 字以内なので，解答例は 7 字の“プレースホルダ”。講評は，この設問を含むプログラミング技法の設問で，正確に記述できているものが少なかったと述べている。

本文の根拠

図 3

pstmt = con->prepareStatement(query);

図 4

ps = con.b(query);

図 4 は図 3 の C++コードと同様の対策を Java で実施したものである。図 3 で PreparedStatement を得ている行は pstmt = con->prepareStatement(query); であり，図 4 の対応する行は ps = con.b(query); である。Java の java.sql.Connection インタフェースには，パラメタの位置を“?”で示した SQL 文を受け取り，プリコンパイル済みの PreparedStatement オブジェクトを返す prepareStatement(String sql) メソッドがある（Oracle の Java SE API 仕様）。したがって b は prepareStatement になる。

query は図 4 で“?”入りの SQL 文として用意されており，直後の ps.setString(1, user) と ps.setString(2, day) で値を割り当てている。この流れは図 3 と同じなので，図 3 の呼出し名から答えを導ける。

英字で答える設問なので，大文字小文字は図 3 の呼出しと同じ prepareStatement とする。

本文の根拠

図 2

cout << "user = '" << user << "'<BR>";

図 2

cout << "report = '" << rep << "'<BR>";

〔代表的な脆弱性への対策方法の確認〕

図 2～4 のコードには SQL インジェクション以外にも①代表的な脆弱性の原因となるコードが含まれていることが分かり

図 2～4 のコードは，利用者から受け取った user と day，及びデータベースから取り出した rep を，そのまま HTML の一部として出力している（cout や out.write の行）。入力値に含まれるスクリプトなどが何も処理されずに Web ページへ出力されると，ブラウザがそれを実行してしまう。これがクロスサイトスクリプティング（ア）であり，SQL インジェクション以外で，このコードが原因になる代表的な脆弱性である。設問 1(5) の対策（HTML における特別な記号のエスケープ）も，この脆弱性に対するものである。

図 2～4 には，OS のコマンドを組み立てて実行する処理は無く，セッション ID を扱う処理や，リクエストの送信元を確かめる処理もない。イ（クロスサイトリクエストフォージェリ），ウ（コマンドインジェクション），エ（セッションフィクセーション）は，コードの内容と合わない。

講評は，(4)の正答率は高かったが，“コマンドインジェクション”という誤った解答が多かったと述べている。出力する値が HTML に埋め込まれる点に注目して選ぶ。

採点講評（IPA）

設問1のコード上から変数名を選択する問題では，(1)は比較対象もあり正答率は高かったが，(6)は正答率は低かった。(4)は代表的な脆弱性を解答群から選択する問題で正答率は高かったが，“コマンドインジェクション”という誤った解答が多かった。設問1の中ではプログラミング技法について複数出題したが，開発標準に関する経験が少ないためか，正確に記述できているものが少なかった。

本文の根拠

〔代表的な脆弱性への対策方法の確認〕

B 君は，c を d 処理するという対策を図 3 と図 4 のコードにそれぞれ追加した。

図 3

cout << "user = '" << user << "'<BR>";

設問 1(4) の脆弱性は，出力する値に含まれる HTML の特別な記号（<，> など）が，そのまま HTML の構造として解釈されることで起きる。対策は，そうした記号を別の表記に置き換える処理で，d はエスケープ，対象を示す c は“HTMLにおける特別な記号”である。

この設問は，d に入れる技法を 10 字以内，その技法の対象を c に 20 字以内で答えさせている。“処理する”の前に入るのは技法の名前なのでエスケープ，その目的語として何をエスケープするのかを c に書く。

解答例は d が 5 字，c が 13 字。c は，単に“特別な記号”とせず，どの言語の記号なのかが分かるように“HTMLにおける”を付ける。対象を明確に示すことが求められており，講評も，プログラミング技法の設問は正確に記述できているものが少なかったとしている。

本文の根拠

図 3

cout << "day = '" << day << "'<BR>";

図 3

cout << "report = '" << rep << "'<BR>";

(5)の対策（HTML における特別な記号のエスケープ）の対象は，HTML の一部として出力される変数である。図 3 で出力に使われているのは，user と day（それぞれ“user = ...”“day = ...”の行）と，データベースから取り出した rep（“report = ...”の行）の三つである。query は SQL 文の雛形（定数），con・pstmt・res は出力する値ではない。

rep は利用者が直接入力した値ではなく，データベースに格納されていた営業報告の本文である。入力時の確認に頼らず，出力する位置で一律にエスケープするので，格納された値も含めて三つが対象になる。

講評は，設問 1 のうち(6)の正答率は低かったとしている。出力する変数は user，day，rep の三つあり，rep を含める点を押さえる。

採点講評（IPA）

設問1のコード上から変数名を選択する問題では，(1)は比較対象もあり正答率は高かったが，(6)は正答率は低かった。(4)は代表的な脆弱性を解答群から選択する問題で正答率は高かったが，“コマンドインジェクション”という誤った解答が多かった。設問1の中ではプログラミング技法について複数出題したが，開発標準に関する経験が少ないためか，正確に記述できているものが少なかった。

本文の根拠

図 5

・eによる誤った領域へのアクセス

図 5

・データへのeと，関数へのeを混同したアクセス

図 6

長時間連続動作させる場合には g の実行による応答性への影響を考慮する必要がある。

e は，“誤った領域へのアクセス”の原因であり，“データへの e と，関数への e を混同したアクセス”という表現からも，データのアドレスと関数のアドレスを保持する値であることが分かる。C++で“メモリ内容への柔軟なアクセス”を可能にしているのはポインタである。f は，図 5 で“上記問題が引き起こす代表的な脆弱性”として，境界チェック漏れなどの結果に挙がっており，整数オーバフローと並ぶものはバッファオーバフローである。

g は，図 6 の Java の特性として，Java VM がメモリマネジメントを行うことと対になって“長時間連続動作させる場合には g の実行による応答性への影響”が出るものである。Java VM が不要になったメモリ領域を自動で回収する仕組みであるガーベジコレクションが当てはまる。表 1 の Java のデメリットにも g が挙がっており，同じ語が入る。

字数は e が 6 字以内，f と g が 12 字以内で，解答例は 4 字，10 字，10 字。f は“バッファオーバフロー”と，語尾の長音を付けない表記で答える。講評は，設問 2 は(1)～(3)全て正答率が高かったと述べている。

採点講評（IPA）

設問2では，二つの言語の特性を表す用語を答える問題だったが，(1)～(3)全て正答率は高かった。

本文の根拠

図 5

C++は，メモリ内容への柔軟なアクセスが可能である。

図 6

Java が提供しているメモリ内容へのアクセス手段は限定的であり，メモリマネジメントは言語処理系の一部である Java VM が行う。

図 5 は，C++がメモリ内容に柔軟にアクセスできる一方で，言語処理系自体では問題を防止できないとしている。これに対し図 6 は，Java が提供するメモリ内容へのアクセス手段は限定的で，メモリマネジメントは Java VM が行うと述べている。バッファオーバフロー攻撃が C++で問題になり Java で問題にならない根本的な理由は，Java にはポインタに相当するアドレスを自分で計算して任意のメモリ位置を指す手段が提供されていないことである。解答例は“アドレスを計算対象にできないから”となる。

設問 2 の e（ポインタ）と同じく，図 5 の“誤った領域へのアクセス”や“データへのポインタと関数へのポインタを混同したアクセス”は，アドレスを自由に扱えることから起きる。アドレスを計算の対象にできなければ，領域を越えた位置への書込みの足がかりがなくなる。

20 字以内に収めるときは，“境界をチェックする”のようなコードの書き方ではなく，言語仕様の特徴を書く。講評は，単純なバッファオーバフローの範囲までの解答が多く，正答率が低かったと述べており，言語特性を述べるために問題文を丁寧に読むよう求めている。解答例は 16 字。

採点講評（IPA）

設問3では，二つの言語を比較してバッファオーバフロー攻撃が可能になる言語特性を問うたが，問題文を丁寧に読んでいないのか，単純なバッファオーバフローの範囲までの解答が多く，正答率が低かった。

本文の根拠

表 1

password：ソルトを付加したパスワードの，ハッシュ関数 a によるハッシュ値を表す。

表 2

“仮パスワード”はソルトを付加した仮パスワードのハッシュ値を

表 1 の password 属性は，パスワードそのものではなく，ソルトを付加したパスワードのハッシュ値を保存している。a には，この“ハッシュ関数”として使うアルゴリズム名が入る。解答群の中でハッシュ関数に当たるのは SHA-256（エ）である。

表 2 の注記 2 も，password に設定する“仮パスワード”をソルトを付加した仮パスワードのハッシュ値と説明しており，password の値はパスワードに戻せない形で保存される前提になっている。ハッシュ関数は，入力から固定長の値を求める一方向の関数であり，保存した値から元のパスワードを復元することを目的としない。

誤りの選択肢は暗号化（復号できる）のアルゴリズムである。AES（ア）と RC4（イ）は共通鍵暗号で，このうち RC4 は RFC 7465 でストリーム暗号と説明され，TLS では使わないこと（暗号スイートとして交渉しないこと）が求められている。RSA（ウ）は公開鍵暗号である。いずれも“ハッシュ関数”ではないので，a には入らない。

本文の根拠

表 1

0：ログイン可能，1：ロックアウト状態，2：サスペンド状態

図 1

ログイン時に，パスワードを連続して 5 回間違えた場合，その UID はログイン不可能になる。

図 1

ロックアウト状態は，60 分以上経過した後の最初のログイン時に解除される。

図 1

仮パスワード状態の UID で N システムにログインすると，ログイン処理の中で強制的にパスワード変更ページへ遷移する。

図 3 の流れを，図 1 のセキュリティ要件と表 1 の属性値に照らして読む。UID 名が存在する場合の最初の分岐 b は，YES でパスワード照合へ進み，NO では“status の値が 1”の判定に進む。status が 0（ログイン可能）ならそのままパスワードを照合するので，b は“statusの値が0”である。status が 1（ロックアウト状態）のときは，c でロックアウトを解除してよいかを判定する。解除後の処理が“fails の値に 0 を設定”“status の値に 0 を設定”であることから，図 1 のロックアウトの解除条件，つまり lockout_t の値から 60 分以上経過していることを調べるのが c である。

パスワードが誤りのときは“fails の値に 1 を加える”。その後の d の NO では lockout_t に現在時刻を設定し，status を 1 にして，メール送信する（ロックアウト発生）。図 1 は 5 回連続して間違えるとロックアウトになるので，1 を加えた後の fails が 4 以下なら YES（失敗のまま終了），5 になったら NO でロックアウトとなる。したがって d は“failsの値が4以下”。パスワードが正しいときは“fails の値に 0 を設定”した後，e で仮パスワード状態かを判定する。NO のとき“パスワード変更処理”を行い，その後に“temppass の値に 0 を設定”するので，YES が仮パスワードでない場合に当たる e は“temppassの値が0”である。

字数は b・d・e が 15 字以内，c が 30 字以内で，解答例は 10 字，24 字，11 字，12 字。属性名は表 1 のとおり書く。講評は，設問 2 の正答率は全体的に高かったとしている。

採点講評（IPA）

設問2は全体的に正答率が高かった。利用者IDの状態を意識してログイン処理のフローを設計することは，システムのセキュリティを確保するためにも重要であり，実務においても確実にできることを期待したい。

本文の根拠

図 1

サスペンド状態は，契約企業の利用責任者からのサスペンド解除申請によってだけ解除でき，利用者自身では解除できないようにする。

表 2

設定変更 (b) パスワード初期化：password は仮パスワード，mailaddr は－，status は 0，temppass は 1，fails は 0，lastlogin_t は－。

図 4

このとき，UID の各属性に対して，表 2 の設定変更 (b) に示す値を設定する。

図 4 の設計案は，仮パスワードの発行時に，表 2 の設定変更 (b) の値を UID の属性に設定する。(b) は status を 0 にするので，パスワード初期化の対象がサスペンド状態（status が 2）の UID でも，status が 0 に書き換わり，ログインできる状態になる。

図 1 の（カ）は，サスペンド状態は利用責任者からの解除申請によってだけ解除でき，利用者自身では解除できないようにするとしている。ところが，この設計案では，サスペンド状態の利用者が，取得ページ URL から仮パスワードを発行することで，自分でサスペンドを解除できる。

解答例は 43 字で，45 字以内に収まる。“サスペンド状態の UID が対象になる”こと，及び“利用者自身で解除できる”ことの二つを含める。講評は，設問 3 の正答率がやや低かったとしている。

採点講評（IPA）

設問3は正答率がやや低かった。現行システムの設計や運用手順を十分に理解しないままシステムに不用意な機能追加を行うと，セキュリティ上の問題が発生する可能性があること，及びそういったセキュリティ上の問題を発見するための組織的なレビューが重要であることを再認識してほしい。

本文の根拠

図 2

サスペンド状態の UID に対しては，UID の削除とサスペンド解除の申請だけを受け付け，それ以外の申請は受け付けない。

表 1

0：ログイン可能，1：ロックアウト状態，2：サスペンド状態

問題の原因は，パスワード初期化が status を 0 にする点にある（設問 3(1)）。防止するには，サスペンド状態の UID に対してはパスワード初期化を行わないようにすればよい。図 2 の運用手順 5 は，ヘルプデスクの運用で既にそうしており，サスペンド状態の UID は削除とサスペンド解除の申請だけを受け付ける。同じ制限を，パスワード初期化機能にも設ける。

表 1 のとおり status の値 2 がサスペンド状態を表すので，“status の値が 2 の UID”がパスワード初期化の対象外になる。解答例は“statusの値が2のUIDはパスワード初期化を実行しない。”の 30 字で，35 字以内に収まる。

属性名を使って書くことが求められており，“サスペンド状態の UID”と状態の名前だけで書くのではなく，status の値という判定の基準まで書く。

採点講評（IPA）

設問3は正答率がやや低かった。現行システムの設計や運用手順を十分に理解しないままシステムに不用意な機能追加を行うと，セキュリティ上の問題が発生する可能性があること，及びそういったセキュリティ上の問題を発見するための組織的なレビューが重要であることを再認識してほしい。

本文の根拠

図 2

設定した仮パスワードは，ヘルプデスク担当者が利用責任者に電話し，読み上げて通知する。

図 4

利用者が，メールで通知された取得ページ URL にブラウザでアクセスすると，プログラムが仮パスワードを発行し，ブラウザに表示する。

図 4

発行する仮パスワードは，図 1 のセキュリティ要件を満たし，ヘルプデスク担当者でも推測できない文字列とする。

図 1 の（エ）が仮パスワード状態でパスワード変更ページへ強制的に遷移させるのは，仮パスワードが他人に知られている可能性があるからである。図 2 のヘルプデスクの運用では，仮パスワードをヘルプデスク担当者が決定し，電話で利用責任者に読み上げて通知する。仮パスワードを担当者や利用責任者が知るので，使い続けさせないために強制変更が必要になる。

今回の設計案では，プログラムが仮パスワードを発行して，取得ページを開いた利用者のブラウザにだけ表示し，推測もできない文字列とする。仮パスワードを知るのは利用者だけなので，強制的な変更は不要ではないか，というのが指摘 2 である。

解答例は“仮パスワードを知っているのが利用者だけであるから”の 24 字（30 字以内）。講評は，この設問の正答率が低く，問題文中に記載されたシステムの変更点だけを書いている解答が散見されたとして，状況設定を理解した上で，仮パスワードを知り得るのが誰であるのかに注目してほしかったと述べている。

採点講評（IPA）

設問4は正答率が低かった。問題文中に記載されたシステムの変更点だけを書いている解答が散見された。状況設定を理解した上で，仮パスワードを知り得るのが誰であるのかに注目して解答してほしかった。

本文の根拠

図 4

プログラムがパスワード取得ページの URL（以下，取得ページ URL という）を発行し，利用者にメールで通知する。

図 4

一度アクセスされた取得ページ URL は無効にする。

図 4

利用者のブラウザと，申請ページ及びパスワード取得ページとの間の通信には，SSL を用いる。

図 4 の手順では，仮パスワードを得る鍵は，メールで通知される取得ページ URL だけである。URL には十分に長いランダムな文字列が含まれ，推測はできないが，メールで通知される以上，その内容を盗聴されると攻撃者も同じ URL を知ることになる。SSL を用いるのは利用者のブラウザと申請ページ・取得ページとの通信であり，メールの通知経路を保護する記述は図 4 に無い。

図 2 の現行の運用では，ヘルプデスクが利用責任者の電話番号に電話して本人確認を行い，仮パスワードも電話で読み上げて通知する。これに対し，新しい手順にはそうした確認が無い。攻撃者が盗聴した URL に，利用者より先にアクセスすれば，仮パスワードがブラウザに表示される。一度アクセスされた URL は無効になるので，攻撃者が先にアクセスしていれば，その後に利用者がアクセスしても取得できなくなる。

解答例は“取得ページURLを通知するメールを盗聴し，利用者より先に取得ページにアクセスする手口”の 42 字で，45 字以内に収まる。“URL を知る方法”と“先にアクセスする”の二つを書く。

本文の根拠

〔本文冒頭〕

インターネットサイトに向けて送信された内容をログとして取得することを定めている。

図 3

暗号化された通信路はブラウザから U プロキシを通り抜けて Web サーバまで一本でつながっている

〔新たなプロキシ製品導入の検討〕

HTTPS 通信時にプロキシで詳細なログを取得するためには，U プロキシとは異なる仕組みをもつプロキシ製品を導入する必要があると考えた。

アクセス管理ルールは，アクセスログと，インターネットサイトに向けて送信された内容のログを取得することを定めている。ところが U プロキシでは，図 3 のとおり，暗号化された通信路がブラウザと Web サーバの間に一本でつながっていて，プロキシは通信の内容を見られない。HTTPS 通信を許すと，このルールが求めるログを記録できなくなる。このため，原則として禁止している。

本文の後半で K 主任が，HTTPS 通信時に詳細なログを取得するには U プロキシとは異なる仕組みをもつプロキシ製品が必要と考えたことも，この点を裏付けている。

解答例は“ログを平文で記録できないから”の 14 字で，20 字以内に収まる。何ができないのかを，ログの取得という観点で書く。

本文の根拠

図 2

リクエストライン（HTTP メソッド，URL，HTTP プロトコルのバージョン）

図 2

インターネットサイトにデータが送信された場合（POST リクエスト，PUT リクエストの利用時など）に，その送信内容を取得する。

図 2

送受信データ内のウイルスをチェックする。

図 3 のとおり，U プロキシを使った HTTPS 通信では，暗号化された通信路がブラウザと Web サーバの間に確立される。プロキシは暗号化された内容を見られないので，通信の内容を見ることが前提の機能は，目的を達成できない。(2) は，リクエストラインの HTTP メソッド，URL などを取得する機能で，これらは暗号化された通信の中にある。(3) は，POST などで送信された内容そのものを取得する機能で，同じく見られない。(5) は，送受信データの中のウイルスを調べる機能で，暗号化されたデータの中身は検査できない。

(1) は，ブラウザが Proxy-Authorization ヘッダに付与し，U プロキシに送信した認証情報で従業員を識別する機能で，暗号化された通信の内側のデータを必要としない。(4) のフィルタリングは，“ホストの FQDN に基づいた”規制で，HTTPS 通信ではホワイトリスト方式を使っており，HTTPS 通信を許可する前提の機能である。

解答は項番を全て挙げる設問なので，(2)，(3)，(5) の三つを“(2)，(3)，(5)”とそろえて書く。ここでは取得する項目の中に URL，送信内容，データのように暗号化の内側にあるものがあるかを見分ける。

本文の根拠

〔新たなプロキシ製品導入の検討〕

U プロキシを利用した HTTPS 通信では，暗号化された通信路をブラウザと Web サーバ間で確立する。

図 3

ブラウザと Web サーバ（○○.co.jp）の間に U プロキシがあり

プロキシ経由で HTTPS サイトに接続するとき，ブラウザはまず，プロキシに宛先のホスト名とポート番号を示して，その宛先とのトンネルを作るよう依頼する。RFC 2817 は，この目的の CONNECT メソッドを説明しており，要求の URI は宛先のホスト名とポート番号をコロンでつないだ形で，要求行の例は“CONNECT server.example.com:80 HTTP/1.1”である。プロキシが受け入れると，宛先との接続を確立してトンネルとして通信を中継する。入力した URL が https://○○.co.jp/index.html なので，ブラウザが最初に送る要求行は“CONNECT ○○.co.jp:443 HTTP/1.1”（ア）になる。

この後のブラウザと Web サーバとの間のやり取りは，トンネル内で暗号化される。したがって GET や POST の要求行にパス（/index.html）を付けた形（イ，ウ）は，プロキシに最初に届く要求行ではない。SSL（エ）は HTTP のメソッドではない。

講評は，設問 1 は(3)の正答率が低かったとして，情報セキュリティ技術者も HTTP プロトコルの基本的な仕様は理解しておいてほしいと述べている。

採点講評（IPA）

設問1は(3)の正答率が低かった。昨今のインターネットの利用形態の多くがHTTPプロトコルをベースとしている状況を踏まえ，情報セキュリティ技術者としてもHTTPプロトコルの基本的な仕様は是非理解しておいてほしい。

本文の根拠

〔HTTPS 通信時の安全性の確認〕

HTTPS 通信で Web サーバのサーバ証明書の正当性を確認しないまま，ブラウザがアクセスを継続すると，偽サイトに誘導された場合でなくても，a 攻撃を受けて，通信を盗聴される可能性がある

サーバ証明書の正当性を確認しないまま通信を続けると，ブラウザは，通信相手が本物の Web サーバかどうかを確かめられない。通信の途中に入り込んだ攻撃者が，自分で用意した証明書をブラウザに示してなりすまし，一方で本物のサーバにも接続して中継すれば，両者の通信を盗聴できる。これが中間者攻撃（man-in-the-middle 攻撃）である。

本文の L プロキシも，図 4 のとおりブラウザと Web サーバの間に入って通信を中継し，ブラウザには自分が作った証明書 2 を示す。これは仕組みとして中間者と同じなので，ブラウザが証明書 2 を正当と確認できる準備（設問 3(1)）が必要になる。

“偽サイトに誘導された場合でなくても”という書きぶりから，偽サイトへの誘導ではなく，通信路上に入り込む攻撃を答える。解答例は“中間者”。

本文の根拠

〔HTTPS 通信時の安全性の確認〕

HTTPS 通信で Web サーバのサーバ証明書の正当性を確認しないまま，ブラウザがアクセスを継続すると

図 4

L プロキシからブラウザに向けて，SSL のハンドシェイクで証明書 2 が送られ，ブラウザが証明書 2 の検証を行う。

中間者攻撃に対する，サーバ証明書の検証でブラウザが確認すべき内容は，次の二つである。一つは，サーバ証明書のコモンネームが，アクセス先のホスト名と一致することである。RFC 2818 の 3.1 節は，クライアントが，URI のホスト名と証明書に記載された識別名（subjectAltName の dNSName，無ければコモンネーム）を照合しなければならないとしている。中間者が別のサイトの正規の証明書を示したとしても，名前が一致しないので検出できる。もう一つは，サーバ証明書がブラウザで信頼する認証局から発行されていることである。中間者が自分で作った証明書は，ブラウザが信頼する認証局の署名を持たないので，検出できる。

講評は，設問 2(2)の正答率が低かったとして，有効期限や CRL の確認を挙げる受験者が多く見られたが，想定する脅威に対してそれぞれの確認事項がどの程度有効であるのかを意識して解答してほしかったと述べている。ここでの脅威は，通信路上に入り込んで正規のサーバになりすます攻撃なので，“誰の証明書か”と“誰が発行したか”を確かめる二つが対策になる。

各 35 字以内で，解答例は 31 字と 30 字。二つは別の観点として書き，順序はどちらが先でもよい。

採点講評（IPA）

設問2は(2)の正答率が低かった。証明書に関する確認事項として，有効期限やCRLの確認を挙げる受験者が多く見られたが，想定する脅威に対してそれぞれの確認事項がどの程度有効であるのかを意識して解答してほしかった。

本文の根拠

〔新たなプロキシ製品導入の検討〕

L プロキシは認証局として証明書 1 と同じコモンネームのサーバ証明書（以下，証明書 2 という）を新たに作成し，ブラウザに送る。

〔HTTPS 通信時の安全性の確認〕

ご指摘のとおり，事前に何の準備もしなかった場合は，証明書 2 の正当性を確認できません。

証明書 2 は，L プロキシが“認証局として”作成する。ブラウザがこれを正当と確認するには，その発行元である L プロキシが，ブラウザにとって信頼できる認証局でなければならない。ブラウザは，信頼するルート証明書をあらかじめ登録しておき，それに連なる証明書を信頼するので，事前に L プロキシのルート証明書をブラウザの信頼するルート証明書としてインストールしておく必要がある。解答例は“Lプロキシのルート証明書を信頼するルート証明書としてインストールする”の 34 字で，40 字以内に収まる。

設問 2(2) で挙げた“ブラウザで信頼する認証局から発行されていること”の確認を，L プロキシの証明書でも満たすための準備である。

講評は，設問 3 は全体的に正答率が低かったとして，暗号化された通信路が二つ存在する応用的な問題ではあるが，HTTPS 通信時の処理の流れを理解していれば解けると述べている。インストールする対象（L プロキシのルート証明書）と，その使い道（信頼するルート証明書）の両方を書く。

採点講評（IPA）

設問3は全体的に正答率が低かった。暗号化された通信路が二つ存在するという応用的な問題ではあったが，HTTPS通信時の処理の流れを理解していれば解ける問題である。重要なところなのでHTTPS通信の基礎を理解してほしい。

本文の根拠

〔HTTPS 通信時の安全性の確認〕

ブラウザは証明書 2 の検証において，証明書 2 の正当性を確認できない

〔新たなプロキシ製品導入の検討〕

L プロキシは認証局として証明書 1 と同じコモンネームのサーバ証明書（以下，証明書 2 という）を新たに作成し，ブラウザに送る。

証明書 2 の発行者は，L プロキシが“認証局として”名乗るものである。ブラウザがあらかじめ信頼している認証局の一覧には，L プロキシは入っていない。そのため，事前に何の準備もしなければ，証明書 2 の発行元を信頼できる認証局と確認できず，正当性を確認できない。これは，設問 2(2) の二つ目の確認事項，サーバ証明書がブラウザで信頼する認証局から発行されていること，を満たさないということである。

コモンネームは証明書 1 と同じにしてあるので，名前の面では問題がない。問題になるのは“誰が発行したか”の側であり，設問 3(1) の対策がこれを解消する。

解答例は“証明書2はブラウザが信頼する認証局が発行したものではないから”の 30 字（40 字以内）。“L プロキシ（発行元）がブラウザの信頼する認証局ではない”という点を明記する。

採点講評（IPA）

設問3は全体的に正答率が低かった。暗号化された通信路が二つ存在するという応用的な問題ではあったが，HTTPS通信時の処理の流れを理解していれば解ける問題である。重要なところなのでHTTPS通信の基礎を理解してほしい。

本文の根拠

図 4

L プロキシからブラウザに向けて，SSL のハンドシェイクで証明書 2 が送られ，ブラウザが証明書 2 の検証を行う。

〔新たなプロキシ製品導入の検討〕

L プロキシは認証局として証明書 1 と同じコモンネームのサーバ証明書（以下，証明書 2 という）を新たに作成し，ブラウザに送る。

ブラウザが検証する証明書 2 は，アクセス先の Web サーバ（○○.co.jp）のものとして示される。設問 2(2) のとおり，ブラウザは，サーバ証明書のコモンネームがアクセス先のホスト名と一致することを確認する。RFC 2818 の 3.1 節も，URI のホスト名と証明書の識別名を照合することを求めている。L プロキシ自身のサーバ証明書は，コモンネームが L プロキシのホスト名なので，アクセス先の○○.co.jp とは一致せず，検証に失敗する。

そのため，L プロキシは証明書 1 と同じコモンネームの証明書 2 を作成する。これにより，ブラウザから見ると，アクセス先の名前と一致するサーバ証明書が示されることになる。

解答例は“サーバ証明書のコモンネームとアクセス先のホスト名を一致させるため”の 32 字（40 字以内）。“コモンネームを一致させる”だけでなく，何と一致させるか（アクセス先のホスト名）まで書く。

採点講評（IPA）

設問3は全体的に正答率が低かった。暗号化された通信路が二つ存在するという応用的な問題ではあったが，HTTPS通信時の処理の流れを理解していれば解ける問題である。重要なところなのでHTTPS通信の基礎を理解してほしい。

本文の根拠

表 2

7.2.4 利用者のアクセス権のレビュー

表 2

7.3.3 名称：b・クリアスクリーンポリシ。

図 3

5. 物理的及び環境的セキュリティ　6. 通信及び運用管理　7. a　8. 情報システムの取得，開発及び保守

表 2 の項番 7.2 と 7.3 に並ぶ項目は，利用者登録，特権管理，利用者パスワードの管理，利用者のアクセス権のレビュー，パスワードの利用，無人状態にある利用者装置，クリアデスク・クリアスクリーンポリシである。どれも，情報や情報システムを使える人を誰に，どのように許し，許された利用者に何を守らせるかに関する項目である。これを束ねる大項目が“アクセス制御”である。

図 3 の他の大項目を見ると，5 は物理的な環境，6 は通信と運用の管理，8 は情報システムの取得・開発・保守で，7.2.1～7.3.3 のような利用者登録やアクセス権に関する項目はこれらには入らない。

解答例は“アクセス制御”。講評は，設問 1 及び設問 2 は穴埋め問題であり高い正答率を期待したが，設問 2c 以外は正答率が低かったとして，これらの用語や内容は情報セキュリティに関する基本的な知識なので，しっかりと理解してほしいと述べている。

採点講評（IPA）

設問1及び設問2は穴埋め問題であり，高い正答率を期待したが，設問2c以外は正答率が低かった。これらの用語や内容は，情報セキュリティに関する基本的な知識であり，しっかりと理解してほしい。また，設問2eは，誤って“破棄や管理”と解答した受験者が多かった。クリアデスクの意味を考えてほしい。

本文の根拠

表 2

書類及び取外し可能な電子記憶媒体に対する b ポリシ，並びに情報処理設備に対するクリアスクリーンポリシを適用しているか。

表 2

(2) サーバ及び PC は，離席時にはログオフ状態にしておくか，若しくはパスワード，c 又は類似の利用者認証機構を使用した d で保護しているか。

表 2

(3) 重要な業務情報を含む文書は印刷後，e いるか。

b は，“クリアスクリーンポリシ”と並ぶ，書類と取外し可能な電子記憶媒体に対する方針で，名称の欄にも“b・クリアスクリーンポリシ”とあるので，クリアデスクである。c と d は，離席時に PC を保護する手段で，“パスワード，c 又は類似の利用者認証機構を使用した d”の形になる。パスワードに並ぶ認証の手段は認証トークン，それを使って画面への操作を制限する仕組みはスクリーンロック機構である。

e は，(3) の“重要な業務情報を含む文書は印刷後”に続く，クリアデスクとして求められる行動で，印刷した文書を放置しないよう，プリンタから速やかに取り出すことである。

字数は b・c が 10 字以内，d が 15 字以内，e が 20 字以内。解答例は 6 字，6 字，10 字，15 字。講評は，設問 2c 以外は正答率が低かったとし，e は，誤って“破棄や管理”と解答した受験者が多かった，クリアデスクの意味を考えてほしいと述べている。

採点講評（IPA）

設問1及び設問2は穴埋め問題であり，高い正答率を期待したが，設問2c以外は正答率が低かった。これらの用語や内容は，情報セキュリティに関する基本的な知識であり，しっかりと理解してほしい。また，設問2eは，誤って“破棄や管理”と解答した受験者が多かった。クリアデスクの意味を考えてほしい。

本文の根拠

〔IT 全般統制に関する指摘〕

会計連携データを運搬中の USB メモリ内のデータ保護対策がとられておらず，財務情報の正確性確保の観点からみて不十分である。

指摘 1 は，運搬中の USB メモリ内のデータ保護対策が無いことを，“財務情報の正確性確保の観点”から不十分としている。正確性（データが正しいまま保たれること）が損なわれる事態は，データが書き換えられる改ざん（ウ）である。

会計連携データは，抽出された後に USB メモリで経理部へ運搬され，会計サーバに入力される。途中で内容が書き換わっていても，入力する側には分からない。これが，財務情報の正確性への脅威である。

誤りの選択肢のうち，漏えい（オ）と盗難（エ）は秘密性や持ち出しの問題，ウイルス感染（イ）は USB メモリを介した感染の問題，DDoS（ア）は可用性の問題で，いずれも“正確性”の観点とは合わない。講評は，設問 3 の(1)，(2)は正答率が高かったとしている。

採点講評（IPA）

設問3では，(1)，(2)は正答率が高かったが，(3)は正答率が低かった。管理的対策としてどのような対策が効果的かを考えて解答してほしかった。

本文の根拠

図 2

(1) 会計連携データの抽出担当者（以下，抽出担当者という）は，USB メモリの貸出しを受けて，i-PC から投資システムにアクセスし，その日の会計連携データを抽出し，USB メモリに保存する。

図 2

(4) 経理部の担当者は，経理部にある U-PC を使用して，会計連携データを直ちに会計サーバに入力する。

データの改ざんを防ぐのではなく，改ざんされたことを検知する技術的対策が現実的である。抽出担当者が USB メモリへ保存する時点でハッシュ値を求めて保存し，経理部の担当者が U-PC で会計サーバに入力する直前にハッシュ値を再計算して照合すれば，運搬中の書換えを検知できる。ただし，単純なハッシュ値は，データを書き換えた人が，ハッシュ値も計算し直して置き換えられる。このため，鍵付きハッシュ値（鍵を知らなければ値を作れない MAC。RFC 2104 の HMAC は，共有の秘密鍵と暗号学的ハッシュ関数による，データの完全性・真正性確認の仕組み）を使う。

図 2 の運用では，抽出（(1)）と入力（(4)）が別の担当者・別の PC で行われるので，この検知の仕組みを両端に置ける。

解答例は“鍵付きハッシュ値などによる改ざん検知対策”の 20 字で，30 字以内に収まる。

採点講評（IPA）

設問3では，(1)，(2)は正答率が高かったが，(3)は正答率が低かった。管理的対策としてどのような対策が効果的かを考えて解答してほしかった。

本文の根拠

図 2

(3) 事務担当者は，USB メモリと会計連携データ管理簿を経理部まで運搬し，経理部の担当者に手渡す。

表 1

事務担当者：投資システムを用いない業務を担当。なし，なし。

図 2 の運用では，運搬（(3)）は事務担当者が 1 人で行う。事務担当者は投資システムの利用者 ID も入室用 IC カードも持たないが，運搬の間は USB メモリを単独で保持するので，悪意があれば内容を書き換えられる。管理的対策としては，ガイドラインを改定し，USB メモリに関わる作業，つまり運搬などの作業を複数人で行うようにして，相互にけん制させる。1 人では不正を行いにくくなる。

解答例は“USBメモリに関わる作業の複数人化による相互けん制”の 25 字で，30 字以内に収まる。講評は，(3)の正答率が低かったとして，管理的対策としてどのような対策が効果的かを考えて解答してほしかったと述べている。

採点講評（IPA）

設問3では，(1)，(2)は正答率が高かったが，(3)は正答率が低かった。管理的対策としてどのような対策が効果的かを考えて解答してほしかった。

本文の根拠

〔Z 社の統制状況〕

しかし，Z 社は，データセンタへの取引先の立入りを認めていない。

〔Z 社の統制状況〕

Z 社の統制状況に関する報告書を f の立場の専門家に作成してもらい

Z 社は，データセンタへの取引先（Q 社）の立入りを認めていないので，Q 社が自ら Z 社の統制状況を確認することはできない。かといって，Z 社自身の担当者が作った報告書では，Q 社が確認する根拠として独立していない。そこで，Q 社とも Z 社とも利害関係のない第三者の立場の専門家に報告書の作成を依頼する。

本文は，Q 社が確認したい項目を含んだ報告書を作ってもらうとしており，確認が必要な項目を指定できる点でも，専門家が第三者であることが前提になる。

字数は 10 字以内で，解答例は“第三者”（3 字）。講評は，設問 4(1)の正答率は高かったとしている。

採点講評（IPA）

設問4では，(1)は正答率が高かったが，(2)は低かった。統制状況に関する報告書では，利用者IDの登録に関してどのような項目の記述が必要かを理解して解答してほしかったが，不十分な解答が多かった。

本文の根拠

図 2

(2) 投資システム担当者は，Z 社に利用者 ID の登録を依頼する（利用者 ID の登録は，Z 社だけが行う）。

図 2

(3) 投資システム担当者は，発行された利用者 ID の情報を Z 社から受け取り，申請した投資担当者に通知する。

〔Z 社の統制状況〕

投資システムのアクセス権管理については，Z 社の統制状況についても確認の必要な項目が存在する。

図 2 の 5. (2) では，Q 社の投資システム担当者が Z 社に利用者 ID の登録を依頼し，登録は Z 社だけが行う。Q 社は，登録が正しく行われたかを自分では確認できない。そこで，Z 社の報告書で，Q 社が依頼した利用者 ID だけが，依頼のとおりに登録されていることを確認する必要がある。その確認の中心になるのが，Q 社から依頼された利用者 ID の登録に関する承認手続である。

同じ 5. の (1) は，投資部長の承認後に提出する Q 社内の手続である。Z 社側については，その依頼を受けた登録が承認された手続のもとで行われているかを，報告書で確かめる。

解答例は“Q社から依頼された利用者IDの登録に関する承認手続”の 25 字（30 字以内）。講評は，(2)は正答率が低く，統制状況に関する報告書では，利用者 ID の登録に関してどのような項目の記述が必要かを理解して解答してほしかったが，不十分な解答が多かったと述べている。

採点講評（IPA）

設問4では，(1)は正答率が高かったが，(2)は低かった。統制状況に関する報告書では，利用者IDの登録に関してどのような項目の記述が必要かを理解して解答してほしかったが，不十分な解答が多かった。