ホームページ保守にセキュリティ対応は含まれる？契約で見る範囲

契約で確認すべきセキュリティ項目の全体像

更新作業と脆弱性対策の範囲

保守契約書に「ソフトウェアの脆弱性対応」や「CMS本体・プラグインのアップデート」などの文言があるか確認します。文言が曖昧な場合は、具体的に「月1回以上のパッチ適用」や「重大脆弱性が判明した際は速やかに対応」など、頻度と対応タイミングを明示させることが重要です。

実務では、ベンダーが提供する更新作業レポートを受領し、社内で「適用済み」かどうかをチェックリストに記録します。IPAのガイドラインでも、バックアップと併せて「定期的な更新」が情報セキュリティ6か条の一つとして推奨されています。

障害時の復旧手順は明記か

障害が発生した際の復旧手順が契約書に明記されているかを確認します。復旧手順には「障害検知→一次対応→復旧作業→検証」の流れと、各フェーズの担当者・連絡先が記載されていることが望ましいです。

復旧手順が抜けていると、実際に障害が起きたときに誰が何をすべきかが不明確になり、復旧までの時間が長引くリスクがあります。契約書に「復旧テストは定期的に実施」や「復旧完了報告書の提出」など、具体的な成果物を要求すると、ベンダー側の責任範囲が明確になります。

契約外作業の費用負担は？

保守契約に含まれない作業が発生した場合の費用負担を事前に取り決めておくことが大切です。例えば、緊急パッチ適用が契約範囲外とされるケースでは、追加料金の見積もり基準や上限額を契約書に記載しておくと、予算オーバーを防げます。

また、ベンダーが提案する新機能追加や大規模改修が必要になった際の「オプション費用」や「見積もり手続き」の流れも明示しておくと、後々の交渉がスムーズです。費用負担の取り決めは、予算計画とリスクマネジメントの両面で重要なポイントです。

見積もりの前提として、障害の一次確認、原因調査、修正、再発防止の提案を分けて聞いてください。同じ「復旧対応」という言葉でも、バックアップを戻すだけなのか、不正な変更の調査や修正まで含むのかで作業が変わります。費用が決まっていない部分は、着手前に追加見積もりと承認が必要になる条件を合意し、緊急時に誰が発注できるかも社内で決めます。

CMS・プラグイン更新は誰が担当か

コアアップデートの頻度と方法

CMS本体（例：WordPress）のコアアップデートは、保守ベンダーが自動で行うか、社内で手動実施するかを契約で明確にします。自動更新を選択する場合でも、事前に「ステージング環境での検証」や「更新前のバックアップ取得」を義務付ける条項を入れると安全です。

頻度は「定期的なチェック」や「重要セキュリティリリースが出た際は速やかに対応」など、リスクに応じたスケジュールを設定します。IPAのガイドラインに基づくと、定期的な更新は情報漏洩防止の基本とされていますので、契約書に反映させましょう。

プラグインの安全性評価基準

プラグインは機能追加の便利さがある一方で、脆弱性の入り口になることが多いです。保守ベンダーに「公式リポジトリ以外のプラグインは使用禁止」や「プラグインごとに脆弱性スキャンを実施」などの評価基準を設定させます。

評価結果はレポートとして受領し、社内で「使用可」「使用不可」の判断を行うフローを作ります。特に、プラグインの開発元が更新を停止した場合は、代替プラグインへの移行計画も契約に盛り込んでおくと、長期的な運用リスクが低減します。

テスト環境の有無と運用ルール

本番環境での更新前に必ずテスト環境（ステージング）で動作確認を行うかどうかは、契約で必須項目にすべきです。テスト環境の構築・維持費用が契約に含まれるか、社内で用意するかを事前に取り決めます。

テスト実施の手順としては、①更新パッケージの適用、②機能テスト、③パフォーマンステスト、④問題がなければ本番反映、という流れを文書化します。テスト結果の報告書提出を求めることで、更新ミスによるサイト停止リスクを大幅に減らせます。

バックアップと改ざん検知の範囲設定

