平成22年度 秋期 午後Ⅰ

本文の根拠

〔契約者情報のバックアップ運用〕

毎週水曜日には，当日取得したフルバックアップだけを磁気テープ媒体に格納して第 2 データセンタに配送し，保管している。配送時間は 8 時間である。

〔契約者情報のバックアップ運用〕

なお，社内ネットワークを使った場合のデータ転送時間は，1 時間と見込んでいる。

〔サービス継続計画の作成〕

S 氏は，契約者情報参照機能について目標復旧時点（以下，RPO という）を設定した上で

RPO は「どの時点のデータまで戻せるか」で，いつバックアップを取るかで決まる。取得のタイミングはテープでもネットワークでも変わらない。運び方を変えても，戻せる時点は同じなので，RPO への効果は「なし」になる。

RTO は「どれだけ早く戻せるか」である。バックアップが第 2 データセンタに届くまでの時間がそのまま復旧の待ち時間に入る。テープの配送は 8 時間，ネットワーク転送は 1 時間なので，7 時間早く使えるようになる。

どちらも 40 字以内。RTO の解答例は「磁気テープ媒体の配送とデータ転送の時間差7時間を削減できる。」で29字。「7 時間」と数字で示すと，本文の 8 時間と 1 時間から計算したことが伝わる。

採点講評（IPA）

設問1は正答率が低く，RPOとRTOの違いを理解できていないと思われる解答が散見された。特に，RPOの内容をRTOと混同している解答が目立った。RPOとRTOは，サービス継続性を考える上で重要な指標であり，是非知っておいてもらいたい。

本文の根拠

〔サービス継続方針〕

契約者情報参照機能を利用するために，契約者情報のデータを障害発生日の午前 0 時の状態にする。

RPO は，要件としてすでに本文に書かれている。「契約者情報のデータを障害発生日の午前 0 時の状態にする」とあるので，戻す時点は障害発生日の午前 0 時である。

バックアップも毎日午前 0 時に取っているので，この時点は実際に戻せる時点とも合っている。

10字。解答例は「障害発生日の午前0時」でちょうど 10 字。「午前 0 時」だけでは何日のかが分からないので，「障害発生日の」を落とさない。

本文の根拠

表 1

X 案：本番サイトで水曜日にフルバックアップを取得し，バックアップサイトに自動転送する。水曜日以外の曜日には，本番サイトで増分バックアップを取得し，バックアップサイトに自動転送する。

〔サービス継続計画の作成〕

S 氏は，表 1 のリストア所要時間について，フルバックアップからのリストアに 1 時間，増分バックアップの適用に 1 日分当たり 10 分間要すると試算した。

X 案で一番時間が掛かるのは，増分が最も溜まった日である。フルバックアップは水曜日の午前 0 時に取り，木曜日から次の火曜日まで毎日増分が 1 つずつ増える。火曜日に被災すると，水曜日のフルに 6 日分の増分を重ねる。

1 時間 ＋ 10 分 × 6 ＝ 2 時間。a は「2」。Y 案は毎日フルを取るので，前日分のフルを 1 回戻すだけで，b は「1」。

数値だけを答える設問なので，単位の「時間」は表にすでにある。増分は水曜日の分がない（フルに含まれる）ことに気を付けて数えると，6 日分になる。

採点講評（IPA）

設問2(2)及び(3)は，取得した増分バックアップからの復旧手順に関連する設問である。正答率が高く，増分バックアップからの復旧作業の手順について正しく理解されていることが推察された。

本文の根拠

〔サービス継続計画の作成〕

ただし，両案ともに，契約者情報参照機能の回復までには被災状況の把握，切替え実施の判断，リストアの事前準備作業など，リストアとは別に 1 時間 30 分を要する見込みである。

〔サービス継続計画の作成〕

契約者情報参照機能の目標復旧時間（以下，RTO という）を 3 時間に設定し

