正解：エ
各選択肢の解説
ア業務が止まっているのでインシデントとして記録し、復旧を最優先にして直ちにアクセス権を付与する。
誤り。インシデントは、提供中のサービスが計画外に中断したり品質が下がったりした事象です。 異動に伴う権限の追加は、あらかじめ想定された依頼で、何かが壊れたわけではありません。 急ぐ理由があっても、確認を飛ばしてよいことにはなりません。
イアクセス権の変更は影響が大きいので、依頼のたびに変更管理の会議を開いて個別に承認を得る。
誤り。変更管理はサービスや構成への影響を評価して承認する活動ですが、 頻繁に起きる定型の依頼まで毎回会議にかけると処理が滞ります。手順と承認者を 事前に定めておき、その手順に沿って処理するのがサービス要求の扱いです。
ウ本人からの依頼なので、サービスデスクの担当者が依頼された内容どおりにその場でアクセス権を付与する。
誤り。依頼者が本人であることと、その権限を持たせてよいことは別です。 フォルダの利用を認める判断は、情報を管理する部署の責任者が持ちます。 依頼どおりに付けると、必要以上の権限が積み重なります。
エサービス要求として記録し、定めた手順に沿って新しい部署の責任者の承認を確かめてから付与する。
正解。権限の追加は想定された利用者からの依頼で、サービス要求として扱います。 手順の中に承認を組み込んでおけば、早く処理しながら、 必要な人にだけ権限を付ける確認も外れません。
理解を深めるために
「壊れた」ではなく「頼みたい」
サービスデスクに届く連絡は、大きく2種類に分かれます。 「使えなくなった」という連絡はインシデント、 「使えるようにしてほしい」「貸してほしい」という依頼はサービス要求です。 パスワードの再設定、機器の貸出し、アクセス権の追加などが代表例です。
サービス要求はどう扱うのか
サービス要求は、あらかじめ起きることが分かっている依頼なので、手順を前もって決めておけます。
- 受け付けたら記録し、種類を分類して、優先度を付ける
- 定めた手順に沿って実現する。承認が要るものは、手順の中に承認者を決めておく
- 実現したら記録を閉じ、依頼者に知らせる
アクセス権の追加は、情報セキュリティの面では「誰に何を見せるか」を決める行為です。 新しい部署の責任者の承認を確かめる手順を入れておくと、定型の依頼として早く回しつつ、 必要な人にだけ権限を付けられます。異動前の部署の権限を外す依頼と組にしておくと、 権限の残りすぎも防げます。
混同しやすいものとの違い
| 用語 | 何をするか |
|---|---|
| サービス要求 | 想定された依頼を、定めた手順と承認に沿って実現する |
| インシデント | 計画外の中断や品質低下に対処し、元に戻す |
| 変更管理 | 構成への変更の影響を評価し、承認してから実施する |
| 依頼どおりの即時対応 | 本人確認だけで、権限を持たせてよいかの確認が抜ける |
試験では「〜してほしい」という依頼の形の連絡はサービス要求、 「〜できなくなった」はインシデント、と連絡の性質で見分けます。