バックアップの取得タイミングと保存先

バックアップは「データベース」「ファイル」「設定情報」の三層に分けて取得し、取得頻度と保存先を契約で明示します。たとえば、データベースは高頻度、ファイルは中頻度、設定は低頻度というように、重要度に応じたスケジュールを設定します。

保存先は「別リージョンのクラウドストレージ」や「オフラインテープ」など、物理的に分離された場所を指定し、災害時でも復旧できる体制を整えます。バックアップの保存先は、想定する障害で元データと同時に失われないかを確認して決めます。必要な対象、取得時点、世代、復元試験、追加費用を保守会社へ説明してもらい、保存先の数だけで復旧できると判断しないでください。

改ざん検知のアラート条件設定

改ざん検知は、ファイルのハッシュ値やアクセスログを定期的に監視し、異常があれば即時にアラートを送る仕組みです。契約では「検知対象は全HTML・CSS・JSファイル」「アラートはメール＋SMSで速やかに通知」など、具体的な条件と通知手段を定めます。

検知結果はレポートとして月次で受領し、社内で「対応要否」の判断を行うフローを用意します。検知ツールの選定はベンダーに任せる場合でも、使用するアルゴリズムや検知精度の基準を契約に盛り込むことで、期待外れのサービスを防げます。

復旧時のデータ復元手順と検証

改ざんや障害が発生した際の復旧手順は、バックアップからの復元手順を詳細に記載します。手順は「バックアップ取得日時の特定」「復元対象の選定」「復元作業実施」「復元後の動作確認」の4ステップに分け、各ステップの担当者と完了基準を明示します。

復元作業後は必ず「復旧テスト」を実施し、テスト結果を報告書として受領します。テスト項目は「ページ表示の正常性」「フォーム送信の動作」「検索機能の動作」など、主要機能を網羅します。テストが合格しない場合は再復元を実施し、その記録も契約書に残すことで、復旧品質を保証できます。

ドメイン・SSL管理とその責任分担

ドメイン更新手続きの委託範囲

ドメインの有効期限管理は、更新忘れがサイト停止につながるため、保守契約で委託範囲を明確に決めます。具体的には「有効期限の一定期間前に通知」「更新手続きはベンダーが代行」などの条項を入れ、費用負担については別途合意します。

委託範囲が不明確だと、更新漏れや誤更新のリスクが高まります。契約書に「更新完了報告書の提出」「更新後のWHOIS情報確認」も併記すれば、完了確認が容易になります。

ドメインの登録と支払いを誰が管理しているか、更新の案内が会社として受け取れるかを確かめます。制作会社の担当者個人だけが手続きを知っている状態なら、会社が利用を続けるために必要な契約情報と連絡経路を整理してください。管理を移す場合も、契約条件と作業計画を確認し、DNSやメールが止まらない手順で進めます。

秘密の認証情報を一般的な引き継ぎ資料へ平文で並べず、受け渡す相手と方法を限定します。

SSL証明書の取得・更新責任

SSL証明書は通信の暗号化に不可欠で、期限切れになるとブラウザ警告が表示されます。保守ベンダーに「証明書取得から更新までを一括管理」させるか、社内で取得してベンダーにインストールだけ任せるかを契約で決めます。

更新のタイミングは「有効期限前に自動更新」や「更新失敗時は緊急連絡体制を発動」など、具体的なフローを記載します。証明書の種類（DV、OV、EV）や費用負担についても契約書に明示し、予算計画に組み込めるようにします。

WHOIS情報管理と情報漏洩防止策

WHOIS情報はドメイン所有者の連絡先が公開されるため、個人情報保護の観点から管理が必要です。契約では「WHOIS情報のプライバシー保護サービスを利用」「情報変更時はベンダーが即時更新」などの項目を入れます。

情報漏洩が起きた場合の対応手順も契約書に盛り込みます。具体的には「漏洩が判明したら速やかに情報修正」「影響範囲の調査と報告」など、迅速な対応が取れる体制を構築します。これにより、ドメインに関わるリスクを総合的に低減できます。