RTO は 3 時間で，リストア以外に 1 時間 30 分掛かる。リストアに使えるのは 1 時間 30 分までである。フルの戻しに 1 時間掛かるので，増分に回せるのは 30 分，つまり 3 日分までになる。

被災した曜日ごとに増分の数を数える。水曜日 0，木曜日 1，金曜日 2，土曜日 3 は間に合う。日曜日 4，月曜日 5，火曜日 6 は，それぞれ 1 時間 40 分，1 時間 50 分，2 時間になり，超える。

答えは「日曜日，月曜日，火曜日」。すべて答えよとあるので，1 つでも抜けると不正解になる。(2)の a と同じ数え方で確かめられる。

本文の根拠

〔本番運用開始に向けた準備〕

4 月 1 日の本番運用開始に向けて，A 社では，3 月 15 日に本番運用に即した形でバックアップサイトへの切替えリハーサルを実施することにした。

〔本番運用開始に向けた準備〕

本番運用に先立って，3 月 1 日からバックアップサイトへのバックアップデータの自動転送を開始し

表 2

項番4：バックアップサイトの DB サーバに対して更新処理を再度実行するための復旧プログラムを，手動で起動する。

リハーサルは「本番運用に即した形で」行うと決めている。3 月 1 日から自動転送が始まっているので，リハーサルの時点で本番と同じバックアップデータがすでにバックアップサイトにある。

テスト用のデータを作ると，本番の手順が確かめられなくなる。自動転送されたデータを使えば，バックアップの取得と転送が正しく行われていることや，項番 4 の復旧プログラムが本物のデータで動くことまで一度に確かめられる。

30字。解答例は3つあり，「本番運用に即した形で切替えリハーサルを行う必要があるから」（27字）などのどれかを書けばよい。

本文の根拠

〔顧客管理システムの概要〕

本番サイトのログサーバ 1 には，AP サーバで処理された利用者の操作ログが，処理の再実行に必要な情報をすべて含んだ状態で取得される。また，A 社の災害対策上の観点から，取得した操作ログは第 2 データセンタに設置されたログサーバ 2 にリアルタイムに反映され，1 年間保存される。

図 2

シーケンス番号，日時，利用者 ID，処理内容。注：シーケンス番号には，AP サーバで実行された処理の順番が記録される。

〔サービス継続計画の作成〕

リストア対象のバックアップ取得以降に行われた契約者情報のデータ更新分については，バックアップサイトの DB サーバに対して更新処理を再度実行するための復旧プログラムを作成しておき

リストアで戻るのは午前 0 時の状態で，その後の更新は失われる。本番サイトは被災しているので，ログサーバ 1 は使えない。リアルタイムに反映されているログサーバ 2 の操作ログを使う。

操作ログは再実行に必要な情報をすべて持ち，シーケンス番号に処理の順番が記録されている。リストアした時点より後の更新を，シーケンス番号の順に実行し直せば，被災直前の状態に近づけられる。

50字。解答例は「ログサーバ2の利用者の操作ログを参照し，リストア済み最終シーケンス番号より後の更新処理を実行する。」で48字。「ログサーバ 2」「シーケンス番号」の2語を入れる。

本文の根拠

〔本番運用開始に向けた準備〕

問題となったオペレーション作業は，1 週間前に実施した本番サイトの基本ソフトウェアの設定変更に伴って追加したもので，本番サイトのオペレーション手順書は，基本ソフトウェアの設定変更後に修正されていた。しかし，バックアップサイトでは，基本ソフトウェアの設定変更を行っただけで，オペレーション手順書を修正していなかった。

リハーサルで戸惑った原因は，本番サイトの手順書は直したのに，バックアップサイトの手順書を直していなかったことである。変更の対象にバックアップサイト側の文書が含まれていなかった。

今回は S 氏がその場で答えて間に合ったが，本当の被災時には頼れない。今後の変更では，バックアップサイトの手順書も変更対象に入れ，本番サイトと食い違わないように変更管理する。

50字。解答例は「変更対象にバックアップサイトのオペレーション手順書を追加し，今後は変更を実施する。」で40字。今回の手順書を直すことだけでなく，「今後」の変更の仕組みまで書く。

