平成24年度 秋期 午後Ⅰ

本文の根拠

表 1 項番2

基本的には 24 時間 365 日，W サービスを利用できるようにする。メンテナンスなどによる計画停止は，毎月第 3 日曜日の 23 時から翌日 8 時までとする。計画停止以外のサービス停止は，年間 50 時間以内とする。

計画停止は毎月 23 時〜翌 8 時の 9 時間で，年に 9 × 12 ＝ 108 時間。1 年は 24 × 365 ＝ 8,760 時間なので，動かす予定の時間は 8,760 − 108 ＝ 8,652 時間である。

そのうち止まってよいのは 50 時間なので，稼働率は (8,652 − 50) ÷ 8,652 ≒ 99.422％。小数第 3 位を四捨五入して「99.42」。

計画停止も停止に数えて 1 年全体で割る考え方もあり，(8,760 − 108 − 50) ÷ 8,760 ≒ 98.196％で「98.20」になる。解答例はどちらも正解としている。

本文の根拠

〔クラウドサービスの活用〕

稼働率に関するサービスレベル目標を達成するためには，プラットフォーム部分の稼働率を 99.9％以上にする必要があると判断した。

表 2

項番2 プラットフォームの稼働率：A 社 99.5％以上，B 社 99.5％以上。

表 2

項番4 障害発生時の連絡時間：A 社 規定なし

表 1 項番4

障害が発生した場合には，障害検知から 30 分以内に営業管理部に連絡する。

表 1 のサービスレベル目標と，A 社の標準サービス（表 2）を 1 行ずつ突き合わせる。

まず稼働率。U 氏はプラットフォームに 99.9％以上が要ると判断したが，A 社は 99.5％以上しか約束していない。次に障害連絡。W サービスは検知から 30 分以内に営業管理部へ連絡する目標があるのに，A 社は障害発生時の連絡時間を規定していない。クラウド側の障害を知らされなければ，30 分以内の連絡はできない。

①・②とも 30 字以内。解答例は「プラットフォームの稼働率が99.9％に満たないから」（24字）と「障害発生時の連絡時間に関して規定がないから」（21字）。リソース追加の所要時間は A 社のほうが短いので，理由にならない。

本文の根拠

表 1 項番1

応答時間は，3 秒以内とする。3 秒を超えた場合は，システムを停止させずに，応答性能の改善を 2 時間以内に実施する。

〔クラウドサービスの活用〕

また，Web 画面の応答性能が低下した場合には，CPU，メモリなどを迅速に増強して改善することにした。

表 2

項番1 リソース追加の所要時間：A 社 依頼から 30 分以内，B 社 依頼から 1 営業日以内。

応答性能の目標では，3 秒を超えたら 2 時間以内に改善しなければならない。U 氏は，応答が遅くなったら CPU やメモリを増強して改善すると決めている。

B 社の標準サービスでは，リソースの追加は依頼から 1 営業日以内で，2 時間では間に合わない。オプションを選べば 30 分以内になり，2 時間の中で増強できる。

40字。解答例は「応答時間が3秒を超えた場合は，2時間以内に改善する必要があるから」で31字。「3 秒」「2 時間以内」の数字を入れて，表 1 のどの目標を守るためかを示す。

採点講評（IPA）

設問2(2)は，正答率が高かった。Web画面の応答性能のサービスレベル目標を達成するために，オプションの選択が必要であることが，おおむね理解されているようであった。

本文の根拠

表 1 項番3

障害が発生した場合には，5 時間以内に復旧させる。

表 2

項番3 プラットフォームの復旧時間：A 社 4 時間以内，B 社 4 時間以内。

〔オンラインショッピングサイトの提供〕

回復後，全機能が正常であることを自社内で確認してから，消費者向けサービスを再開する。

〔オンラインショッピングサイトの提供〕

しかし，確認作業は 1 時間 30 分も掛かることが判明した。

