SiteGuard更新と侵害調査、保守会社へ分けて依頼する項目

SiteGuard更新と侵害調査、保守会社へ分けて依頼する項目。この記事は2026年10月21日に確認できた公式情報を起点に、SiteGuard更新と侵害調査、保守会社へ分けて依頼する項目という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

SiteGuard更新依頼の基本項目と担当者確認

更新対象バージョンと適用範囲の明示

保守会社に更新を依頼する際は、まず「どのバージョンに更新したいか」だけでなく、実際にそのバージョンが適用可能かどうかを確認することが重要です。バージョン番号だけを書いても、サーバごとの構成や利用状況によっては適用できないケースがあります。

そのため、担当者には「対象サーバの現在のバージョンと構成情報は何か」「新バージョンが動作保証されている環境条件は満たしているか」を具体的に提示してもらうよう依頼してください。これにより、保守会社が不要なサーバまで手を加えるリスクを減らし、見積もりや作業計画が正確になります。

また、更新対象外とするサーバについては、単に「対象外」と記すだけでなく、なぜ対象外にしたのか、その根拠となる情報（例えば別の保守契約がある、利用目的が異なるなど）を担当者に確認してください。根拠が明確であれば、後から対象外サーバが誤って更新されることを防げます。

質問例としては「対象外にしたサーバの保守範囲はどこか」「対象外にした理由は何か」を具体的に聞き、回答を一覧にまとめると、情報の抜け漏れを防げます。

更新作業実施者と承認フローの設定

社内での承認フローは、情報システム部門の責任者が作業計画をレビューし、経営層または情報セキュリティ委員会の承認を得たうえで保守会社へ指示します。保守会社側は、実作業担当者（例：テクニカルエンジニア）とリーダー（プロジェクトマネージャー）を明示し、作業開始前に担当者一覧と連絡先を共有します。

承認済みの指示書に署名または電子署名を付与し、双方で保管することで、後日のトレーサビリティが確保されます。承認プロセスが明確になると、緊急対応時でも手順が混乱せず、責任範囲がはっきりします。

更新完了後の検証項目と合格基準

更新が完了したことを確認したら、まず担当者に現在のバージョンが期待通りのものになっているかを聞きましょう。その際、バージョン情報がどこに記録されているか、確認手順や取得した記録の保管場所を教えてもらうと、後で証拠として提示しやすくなります。

次に、主要な機能が正常に動作しているかを確認するため、代表的な画面や API の応答を数件実際に利用してみてください。その結果にエラーや予期しない挙動がないかを担当に報告し、問題があれば具体的にどの機能で何が起きたかを記録してもらうよう依頼します。

最後に、更新前後のシステムログを取得できるかどうか、取得したログに異常なエラーメッセージやアクセスが増えていないかを担当に確認してください。ログの比較方法や、異常が見つかった場合の対応手順についても併せて質問すると、検証結果の根拠が明確になります。

全ての項目で問題がなければ、検証完了の旨を報告書にまとめ、保守会社に受領確認を依頼する旨を伝えてください。これらの確認を行うことで、更新が正しく適用されたことを客観的に示す根拠が得られ、後日のトラブル防止につながります。

侵害調査依頼時の情報提供と例外条件

初動報告書に含める必須情報一覧

侵害調査を保守会社に依頼する際は、初動報告書に以下の情報を必ず記載します。まず、侵入が判明した日時と検知手段（IDSアラート、ログ解析等）を時系列で示します。次に、影響を受けたシステム（サーバ名・IP・サービス）と、被害範囲（取得したデータや改ざんの有無）を具体的に列挙します。

さらに、取得したログの種類（Webアクセスログ、システムログ、アプリケーションログ）と保存期間を明示し、保守会社が分析に必要なデータをすぐに受け取れるようにします。これらの情報が揃っていれば、調査開始までの手待ち時間が短縮され、迅速な対応が可能になります。

調査対象外となる例外ケースの明示

保守会社に依頼する調査範囲は、社内システムに限定し、外部委託先のサービスや過去に同様の調査を実施したケースは除外します。例えば、クラウド提供元が提供する SaaS アプリは提供元側の責任範囲となり、保守会社の調査対象外です。

また、同一インシデントで過去に詳細なフォレンジックが完了している場合は、再調査の必要がない旨を明記します。例外ケースを明示することで、保守会社の作業工数が無駄に増えることを防ぎ、費用対効果の高い調査が実現します。

調査結果の受領方法と検収手順

