IT保守会社を変えたい。セキュリティ設定と管理権限を引き継ぐ手順

IT保守会社を変えるときは、セキュリティ設定や管理権限が抜け落ちてしまうと、システムの監視が途切れ、攻撃リスクが高まります。まずは現状を正確に把握し、現ベンダーと新ベンダーの間で引き継ぎ範囲を明確に合意することが重要です。その後、具体的な手順を計画し、実行・検証・フォローアップを順に行うことで、監視の空白や権限の漏れを防げます。

現状把握と引き継ぎ範囲の明確化

保有アカウントと権限の一覧化

システムやクラウドサービスに登録されているすべてのアカウントを抽出し、どの権限がどの担当者に付与されているかを一覧表にします。IPAのガイドラインでは資産管理台帳の作成が推奨されており、アカウント情報を「誰が」「何に」アクセスできるかを可視化することが第一歩とされています。

対象はサーバー、ネットワーク機器、監視ツール、バックアップシステムなど、主要なインフラです。

次に、権限のレベル（管理者、限定管理者、閲覧者）を分類し、業務上必要な最小権限に絞り込む方針を立てます。一覧化した表は、現ベンダーと新ベンダーの双方に共有し、引き継ぎ対象と除外対象を合意する資料として活用します。作成時は、担当者名、連絡先、権限有効期限も併記すると、後の更新作業が楽になります。

セキュリティ設定の現状レビュー

現行のファイアウォールルール、VPN設定、IDS/IPSの検知ポリシー、パッチ適用状況など、主要なセキュリティ設定を点検します。IPAの「情報セキュリティ6か条」では、不要な通信の遮断やバックアップの確保が基本とされており、これらが適切に実装されているかを確認することが重要です。

設定のスクリーンショットや設定ファイルのコピーを取得し、ドキュメント化しておきましょう。

レビュー結果は、設定が最新かつ組織のリスク要件に合致しているかを評価し、改善が必要な項目はリスト化します。このリストは新ベンダーへの引き継ぎ指示書に組み込み、移行後に必ず実施してもらう項目として明示します。特に、暗号化設定や多要素認証の有無は、セキュリティの根幹をなすため、抜け漏れがないよう注意します。

監視体制と緊急連絡先の整理

現在の監視体制（監視ツール、監視対象、アラートの閾値）と、インシデント発生時のエスカレーションフローを把握します。IPAが示すサプライチェーン評価制度の考え方を参考に、外部ベンダーが関与する場合は連絡先と責任範囲を明確にしておくことが望ましいです。

緊急連絡先は電話番号だけでなく、メールアドレスやSlack等のチャットツールのIDも含め、可能であれば24時間体制で対応できる体制を確認します。

整理した情報は、表形式で「監視項目」「担当ベンダー」「連絡先」「対応時間帯」をまとめ、現ベンダーと新ベンダーの双方に配布します。これにより、ベンダー交代のタイミングで監視が途切れないよう、引き継ぎ期間中の連絡窓口が重複しないように調整できます。緊急時の手順書は、実際にシミュレーションを行いながら確認しておくと、実務での混乱を防げます。

現ベンダーとの合意形成と手続き

契約解除のタイミングと注意点

ベンダー変更は契約書に定められた解約予告期間や違約金条項を確認した上で進めます。IPAは情報セキュリティの観点から契約管理の重要性を指摘しており、解除手続きは文書で行い、証拠を残すことが実務上推奨されています。まずは、現在の保守契約書を見直し、解約通知の提出期限や必要な書類をリスト化します。

次に、解約通知は内容証明郵便やメールの送受信記録を残す形で行い、受領確認を必ず取得します。解約日までに残すべきデータや、返却が必要なハードウェア、ライセンスの扱いについても事前に合意しておくと、後日のトラブルを回避できます。解約後のサポート停止時期を明確にし、移行期間中は両社が共同で監視を継続できるようスケジュールを調整します。

無断解除防止の手順と証跡確保

ベンダーを無断でサービス停止させると、システムが突如停止し、業務に重大な支障が出る恐れがあります。したがって、解除前に必ず「サービス停止手順書」を作成し、関係者全員の承認を得ます。この手順書には、停止対象のサービス、停止時刻、バックアップ取得の有無、復旧手順を詳細に記載します。

手順書は社内の情報セキュリティ委員会や経営層に回覧し、承認サインを取得したうえで、現ベンダーにも共有します。実施後は、実際に行った操作ログやシステムの状態スクリーンショットを保存し、証跡として保管します。これにより、万が一トラブルが発生した際に、適切に手順を踏んだことを証明でき、法的リスクも低減できます。

現ベンダーへの引き継ぎ指示書作成

引き継ぎ指示書は、現ベンダーに対して具体的に何をいつまでに実施してもらうかを明示する文書です。引き継ぎ計画は、作業、担当、実施時点、完了の確認方法を並べると、両社と自社が確認しやすくなります。まずは、先ほど整理したアカウント一覧、セキュリティ設定、監視体制を項目ごとに分け、各項目の引き継ぎ担当者を指定します。