プラットフォームが壊れると，B 社の復旧に最大 4 時間掛かる。そのあと社内ルールで全機能を確かめてから再開するので，確認の時間が足される。

確認に 1 時間 30 分掛かると，4 時間 ＋ 1 時間 30 分 ＝ 5 時間 30 分で，復旧時間の目標 5 時間を超える。B 社の復旧が 3 時間 30 分を超えたら間に合わない。下線（イ）で確認を 1 時間に縮めたので，4 時間 ＋ 1 時間 ＝ 5 時間に収まった。

50字。解答例は「プラットフォームの復旧時間が3時間30分を超えた場合に，Wシステムを5時間以内に復旧できない。」で47字。「どういう場合に」「どの目標を守れないか」を書く。

本文の根拠

〔オンラインショッピングサイトの提供〕

U 氏は，8 月 1 日からは，初期提供期間の利用者数に見合ったリソースで運用を開始する方針とした。そして，10 月 1 日からは，本格サービスの利用者数に見合ったリソースを追加する計画である。

表 1 項番1

応答時間は，3 秒以内とする。

初期提供期間は，利用者の少ない状態に合わせたリソースで始める。10 月からは本格サービスに合わせてリソースを足す計画である。

この 2 か月は，計画したリソースで本当に 3 秒以内を守れているかを確かめる期間になる。リソースの使用状況と応答時間の実績を見て，計画と合っているかを確認しておけば，10 月に足すリソースの量も実績から見直せる。

40字。解答例は「リソースの使用状況と応答時間の実績値が計画に見合っているかどうか」で31字。「リソース」と「応答時間」の両方を，計画と照らすことを書く。

採点講評（IPA）

設問3(2)は，リソースに関する計画や各種実績値に着眼していない回答が多く，正答率は低かった。本格サービスに先立って初期提供期間を設けた意図を考えて，正解を導き出してほしかった。

本文の根拠

〔オンラインショッピングサイトの提供〕

“オンラインショッピングサイトという新規サービスの提供に当たって，サービス稼働中は，利用者が快適に使用できる環境を提供したい。”との意見が出された。

表 1 項番1

Web 画面の応答性能

営業管理部の意見は「利用者が快適に使用できる環境」である。サービスレベル目標のうち，利用者の快適さに直接かかわるのは Web 画面の応答性能である。

稼働率や復旧時間は止まったときの話で，動いているときの使い心地は表さない。数値の目標（3 秒以内）が利用者にとって十分かを，アンケートで確かめる。

20字。解答例は「Web画面の応答性能に関する満足度」で17字。「満足度」と書いて，アンケートで問う形にする。

本文の根拠

〔予算の立案〕

2012 年度のインターネット予約とサイト閲覧を合わせたピーク時の Web サーバへのアクセス要求の予測値は，21.5 要求／秒となる。これは，現在の Web サーバ群の処理能力 18 要求／秒と AP サーバ群のインターネット予約に割り当てられた処理能力 20 要求／秒のいずれも超過する。

表 4

2009 年度：10.0，1.0，11.0。2010 年度：13.0，1.5，14.5。2011 年度：16.0，2.0，18.0。

T 氏は 21.5 要求／秒を Web サーバにも AP サーバにも当てはめている。しかし AP サーバに来るのはインターネット予約だけで，サイト閲覧は来ない。

インターネット予約は毎年 3.0 ずつ増えているので，2012 年度は 16.0 ＋ 3.0 ＝ 19.0 要求／秒。AP サーバのインターネット予約の枠は 10 × 2 台 ＝ 20 要求／秒で，足りている。Web サーバは 21.5 に対して 6 × 3 台 ＝ 18 なので，こちらは 1 台増やす必要がある。

答えは「AP サーバ」。サイト閲覧も 1.5，2.0 と毎年 0.5 ずつ増えていて，合わせると 19.0 ＋ 2.5 ＝ 21.5 になり，T 氏の数字とも合う。