採点講評（IPA）

設問3(3)は，正答率が低かった。今後も本番サイトにおける変更が発生することに着眼し，ITサービスマネージャとして，サービス継続計画を維持するための視点が必要であることを理解しておいてほしい。

本文の根拠

表 2

増強方式1：増強が必要となった場合は，CPU やメモリなどのサーバを構成するハードウェアを追加して対応する方式。増強方式2：専用の LB を設置して，複数台のサーバに処理を分散させ，増強が必要となった場合は，別途新規にサーバを追加する方式。

〔予約方式 2，予約方式 3 の処理概要〕

これらの情報は，AP サーバ 3 だけで処理されている。

増強方式 1 は，今の AP サーバ 3 に CPU やメモリを足す。1 台だけで処理しているサーバの中を触るので，増強の作業中はサービスを止めることになる。

増強方式 2 は，LB で複数台に振り分けておき，足りなくなったら別のサーバを加える。既存のサーバは動かしたまま新しいサーバを足せるので，サービス全体を止めずに済む。1 台が壊れても残りで続けられる点も可用性に効く。

方式は「増強方式 2」。理由は 30 字以内で，解答例は「サービス全体を停止させずにサーバの増強が可能だから」で25字。増強の作業に絞って書くと，設問の「更なる増強が必要となった場合」に合う。

採点講評（IPA）

設問1，2は，正答率が高かった。負荷分散装置を活用し複数サーバに処理を分散させることで高い可用性を維持できることは，おおむね理解されているようであった。

本文の根拠

〔予約方式 1 の処理概要〕

LB は，利用者からの要求を 2 台の Web サーバに均等に振り分けるとともに，Web サーバの稼働状態を 5 分間隔で監視し，正常と判断した Web サーバに要求を割り当てる。LB は設定を変更することで，特定の Web サーバへの処理割当てを一時的に取りやめることができる。

表 3 項番2

サービスの回復時間，C 社 Web サイトの障害を検知してから障害が回復するまでの時間，15 分以内

LB は 5 分おきにしか Web サーバを見ていない。障害が起きた Web サーバ 1 に，最大で 5 分近く要求が振られ続けるおそれがある。そのまま再起動などを始めれば，その間の利用者はエラーになる。

LB は設定で特定の Web サーバへの割当てを止められる。障害状況の確認や再起動の前に，まず LB で Web サーバ 1 への割当てを止め，Web サーバ 2 だけで受ける状態にする。

40字。解答例は「LB（負荷分散装置）の設定を変更して当該Webサーバへの処理割当てを取りやめる。」で39字。「LB の設定変更」という手段と，「割当てを止める」という目的の両方を書く。

本文の根拠

〔予約方式 1 の処理概要〕

AP サーバ 1，AP サーバ 2 も Web サーバ 1，Web サーバ 2 と同様に設計されている。

〔予約方式 1 の処理概要〕

同様に Web サーバに振り分けられた要求は，各 Web サーバの設定に従って，AP サーバ 1 又は AP サーバ 2 に割り当てられる。この設定はオンライン中でも変更できる。

〔パッチの適用〕

Web サーバを除く全サーバに対して，定期メンテナンスを待たずに緊急でパッチを適用する必要が生じた。

AP サーバ 1 と 2 は，1 台が止まっても残りで処理できるように作られている。Web サーバの設定はオンライン中でも変えられるので，片方への割当てを止めてからパッチを当て，終わったらもう片方に同じことをすればよい。

この方法なら深夜に作業する必要がなく，人手のある昼間に 1 台ずつ当てられる。サービスも止めないので可用性は下がらない。

50字。解答例は「APサーバ1とAPサーバ2は昼間の時間帯にサービスを停止させずに1台ずつパッチを適用する。」で44字。対象（AP サーバ 1・2），時間帯（昼間），やり方（1 台ずつ）の3点をそろえる。

採点講評（IPA）