指示書には、データのエクスポート形式や暗号化要件、パスワードの取り扱い方法も明記します。また、引き継ぎ完了後の検証方法（例：新ベンダーが設定を確認し、チェックリストにサイン）を記載し、双方が合意できる形で署名します。指示書はPDF化し、社内の文書管理システムに保存すると同時に、現ベンダーと新ベンダーの両方に配布し、進捗管理に活用します。

新ベンダーへの情報移行と設定確認

新ベンダーへの権限委譲手順

新ベンダーに管理権限を委譲する際は、最小権限の原則に基づき、必要な権限だけを付与します。まずは、先に作成したアカウント一覧から新ベンダーが担当する範囲を抽出し、個別にユーザーを作成または既存アカウントに権限を付与します。

権限付与は、IAM（Identity and Access Management）やAD（Active Directory）で行い、付与履歴をログに残すことが重要です。

権限付与後は、必ず新ベンダー側で二要素認証（2FA）を設定し、パスワードは安全な方法で共有します（例：暗号化メールやパスワード管理ツール）。さらに、権限変更の通知を社内の情報セキュリティ担当者に自動で送信する仕組みを導入すれば、権限の不正利用を早期に検知できます。権限委譲が完了したら、権限一覧を再度レビューし、不要な権限が残っていないか最終確認します。

設定データの安全な移行方法

設定データは機密情報を含むことが多く、移行時の漏洩リスクを最小化する必要があります。まずは、設定ファイルや構成情報を暗号化した状態でエクスポートし、専用の転送用ストレージ（例：SFTPサーバー）にアップロードします。転送時はTLS/SSLで暗号化し、アクセス権は新ベンダーの担当者に限定します。

受領側は、受け取ったデータを検証環境で復元し、動作確認を行います。この際、IPAの「バックアップを取ろう！」の指針に従い、移行前の設定のバックアップを取得しておくことが推奨されます。検証が完了したら、正式環境へ適用し、適用後の設定が期待通りに機能しているかテストケースを実行します。テスト結果はレポートにまとめ、両ベンダーの合意サインを得て完了とします。

移行後のテストと検証項目

移行が完了したら、システム全体の機能とセキュリティが維持されているかを検証します。具体的には、以下の項目をチェックリスト化します：①ファイアウォールルールの有効性、②VPN接続の認証・暗号化、③監視ツールのアラート設定、④バックアップジョブの実行結果、⑤権限変更のログ取得。各項目は、テスト担当者が実施し、合格基準を満たすかを評価します。

試験結果は、実際に確認した対象、手順、結果、未解決事項を記録します。自己診断の点数だけで技術的な引き継ぎの完了とは判断しません。不合格項目があれば、速やかに改善策を立案し、再テストを実施します。全項目が合格した時点で、引き継ぎ完了報告書を作成し、経営層へ提出します。これにより、移行作業が計画通りに完了したことを示すことができます。

引き継ぎ完了後のチェックとフォロー

監視空白が生じないかの最終確認

ベンダー変更後に監視が途切れると、インシデントの検知が遅れ重大な被害につながります。最終確認として、監視ツールのデータ取得タイミングとアラート送信先が新ベンダーに正しく設定されているかをリアルタイムでモニタリングします。具体的には、テストアラートを発生させ、指定した連絡先（メール・電話・チャット）が確実に届くかを確認します。

また、監視対象のサーバーやネットワーク機器がすべて新ベンダーの管理下にあることを資産管理台帳と照合し、抜け漏れがないか二重チェックします。IPAが示すサプライチェーン評価制度の考え方では、継続的な監視体制の維持が重要とされています。

そのため、定期的な監視レポートの受領と内容確認をスケジュール化し、問題があれば速やかにエスカレーションできる体制を整えておくことが望ましいです。

引き継ぎ後のドキュメント整備

引き継ぎが完了したら、全ての手順書・設定資料・権限一覧を最新版として社内の情報セキュリティリポジトリに格納します。ドキュメントには、作成日・改訂履歴・担当者を明記し、誰でもアクセスできるが改ざんできないよう権限を設定します。特に、緊急連絡先リストやインシデント対応フローは、迅速な対応が求められるため、紙媒体でも社内の掲示板に掲示しておくと安心です。

さらに、ドキュメントの内容を定期的にレビューし、ベンダーのサービス変更やシステム追加に応じて更新します。更新時は、変更点を関係者に周知し、承認プロセスを経てから正式版として保存します。契約と実際の設定・担当のつながりが分かる資料を残すことで、次の担当者も変更の理由を確認できます。

定期的なレビューと改善サイクル

ベンダー変更は一度きりの作業ではなく、継続的なリスク評価と改善が必要です。半年に一度、現ベンダーと新ベンダーのサービスレベルを評価し、SLA（サービスレベル合意）やセキュリティ要件が満たされているかをチェックします。評価項目は、インシデント対応速度、パッチ適用率、監視精度、権限管理の適切性などです。

評価結果を基に、必要な改善策を策定し、次回のベンダーレビューに反映させます。また、内部の情報セキュリティ委員会で定例会議を開催し、最新の脅威情報や法令改正に合わせたポリシー改訂を行うことで、常に最適なセキュリティ体制を維持できます。定期的なレビューは、予期せぬリスクを早期に発見し、迅速に対策を講じるための重要なサイクルです。