採点講評（IPA）

設問1(1)(b)は，Webサーバへのアクセス要求合計の予測値（21.5要求／秒）が全てAPサーバで処理されるものと誤解し，インターネット予約と窓口予約の処理能力割当てを変更すればこれらの要求を処理可能とした解答が目立った。問題中の表に記載されている数値の意味について正しく理解することを心がけてもらいたい。

本文の根拠

表 1

サイト閲覧（注1）：利用者 PC から観光案内を閲覧する。利用者 PC→Web サーバ。注1）サイト閲覧は，Web サーバだけで要求が完結する。

〔総合予約システムの概要〕

現在，AP サーバ 1 台当たりの処理能力 15 要求／秒のうち，10 要求／秒をインターネット予約に，5 要求／秒を窓口予約に割り当てている。

(a)のとおり，AP サーバの枠を超えるかどうかは，インターネット予約だけで見ればよい。表 1 の要求の流れで，サイト閲覧は Web サーバで終わり，AP サーバに届かない。

T 氏はサイト閲覧を含めた 21.5 で比べたので，AP サーバも足りないと判断してしまった。

45字。解答例は「APサーバが処理するWebサーバ経由のアクセス要求に，サイト閲覧は含まれないから」で40字。「要求の流れに着目して」とあるので，表 1 の流れから「サイト閲覧は AP サーバに来ない」を書く。

採点講評（IPA）

設問1(1)(b)は，Webサーバへのアクセス要求合計の予測値（21.5要求／秒）が全てAPサーバで処理されるものと誤解し，インターネット予約と窓口予約の処理能力割当てを変更すればこれらの要求を処理可能とした解答が目立った。問題中の表に記載されている数値の意味について正しく理解することを心がけてもらいたい。

本文の根拠

表 3

Web サーバ：取得価額 5,000，年間保守費 750。AP サーバ：10,000，1,500。DB サーバ：20,000，3,000。

図 1

負荷分散装置①とその配下の Web サーバ①・②・③，負荷分散装置②とその配下の AP サーバ①・②，DB サーバが接続されている。

追加で買うのは Web サーバ 1 台なので，a は取得価額の「5,000」千円。

b は追加分を含めた全サーバの保守費である。今は Web サーバ 3 台，AP サーバ 2 台，DB サーバ 1 台で，1 台足すと Web サーバは 4 台。750 × 4 ＋ 1,500 × 2 ＋ 3,000 × 1 ＝ 3,000 ＋ 3,000 ＋ 3,000 ＝「9,000」千円。

数値だけを答える。台数は図 1 から数える。

本文の根拠

〔システム運営費用〕

ハードウェア償却費については，耐用年数 5 年，償却率 0.5 の定率法の償却方式を適用している。

〔システム運営費用〕

ハードウェア償却費＝（取得価額－前年度までの償却費の合計額）× 0.5

2012 年 4 月に使い始めた Web サーバは取得価額 5,000 千円で，2012 年度が 1 年目になる。

1 年目（2012 年度）は 5,000 × 0.5 ＝ 2,500。2 年目（2013 年度）は (5,000 − 2,500) × 0.5 ＝ 1,250。3 年目（2014 年度）は (5,000 − 3,750) × 0.5 ＝ 625。

答えは「625」千円。定率法なので，毎年，残りの半分ずつになる。

本文の根拠

〔システム運営費用の見直し〕

2015 年度以降の年間システム運営費用を大幅に削減してほしい

〔システム運営費用の見直し〕

大容量ディスクの導入には，15,000 千円のハードウェアの購入と年間保守費 2,000 千円が必要である。

〔システム運営費用〕

5 年目までの各年度のハードウェア償却費は次の式で計算し，6 年目以降は償却費が発生しないものとしている。