設問3(1)は，単純にパッチ適用の作業回数を増やすなどの誤った解答が多かった。緊急対応が必要となる作業で短い作業時間しか確保できない場合には，作業内容を見直したり，作業対象のサーバ台数を減らしたりするなどの対策を立案する。起こり得る事態を予測し予防措置をとることはITサービスマネージャに要求される重要な技能であるので，十分に理解しておいてほしい。

本文の根拠

〔宿泊予約システムの運用〕

データのフルバックアップ作業には 1 時間が必要である。C 社では，機能増強などを行うために DB サーバの変更が必要な場合は，変更作業中に発生する障害に備えて，データのフルバックアップを取得してから変更作業を行うルールになっている。

〔パッチの適用〕

サーバ 1 台当たりの緊急のパッチ適用に必要な時間は 50 分であることが分かった。

〔パッチの適用〕

緊急のパッチを適用する臨時の保守時間帯を，サービスの利用が少なくなる午前 2 時から午前 3 時までの 1 時間とした。

パッチは Web サーバ以外の全サーバに当てるので，DB サーバも含まれる。DB サーバを変更するときは，先にフルバックアップを取るルールがある。

フルバックアップに 1 時間，パッチに 50 分で，DB サーバだけで 1 時間 50 分掛かる。臨時の保守時間帯は 1 時間なので収まらない。H 氏はパッチの時間は検証したが，このルールを見落としていた。

50字。解答例は「パッチ適用前にデータのバックアップを取る必要があるので，臨時の保守時間帯では作業が完了しない。」で46字。「バックアップが要る」ことと「時間内に終わらない」ことを因果でつなぐ。

本文の根拠

〔予約方式 1 の処理概要〕

予約方式 1 では，利用者が予約を取るまでに，予約処理のほかに空室の検索処理や料金参照処理が多数要求されるので，DB サーバの処理負荷が高い。

〔予約方式 1 での販売拡大〕

バナー広告によって，予約方式 1 による予約件数が大幅に増加することが見込まれた。

増えるのは予約方式 1 の件数である。予約方式 1 は，予約 1 件の裏で空室の検索や料金の参照が何度も行われ，それが DB サーバの負荷を押し上げる。

予約件数が大幅に増えれば，検索と参照の要求はそれ以上に増える。Web サーバや AP サーバは 2 台ずつあるが，DB サーバは 1 台で，ここが詰まると全体が遅くなる。

40字。解答例は「空室の検索処理や料金参照処理の増加による負荷増加が見込まれるから」で31字。「予約件数が増えるから」だけでは，DB サーバに絞る理由にならない。

本文の根拠

〔宿泊予約システムの運用〕

システム運用部では，C 社宿泊予約サービスを管轄している営業部に対して，サービスレベルの達成状況を月次レポートにまとめて報告している。

〔予約方式 1 での販売拡大〕

システム運用部では，予約方式 1 による予約件数の増加に合わせて，予約方式 1 の利用者が快適に空室検索や予約を行えるように，システムの構成，運用方式の見直しを行った。

今のサービスレベルは可用性と回復時間の2つで，速さの項目がない。営業部が求めているのは，予約が増えても利用者が快適に使えることである。

快適さを表すのは，利用者が操作してから結果が返るまでの時間である。サーバの CPU 使用率ではなく，利用者から見た応答時間を報告の項目に加える。

20字。解答例は「サービス利用者から見た応答時間」で15字。「応答時間」だけでもよいが，「利用者から見た」を付けるとサービスレベルとしての項目になる。

採点講評（IPA）

設問4(2)は，正答率が高かった。可用性を管理する上で，利用者からの視点でサービスを監視することが重要であり，実務においても十分に意識しておいてほしい。

本文の根拠

〔サポートセンタの概要〕

問合せ内容が FAQ に適合した場合は，問合せ内容と参照した FAQ 番号を，インシデント履歴に記録する。

〔FAQ の改訂〕

一定期間以上にわたって参照されていない項目を抽出して，FAQ から削除する。

