平成25年度 春期に実施された情報処理安全確保支援士試験
午後Ⅱの全2問（記述式）の全設問に，運営者が独自に書いた解説を付けています。事例本文のどこが根拠になるかを示し，IPA の解答例・採点講評と並べています。
問1 業務パッケージの開発
業務パッケージの開発に関する次の記述を読んで，設問1〜4に答えよ。
U 社は，従業員数 100 名のソフトウェア開発会社で，以前は受託開発を主に行っていたが，数年前から業務パッケージの開発も手がけるようになり，業績を伸ばしている。今回，新たに美容室向けの自社製品として，表1の機能を備えた美容室管理システム（以下，HSS という）を開発することが決まり，M 専務が開発責任者になった。M 専務は，美容室が HSS を運用することは難しいと考え，U 社が HSS を運用し，インターネット経由で美容室へサービスを提供する，いわゆる SaaS 型の商品とすることにした。また，美容室間の情報の独立性を高めるために，美容室ごとに仮想サーバを用意し，その上で HSS を運用することにした。
表1 HSS の機能
〔機能要件の定義〕
M 専務は，HSS の要件定義から詳細設計までを担当するグループ（以下，S グループという）を編成し，T 主任をリーダに任命した。S グループは，HSS の想定契約先に関する調査などを行い，機能要件の定義を行った。そのうち，顧客管理と予約管理に関する機能要件は，それぞれ図1，図2のとおりである。
図1 顧客管理の機能要件
図2 予約管理の機能要件
なお，HSS では美容室の従業員及び顧客の利用時に認証を行う。
〔システム・ソフトウェア要件定義〕
S グループは，システム方式設計及びソフトウェア要件定義を開始し，まず図3のとおり，ソフトウェア構成を決定した。
なお，図3中の太線枠内が，今回 HSS として開発する Web アプリケーションである。
図3 ソフトウェア構成
〔リスクアセスメント〕
M 専務は，HSS では，美容室が顧客から取得した個人情報を含む情報資産を取り扱うことから，情報の漏えいや滅失の可能性を評価するためにリスクアセスメントを実施し，その結果に基づきソフトウェア要件の中でセキュリティ仕様を定めることにした。この作業を，ソフトウェア要件定義の他のタスクと並行して行うために，S グループとは別のグループ（以下，R グループという）を編成した。
R グループでは，次の(1)〜(3)の手順に従ってリスクアセスメントを実施した。
(1) 表2のように，美容室における情報資産の分類を定義した。 (2) 表3のように，HSS で取り扱う情報資産を特定し，情報セキュリティの 3 要素に照らして情報資産の分類を行った。 (3) 各情報資産に対する脅威と脆弱性を特定し，それぞれについてリスク分析を行い，その結果を取りまとめた。そのうち，顧客データに対する結果を表4に示す。
表2 美容室における情報資産の分類の定義
表3 HSS で取り扱う情報資産（抜粋）
表4 顧客データに対するリスク分析の結果（抜粋）
〔セキュリティ仕様の決定〕
R グループはリスク分析の結果から，Web アプリケーションに係るセキュリティ仕様と HSS の運用管理に関する要件を取りまとめた。そのうち，顧客管理機能に関するセキュリティ仕様を表5に，HSS の運用管理に関する要件を表6に示す。
表5 顧客管理機能に関するセキュリティ仕様（抜粋）
表6 HSS の運用管理に関する要件（抜粋）
R グループは，検討したセキュリティ仕様と運用管理に関する要件を M 専務に報告し，その承認を受けた。
〔予約管理機能の不具合〕
その後，HSS の開発は順調に進み，予約管理機能のうち，顧客が操作する画面の機能テストを開始した。予約管理機能の画面遷移を図4に示す。
図4 予約管理機能の画面遷移（抜粋）
機能テストの結果，複数の予約を同時に処理した場合，画面上では正常に予約が完了したように見えるにもかかわらず，データベースには反映されていないことがあるという不具合が発見された。不具合の原因と思われるプログラムは，図5，図6のとおりである。また，データベースのテーブルは，図7，図8のとおりである。
図5 サーブレット“WakuClick”
図5 サーブレット“WakuClick”（続き）
図6 サーブレット“KakuteiClick”
図6 サーブレット“KakuteiClick”（続き）
図7 主なテーブルの構造
図8 予約リストテーブルの仕様
不具合の発見を受けて，図5及び図6について，顧客 α と顧客 β がそれぞれのブラウザから操作を行うことを想定して，ソースコードレビューを行った。
その結果，顧客 α と顧客 β が，画面2で空き状態であった同一の予約枠をほぼ同時に選択した場合，表7に示す順序で各処理が完了すると，顧客 α の仮予約がデータベースに反映されないことが確認できた。
表7 仮予約が無効になる処理の順序
さらに，①空き状態であった予約枠を，顧客 α が画面2で選択して画面3に進むのと並行して，同一の予約枠を顧客 β が画面2で選択した場合，表8に示す順序で各処理が完了すると，顧客 β の個人情報が顧客 α の画面4に表示されてしまう ことが確認できた。
表8 個人情報の漏えいにつながる処理の順序
〔予約管理機能における不具合の修正〕
S グループのリーダとしてソースコードレビューに参加していた T 主任は，この不具合を修正するために，executeUpdate メソッドで UPDATE 文を実行したとき，更新した行数が戻り値になることに着目した。そして，図5の 25 行目のパラメタ付き SQL 文の WHERE 句を修正した上で，図5の 60 行目の executeUpdate メソッドの実行時に異常の発生を検知する仕組みを提案した。この提案に基づき修正されたプログラムは図9のとおりである。
図9 修正されたサーブレット“WakuClick”
〔販売の開始〕
U 社はその後も HSS のテストを続け，更にいくつかの不具合を発見し，プログラムの修正を行った。その結果，テストを完了し，予定どおりに発売日を迎えることができた。発売後，HSS は順調に契約数を伸ばしており，U 社の業績向上に寄与している。
出題趣旨（IPA）
ソフトウェアの開発に当たっては，要件定義からテストまでの全てのプロセスにおいて，ソフトウェアのセキュリティレベルを確保する方策が必要である。本問では，まず要件定義フェーズでの方策として，リスク分析及びセキュリティ要件定義の手法に関する知識と能力を問う。続いて，テストフェーズでの方策として，Javaマルチスレッドプログラミングにおけるレースコンディションを例にとり，発見された脆弱性の分析及び修正の方法についての知識と能力を問う。
採点講評（問全体・IPA）
問1では，ソフトウェア開発におけるリスクアセスメントとレースコンディション対策について出題した。全体として正答率は高かった。
設問と解答例
設問1(1)
解答欄1つ
表3中の a に入れる適切な字句を答えよ。
解説
本文の根拠
〔リスクアセスメント〕
表3のように，HSS で取り扱う情報資産を特定し，情報セキュリティの 3 要素に照らして情報資産の分類を行った。
表3
完全性に係る分類，可用性に係る分類
a は“機密性”である。情報セキュリティの 3 要素は，機密性（許可された者だけが情報にアクセスできること），完全性（情報が正確で改変されていないこと），可用性（必要なときに情報を使えること）の三つである。
表3の列は，a に係る分類，完全性に係る分類，可用性に係る分類の三つで，本文は“情報セキュリティの 3 要素に照らして”分類したと書いている。完全性と可用性の 2 列が既にあるので，残る一つの要素である機密性が入る。
字数制限のない穴埋めなので，用語を一つ書けばよい。“秘密性”“守秘性”のような言い換えではなく，3 要素の名称どおり“機密性”と書く。
採点講評（IPA）
設問1は，リスクアセスメントに関する設問であったが，正答率は高く，おおむね理解されているようであった。
設問1(2)
解答欄2つ
表4中の b ，c に入れる適切な字句を解答群の中から選び，記号で答えよ。解答群 ア 管理端末の保守体制の不備 イ 推測可能なパスワード ウ 耐震性能の不足 エ データセンタの施錠管理不良 オ 美容室の施錠管理不良 カ 防火体制の不備
解説
本文の根拠
表4
美容室従業員による物品持ち去り
表5 顧客の認証
顧客の認証用パスワード設定時に，次の条件を強制する。
表5 顧客の認証
パスワードの入力を所定回数連続して誤った場合
b はイの“推測可能なパスワード”，c はオの“美容室の施錠管理不良”である。
b は，リスク No. 1 と 7 の脆弱性である。リスク 1 の脅威は“インターネット経由の HSS への不正アクセス”，リスク 7 は“美容室従業員による不正アクセス”で，どちらも被害は情報漏えいである。表5で，顧客の認証にはリスク No. 1，4 が，美容室の従業員の認証には 7，8 が対応づけられている。この認証の仕様は，パスワードの長さ・文字種・禁止文字列の強制や，誤入力を繰り返したときの対処であり，パスワードを推測されることへの対策なので，b は“推測可能なパスワード”になる。リスク 4 と 8 の“脆弱な認証とアクセス権管理の仕組み”は，権限管理（最小権限）の仕様に対応するものとして別に挙がっている。
c は，脅威“美容室従業員による物品持ち去り”に対応する脆弱性である。同じ脅威のリスク 5 が“物品管理の不備”なので，c は同じ場面でなされる管理の不備を選ぶ。持ち去る主体は美容室の従業員なので，美容室の施錠管理が不良であれば持ち去りが起こりうる。エの“データセンタの施錠管理不良”は，HSS を運用する U 社側の話で，美容室の従業員による持ち去りとは別の脅威に結びつく。ア（管理端末の保守体制の不備），ウ（耐震性能の不足），カ（防火体制の不備）は，持ち去りという脅威とは結びつかない。解答群から選ぶ設問なので，字数の問題はない。
採点講評（IPA）
設問1は，リスクアセスメントに関する設問であったが，正答率は高く，おおむね理解されているようであった。
設問2(1)
解答欄1つ
表5中の d に入れる適切な字句を 30 字以内で述べよ。
解説
本文の根拠
表5 顧客の認証
パスワードの入力を所定回数連続して誤った場合
表4
インターネット経由の HSS への不正アクセス
解答例は“当該アカウントの認証時に待ち時間を挿入する。”（22 字）である。パスワードの入力を所定回数続けて誤ったときは，不正なログインの試行（パスワードを次々に当てる攻撃）とみなせるので，そのアカウントについて，次の認証を受け付けるまでに待ち時間を置く。
表4のリスク 1・4 は，インターネットから HSS に不正アクセスされて情報漏えいにつながるものである。表5のこの欄は，リスク 1・4 への対策なので，攻撃者が短時間に多数のパスワードを試せないようにする仕様が入る。誤入力が続いたアカウントを永久にロックする方法だと，他人が誤入力を繰り返すだけで正規の顧客が利用できなくなるので，待ち時間を挿入して試行の速度を落とす方法が使われる。
制限は 30 字である。“誤入力を所定回数連続して繰り返したアカウントの認証を一定時間停止する”のように，何を（そのアカウントの認証を）どうする（待たせる・停止する）かを書く。
採点講評（IPA）
設問2は，セキュリティ仕様の決定に関する設問であった。いずれも基本的な対策を問う設問であり，正答率は高かった。
設問2(2)
解答欄1つ
表5中の e に入れる適切なリスク No. を一つ答えよ。
解説
本文の根拠
表5 Web 画面入出力
Web 画面からの入力については，全て値チェックを行う。
表5 Web 画面入出力
Web 画面の出力時には，エスケープ処理を行う。
表4 リスク2
Web アプリケーションのセキュリティホール
e は 2 である。
表5の“Web 画面入出力”の仕様は，入力値のチェックと，出力時のエスケープ処理である。これらは Web アプリケーションの作り方で防ぐ仕様であり，表4で Web アプリケーションに由来する脆弱性は，リスク 2 の“Web アプリケーションのセキュリティホール”だけである。
リスク 1 と 4 は表5の“顧客の認証”に，リスク 3 の“Web サーバ基盤のセキュリティホール”は，表6のようにサーバや回線の運用管理で対処する。この設問は“リスク No. を一つ答えよ”なので，2 だけを書く。入力値のチェックを抜けた攻撃が Web アプリケーションの脆弱性を突く，という対応関係で選ぶとよい。
採点講評（IPA）
設問2は，セキュリティ仕様の決定に関する設問であった。いずれも基本的な対策を問う設問であり，正答率は高かった。
設問2(3)
解答欄1つ
表6中の f に入れる適切なリスク No. を二つ答えよ。
解説
本文の根拠
表6
IPS を設置し，不正アクセスの検出と，自動遮断を行う。
表6
Web アプリケーションファイアウォールを設置し，不正な HTTP アクセスを遮断する。
表4
Web サーバ基盤のセキュリティホール
f は 2，3 である。
表6のこの行は“インターネットからのアクセスを受け付ける回線”に設置する FW・IPS・Web アプリケーションファイアウォール（WAF）である。表4のうちインターネット経由の不正アクセスは，リスク 1〜4 である。1 と 4 は認証の仕様（表5）で対処するので，回線で防ぐのは，ネットワーク経由の攻撃で突かれるセキュリティホールのリスク 2（Web アプリケーション）と 3（Web サーバ基盤）である。WAF は不正な HTTP アクセスを，IPS は不正アクセスを検出して遮断するので，この二つのセキュリティホールを突く攻撃への補完的な対策になる。
“二つ答えよ”なので 2 と 3 を挙げる。リスク 1 は，表5の権限管理にも表れる認証の問題で，回線に置く機器の対象ではない。
採点講評（IPA）
設問2は，セキュリティ仕様の決定に関する設問であった。いずれも基本的な対策を問う設問であり，正答率は高かった。
設問2(4)
解答欄1つ
表6中の g に入れる適切な字句を 40 字以内で述べよ。
〔g〕解答例
セキュリティ修正プログラムが公表されたら速やかに適用する。
解説
本文の根拠
表4 リスク3
Web サーバ基盤のセキュリティホール
図3
Java サーブレットコンテナ
解答例は“セキュリティ修正プログラムが公表されたら速やかに適用する。”（29 字）である。表6のこの行は，インターネットからのアクセスを受け付ける Web サーバに適用する要件で，対応するリスクは 3（Web サーバ基盤のセキュリティホール）だけである。セキュリティホールは，製品の提供元がセキュリティ修正プログラム（パッチ）を公表して塞ぐものなので，公表されたら速やかに適用することが要件になる。
図3のとおり，Web サーバ基盤は，Java サーブレットコンテナ・Web サーバ・RDBMS・OS からなり，HSS 自身が開発するものではない。開発する Web アプリケーション（リスク 2）は設計・実装で，基盤は修正プログラムの適用で守る，という分担になる。
制限は 40 字である。“脆弱性を修正するパッチを速やかに適用する”のように，何を（修正プログラムを）いつ（公表後速やかに）するかを書く。“定期的にウイルスをスキャンする”のような別の対策にしない。
採点講評（IPA）
設問2は，セキュリティ仕様の決定に関する設問であった。いずれも基本的な対策を問う設問であり，正答率は高かった。
設問3(1)
解答欄5つ
表7を完成させるために，h 〜l に入れる適切な字句又は数字を答えよ。
解説
本文の根拠
〔予約管理機能の不具合〕
顧客 α と顧客 β が，画面2で空き状態であった同一の予約枠をほぼ同時に選択した場合，表7に示す順序で各処理が完了すると，顧客 α の仮予約がデータベースに反映されないことが確認できた。
図5 55行目
if (rsvStatus == RSV_AKI) {
図5 60行目
psUp.executeUpdate();
h は 42，i は α，j は 60，k は β，l は 60 である。順序 1 の“α が図5の 42 行目”は，予約枠の状態を調べる SELECT の実行である。
順序 2 で β も同じ 42 行目を実行する。この時点ではどちらも更新しておらず，α も β も“Status が空き”を読み取る。その後，順序 3 で α が 60 行目の UPDATE で仮予約を書き込み，順序 4 で β が同じ 60 行目の UPDATE を実行して，同じ行を上書きする。図5の 55 行目で状態を確認してから 60 行目で更新するまでの間に，確認した結果が変わっていないかを調べていないので，両方が 55 行目の条件を満たして更新に進める。この結果，最後に更新した β の仮予約だけが残り，α の仮予約はデータベースに反映されない。
数字と記号だけの穴埋めなので字数制限はない。順序 2 は “β の 42 行目”（SELECT を先に済ませる）で，順序 3・4 は“更新（60 行目）を α，β の順に行う”，と並びの意味で考えると取り違えにくい。
採点講評（IPA）
設問3は，ソースコードを解析してレースコンディションの発生を発見する能力を問うものであったが，正答率は低かった。特に設問3(3)では，setIntメソッドを使用するべきところをsetStringメソッドと誤って記述した解答が目立った。データ型の誤った取扱いは修復が難しい不具合を引き起こすことがあり，細心の注意が必要である。
設問3(2)
解答欄6つ
表8を完成させるために，m 〜r に入れる適切な数字を答えよ。
解説
本文の根拠
表8 備考
順序1の処理が完了し，10 分以上経過してから実行される。
図5 47行目
既に仮予約状態であった場合，仮予約の最終更新日時を確認し，TIMEOUT_KARI 経過後なら空きにする
図6 48行目
予約状況が仮であり，自分の予約であることを確認する
図6 58行目
rs = psSel.executeQuery();
m は 5，n は 42，o は 6，p は 55，q は 5，r は 60 である。
順序 1 で α が仮予約を書き込み（図5の 60 行目），10 分以上たってから順序 2 で α が図6の 42 行目で予約枠を読む。この間に，順序 3 で β が図5の 42 行目で同じ枠を読むと，Status は仮予約（1）だが，図5の 47〜53 行目の処理で最終更新から TIMEOUT_KARI（600000 ミリ秒＝10 分）を過ぎているので，空きとして扱われる。順序 4 では α が図6の 55 行目（UPDATE）を実行して確定（Status＝2，CustID＝α）にする。続く順序 5 で β が図5の 60 行目を実行し，空きとみなした枠に仮予約（Status＝1，CustID＝β）を書き込んで上書きする。順序 6 で α が図6の 58 行目で結合した結果を読むと，CustID が β の行になっているので，β の氏名やメールアドレスが α の画面 4 に表示される。
図6の 49 行目は，α の 42 行目の読取り結果（仮予約・自分の予約）で判定するので，順序 5 の更新より前の状態で確定処理に進む。順序 3〜5 は“図 m の n 行目”の形なので，図5と図6の取り違えに注意する（m，o，q に入るのは図の番号）。
採点講評（IPA）
設問3は，ソースコードを解析してレースコンディションの発生を発見する能力を問うものであったが，正答率は低かった。特に設問3(3)では，setIntメソッドを使用するべきところをsetStringメソッドと誤って記述した解答が目立った。データ型の誤った取扱いは修復が難しい不具合を引き起こすことがあり，細心の注意が必要である。
設問3(3)
解答欄3つ
図9を完成させるために，s 〜u に入れる適切な文字列を答えよ。
〔t〕解答例
psUp.setInt(10, rsvStatus) psUp.setLong(10, lastDateTime)
〔備考〕同じ群中の組合せとする（a 群：Status=?，psUp.setInt(10, rsvStatus)，b 群：LastUpdate=?，psUp.setLong(10, lastDateTime)）。u は 1
解説
本文の根拠
〔予約管理機能における不具合の修正〕
executeUpdate メソッドで UPDATE 文を実行したとき，更新した行数が戻り値になることに着目した。
図8
LastUpdate の型は long 型である。
図5 44行目
long lastDateTime = rs.getLong("LastUpdate");
図5 48行目
int rsvStatus = rs.getInt("Status");
s と t は，a 群なら“Status=?”と“psUp.setInt(10, rsvStatus)”，b 群なら“LastUpdate=?”と“psUp.setLong(10, lastDateTime)”（どちらも同じ群中の組合せ），u は 1 である。
図9の 25 行目の UPDATE 文では，SET 句のパラメタが 1〜5 番，WHERE 句の rsvDate・rsvTime・Biyoshi が 6〜8 番で，追加した CustID=? が 9 番なので，s のパラメタは 10 番になり，58 行目の t が 10 番を設定する。更新の条件に，読み取ったときの Status（または LastUpdate）を加えておけば，読み取ってから更新するまでの間に他の処理がその行を書き換えた場合は条件に合わず，更新される行数は 0 になる。JDBC の executeUpdate は，DML では更新した行数を返すので（Java の PreparedStatement の仕様），59 行目で 1 と比較して，1 のときだけ仮予約の成功，それ以外を失敗として扱える。
型は，Status が int（getInt），LastUpdate が long（getLong）なので，setInt と setLong を使う。採点講評のとおり，setString で書いた解答が目立った。型の取り違えは，書いた時点でコンパイルが通っても実行時の不具合になりうるので，読み取りに使った getInt・getLong に型をそろえる。
採点講評（IPA）
設問3は，ソースコードを解析してレースコンディションの発生を発見する能力を問うものであったが，正答率は低かった。特に設問3(3)では，setIntメソッドを使用するべきところをsetStringメソッドと誤って記述した解答が目立った。データ型の誤った取扱いは修復が難しい不具合を引き起こすことがあり，細心の注意が必要である。
設問3(4)
60字以内
本文中の下線①の事象をテストにおいて再現させるための方法を 60 字以内で具体的に述べよ。
解答例
デバッガで，SQL文の発行直前にブレークポイントを設定して，二つの予約処理を並行して実行する。
解説
本文の根拠
〔予約管理機能の不具合〕
複数の予約を同時に処理した場合，画面上では正常に予約が完了したように見えるにもかかわらず，データベースには反映されていないことがある
表8
順序1の処理が完了し，10 分以上経過してから実行される。
解答例は“デバッガで，SQL文の発行直前にブレークポイントを設定して，二つの予約処理を並行して実行する。”（47 字）である。レースコンディションは，複数の処理が重なる順序と時刻の組合せで起こり，通常の操作では偶然にしか起きない。表7・表8のように処理の順序を決めた状態を作るには，処理をその場で止めて順序を人手で操作できるデバッガで，SQL 文の発行（図5の 42 行目や 60 行目など）の直前にブレークポイントを置き，二つの予約処理を並行して動かして，目的の順序に進める。
下線①の事象は，仮予約から 10 分以上たってから起こるもの（表8の順序 2）なので，ブレークポイントで止めておけば，その時間を実際に待たなくても，順序を合わせて再現できる。
制限は 60 字である。“ブレークポイントで処理を止める”“二つの処理を並行して実行する”の二つの要素を落とさず，“具体的に”と求められているので，止める位置（SQL 文の発行直前）まで書く。
採点講評（IPA）
設問3は，ソースコードを解析してレースコンディションの発生を発見する能力を問うものであったが，正答率は低かった。特に設問3(3)では，setIntメソッドを使用するべきところをsetStringメソッドと誤って記述した解答が目立った。データ型の誤った取扱いは修復が難しい不具合を引き起こすことがあり，細心の注意が必要である。
設問4
80字以内
今回のような予約管理機能の不具合を未然に防止するためには，データベースを利用した Web アプリケーションの開発における規約が必要である。特に，データベースから読み込んだデータの更新処理に必要な規約について，Web アプリケーションの特性を考慮した上で，80 字以内で述べよ。
解答例
データベースから読み込んだデータを更新する際に，そのデータが他のスレッドによって変更されていないことを確認する。
解説
本文の根拠
〔予約管理機能の不具合〕
複数の予約を同時に処理した場合
〔予約管理機能における不具合の修正〕
WHERE 句を修正した上で
解答例は“データベースから読み込んだデータを更新する際に，そのデータが他のスレッドによって変更されていないことを確認する。”（56 字）である。Web アプリケーションは，複数の利用者からの要求を同時に処理する（スレッドが並行して動く）ので，読み込んだ後，更新する前に他のスレッドがその行を書き換えている場合がある。そこで，更新するときに，読み込んだ時点から変更されていないことを確認する，という規約を決める。
図9の修正（WHERE 句に読み込み時の値を加え，executeUpdate の更新行数で成功を確かめる）は，その規約を実装した例である。読み込みと更新が別々の画面の操作に分かれる Web アプリケーションでは，画面の表示中にデータベースの行を占有しておくことは現実的でないので，更新時に確認する方法が適する。
制限は 80 字である。採点講評のとおり，“排他制御を行う”のような抽象的な一般論だけでは規約として足りない。“更新時に”“読み込んだ値が他から変更されていないことを確認する”の 2 点を入れる。
採点講評（IPA）
設問4は，RDBMSを利用したソフトウェア開発において，レースコンディションの発生を未然に防止するための規約について問うたが，抽象的な一般論だけを記載するなど，規約としては不十分な解答が散見された。
出典：平成25年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問1（表記を一部改変）
問2 技術情報の管理
技術情報の管理に関する次の記述を読んで，設問1〜5に答えよ。
W 社は，従業員数 3,000 名の機械部品メーカである。東京に本社，国内 8 か所に営業所，関西地区 1 か所に工場がある。本社には，経営管理部，人事総務部，営業部及び情報システム部があり，営業部は各営業所を統括する。工場には，開発部及び製造部がある。
〔特許取得の推進〕
W 社では，国内での特許取得を推進しており，経営管理部，開発部及び製造部は，合同で特許検討会を月 1 回開催している。従業員は，発明の内容及び実施計画を説明した技術報告書を特許検討会に提出する。特許検討会では，技術報告書について審議し，議事録を作成する。審議の結果には，“特許庁に出願”，“ノウハウとして秘匿”及び“発明者への差戻し”の 3 種類がある。W 社の知的財産管理規程では，技術報告書及び議事録（以下，技術報告書と議事録を合わせて，検討会文書という）は，紙のほか，電子ファイルとしても 30 年間保管することになっている。
特許として登録された場合は，通常，出願から 20 年間，特許権を保持できる。しかし，特許検討会に提出された技術報告書を全て出願するわけではない。仮に出願すれば，出願の内容が，全て一定期間後に公開されるので，特許として登録されなかった場合は，技術が流出してしまうからである。
一方，W 社が特許庁に出願せずに実施した技術に関して，他社の特許が登録された場合は，損害賠償などを請求される可能性がある。
特許検討会では，“ノウハウとして秘匿”と決定した審議案件の紙の検討会文書については，先使用による通常実施権（以下，先使用権という）を確保するために，“公証人の確定日付の付与”を得ている。
特許検討会のメンバが送受信する電子メール（以下，メールという）に添付されている電子ファイルやファイルサーバに保存されている電子ファイルのような日常的にやり取りしている技術情報は，“公証人の確定日付の付与”を得ていない。
特許検討会は情報システム部に対して，次の二つの要望を出した。
先使用権を確保するために，検討会文書の電子ファイルは，経営管理部の特許責任者の押印に相当するディジタル署名を付与し，署名日の証明機能をもたせたい。 従業員が送信したメールに添付された技術報告書の電子ファイルを検索できるようにしたい。 〔W 社の情報システム〕
W 社の情報システムには，インターネット接続システム，製造管理システム，業務管理システム及び PC 管理システムがある。情報システムの各サーバは，導入後，5 年をめどに更新している。情報システムの全てのサーバは，全ての電子ファイルのウイルススキャンを 1 日に 1 回行っている。W 社のネットワーク構成を図1に示す。
図1 W 社のネットワーク構成
FW では，拒否した通信をログとして記録している。情報システムの各サーバでは，サーバへのアクセス及びプログラムの動作をログとして記録している。FW 上及びサーバ上でのログの保存期間は 6 か月である。
外部 DNS サーバは，インターネット上の時刻サーバとの間で，a を用いて時刻同期を行っている。FW 及び情報システムの各サーバは，外部 DNS サーバとの間で，a を用いて時刻同期を行っている。
〔PC の利用状況〕
W 社の PC は全て会社が貸与している。各部門における，PC の貸与状況を表1に示す。
表1 PC の貸与状況
W 社では，全ての PC にウイルス対策ソフトを導入している。ウイルス対策ソフトは，PC の起動時及び起動後は 2 時間ごとに PC 管理サーバからウイルス定義ファイルをダウンロードし，更新する。
PC 管理サーバは，1 時間ごとにプロキシサーバ経由でウイルス対策ソフトのベンダの Web サーバからウイルス定義ファイルをダウンロードし，更新する。
全ての PC は，起動時に，PC 管理サーバとの間で時刻同期を行っている。
PC の IP アドレスは，DPC には固定的に割り当て，NPC には，L3SW の DHCP リレーエージェント機能によって動的に割り当てている。
PC の利用者 ID は，従業員ごとに割り当てている。
〔W 社におけるメールの利用〕
従業員は，PC のメールソフトを用いて，他の従業員との間及びインターネットとの間でメールの送受信を行っている。表計算ソフトを使って作成した注文票など，第三者に秘匿したい電子ファイルを送信する場合は，暗号化した上で，メールに添付している。メールソフトの受信フォルダと送信済フォルダの管理は，従業員に任されている。
W 社のメールアドレスのドメイン名には，W 社が取得したドメイン名（以下，W 社ドメイン名という）を用いている。
情報システムのサーバのうち，メールを扱うのは，外部メールサーバ，内部メールサーバ及び WF サーバである。各サーバのメールに関する機能及び動作概要を表2に示す。
表2 各サーバのメールに関する機能及び動作概要
外部メールサーバ及び内部メールサーバでは，オープンリレー対策を実施している。オープンリレー対策では，SMTP の転送元又は送信元と，エンベロープの受信者ドメイン名の組合せで，転送と送信の許可又は拒否を判定する。判定条件は，図1，従業員用 PC の使用状況及び表2を考慮して決めている。外部メールサーバのオープンリレー対策設定を表3に，内部メールサーバのオープンリレー対策設定を表4に示す。
表3 外部メールサーバのオープンリレー対策設定
表4 内部メールサーバのオープンリレー対策設定
表2の“PC からのメール受信要求受付”では利用者認証が行われる。しかし，表2の“WF サーバ及び PC からのメール送信要求受付”では利用者認証（以下，“WF サーバ及び PC からのメール送信要求受付”での利用者認証を，送信利用者認証という）が行われておらず，送信利用者認証の実現が課題になっている。
〔送信利用者認証と特許検討会の要望の実現に関する検討〕
情報システム部の G 部長は，送信利用者認証及び特許検討会の要望の実現を検討するように，H 主任と J さんに指示した。
H 主任と J さんは，G 部長の指示について検討し，実現すべき機能を表5のようにまとめた。
表5 実現すべき機能
J さんは，表5の実現すべき機能について検討した。
〔送信利用者認証機能に関する具体的な検討〕
J さんは，送信利用者認証機能について，表6に示す具体案を H 主任に説明した。
表6 送信利用者認証機能を実現するための具体案
J さんは，PC からのメール送信方法が現在と変わらない X 案を採用したいと，H 主任に説明した。H 主任は，W 社における PC 及びメールの利用状況を考慮すると，X 案では，POP3 の認証を実行しなくてもメールを送信できる場合があり，課題が解決できないことを指摘した。H 主任の指摘を踏まえて，Y 案が採用されることになった。
〔メールの保管及び検索機能に関する具体的な検討〕
J さんは，内部サーバ LAN にアーカイブサーバを導入してメールの保管及び検索機能を実現することとし，図2に示すアーカイブサーバの機能及び運用案を作成した。
図2 アーカイブサーバの機能及び運用案
J さんは，H 主任に図2の案を説明した。次は，その時の会話である。
H 主任：図2の 3.1 と 3.6 について，社内メールサーバの機能を考慮すると，保管されているメールの添付ファイルからウイルスが検知される可能性がありますね。 J さん：アーカイブサーバに保存された時点のウイルス定義ファイルにないウイルスが検知されるということでしょうか。 H 主任：はい。図2の 3.1 についてはそうですね。しかし，アーカイブサーバに保存された時点のウイルス定義ファイルにあるウイルスであっても，図2の 3.6 で検知される可能性があります。①具体的には，アーカイブサーバから PC にダウンロードしたメールの添付ファイルにアクセスしたときに，ウイルスが検知される可能性があります。 J さん：そのほかに，PC のメールソフトで受信したメールの添付ファイルにアクセスしたときに，同じようにウイルスが検知される可能性がありますね。利用者への説明事項を作成するようにします。 H 主任：図2の 3.2 について，どのように検索の範囲を限定しますか。 J さん：ヘッダにある From，To，Cc のメールアドレスと従業員のメールアドレスを比較し，限定します。 H 主任：それでは不十分ですね。従業員宛てに届いたメールを例に説明します。②ヘッダのメールアドレスと従業員のメールアドレスとの比較では，従業員宛てに届いたメールであっても，検索できないことがあります 。図2の 3.3 も同様です。 J さん：はい，分かりました。比較方法を修正します。 H 主任：専用メールアドレスに届くメールは，従業員が社内から送信したメールに限定すべきです。どのように実現しますか。 J さん：③表2に示したメールに関する機能で実現します 。 H 主任：分かりました。それから，④アーカイブサーバの導入によって，メール利用に関する抑止的な効果が期待できます ね。 最後に，J さんは，図2の 4.について H 主任に説明した。H 主任は説明内容を了承した。
〔電子提出機能に関する具体的な検討〕
J さんは，図3に示す電子提出機能に関する案を H 主任に説明した。
図3 電子提出機能に関する案
H 主任は，図3の 3.の DVD-R では，第三者に署名日を証明できないことを指摘した。J さんが検討したところ，TSA（Time Stamping Authority）が発行するタイムスタンプを付与すれば，タイムスタンプの有効期間中は，電子ファイルが e 及び f を証明可能であることが分かった。
Z 社のタイムスタンプサービスの導入を前提に調査したところ，TSA 証明書の有効期間は 10 年間であった。
そこで，H 主任は，検討会文書の保管が必要な期間を考慮し，長期署名サービスの導入を行うように指示した。長期署名とは，電子ファイルのディジタル署名値とそのタイムスタンプの検証に必要な公開鍵証明書や失効情報などの情報を加えたタイムスタンプ（以下，アーカイブタイムスタンプという）を付与し，そのアーカイブタイムスタンプの有効期間内に，再びアーカイブタイムスタンプの付与を繰り返す方式である。J さんは，更に検討を行い，図3を修正した。
続いて，長期署名の検討を踏まえて，J さんは，図4に示す DVD-R の保管方法案を作成した。
図4 DVD-R の保管方法案
H 主任と J さんは，⑥情報セキュリティ技術の観点から，アーカイブタイムスタンプについての事項を確認する手順を図4の 2.に追加した 。
H 主任は，DVD-R の保管方法案を特許検討会に提示した。特許検討会では，検討の結果，提示された DVD-R の保管方法案を採用することにした。
H 主任と J さんは，これまでの検討結果を踏まえ，表5の機能の導入計画を作成し，G 部長に報告した。計画は経営会議で報告され，承認された。そこで，H 主任と J さんは，計画を実行に移した。
出題趣旨（IPA）
文書保管の媒体が紙から電子ファイルに変化している。電子ファイルによる保管では，検索が容易になるという利便性がある。しかし，ビジネス用途では，改ざんや作成時期の確定に関する課題がある。電子ファイルによる保管を進めてゆくためには，これらの課題解決が必要である。本問では，技術情報の保管を題材にして，電子メール，電子メールアーカイブ及びディジタル署名に関する知識及び設計能力を問う。
採点講評（問全体・IPA）
問2では，技術情報の管理を題材にして，そこで必要となる情報セキュリティ対策について出題した。全体として正答率は高かった。
設問と解答例
設問1
解答欄2つ
本文中の a ，表2中の b に入れる適切な字句を，それぞれ英字 5 字以内で答えよ。
解説
本文の根拠
〔W 社の情報システム〕
外部 DNS サーバは，インターネット上の時刻サーバとの間で，
表2 送信ドメイン認証
ディジタル署名を利用する
表2 送信ドメイン認証
SPF（Sender Policy Framework）検証機能によってメールの送信ドメインを認証する
a は NTP，b は DKIM である。
a は，時刻サーバとの間で時刻同期を行うプロトコルなので NTP（Network Time Protocol）である。RFC 5905 は，NTP を“インターネット上でコンピュータの時計を同期するために広く使われている”プロトコルと説明している。FW と各サーバは外部 DNS サーバと NTP で時刻を合わせ，ログの時刻がそろうようにしている。b は，メールの送信ドメインを認証する機能で，SPF 検証とともに使われ，ディジタル署名を利用するものなので，DKIM（DomainKeys Identified Mail）である。RFC 6376 は，DKIM を，署名するドメインの持ち主がメッセージに対する責任を引き受けるための仕組みとして定めている。送信側のドメインがメールにディジタル署名を付け，受信側が DNS に公開された公開鍵で検証する。
ともに英字 5 字以内という制限があり，NTP（3 字）と DKIM（4 字）で収まる。SPF は IP アドレスによる認証でディジタル署名を使わないので，b には入らない。S/MIME のようにメール本文に署名して利用者を証明する方式でもない点に注意する。
採点講評（IPA）
設問1のbは，正答率が低かった。DKIM(DomainKeys Identified Mail)は，迷惑メールに対する有効な対策の一つである。DKIMの仕組みをよく理解しておいてほしい。
設問2(1)
40字以内
メール転送時のウイルススキャンを，外部メールサーバではなく内部メールサーバで行う目的を 40 字以内で述べよ。
解答例
従業員間で送受信するメールによるウイルス感染の可能性を減らすため
解説
本文の根拠
〔W 社におけるメールの利用〕
従業員は，PC のメールソフトを用いて，他の従業員との間及びインターネットとの間でメールの送受信を行っている。
表2 外部メールサーバ メール転送
SMTP を使用し，インターネットと内部メールサーバとの間でメールを転送する。
表2 内部メールサーバ ウイルス対策
メール転送，並びに WF サーバ及び PC からのメール送信要求受付で，ウイルススキャンを行う。
解答例は“従業員間で送受信するメールによるウイルス感染の可能性を減らすため”（32 字）である。外部メールサーバが扱うのは，インターネットと内部メールサーバとの間で転送するメールだけである。従業員間のメールは，PC のメールソフトから内部メールサーバに送られ，内部メールサーバのメールボックスに保存されるだけで，外部メールサーバを経由しない。
したがって，ウイルススキャンを外部メールサーバだけで行うと，従業員の PC が感染して従業員間で送るメールのウイルスを見逃す。内部メールサーバは，メール転送のほか，WF サーバや PC からのメール送信要求を受け付けるときにもウイルススキャンを行うので，社内から送られるメールもスキャンの対象になる。
制限は 40 字である。“社外から届くメール”ではなく，“従業員間のメール（社内で送受信するメール）”がスキャンされない点と，その目的（ウイルス感染を防ぐ）を入れる。
設問2(2)
解答欄1つ
表3中の c に入れる適切なサーバ名を，図1中の字句を用いて答えよ。
解説
本文の根拠
表3
社外のドメイン名
表2 外部メールサーバ メール転送
SMTP を使用し，インターネットと内部メールサーバとの間でメールを転送する。
表2 内部メールサーバ
外部メールサーバとの間でメールを転送する。
c は“内部メールサーバ”である。表3は外部メールサーバのオープンリレー対策で，項番 1 が“インターネット→W 社ドメイン名宛て”（社外から社内宛て）の許可，項番 3 が“全て拒否”である。項番 2 は“社外のドメイン名宛て”を許可する行なので，社内から社外へ送るメールを中継する相手を書く。
社外宛てのメールは，PC のメールソフトや WF サーバから内部メールサーバに送られ，内部メールサーバから外部メールサーバに転送される。図1で外部メールサーバと接続しているのは，社内側では内部メールサーバだけなので，c は“内部メールサーバ”である。
図1中の字句を用いて答える設問なので，“内部メールサーバ”と書く。“社内のサーバ”“PC”とすると，許可の範囲が広がりすぎて，オープンリレー対策にならない。
採点講評（IPA）
設問2(2)は，正答率が高かった。メールのオープンリレー対策に関する理解が高いことがうかがわれた。
設問2(3)
解答欄1つ
表4中の d に入れる適切なネットワークを，図1中の(a)〜(i)から全て選び，記号で答えよ。
解説
本文の根拠
図1 注記
W 社の PC は全て，いずれかの PC-LAN に接続されている。
表4
WF サーバ
表2 内部メールサーバ
SMTP を使用し，WF サーバ及び PC 上のメールソフトから送信されたメールを受け付ける。
d は“(d)，(f)，(g)”である。表4は内部メールサーバのオープンリレー対策で，項番 1 が外部メールサーバ（外部からの転送），項番 2 が WF サーバからの W 社ドメイン名宛て，項番 3 が“全て宛て”の許可，項番 4 が全て拒否である。項番 3 は，社内から社外宛てのメールを送る PC 側（送信元）の許可を書く。
内部メールサーバが PC から送信を受け付けるのは，表2のとおり PC 上のメールソフトからである。図1の注記により，PC は全ていずれかの PC-LAN に接続されており，PC-LAN は，(d) 工場 PC-LAN，(f) 営業所ネットワーク（の営業所 PC-LAN），(g) 本社 PC-LAN である。
(a) インターネットは外部からの送信元になるので許可しない（拒否の項番 4 に任せる）。(b) DMZ は外部メールサーバが入っていて，項番 1 で扱う。(c) 内部サーバ LAN と (e) 製造管理システム LAN，(i) PC 管理システム LAN は PC が接続されず，(h) 業務管理システム LAN の WF サーバは項番 2 で扱っている。“全て選び”なので 3 つとも書く。
設問3
55字以内
〔送信利用者認証機能に関する具体的な検討〕について，X 案で，POP3 の認証を行わなくてもメールを送信できる状況を 55 字以内で具体的に述べよ。
解答例（2通り）
製造部のDPCで，ある従業員がPOP3認証された後の一定時間内に，他の従業員がログインした場合 POP3認証を行ったNPCのIPアドレスが，認証後の一定時間内に他のNPCに割り当てられた場合
解説
本文の根拠
表6 X案
POP3 の認証が行われた IP アドレスから内部メールサーバへのメール送信を，認証後，一定時間だけ許可する。
表1 製造部
5 名のメンバで構成される作業グループごとに，1 台の共用 DPC を貸与
〔PC の利用状況〕
NPC には，L3SW の DHCP リレーエージェント機能によって動的に割り当てている。
X 案の POP before SMTP は，POP3 で認証された IP アドレスからのメール送信を，一定時間だけ許可する方式である。許可の単位が利用者ではなく IP アドレスなので，認証した人と送信する人が違っても，同じ IP アドレスなら POP3 の認証なしで送信できる。解答例は，次の 2 つの状況を挙げている。
・製造部では 5 名で 1 台の共用 DPC を使い（47 字），ある従業員が POP3 認証した後の一定時間内に，他の従業員が同じ DPC にログインして送信する場合。
・NPC の IP アドレスは DHCP で動的に割り当てているので（47 字），POP3 認証を行った NPC の IP アドレスが，認証後の一定時間内に他の NPC に割り当てられる場合（その NPC は POP3 認証をしなくても送信できる）。
字数は，どちらも 47 字（制限は 55 字）である。“共用 PC”“IP アドレスの再割当て”のどちらか一方を，“認証後の一定時間内”の条件とともに具体的に書く。どちらでもよい。
設問4(1)
50字以内
本文中の下線①について，ウイルスが検知される可能性がある理由を 50 字以内で具体的に述べよ。
解答例
暗号化されていたためにウイルス駆除できなかった添付ファイルが，復号される場合があるから
解説
本文の根拠
〔W 社におけるメールの利用〕
第三者に秘匿したい電子ファイルを送信する場合は，暗号化した上で，メールに添付している。
下線①
アーカイブサーバから PC にダウンロードしたメールの添付ファイルにアクセスしたときに，ウイルスが検知される可能性があります
解答例は“暗号化されていたためにウイルス駆除できなかった添付ファイルが，復号される場合があるから”（43 字）である。W 社では，秘匿したい電子ファイルは暗号化してメールに添付している。暗号化された添付ファイルは，内部メールサーバやアーカイブサーバでウイルススキャンをかけても中身を調べられない。
PC に保存し，従業員が添付ファイルを開く（アクセスする）ときには，復号されるので，PC のウイルス対策ソフトが，最新のウイルス定義ファイルで中身を検査できる。アーカイブサーバに保存された時点のウイルス定義ファイルにはなかった新しいウイルスだけでなく，保存時点で駆除できなかった暗号化ファイルの中のウイルスも，PC で検知されることになる。
制限は 50 字である。“暗号化されていた”→“スキャンできなかった”→“復号したときに検知される”という筋道を，43 字に収めている。単に“ウイルス定義ファイルが古い”とだけ書くと，下線①の PC での検知の理由にならない。
設問4(2)
解答欄2つ
本文中の下線②について，検索できないメールの例を一つ挙げ，25 字以内で具体的に述べよ。また，修正後のメールアドレスの比較方法を 40 字以内で述べよ。
〔メールの例〕解答例
受信者メールアドレスをBccに設定したメール メーリングリスト宛に送信したメール
〔比較方法〕解答例
メールのエンベロープのメールアドレスと検索対象のメールアドレスを比較する。
解説
本文の根拠
会話
ヘッダにある From，To，Cc のメールアドレスと従業員のメールアドレスを比較し，限定します。
図2 2.1
複製したメールにエンベロープなどの情報を付加し，アーカイブサーバに転送する。
下線②
従業員宛てに届いたメールであっても，検索できないことがあります
検索できないメールの例は，“受信者メールアドレスをBccに設定したメール”か“メーリングリスト宛に送信したメール”（22 字，17 字）で，比較方法は“メールのエンベロープのメールアドレスと検索対象のメールアドレスを比較する。”（37 字）である。
ヘッダの From，To，Cc と比べる方法では，Bcc で受信した従業員のアドレスはヘッダに書かれない。メーリングリスト宛てのメールも，ヘッダにはリストのアドレスしかなく，個々の従業員のアドレスが載らない。RFC 5321 は，SMTP のエンベロープを，送信者のアドレス，一つ以上の受信者アドレスなどからなると定めている。配送のための受信者アドレスはエンベロープに入っているので，図2の 2.1 で付加するエンベロープの宛先と比較すれば，Bcc やメーリングリストで受け取った従業員のメールも検索できる。
制限は，例が 25 字，比較方法が 40 字である。例は，ヘッダに従業員のアドレスが載らない具体例（Bcc，メーリングリスト）を一つ書く。比較方法は，何と何を比べるか（エンベロープの宛先と従業員のメールアドレス）を書き，“ヘッダ”と答えない。採点講評でも，エンベロープの扱いを誤った解答が目立ったとされている。
採点講評（IPA）
設問4(2)比較方法は，エンベロープの扱いに関して誤った解答が目立った。SMTPの仕組みをよく理解しておいてほしい。
設問4(3)
50字以内
本文中の下線③について，実現した内容を図1中のサーバ名を含めて 50 字以内で述べよ。
解答例
外部メールサーバの受信者メールアドレスの拒否リストに，専用メールアドレスを登録する。
解説
本文の根拠
表2 迷惑メール対策
情報システム部の運用担当者は，送信者メールアドレスや受信者メールアドレスを，それぞれの拒否リストに登録できる。
図2 1.
内部メールサーバ上の技術情報同報専用のメールアドレス（以下，専用メールアドレスという）にも同報する。
会話
専用メールアドレスに届くメールは，従業員が社内から送信したメールに限定すべきです。
解答例は“外部メールサーバの受信者メールアドレスの拒否リストに，専用メールアドレスを登録する。”（42 字）である。専用メールアドレスは，内部メールサーバ上のアドレスで，社内の従業員が送るメールだけを同報したい。社外から届くメールが専用アドレス宛てに入ると，検索の対象が社外のメールで汚れる。
そこで，インターネット側の入口になる外部メールサーバで，受信者メールアドレスの拒否リストに専用アドレスを登録すれば，社外から専用アドレス宛てのメールは外部メールサーバが拒否する。社内から送るメールは外部メールサーバを経由しないので，この設定の影響を受けない。表2の“迷惑メール対策”の機能で実現できる，というのが J さんの答えである。
制限は 50 字である。“図1中のサーバ名”を含めるよう求められているので，外部メールサーバという名称，拒否リスト，登録するもの（専用メールアドレス）の 3 点を書く。送信者メールアドレスの拒否リストでは，社外の送信者を網羅できない。
設問4(4)
25字以内
本文中の下線④について，どのような行為を抑止する効果が期待できるか。その行為を 25 字以内で述べよ。
解答例
解説
本文の根拠
図2 1.
従業員が技術情報の電子ファイルを添付したメールを送信する場合は，内部メールサーバ上の技術情報同報専用のメールアドレス
図2 4.1
アーカイブサーバの運用を開始する前に，全従業員にアーカイブサーバの機能を説明する。
下線④
アーカイブサーバの導入によって，メール利用に関する抑止的な効果が期待できます
解答例は“技術情報を含むメールを社外に送信する行為”（20 字）である。アーカイブサーバには，従業員が送ったメールが全て保存され，技術情報の電子ファイルを添付したメールは専用アドレスにも同報される。主任以上や人事総務部長が検索でき，従業員には運用開始前に機能を説明するので，“送ったメールが後から調べられる”ことが全従業員に知らされる。
これは，技術情報を社外に送って流出させる行為を思いとどまらせる効果がある。W 社は技術をノウハウとして秘匿することもある（特許検討会の“ノウハウとして秘匿”）ので，技術情報の社外への送信は最も防ぎたいメール利用の行為である。
制限は 25 字である。“メールを私的に使う”のような広い表現ではなく，“技術情報を含むメール”を“社外に送信する”の 2 点を入れる。
設問5(1)
解答欄2つ
本文中の e ，f に入れる証明可能なことを，それぞれ 30 字以内で述べよ。
〔e〕解答例
タイムスタンプの時刻に存在していたこと タイムスタンプの時刻以降に改ざんされていないこと
〔f〕解答例
タイムスタンプの時刻に存在していたこと タイムスタンプの時刻以降に改ざんされていないこと
〔備考〕e と f は順不同
解説
本文の根拠
〔電子提出機能に関する具体的な検討〕
TSA（Time Stamping Authority）が発行するタイムスタンプを付与すれば，タイムスタンプの有効期間中は，電子ファイルが
図3 3.
ディジタル署名を付与した検討会文書の電子ファイルを直ちに DVD-R に保存する。
e と f は，一方が“タイムスタンプの時刻に存在していたこと”，もう一方が“タイムスタンプの時刻以降に改ざんされていないこと”である（順不同）。RFC 3161 は，時刻認証局（TSA）の役割を，“データがある時刻より前に存在したことの証拠を作ること”と述べている。TSA は，電子ファイルのハッシュ値に時刻を結び付けて署名したタイムスタンプトークンを発行するので，ハッシュ値が一致すれば，その時刻にそのファイルがあった（存在証明），その時刻以降は変更されていない（完全性の証明）ことを示せる。
DVD-R に保存しただけでは，第三者に署名日を示す根拠がない。H 主任が指摘したのは，この点である。タイムスタンプは，署名日の証明の部分を，TSA の保証で補う。
制限は，それぞれ 30 字（19 字と 24 字）である。“いつ（時刻）”と“何が（存在・改ざんがないこと）”を入れる。順不同なので，e と f のどちらにどちらを書いてもよい。
採点講評（IPA）
設問5(1)は，タイムスタンプによる電子ファイルの完全性証明と存在証明を理解していない解答が散見された。
設問5(2)
60字以内
図4中の下線⑤の手順を，60 字以内で具体的に述べよ。
解答例（2通り）
作成したDVD-Rの情報を，W社のネットワークを用いて工場に転送し，工場で複製DVD-Rの作成及び保管を行う。 複製したDVD－Rを安全性が確保された手段で遠隔地の保管業者へ運送し，その保管業者で保管する。
解説
本文の根拠
冒頭
東京に本社，国内 8 か所に営業所，関西地区 1 か所に工場がある。
図4 2.
災害対策としての DVD-R の作成及び保管の手順
〔特許取得の推進〕
技術報告書及び議事録（以下，技術報告書と議事録を合わせて，検討会文書という）は，紙のほか，電子ファイルとしても 30 年間保管することになっている。
解答例は 2 つの手順を示している（どちらか一方でよい）。“作成したDVD-Rの情報を，W社のネットワークを用いて工場に転送し，工場で複製DVD-Rの作成及び保管を行う。”（55 字）と，“複製した DVD-R を安全性が確保された手段で遠隔地の保管業者へ運送し，その保管業者で保管する。”（47 字）である。
検討会文書は 30 年間保管するもので，本社で作成した DVD-R が災害で失われても使えるように，遠隔地に複製を持つ手順を決める。W 社は，東京に本社，関西に工場があり，既に遠隔地にある拠点を使える。社外の保管業者を使うなら，運送中の紛失や盗難から守るために，安全性を確保した手段で運ぶことを手順に入れる。
制限は 60 字である。採点講評では，運送時の安全性に触れない解答が多かったとされている。“遠隔地”“複製”“保管”に加え，運送する場合は安全性の確保を書く。
採点講評（IPA）
設問5(2)は，“複製したDVD-Rを遠隔地に運送する”とした解答において，運送時の安全性に言及のない解答が多かった。
設問5(3)
40字以内
本文中の下線⑥について，確認する手順を 40 字以内で具体的に述べよ。
解答例
アーカイブタイムスタンプが有効期間内に偽造されない強度があること
解説
本文の根拠
〔電子提出機能に関する具体的な検討〕
そのアーカイブタイムスタンプの有効期間内に，再びアーカイブタイムスタンプの付与を繰り返す方式である。
〔電子提出機能に関する具体的な検討〕
TSA 証明書の有効期間は 10 年間であった。
図4 2.
5 年ごとに実施する。
解答例は“アーカイブタイムスタンプが有効期間内に偽造されない強度があること”（32 字）である。長期署名は，アーカイブタイムスタンプの有効期間内に，再びアーカイブタイムスタンプを付けて，有効期間をつないでいく方式である。そのため，アーカイブタイムスタンプで使っているハッシュ関数や署名の暗号アルゴリズムが，次に付与するまでの間に破られて偽造できる状態にならないことを，確認しておく必要がある。
暗号アルゴリズムの安全性は時間とともに変わりうる。CRYPTREC は，電子政府で使う暗号の安全性を評価・監視し，推奨する暗号のリストを改定している。5 年ごとの実施手順（図4の 2.）に，使っている暗号の強度を確かめる手順を加えるのは，情報セキュリティ技術の観点からの確認にあたる。
制限は 40 字である。“有効期間内に偽造されない強度”を書く。DVD-R の読取確認（1.）や保管場所のような，技術ではなく運用の観点の確認を挙げると，“情報セキュリティ技術の観点”という条件に合わない。
出典：平成25年度 春期 情報処理安全確保支援士試験 午後Ⅱ 問2（表記を一部改変）
![主なテーブルの構造。rsvList[予約リスト]（rsvDate[予約年月日]，rsvTime[予約時刻]，Biyoshi[従業員 ID]，CustID[顧客 ID]，Status[予約状態]，Menu[注文メニュー]，Messages[美容室へのメッセージ]，LastUpdate[最終更新日時]）。主キーは rsvDate，rsvTime，Biyoshi（下線）。custMaster[顧客マスタ]（CustID[顧客 ID]，Name[氏名]，Address[住所]，Birth[生年月日]，Gender[性別]，Tel[電話番号]，Mail[メールアドレス]，Password[パスワード]，LastUpdate[最終更新日時]）。主キーは CustID（下線）。注記 表記ルールは次のとおり。下線は，主キーを表す。テーブル名[注釈]（列名1[注釈]，列名2[注釈]，列名3[注釈]，…，列名 n[注釈]）。](/data/figures/2013h25h-sc-pm2/q1-f7.png)
![修正されたサーブレット“WakuClick”のソースコード。下線は修正した部分を表す。
1〜23: （省略）〔図5の 1〜23 と同じ〕
24: psSel = conn.prepareStatement("SELECT * FROM rsvList WHERE rsvDate=? AND rsvTime=? AND Biyoshi=?");
25: psUp = conn.prepareStatement("UPDATE rsvList SET Status=?, CustID=?, Messages=?, Menu=?, LastUpdate=? WHERE rsvDate=? AND rsvTime=? AND Biyoshi=? AND CustID=? AND [ s ]");（“ AND CustID=? AND [ s ]”の部分に下線）
26:
27〜46: （省略）〔図5の 27〜46 と同じ〕
47: int rsvStatus = rs.getInt("Status");
48: String rsvCustID = rs.getString("CustID");（下線）
49: if (rsvStatus == RSV_AKI) {（下線）
50: // 予約状況が空きであることを確認し，仮予約処理を行う（下線）
51: （省略）〔予約リストを適切に更新し，仮予約処理を行う〕（下線）
52: } else if (rsvStatus == RSV_KARI && ((nowDateTime - lastDateTime) > TIMEOUT_KARI)) {（下線）
53: // 既に仮予約状態であっても，TIMEOUT_KARI 経過後なら，自分の仮予約に変更する（下線）
54: psUp.setInt(1, RSV_KARI); psUp.setString(2, loginUserID); psUp.setString(3, "");
55: psUp.setString(4, ""); psUp.setLong(5, nowDateTime);
56: psUp.setString(6, rsvDate);
57: psUp.setString(7, rsvTime); psUp.setString(8, rsvBiyoshi);
58: psUp.setString(9, rsvCustID); [ t ];（“psUp.setString(9, rsvCustID);”と［ t ］の部分に下線）
59: if (psUp.executeUpdate() == [ u ]) {（“if (psUp.executeUpdate() ==”と“) {”の部分に下線）
60: （省略）〔図6の処理に引き継ぐために，選択した予約枠の情報をサーブレットのセッション情報に保存する〕
61: （省略）〔画面3の HTML 出力を行う〕
62: } else {（下線）
63: （省略）〔予約失敗画面の HTML 出力を行う〕（下線）
64: }（下線）
65: } else {
66〜71: （省略）〔図5の 64〜69 と同じ〕
注記1 SQL 例外を含め，例外処理については省略している。注記2 下線は，修正した部分を表す。注記3 （省略）〔…〕は，その位置に〔 〕内に示す処理が記述されているが，省略していることを示す。](/data/figures/2013h25h-sc-pm2/q1-f9.png)