定率法では，償却費は最初の年が一番大きく，年ごとに半分になる。大容量ディスクは 1 年目 7,500，2 年目 3,750，3 年目 1,875 千円である。

経営企画部が削減を求めているのは 2015 年度以降である。2013 年 4 月に始めれば，大きい 1・2 年目の償却費は 2013・2014 年度に済み，2015 年度は 1,875 千円まで下がる。遅く始めるほど大きい償却費が 2015 年度以降に残り，削減効果が小さくなる。

40字。解答例は「2015年度以降の減価償却費負担を減らし，費用削減効果を高めたいから」で34字。「減価償却費に着目して」とあるので，いつ償却費が重いかを書く。

採点講評（IPA）

設問2(1)は，特定の年度におけるシステム運営費用の内訳に基づいた解答が多く，正答率が低かった。定率法の償却方式による減価償却や早期の使用開始に着目して，正解を導き出してほしかった。

本文の根拠

〔システム運営費用の見直し〕

大容量ディスクという）を導入し，バックアップの実施と複写を自動化することでオペレーション要員を 1 名削減できることが判明した。

表 5

要員 1 人当たりの運用人件費は年間 6,000 千円で一定である。

2014 年度に，変更案で増える費用と減る費用を比べる。増えるのは大容量ディスクの保守費 2,000 千円と，2 年目の償却費 (15,000 − 7,500) × 0.5 ＝ 3,750 千円で，合計 5,750 千円。

減るのはオペレーション要員 1 名分の人件費 6,000 千円。差し引きで変更案のほうが 250 千円安い。

答えは「変更案」。2013 年度（1 年目）は増える費用が 2,000 ＋ 7,500 ＝ 9,500 千円で，現行案のほうが安い。年度によって有利な案が入れ替わる。

本文の根拠

〔システム運営費用の見直し〕

S 氏が総合予約システムの計画を調査したところ，サーバ増強は当面不要で，サーバに関係する新たな保守費の増加，償却費の発生はないことを確認した。

サーバの保守費や償却費は両案で同じなので，差は大容量ディスクと人件費の分だけになる。

変更案は保守費 2,000 ＋ 償却費 3,750 ＝ 5,750 千円増え，人件費が 6,000 千円減る。差は 6,000 − 5,750 ＝ 250 千円。

答えは「250」千円。両案に共通する費目は比べる前に消しておくと，計算が短くなる。

本文の根拠

表 6

インターネット接続：総合予約システムをインターネットに接続する。総合予約システム以外に，電子メールシステムを使った営業部門と利用者間の情報授受にも使用されている。

表 6 を見ると，専用線は総合予約システムだけで使っている。これは全額を総合予約システムに割り当ててよい。

インターネット接続は，総合予約システムのほかに電子メールシステムでも使っている。全額を総合予約システムに付けると，電子メールシステムの分まで負担させることになり，費用の実態と合わない。

40字。解答例は「インターネット接続費用は総合予約システムだけで使用している費用ではないから」で37字。専用線ではなくインターネット接続のほうが問題だと，費目を特定して書く。

本文の根拠

〔ネットワーク関連費用の管理方針変更〕

経営企画部は，財務管理をよりきめ細かく行うために，情報システム部が一括管理しているネットワーク関連費用を，社内システムに適切に割り当てることができないか，検討を始めた。

インターネット接続は複数のシステムで共用している。共用している費用を各システムに割り当てるには，使った量などの基準で分ける「配賦」が要る。

総合予約システムと電子メールシステムの間で，インターネット接続費用を配賦する仕組みを作れば，それぞれのシステムに見合った費用を割り当てられる。

40字。解答例は「総合予約システムと電子メールシステムでインターネット接続費用を配賦する仕組み」で37字。「配賦」の語と，配賦する相手の2つのシステムを入れる。

採点講評（IPA）