「参照されていない FAQ」を見つけるには，どの FAQ が何回参照されたかの記録が要る。

サポートセンタは FAQ に適合した問合せについて，参照した FAQ 番号をインシデント履歴に残している。この履歴を集計すれば，長いあいだ使われていない FAQ が分かる。

字数の指定はない。解答例は「インシデント履歴」。本文に出てくる参照情報（対応マニュアル，操作マニュアルなど）のうち，FAQ 番号を記録しているのはインシデント履歴だけである。

採点講評（IPA）

設問1は，(1)，(2)ともに正答率が高く，FAQの運用に関する理解度は高いと思われる。

本文の根拠

〔サポートセンタの概要〕

適合しなかった場合は，問合せ内容，回答内容及び FAQ 不適合の旨を，インシデント履歴に記録する。

〔FAQ の改訂〕

FAQ が問合せ内容に適合しない場合が多く，記録に手間が掛かるので，FAQ を改善してほしい

FAQ に合わない問合せは，内容と回答を全部書かないといけない。合う問合せなら FAQ 番号だけで済む。窓口担当者の手間を減らすには，合わない問合せを減らせばよい。

インシデント履歴には「FAQ 不適合」の印と，そのときの問合せ内容と回答がすでに残っている。これを抜き出して FAQ に加えれば，次に同じ問合せが来たときは番号だけで記録できる。今の改訂方法は削除と事前予想だけで，実際の問合せから足す方法がない。

55字。解答例は「インシデント履歴からFAQ不適合となっているものを抽出し，当該問合せと回答内容をFAQに追加する。」で48字。どこから抜き出し，何を足すかを書く。

採点講評（IPA）

設問1は，(1)，(2)ともに正答率が高く，FAQの運用に関する理解度は高いと思われる。

本文の根拠

〔発生したインシデントへの対応例〕

システム運用課では，販売システムの稼働状況を確認したが，営業店舗のルータの不具合が疑われたので，営業店舗に直接連絡し，ルータの状態を確認してもらったところ，ルータの異常を示すランプが点灯していることが分かった。

〔インシデント発生時の対応〕

業務に関することはアプリケーション保守課に，ネットワークに関することはネットワーク保守課に，その他に関すること及び不具合箇所を特定できないときはシステム運用課に，それぞれ対応を依頼する。

今回は，サポートセンタが原因を絞れずにシステム運用課へ回し，システム運用課が店舗にルータのランプを見てもらって，ようやくネットワーク保守課へ回った。

ルータのランプの確認は，店舗に見てもらうだけの簡単な作業である。「接続できない」という問合せを受けた時点でサポートセンタが店舗に確かめれば，最初からネットワーク保守課に回せる。システム運用課を通る分の経路がなくなる。

50字。解答例は「ルータの状態を営業店舗に確認し，異常があればネットワーク保守課に対応を依頼する。」で39字。「確認する」だけでなく，異常時の依頼先まで書く。

採点講評（IPA）

設問2(1)は，正答率が低かった。サポートセンタ（1次窓口）では，受け付けたインシデントについて，利用者へのヒアリングによって，障害の原因を特定できるように状況を正確に把握した上で，適切な2次窓口にエスカレーションすることが必要であることを理解しておいてほしい。

本文の根拠

〔発生したインシデントへの対応例〕

この対応例の場合，図中の矢印で示される連絡経路は，“営業店舗→サポートセンタ”，“サポートセンタ→システム運用課”，“システム運用課→営業店舗”，“システム運用課→ネットワーク保守課”，“ネットワーク保守課→サポートセンタ”，“サポートセンタ→営業店舗”で，連絡経路数は 6 となる。

今の 6 経路のうち，システム運用課が絡むのは「サポートセンタ→システム運用課」「システム運用課→営業店舗」「システム運用課→ネットワーク保守課」の 3 つである。

