保守を委託すれば、安全は続くのか——サービスマネジメント・変更管理・遠隔保守の要点｜支援士解説2の7

この記事の重要度：Cランク（主に午前II（科目A-2）で問われる論点。午後では問題文の前提として読めれば十分）

この記事で分かること：

• サービスマネジメント（ISO/IEC 20000・ITIL）とSLA、インシデント管理・問題管理・変更管理・構成管理の違い

• パッチ適用の手順、暫定策、緊急変更、切り戻し

• 遠隔保守の運用と、保守を委託するときの役割分担

シラバスとの対応：小項目2-7「運用・保守」。遠隔保守の経路の構成は支援士解説2の3、脆弱性への対応の判断は支援士解説3の6、ログと監視は支援士解説3の4、バックアップは支援士解説3の3で扱います。

システムは、作って終わりではありません。脆弱性が見つかれば更新し、設定を変え、障害があれば復旧し、保守事業者が遠隔から作業します。運用・保守の段階で入る変更や経路が、事故の入口になることは少なくありません。

午後の試験では、運用・保守そのものが大問の主題になることは多くありません。一方、問題文には、保守事業者が保守用の中継サーバを経由して作業する、パッチを適用する前に検証環境で確かめる、といった前提がよく出てきます。午前IIでは、サービスマネジメントの用語（問題管理、変更管理など）の区別が問われます。この記事では、それらを要点に絞って整理します。

1. サービスマネジメント：機械の正常と、業務の正常を分ける

運用・保守が守るのは、サーバが動いていることではなく、利用者が業務を続けられる状態です。サーバは起動していても、ログインできない、申請が送れない、不正な操作が続いている、という状態はあり得ます。

ITサービスを管理する考え方として、次の二つを押さえます。

• ITIL（Information Technology Infrastructure Library）：英国政府の機関が作成した、ITサービスマネジメントの業務と管理の方法を体系的にまとめた書籍群。2019年にITIL 4が公表された

• ISO/IEC 20000（JIS Q 20000）：ITサービスマネジメントシステム（ITSMS）の国際規格。ITILを基にしている。第1部が要求事項で認証の基準になり、ISMSでのISO/IEC 27001に当たる。第2部は適用の手引

ITSMSは、監視ソフトの名前ではありません。サービスの計画、提供、評価、改善をPDCAで回す仕組みです。

SLA（Service Level Agreement、サービスレベル合意書）は、サービスの提供者と利用者が、サービスの内容と品質の水準を合意した文書です。よく使われる指標は稼働率ですが、それだけでは運用の条件は決まりません。

• 稼働率99.9％でも、停止がいつ起きるかは別。30日間を24時間で数えれば、停止は月に約43分に当たる。それが申請の締切の直前に集中すれば、影響は大きい

• 「24時間受付」は連絡を受け付けることで、24時間以内に直すことではない。受付時間、初動（応答）の時間、復旧の目標、未解決の間の報告を分けて決める

• サービスが止まっていなくても、不正なログインや情報の流出の疑いはある。セキュリティ上の事象の報告と証跡の保全も、契約や運用のルールで決めておく

• 発注者の側にも、承認者、代わりの承認者、夜間の連絡方法が要る。委託先が「停止の承認待ち」のままでは、作業は進まない

サービスデスクは、利用者からの問い合わせや障害の連絡を受け付ける単一の窓口（SPOC：Single Point of Contact）です。利用者の申告は、監視の仕組みとは別の、異常を見つけるもう一つの入口になります。「画面の表示がいつもと違う」「身に覚えのない通知が来た」という問い合わせが、攻撃の最初の兆候であることもあります。問い合わせの記録には、日時、利用者、対象、症状、行った案内を残し、似た問い合わせが続いたら、担当へ引き上げる（エスカレーションする）条件を決めておきます。

2. インシデント・問題・変更・構成：似た言葉を分ける

午前IIでよく問われるのが、サービスマネジメントの管理の区別です。