設問3(2)は，システムごとの回線使用量を把握可能とすることだけに言及した解答が多くみられた。ITサービス財務管理という視点においては，技術的な面だけにとどまらず，サービスへの費用の割当ての重要性を理解しておいてほしい。

本文の根拠

表 2

グループ1：×，できる。グループ2：×，できない。グループ3：○，できる。グループ4：○，できない。

〔新システムへの移行方式の検討〕

この方式では，新システム移行後に不具合が見つかり，切戻しが必要となった場合でも，グループ単位で現システムに戻すことができる。

グループ 1・3 は，トラブルが起きたら旅行代理店のシステムから宿泊通知を再送できる。グループ 2・4 はできない。

新システムに不具合があって現システムへ切り戻すとき，再送できるグループなら送り直せば取り戻せる。再送できないグループは，通知が失われて本番の業務に影響が出る。そこで，影響の小さいグループ 1・3 を先に切り替えて新システムの不具合を出し切り，影響の大きいグループ 2・4 はあとに回す。

50字。解答例は「後半のグループは切戻し時に宿泊通知の再送ができないので，本番業務に影響を与えるリスクがあるから」で46字。「再送できない」ことと「業務への影響」をつなげる。

採点講評（IPA）

設問1は，正答率が高かった。安全にシステムを切り替えるために，リスクを考慮して段階的に切替えを実施していくという考え方は，おおむね理解されているようであった。

本文の根拠

表 3

宛先ファイル：旅行代理店ごとに，送信可能な宿泊施設の PC 又は FAX の宛先が記録されたファイル。データ量が多く頻繁に追加，変更及び削除が発生し，データの更新頻度が高い。

〔ファイル移行計画の検討〕

全ての旅行代理店の新システムへの移行が完了するまで，新旧のシステムで宛先の追加，変更及び削除について同一の処理を行うことにした。

移行中は，旅行代理店をグループごとに切り替え，不具合があれば現システムに戻す。宛先ファイルは更新が多いので，普通なら，戻すたびに新システムで変わった宛先を現システムに移し直さなければならない。

新旧で同じ更新を続けていれば，どちらの宛先ファイルも常に同じ中身になる。切戻しになっても宛先ファイルを移す作業が要らない。

40字。解答例は「運用開始後に切戻しを行った場合でも，宛先ファイルの移行が不要な点。」で32字。移行時間の短縮以外という条件なので，切戻しの場面での利点を書く。

採点講評（IPA）

設問2(1)は，新旧システムで内容が同一となってバックアップとして利用できるなどとした誤った解答が多く，正答率が低かった。移行計画を策定する場合は，トラブル発生時の切戻しが容易になるよう事前に検討しておくことが，ITサービスを安定して提供するために重要であることを認識してほしい。

本文の根拠

表 3

蓄積ファイル：PC からの取出しのために，過去に送信した宿泊通知が記録されたファイル。旅行代理店ごとに 1 日 1 ファイルが作成される。

〔ファイル移行計画の検討〕

ファイル移行時間を短縮するために，並行稼働開始前に，新システムに全ての宛先ファイルを移行しておき

切替え当日に移す必要があるのは，宛先ファイル（事前に移行済み）とログファイル（移行不要）を除いた，送信・蓄積・課金ファイルである。

蓄積ファイルは 1 日 1 ファイルで，過去の日の分はもう書き換わらない。当日より前の分を切替えの前に新システムへ移しておけば，当日は当日分だけを移せばよい。蓄積ファイルは最大 6 か月分あるので，減らせる量が大きい。

30字。解答例は「過去分の蓄積ファイルを事前に新システムに移行する。」で24字。「過去分」と「事前に」の2語が要点になる。

採点講評（IPA）

設問2(2)は正答率が高かった。切替え当日の作業量軽減対策については，よく理解されているようだった。

本文の根拠

〔宿泊通知管理システムのリニューアル〕