見直し後はシステム運用課を通らない。ルータの確認は最初の問合せのやり取りの中で行う。残るのは「営業店舗→サポートセンタ」「サポートセンタ→ネットワーク保守課」「ネットワーク保守課→サポートセンタ」「サポートセンタ→営業店舗」の 4 つである。

答えは「4」。サポートセンタ→ネットワーク保守課の依頼が 1 本増え，システム運用課の 3 本が消えるので，6 − 3 ＋ 1 ＝ 4 と数えても同じになる。

本文の根拠

〔インシデント発生時の対応〕

1 次窓口であるサポートセンタでは，受け付けたインシデントを解決するために，診断スクリプトを使用してインシデントの初期診断などを行う。また，FAQ などの情報に基づいて調査し，サポートセンタで回答できる場合は，速やかに回答する。

〔インシデント発生時の対応〕

対応を依頼された各課では，サポートセンタから得た情報を基にして，各課で整備されている診断手順によって原因と対処方法を特定し

〔営業店舗チームの改善〕

今年 5 月以降，営業店舗から，端末の業務アプリケーションに関する問合せが多く寄せられていて，その都度アプリケーション保守課に対応を依頼していた

業務アプリケーションの問合せを，サポートセンタは毎回アプリケーション保守課に回している。サポートセンタで答えるための材料（診断スクリプトと FAQ）に，この分野の中身が足りないからである。

アプリケーション保守課は自分たちの診断手順で答えを出している。その診断手順の一部を診断スクリプトに組み込むか，これまでの問合せと回答を FAQ に加えれば，サポートセンタだけで答えられるようになる。

40字。解答例は「アプリケーション保守課の診断手順の一部を診断スクリプトに反映する。」（32字）と「アプリケーションに関する問合せと回答内容をFAQに反映する。」（29字）の2つ。どちらもサポートセンタが使う道具に，保守課の知識を移す考え方である。

本文の根拠

〔法人会員チームの改善〕

問合せの受付から回答までに時間が掛かりすぎている

表 1

項番2：平均応答時間，サポートセンタに着信してから，窓口担当者が電話に出るまでの平均時間，10 秒以下。

〔インシデント発生時の対応〕

インシデントが重要トラブルと判断される場合，サポートセンタではインシデントの解決時間に目標値を設定し，対応を開始する。

不満は「受付から回答までの時間」である。ところが表 1 の管理指標は，電話に出るまでの時間と解決率で，回答までの時間を測っていない。解決時間の目標値を置くのも，重要トラブルのときだけである。

各課に対策を頼んでも，サポートセンタが回答までの時間を見ていなければ，改善したかどうか分からない。受付から利用者への回答までの時間を管理するか，重要トラブル以外にも解決時間の目標値を置いて管理する。

40字。解答例は「サポートセンタで受け付けてから利用者に回答するまでの時間を管理する。」（33字）と「すべてのインシデントについて目標解決時間を設定して，管理する。」（30字）の2つ。

採点講評（IPA）

設問4は，正答率が低かった。問合せから解決までに要する時間は，利用者の満足度に大きく影響する。“問合せの受付から回答までに時間が掛かりすぎている”という利用者の不満を解消するために，利用者の視点に立った管理指標を設定し，測定・管理することが重要であることを理解しておいてほしい。

本文の根拠

表

a → パスワードは，定期的に変更することとし，類推が困難な文字列を採用すること。

表

不正利用した個人を特定できない

空欄 a の対策は「パスワードを定期的に変え，類推されにくい文字列にする」である。これで防ぐのは，他人にパスワードを知られたり当てられたりして，その人になりすまして使われることである。

他の行の想定脅威が「〜の不正利用」「〜できない」と書かれているので，同じ形で書くとそろう。

20字。解答例は「なりすましによる不正利用」で12字。「パスワードの漏えい」だけでは，その結果何が起きるかが書けていない。

採点講評（IPA）

設問1は，正答率が高かった。セキュリティ要件については，おおむね理解されているようであった。

本文の根拠

表

ログを収めたファイルの改ざん → ファイルは，外部から書き換えられないように，独立したサーバに集約すること。