• インシデント管理：サービスの中断や品質の低下に対応し、できるだけ早くサービスを回復させる。暫定的な回避策で業務を続けることも含む

• 問題管理：インシデントの根本原因を特定し、恒久的な解決策を決める。インシデントのデータや傾向を分析し、起きる前に問題を見つけて防ぐことも含む

• 変更管理：システムへの変更を、影響を評価し、承認し、記録して、安全に行うための統制

• リリース管理（リリース及び展開管理）：承認された変更を、本番の環境に展開する

• 構成管理：機器、ソフトウェア、設定、その関係（構成品目）を正確に把握し、記録する。記録の集まりをCMDB（構成管理データベース）と呼ぶ

四つは、次のようにつながります。不審な通信でサービスが不安定になったとき、まず通信を止めて業務を戻すのがインシデント管理です。なぜその通信が起きたかを調べ、設定の誤りが原因と分かれば問題管理です。設定を直すのは変更管理の手続で行い、直した後の正しい設定を構成管理の記録に反映します。

ここでいう「インシデント」は、セキュリティに限らず、サービスの障害全般を含みます。セキュリティインシデントへの対応は支援士解説4の3で扱います。

3. 変更管理と構成管理

変更管理で押さえる点は次のとおりです。

• 変更の目的、対象、影響、作業の手順、失敗したときの戻し方を、承認の前に示す

• 作業する人と承認する人を分ける

• 作業の後に、意図した変更だけが行われたか、ほかの設定が変わっていないかを確かめ、記録する

• 承認されていない変更を見つける仕組みも持つ。設定を定期的に比べ、記録にない変更がないかを確かめる

構成管理は、脆弱性への対応の土台です。「どの機器が、どの版の、どのソフトウェアを使っているか」が分からなければ、注意喚起が届いても影響を判断できません（支援士解説1の6）。台帳には、ネットワーク機器のファームウェア、VPN装置、仮想化の基盤、アプリケーションに組み込まれたライブラリも含めます。クラウドでは、事業者が更新する部分と、利用者が更新する部分を分けて記録します。

作業計画書と手順書のレビューも、変更管理の一部です。

• 作業計画書は、承認者が実施の可否を判断するための文書。目的、対象、日時、作業者、想定する影響を示す

• 作業手順書は、実施者が使う文書。対象を一意に特定できるか（本番と検証の取り違えを防ぐ）、各段階の成功の条件、失敗したときにどこで止め、どう戻すかを書く

• 手順書に実際のパスワードを書き込まない。許可された担当者が認証情報を取り出す方法を示す

4. パッチの適用：評価から適用後の確認まで

パッチ（修正プログラム）の適用は、配布のボタンを押す作業ではありません。適用するリスクと、適用しないで残るリスクの両方を考えて、次の順に進めます（図1）。

1. 対象を確認：製品、版、設定、公開範囲、依存関係を、構成管理の台帳と実際の構成で確かめる

2. 優先度を判断：悪用の状況と業務への影響を見る。すぐに適用できなければ、暫定対策と期限を決める（判断の基準は支援士解説3の6）

3. 検証と準備：検証環境で、起動だけでなく業務の主な機能や外部との連携を試験する。切り戻し（変更前の状態へ戻すこと）の条件と方法を決める

4. 承認して実施：計画した対象と作業者を照合して実施する。緊急時も所定の手続による

5. 適用後の確認：実際に適用された版、再起動の要否、機能、設定、監視の状態を確かめる

6. 記録と追跡：構成の記録と手順を更新する。適用できなかった機器を管理し続ける

押さえておきたい点は次のとおりです。

• 更新の正当性：更新ファイルは公式の配布元から取得し、署名などで改ざんされていないことを確かめる。ハッシュ値で照合するときは、比べる値そのものを信頼できる経路で得る

• 切り戻しの限界：アプリケーションの版を戻しても、データベースの形式が変わっていれば、古い版が新しいデータを読めないことがある。何を戻すか、作業中に受け付けたデータをどう扱うか、いつまでに戻す判断をするかを決めておく