新システムではハードウェア費用を低減させるために，E 社が既に運用しているサーバ上に本番環境を構築することにした。このサーバでは，E 社がサービスを提供する多数のシステムが稼働している。深夜には，各サービス用システムでバッチ処理及びバックアップ処理が行われていて，ファイル書込み処理の負荷が高い。

〔ファイル移行計画の検討〕

K 氏は開発環境のサーバを利用してファイル移行テストを実施し，1 時間以内に移行が完了することを確認した。

〔ファイル移行計画の検討〕

宿泊通知サービスのサービス提供時間は，午前 4 時から翌日午前 3 時までであり，システム移行に利用できる時間は 1 時間しかない。

ファイルを移す 1 時間は午前 3 時〜4 時の深夜である。本番のサーバは他のシステムと共用で，深夜はバッチやバックアップのファイル書込みで負荷が高い。

移行テストは開発環境のサーバで行ったので，この負荷がない。ファイルの移行も書込みなので，本番の深夜では遅くなるおそれがある。本番で起こる高い負荷をかけた状態で，1 時間以内に終わるかを確かめる必要がある。

40字。解答例は「本番環境で発生する負荷の高い状況でも1時間以内にファイル移行が完了できること」で37字。「負荷の高い状況」と「1 時間以内」の2つの条件をそろえる。

本文の根拠

〔宿泊通知管理システムのリニューアル〕

宿泊通知管理システムは，利用開始から 7 年が経過し，その間に，接続する旅行代理店数及び宿泊通知件数が大幅に増加し

〔受入れテストの実施〕

現在のシステム構築時に想定した旅行代理店数及び宿泊通知件数のテストデータを用いて負荷をかけても，処理性能に問題がないことを確認した。

負荷テストは，7 年前に今のシステムを作ったときの旅行代理店数と宿泊通知件数で行っている。その後，どちらも大幅に増えた。

実際に遅延が起きたのは，利用量が最大の午前 9 時ごろ，複数の旅行代理店が大量に送ったときである。今の規模で負荷をかけていれば，テストの段階で見つけられた。

40字。解答例は「負荷テストにおいて旅行代理店数及び宿泊通知件数の増加を考慮していない。」で34字。どの数字を増加分として考えるべきだったかを，本文の語で書く。

採点講評（IPA）

設問3(1)は，機能確認テストが不十分というような誤った解答が多く，正答率は低かった。負荷テストの実施内容が不十分な場合，システムの切替え後にトラブルが発生すると業務への影響が大きくなる。テストの実施方法や負荷が適正かの見極めについて，十分に理解しておいてほしい。

本文の根拠

〔新システムへの切替え〕

K 氏は，F 部長と相談し，システム移行計画を当初予定から 1 週間前倒しして，グループ 3 の切替えを実施した。

〔新システムへの切替え〕

サポートデスクでは一部の旅行代理店からの問合せに対して，K 氏から説明された時点の移行計画に基づいて現システムの調査をしたので，回答に時間を要するなど

移行計画は 1 週間前倒しになったのに，サポートデスクには伝わっていなかった。サポートデスクは古い計画のまま，グループ 3 はまだ現システムだと思って調べてしまった。

問合せに答えるサポートデスクは，どの旅行代理店がどちらのシステムにいるかを正しく知っている必要がある。計画が変わったら，そのたびにサポートデスクへ最新の計画を説明する。

40字。解答例は「移行計画が変更された場合は，サポートデスクに最新のリリース計画を説明する。」で36字。「変更された場合は」と条件を付け，一度きりの説明で終わらないようにする。

本文の根拠

〔サーバの監視〕

販売管理システムのサーバの監視は，監視サービス会社に委託している。レスポンスの低下及びハードウェア障害を検知した場合は，自動的に監視サービス会社に通知され，監視サービス会社が迅速に初動対応を行っている。

〔脆弱性検査の計画〕

検査によってシステムへの負荷が増えるが，潜在する脆弱性を極力洗い出すために，R 社が検査可能な項目のほぼ全てを検査する。