調査完了後の報告書は、PDF 形式で提出し、以下の項目を必ず含めます。調査概要、発見された侵入経路、影響範囲、復旧手順、再発防止策の提案です。受領側は、情報セキュリティ担当者が内容をレビューし、合格/不合格の判定基準（例：全ての侵入経路が特定できているか）に基づいて評価します。

合格と判断した場合は、受領確認サインを付与し、保守会社へ正式に受領通知を送ります。不合格の場合は、指摘事項を列挙し、再調査または追加調査の依頼を行います。

保守会社への作業指示書作成ポイント

作業指示書の必須項目と記載例

依頼書には、SiteGuard Server Editionを使っている対象環境、確認した注意情報、依頼する作業、業務への影響を記載します。更新だけを頼むのか、侵害の可能性の調査も含めるのかを区別してください。

具体的な技術手順は、保守会社が利用版と公式案内に照らして確認します。自社は、作業を了承する責任者、問題が出たときの連絡先、結果として受け取りたい情報を伝えます。管理用のパスワードや秘密情報を、広く共有する依頼文書へ貼り付けないようにします。

作業失敗時のエスカレーションフロー

作業が失敗した場合は、止まった機能と影響する業務、作業前後の状態を整理して、合意した窓口へ連絡します。自社の責任者と技術的な調査担当が、同じ事実を把握できることが重要です。

一律に特定の役職へ電話する手順を求めるものではありません。連絡がつかない場合の代わりの窓口や、作業継続を判断する相手も確認してください。更新前へ戻す対応が適切かは、脆弱性が残る問題も含めて、公式案内と実際の構成に合う方法を専門家へ確認します。

作業完了報告のフォーマットと提出期限

完了報告には、対象環境、実施した変更、確認した動作、未対応の項目をまとめてもらいます。更新されたことと、侵害の可能性を調べたことは分けて確認します。画像や記録を受け取る場合は、何を示すものかも説明してもらってください。

提出する形式や時期は、自社と保守会社で合意します。特定の保存形式や日数を一律に求めるものではありません。受け取った内容を依頼項目と照合し、確認できない点があれば追加で質問します。了承した範囲と残課題を、次の担当へ引き継げるように残します。

更新・調査後のフォローアップと継続的管理

更新後の定期点検項目と担当者割り当て

更新後の確認では、対象環境へ正規の修正が反映されたことと、必要な業務が意図したとおりに動くことを分けて確認します。実際に適用する版は、製品の公式案内と自社の構成に合わせて保守担当が特定します。

専門的な検査を行う場合も、対象と方法、業務への影響を事前に合意してください。検査で問題が見つからなかったことを、過去の侵害がなかった証明と混同しません。報告には未確認の条件や追加で調べる担当を残します。

侵害再発防止策の策定とレビュー体制

侵害調査が終わったら、得られた教訓をもとに再発防止策を検討する必要があります。その際、どの対策が実際に効果的かは、担当者が過去のインシデントやログの内容を確認したうえで判断すべきです。たとえば入力検証の見直しや防御機能の追加については、現在のシステム構成や運用方針と照らし合わせて、実装の可否や影響範囲を確認してください。

対策を決めたら、実施状況や効果を定期的にチェックする仕組みを設けますが、レビューの頻度や担当者は組織の体制に合わせて柔軟に設定します。担当者には次の点を確認してもらうとよいでしょう。
・今回の調査で得られた具体的な教訓は何か。
・入力検証や防御機能の変更が必要か、必要ならどの範囲で行うか。
・実施した対策の効果を測る指標は何が適切か。

これらの質問をもとに、実際に必要な対策とその評価方法を関係者と合意し、文書化しておくことが重要です。

保守契約の見直しポイントと更新条件

保守契約は、実際の利用状況やサービスの品質を踏まえて見直すことが重要です。たとえば、導入している製品のバージョンやサポート内容が現在の業務に合っているか、料金が他社と比べて妥当かを確認します。これらは、過去の障害対応実績だけで判断できない点があるため、担当者から具体的な対応記録や費用の根拠を提示してもらう必要があります。

担当者に確認すべきポイントは次のとおりです。まず、現在契約している製品のバージョンと、最新のアップデートが適用されているかを教えてください。次に、過去一年間に発生した障害の内容と、実際にどの程度の復旧時間で対応したかの記録を提出してもらいましょう。

また、料金体系については、同様のサービスを提供している他社の価格と比較した資料があるかどうかも確認してください。これらの情報を基に、経営層へ提案する際の根拠として整理すれば、不要な固定的ルールにとらわれず、実情に即した契約見直しが可能になります。