• 段階的な適用：少数の対象から適用して問題がないことを確かめ、範囲を広げる方法もある。ただし、攻撃が迫っているときは、待つ間のリスクと比べて判断する。検証環境と本番の違い（データの量、連携先、設定）が結果に影響しないかも考える

• 配布の成功と適用の完了は別：ツールが「成功」と表示しても、再起動待ちで有効になっていない、一部の機器だけ失敗している、ということがある

• 緊急変更：攻撃が迫っているときは、通常の会議を待てない。そのために、緊急時の承認者、最低限の確認、実施後のレビューを事前に決めておく。緊急変更は、無承認・無記録の変更ではない

• サポートの終了：製品の提供元のサポートが終わると、脆弱性が見つかってもパッチが出ない。構成管理の台帳にサポートの終了日も記録し、終了の前に更新や移行を計画する。やむを得ず使い続けるなら、ネットワークから隔離するなどの対策と、終了の期限を決める

• 暫定策（回避策）：すぐに適用できないときは、問題の機能を止める、接続元を限定するなど、その脆弱性の攻撃経路に効く対策を選ぶ。WAFはすべての脆弱性を防ぐ仕組みではない。暫定策には理由、担当、期限、次に見直す条件を付け、何を待っているか分からない保留にしない

監視とバックアップの運用も、パッチと同じく「やったつもり」が残りやすい部分です。

• 死活監視（機器が応答するか）だけでは、サービスの安全は分からない。認証の失敗の急増、管理者の操作、想定外の通信なども見る

• 監視やログの収集そのものが止まったことも検知する。ログが届かなくなった機器は、攻撃者が記録を止めた可能性もある

• ログの時刻を同期し、ログを書き換えられない場所へ送って守る（支援士解説3の4）

• バックアップは「取れた」ではなく「戻せる」まで確かめる。復旧の訓練で、手順と所要時間を確かめる

• バックアップの保存先と管理の権限を、本番と分ける。本番と同じ管理者の権限で消せるバックアップは、ランサムウェアの被害を一緒に受ける（支援士解説3の3）

5. 遠隔保守の運用

外部の保守事業者がネットワーク経由で作業する遠隔保守（リモート保守）は、便利な一方で、攻撃者にとっての入口にもなります。保守用の中継サーバを置く、接続元を限定する、といった経路の構成は支援士解説2の3で扱います。ここでは、運用の手続を整理します。

作業の前

• 作業の申請と承認：誰が、いつ、どの対象に、何の作業をするか

• 経路と権限は、作業の時間だけ有効にする。常に開いた入口と広い権限を残さない

• アカウントは保守員ごとに分け、共用しない。共用のIDでは、誰が操作したかを特定できない

• 認証を強くする：パスワードだけに頼らず、公開鍵認証や多要素認証を使う

作業中

• 操作の記録を取る。記録は保守事業者が消したり書き換えたりできない場所に保管する

• 保守用の端末と、持ち込む記録媒体の安全を確かめる

作業の後

• 作業の報告と、操作の記録を照合する。報告にない操作がないかを確かめる

• 経路と権限を閉じたことを確かめる

• 保守員の交代や契約の終了のときは、アカウントと鍵を無効にする

午後で出てくる場面

• 令和3年度秋期 午後I問1：保守員の利用者IDに推測しやすいパスワードが設定されていて、保守用の中継サーバに不正にアクセスされた事故の再発防止が題材だった。SSHの認証をパスワード認証から公開鍵認証に変え、鍵ペアは保守員が保守PCごとに作って管理する手順にした。秘密鍵にパスフレーズを設定する目的が問われ、解答例は、保守員以外が不正に秘密鍵を使えないようにするため（秘密鍵が盗まれても悪用できないようにするため）という趣旨だった。中継サーバに秘密鍵を置かない運用、接続元の限定は支援士解説2の3で扱う