〔脆弱性検査の計画〕

検査日程と，考えられる検査の影響を社内関連部門に事前に通知する。

検査は本番サービス中に行い，ほぼ全項目を試すので負荷が増える。レスポンスが落ちると，監視サービス会社に自動で通知され，監視サービス会社は障害だと思って初動対応を始めてしまう。

事前に知らせる相手は社内関連部門だけになっている。社外の監視サービス会社にも検査の計画を伝えておけば，検査による変化を障害と取り違えずに済む。

40字。解答例は「販売管理システムの監視サービス会社に対し，脆弱性検査の計画を通知する。」で34字。計画(4)が社内だけなので，「社外の誰に」を書く。

本文の根拠

〔C 社販売管理システムの概要〕

Web サーバ，DB サーバ及びメールサーバでは，ログを取得している。情報システム部では，それらを販売管理システムのログとして管理している。

〔販売管理システムのセキュリティ対策〕

D 氏は，ログとその統計情報から不正アクセスの有無を点検している。

検査は攻撃をまねてサーバにアクセスするので，各サーバのログには不正アクセスそっくりの記録が大量に残る。D 氏はログから不正アクセスを点検しているので，そのままでは本物の攻撃と見分けられない。

検査端末の IP アドレスが分かっていれば，その送信元のレコードは検査によるものと区別できる。社外は R 社のグローバル IP アドレス，社内は C 社の検査端末のプライベート IP アドレスである。

40字。解答例は「各サーバのログを，検査に伴うレコードと通常運用のレコードに区別するため」で35字。何と何を分けるのかを書く。

採点講評（IPA）

設問1(2)はファイアウォールの設定を変更し検査端末がサーバへアクセスしやすくするなどの誤った解答が多く，正答率は低かった。本番環境で脆弱性検査を行う場合は，サーバのログを，検査に伴うレコードと通常運用のレコードに区別し，解析などを行う必要があることを意識しておいてほしい。

本文の根拠

表 2

脆弱性②：総当たり攻撃によってシステム管理者の利用者 ID とパスワードが発見される。

〔販売管理システムのセキュリティ対策〕

D 氏は，ログとその統計情報から不正アクセスの有無を点検している。

検査で見つかったのは「こういう攻撃ができる」という弱点で，実際に攻撃されたかどうかは分からない。管理者権限を奪われる，管理者のパスワードが見つかるなど，悪用されていれば被害が大きいものばかりである。

過去のログを見て，すでに不正アクセスがあったかを確かめる。あった場合は，弱点をふさぐだけでなく被害への対応も要り，急ぎ度合いも変わる。

40字。解答例は「不正アクセスがあった場合，対策の内容と対策の緊急度を決めるため」で30字。「対策の内容」と「緊急度」の両方を入れる。

採点講評（IPA）

設問2は，正答率が高かった。脆弱性が発見された場合は既に不正アクセスが発生していないか確認し対策をとることや，脆弱性検査結果に基づいてセキュリティ要件と実装されたシステム内容の差異を分析し対策をとることについては，おおむね理解されているようであった。

本文の根拠

表 2

脆弱性②：総当たり攻撃によってシステム管理者の利用者 ID とパスワードが発見される。

〔販売管理システムのセキュリティ対策〕

利用者認証は，利用者 ID とパスワードの組合せで行う。

総当たり攻撃は，パスワードを次々に試して当たるまで繰り返す手口である。パスワードを強くしても，何度でも試せる限り，いずれ見つかるおそれがある。

試せる回数を絞ればよい。ログインに続けて失敗したら，その利用者 ID をロックして，それ以上試せないようにする。

40字。解答例は「連続して利用者認証に失敗した場合に，該当する利用者IDをロックする機能」で35字。「連続して失敗したら」という条件と，「ロックする」という動作の両方を書く。

採点講評（IPA）