図

（A），（B）は新規に設置するサーバに，（C）は Web サーバに，（D）は購買管理サーバに，それぞれ保存されるファイルを示す。LAN1：社外向けサーバを接続するネットワーク。LAN2：社内向けサーバを接続するネットワーク。

セキュリティ要件は「外部から書き換えられないように，独立したサーバに集約する」である。まず，(C) の Web サーバと (D) の購買管理サーバは業務用のサーバなので，独立したサーバではない。

残るのは新しく置く (A) と (B) である。(A) は LAN1，社外向けのサーバをつなぐネットワークにあり，外から攻撃される側に置くことになる。(B) は社内向けの LAN2 にあり，外部から守られている。

場所は「(B)」。理由は 40 字以内で，解答例は「セキュリティが確保されたLAN上でE社のセキュリティ要件を満たす場所であるから」で39字。「独立したサーバ」と「外部から守られた LAN」の2つを押さえる。

採点講評（IPA）

設問1は，正答率が高かった。セキュリティ要件については，おおむね理解されているようであった。

本文の根拠

〔アカウントの管理〕

サーバ管理者は利用者 ID と初期パスワードを設定し，アカウント付与依頼書に記載された業務内容に応じたサーバにアカウントを登録するとともに，設定内容をアカウント付与依頼書に記入して発行元の部門に返送する。各部門は返送されたアカウント付与依頼書を保管する。

〔トラブルの発生〕

前任者はアカウントを付与されてから 30 日後に退職したので，保管してあるアカウント付与依頼書に記載されていた初期パスワードが有効な状態であった。

初期パスワードは依頼書に書かれ，部門で保管されている。部門の人なら誰でも見られる。前任者は 60 日の有効期間のうち 30 日しか使わず，初期パスワードのまま退職したので，後任がそれで入れた。

初期パスワードは本人以外も知っている前提で扱う。最初にログインしたときに必ず本人に変えさせれば，依頼書のパスワードは使えなくなる。

30字。解答例は「初期ログイン時に初期パスワードの変更を強制する。」で23字。「変更を促す」ではなく「強制する」と書く。本人任せでは今回の状態を防げない。

採点講評（IPA）

設問2は，発生したトラブルについて，パスワードが不正利用されない対策やアカウント管理の運用変更を取り上げている。ITサービスマネージャとして，セキュリティインシデントの再発防止には，技術面だけでなく運用面での対策も重要であることを理解しておいてほしい。

本文の根拠

〔アカウントの管理〕

退職した正社員・派遣社員のアカウントの削除については，直ちに承認されているが，サーバからの削除は 2 週間ごとに実施する定期メンテナンス作業の中で行っている。

表

退職者のアカウントの不正利用 → アカウントを利用する必要がなくなった場合は，速やかに削除すること。

退職者のアカウント削除は承認までは早いが，実際にサーバから消すのは 2 週間ごとの定期メンテナンスのときである。最大で 2 週間ほど，退職者のアカウントが使える状態で残る。

セキュリティ要件は「速やかに削除する」である。前任者のアカウントが残っていたのが今回の原因なので，削除の依頼を受けたらその時点ですぐサーバから消す運用に変える。

30字。解答例は「退職者のアカウント削除を，削除依頼時点で即時実施する。」で26字。「いつ消すか」を変えるのが要点なので，「依頼時点で」「即時に」を入れる。

採点講評（IPA）

設問2は，発生したトラブルについて，パスワードが不正利用されない対策やアカウント管理の運用変更を取り上げている。ITサービスマネージャとして，セキュリティインシデントの再発防止には，技術面だけでなく運用面での対策も重要であることを理解しておいてほしい。

本文の根拠

〔ログの管理〕

ログはオーバラップ方式で記録し，セキュリティ要件で規定された期間中は保存できる設計となっている。

表

サーバへの不正侵入や不正操作 → ログは，一定期間保存し，定期的に分析すること。