• 平成27年度秋期 午後I問2（情報セキュリティスペシャリスト試験）：保守の委託先が使う特権IDのうち、データベースを操作するIDが、業務アプリケーションがデータベースに接続するIDと同じなので、データベースサーバのアクセスログからは使った人を特定できないことが問われた。委託先の個人IDの管理状況の確認と、使った人が特定されることの周知（抑止効果）は支援士解説3の9で扱う

6. 保守を委託するときの役割分担

保守を委託しても、システムの安全に対する発注者の責任はなくなりません。同じ保守契約の中でも、役割は分かれます。

• 監視する人：異常を見つけて知らせる

• 作業する人：設定を変え、更新を適用する

• 承認する人：変更の実施を認める

• 業務を判断する人：止める時間帯、利用者への案内、代わりの業務を決める

たとえば、事業者が脆弱性の情報を評価して対策を提案し、発注者の担当者が業務への影響を確かめ、所定の承認者が実施を認めます。作業の後は、事業者が技術面を、業務の担当が主な操作を確かめます。すべての軽微な作業を管理職の判断にする必要はありません。事前に承認した定型の作業と、追加の判断が要る作業の条件を分けます。

保守事業者が交代するときは、完成した文書だけでなく、未解決の課題、暫定対策と次の確認の期限、例外の設定を残した理由も引き継ぎます。理由が分からない例外の設定は、消してよいかを誰も判断できません。

運用の報告は、件数だけで見ません。パッチの適用率が高くても、重要な公開サーバ1台が未適用なら、その1台が攻撃の入口になります。未適用の重要な機器、期限を過ぎた例外、ログの収集が止まっている対象など、残るリスクに結び付く指標も確かめます。

委託先の選定から終了までの管理は支援士解説3の10で扱います。

7. 午前II（科目A-2）で正誤を見分けるポイント

• 「問題管理は、インシデントの発生後に暫定的にサービスを復旧させる活動である」→ 誤り。それはインシデント管理。問題管理は根本原因を特定し、恒久的な解決策を決める

• 「インシデント管理の目的は、根本原因を取り除くことである」→ 誤り。サービスをできるだけ早く回復させること

• 「構成管理は、変更を承認する活動である」→ 誤り。承認は変更管理。構成管理は構成品目と関係を把握・記録する

• 「ISO/IEC 20000は、ISMSの要求事項を定める規格である」→ 誤り。ITサービスマネジメントシステムの規格。ISMSはISO/IEC 27001

• 「SLAで稼働率99.9％と合意すれば、停止の時間帯の影響は考えなくてよい」→ 誤り。いつ止まるかで影響は変わる

• 「緊急変更では、承認と記録を省略してよい」→ 誤り。手続を速めても、誰が何を判断したかを残す

• 「パッチの配布ツールが成功と表示すれば、適用は完了である」→ 誤り。実際の版、再起動、機能を確かめる

• 「切り戻しは、アプリケーションの版を戻せば必ず元の状態に戻る」→ 誤り。データの形式の変更などで戻せないことがある

• 「遠隔保守の経路は、常に接続できるようにしておくのが望ましい」→ 誤り。作業の時間だけ有効にする

• 「保守を委託すれば、変更の承認も委託先が行う」→ 誤り。承認と業務の判断は発注者の役割として決める

• 「サービスデスクは、障害の根本原因を調べる部署である」→ 誤り。利用者からの問い合わせを受け付ける単一の窓口。原因の調査は問題管理

• 「バックアップの取得に成功していれば、復旧できることは確かめなくてよい」→ 誤り。復旧の訓練で、戻せることと所要時間を確かめる

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　サービスマネジメントの管理

サービスマネジメントにおける問題管理の活動として、最も適切なものはどれか。

• ア：インシデントの発生後、暫定的にサービスを復旧させ、業務を続けられるようにする

• イ：インシデントの根本原因を特定し、恒久的な解決策を決める

• ウ：承認された変更を、本番の環境へ展開する

• エ：機器とソフトウェアの構成品目を記録する

正解：イ。アはインシデント管理、ウはリリース管理、エは構成管理の活動です。