設問2は，正答率が高かった。脆弱性が発見された場合は既に不正アクセスが発生していないか確認し対策をとることや，脆弱性検査結果に基づいてセキュリティ要件と実装されたシステム内容の差異を分析し対策をとることについては，おおむね理解されているようであった。

本文の根拠

〔FW のアクセス制御要件〕

インターネットから Web サーバへは，HTTP サービス，HTTPS サービスへのアクセスだけを許可する。

表 1

R 社検査端末からインターネット経由で外部接続セグメントを検査：Web サーバで HTTP，HTTPS，TELNET，メールサーバで DNS，SMTP が発見された。

表 1 のうち，インターネットから見えたサービスを要件と比べる。メールサーバは DNS と SMTP で，要件どおりである。Web サーバは HTTP・HTTPS に加えて TELNET が見えている。要件ではインターネットから Web サーバへは HTTP・HTTPS だけなので，TELNET が余計に通っている。

社内 LAN から見えた TELNET や POP は，社内からは全サービスを許可する要件なので問題ない。

a は「インターネット」，b は「Web サーバ」，c は「TELNET」。a は「経由」列，b は「発見されたサーバ」列から選ぶという指定どおりの語で書く。

採点講評（IPA）

設問2は，正答率が高かった。脆弱性が発見された場合は既に不正アクセスが発生していないか確認し対策をとることや，脆弱性検査結果に基づいてセキュリティ要件と実装されたシステム内容の差異を分析し対策をとることについては，おおむね理解されているようであった。

本文の根拠

〔販売管理システムのセキュリティ対策〕

システム管理者が特権 ID を利用した作業を行う場合は，J 部長に申請する。

〔販売管理システムのセキュリティ対策〕

特権 ID を使用した操作が実施されると，操作日時と操作内容が記載された電子メール（以下，特権 ID 行使メールという）がシステム管理者に通知される。

〔販売管理システムのセキュリティ対策〕

システム管理者は，通知を受けた特権 ID 行使メールを基に販売管理システムのログを参照し，特権 ID を使った操作に問題がないことを確認する。

特権 ID を使った操作は，特権 ID 行使メールとログで確かめる仕組みになっている。ところが確かめるのはシステム管理者自身である。

システム管理者が自分で特権 ID を使った場合，自分の操作を自分で確かめることになり，不正があっても見逃せてしまう。操作した人と確かめる人を分けるため，システム管理者以外の情報システム部員に作業内容を確認してもらう。

30字。解答例は「システム管理者以外の情報システム部員が作業内容を確認する。」で28字。「誰が」確認するかを変えることが要点になる。

本文の根拠

〔サーバの監視〕

月 1 回の定期保守の際，システム管理者が各サーバの時刻を確認し，FW の時刻と異なる場合は，手動で時刻を補正しているが，時刻が大きくずれていることも多い。

〔外部監査人の指摘〕

販売管理システムのログを分析し，特権 ID を使用した操作の正当性を確認する際に，ログの分析に支障を来すおそれがある。

販売管理システムのログは Web サーバ・DB サーバ・メールサーバの3台で取っている。時刻は月 1 回手で直すだけで，大きくずれていることも多い。

サーバごとに時刻が違うと，特権 ID 行使メールの時刻と各サーバのログを突き合わせても，同じ出来事の記録がつながらない。NTP サーバで全サーバの時刻を自動で合わせれば，ログを時刻でたどれるようになる。

40字。解答例は「全サーバの時刻が一致していないと，取得したログの分析に支障があるから」で33字。「時刻の不一致」と「ログ分析への支障」をつなげて書く。

採点講評（IPA）

設問3(2)は，正答率が低かった。ログを使った調査では，複数のサーバのログをつき合わせて原因究明をする場合がある。この際，全てのサーバの時刻が同期していない場合，原因究明で支障が出る可能性が高いことを，十分理解しておいてほしい。