今のログは，パスワードの誤りや特権 ID の操作など，一部だけを取っている。オーバラップ方式は領域がいっぱいになると古い記録から上書きしていく。記録する量に合わせて「規定の期間は残る」ように容量を決めてある。

すべての利用者 ID の操作を取れば，ログの量は大きく増える。今の容量のままだと早く上書きが始まり，規定の期間を保存できなくなるおそれがある。

30字。解答例は「現在準備されているログ保存用の記憶容量で十分か確認する。」で27字。「容量を増やす」と対策を書くのではなく，設問どおり「確認すること」を書く。

採点講評（IPA）

設問2は，発生したトラブルについて，パスワードが不正利用されない対策やアカウント管理の運用変更を取り上げている。ITサービスマネージャとして，セキュリティインシデントの再発防止には，技術面だけでなく運用面での対策も重要であることを理解しておいてほしい。

本文の根拠

〔アカウントの管理〕

派遣社員のアカウントの付与については，承認者を総務部長に一元化している。

〔アカウントの管理〕

派遣社員のアカウントの付与について，購買部長は比較的早期に確認しているのに対して，総務部長は承認に時間を要している。

〔アカウントの管理〕

最近，派遣社員の増強に伴って，購買部が派遣契約を締結することになった。

派遣社員のアカウントは，承認者を総務部長に一本化している。総務部長が派遣会社との契約をまとめていたからである。承認に時間が掛かっているのも総務部長のところである。

ところが最近は購買部が自分で派遣契約を結ぶようになった。派遣社員のことを一番分かっているのは購買部長で，確認も早い。承認者を購買部長に変えれば，二度手間がなくなる。

40字。解答例は「派遣社員のアカウントを付与する承認者を，総務部長から購買部長に変更する。」で35字。「誰から誰に」を名指しして書く。

本文の根拠

〔アカウントの管理〕

アカウントの付与は，各部門の課長が作成して部長が承認したアカウント付与依頼書に基づいて行う。

〔セキュリティ監査〕

アカウントの管理の運用改善策として，サーバ管理者がサーバに登録されているアカウントを定期的に点検することにした。

点検で見つけたいのは，要らなくなったのに残っているアカウントや，承認されていないアカウントである。サーバ管理者はサーバに何が登録されているかは分かるが，その人がまだ業務で使うべきかどうかは分からない。

それを判断できるのは，付与を承認した各部門の部長である。サーバごとにアカウントの一覧を作り，承認者に見てもらって，不要なものがないか確かめてもらう。

40字。解答例は「登録されているアカウントの一覧をサーバごとに作成し，承認者に確認を依頼する。」で37字。「一覧を作る」ことと「承認者に確かめてもらう」ことの2つを入れる。

採点講評（IPA）

設問3(2)では，点検内容として，ログで利用状況を確認するという誤った解答が多かった。問題文中のセキュリティ監査の指摘から読み取って，解答を導き出してほしかった。

本文の根拠

表

管理者による不正利用 → 承認者と行為者の職務を分離すること。

〔購買管理システムの利用状況〕

なお，特権 ID では，サーバの起動・停止や格納されているデータの変更などあらゆる操作の実行が可能なので，情報システム部のサーバ管理者に利用を限定している。

セキュリティ要件は「承認者と行為者の職務を分離する」である。特権 ID 管理者は特権 ID を承認する側なので，自分で特権 ID を使って操作までできてしまえば分離にならない。

特権 ID 管理者は承認だけを行い，特権 ID での操作はできないようにする。あるいは，特権 ID 管理者が特権 ID を不正に使っていないかをログで確かめる仕組みを置く。

40字。解答例は「特権ID管理者は，承認だけ行い，特権IDを使った操作はできないようにする。」（35字）と「特権ID管理者が特権IDを不正に使用していないことをログで確認する。」（33字）の2つ。

採点講評（IPA）

設問3(3)は，正答率が低かった。特権ID管理者による不正利用防止には，承認者と行為者の職務を分離した上で，実効性のある統制が必要であることを理解しておいてほしい。