問2　パッチの適用の完了

パッチの配布ツールで「全台成功」と表示された。完了と判断する前に行うこととして、最も適切なものはどれか。

• ア：表示を信頼し、完了として記録する

• イ：実際に適用された版、再起動の要否、業務の主な機能、監視の状態を確かめ、適用できなかった機器があれば管理を続ける

• ウ：念のため、同じパッチをもう一度配布する

• エ：利用者から苦情がなければ完了とする

正解：イ。配布の成功と、必要な対象への適用の完了は別です。アとエは確認を省き、ウは確かめずに作業を繰り返しています。

問3　遠隔保守

外部の保守事業者による遠隔保守の運用として、最も適切なものはどれか。

• ア：保守員が交代しても使えるよう、保守用のIDを1つにして共用する

• イ：作業の申請と承認に合わせて経路と権限を有効にし、作業後に操作の記録と作業報告を照合して、経路と権限を閉じる

• ウ：緊急の作業に備え、保守用の経路を常に開いておく

• エ：操作の記録は、保守事業者のサーバだけに保存する

正解：イ。アは操作した人を特定できず、ウは攻撃の入口を常に開けておくことになります。エは、記録を保守事業者が書き換えられるおそれがあります。

問4　暫定策

公開サーバの製品に脆弱性が公表されたが、業務の繁忙期ですぐにパッチを適用できない。対応として、最も適切なものはどれか。

• ア：繁忙期が終わるまで、何もしないで待つ

• イ：その脆弱性の攻撃経路に効く暫定策を実施し、理由・担当・期限・次に見直す条件を決める

• ウ：WAFを導入すれば、どの脆弱性も防げるので、パッチは適用しない

• エ：検証をせずに、すぐ本番に適用する

正解：イ。暫定策には期限と見直しの条件を付けます。アは攻撃の経路を残したままです。ウのように、WAFはすべての脆弱性を防ぐ仕組みではありません。エは、適用による障害のリスクを考えていません。

実務と国・自治体では

• 政府機関等の統一基準：情報システムの変更の後に、セキュリティ対策が維持されているかを確かめ、記録することを求めている。ログについても、保存だけでなく点検・分析までを扱う。政府機関等向けの基準なので、自治体や企業の直接の義務として読み替えない

• 自治体向けガイドライン：総務省のガイドラインの解説は、システムの変更などの作業を2人以上で確認することや、変更の後も対策が有効かを確かめること、同じネットワーク上のバックアップが本番と同時に暗号化される危険と保存先の分離にも触れている。ログは1年以上保管することが望ましいとしつつ、法令なども確かめて期間を決めるよう示しており、推奨と適用の条件を分けて読む

• 調達・運用の仕様：「保守を行うこと」の一文で終わらせず、変更の承認者、緊急変更の手続、遠隔保守の申請と記録、作業報告の項目、保守員の交代時の手続を仕様書と契約に書く

まとめ

• インシデント管理は回復、問題管理は根本原因と恒久策。 変更は承認して記録し、構成管理に反映する。

• SLAは稼働率だけでなく、受付・初動・復旧・報告を分ける。

• パッチは対象の確認から記録と追跡まで。 配布の成功と適用の完了は別。緊急変更も承認と記録を残す。

• 遠隔保守は、作業のときだけ開き、個人のIDで、記録を照合して閉じる。

関連記事

• あわせて読む：安全な機器も、つなぎ方で守りは変わる｜支援士解説2の3（遠隔保守の経路の構成）

• あわせて読む：脆弱性対応の優先順位はどう決める？｜支援士解説3の6（パッチと暫定策の判断）

• あわせて読む：委託すれば、任せて安心？｜支援士解説3の10（委託先の管理）

• あわせて読む：本番と分ければ開発環境は安全？｜支援士解説2の8（変更を本番へ届ける仕組み）

2026年10月改訂：午前IIで問われるサービスマネジメントの用語、パッチ適用の手順、遠隔保守の運用、保守の委託の役割分担に絞って構成を見直しました。