正解：ウ
各選択肢の解説
ア障害時に委託先がすぐ対応できるよう、開発時の管理者アカウントをそのまま残す。
誤り。障害対応への備えは必要ですが、誰が使っているか分からない共用の管理者アカウントを 残すと、不正な操作があっても行為者を特定できません。保守で必要な権限は、 引継ぎの際に、必要な人に必要な範囲で改めて与えます。
イ共用の管理者アカウントのパスワードを運用部門にも伝え、両者で使えるようにする。
誤り。引継ぎで情報を渡すという点は合っていますが、共用アカウントを使う人が 増えるだけで、操作した人を区別できない状態はかえって悪くなります。 渡すべきは共用のパスワードではなく、個人ごとのアカウントと権限です。
ウ開発時に作られたアカウントと権限を棚卸しし、不要なものを削除してから引き継ぐ。
正解。開発のために作られたアカウントや広い権限は、本番の運用では不要なものが残りがちです。 引継ぎの時点で棚卸しして整理しておけば、運用部門は管理すべき権限を把握した状態で始められます。
エ稼働後1年の保守期間が終わった時点で、委託先のアカウントをまとめて削除する。
誤り。いずれ削除するという方針自体は正しいのですが、それまでの1年間、 不要な権限と共用アカウントが本番環境に残り続けます。不要と分かった時点、 つまり運用への引継ぎのときに整理するのが筋です。
理解を深めるために
引継ぎは「鍵の付け替え」の機会
工事が終わった建物を引き渡すとき、工事業者が使っていた合鍵は回収し、必要なら錠を付け替えます。 システムの運用引継ぎも同じで、開発のために配った**鍵（アカウントと権限）**を整理してから 運用部門に渡します。
なぜ引継ぎで棚卸しするのか
運用引継ぎは、移行のあとに開発側から運用側へ、サービスを日々動かすために必要な 情報と責任を移す工程です。手順書や構成の情報だけでなく、誰がどの権限を持っているかも 引き継ぐ対象です。開発中は作業のしやすさが優先され、次のようなものが残りがちです。
- 複数人で共用している管理者アカウント
- テストのために作った一時的なアカウント
- 必要以上に広い権限
これらを残したまま引き継ぐと、運用部門は把握していない入口を抱えたまま運用を始めることになり、 不正な操作があっても誰が行ったかを特定できません。引継ぎの時点で棚卸しし、 不要なものを削除し、保守に必要な権限は個人ごとに必要な範囲で与え直します。
混同しやすいものとの違い
| 対応 | 問題点 |
|---|---|
| 棚卸しして不要なものを削除してから引き継ぐ | 運用開始時点で権限が把握されている |
| 開発時の管理者アカウントをそのまま残す | 行為者を特定できない入口が残る |
| 共用パスワードを運用部門にも伝える | 共用する人が増え、区別できない範囲が広がる |
| 保守期間の終了時にまとめて削除する | 不要な権限が1年間残り続ける |
試験では「便利だから残す」「いずれ消す」が誤答として並びます。 引継ぎは、不要な権限を整理する区切りのタイミングだと押さえておきます。