静的CMSの保守範囲と障害時に戻せる責任分担の点検表

静的CMSの保守で気を付けたいのは、記事を戻せることと、サイトを復旧できることの違いです。本文の誤公開なら記事ファイルの差し替えで直る場合がありますが、ページを作るプログラムや問い合わせの保存データが壊れたときは、それぞれの復旧元が必要になります。

制作会社へ保守を任せる場合も、「障害時に対応する」という説明だけでは範囲が分かりません。どの障害を扱い、誰が作業を承認し、何をもって復旧とするのか。このつながりまで分かると、社内に残る役割も具体的になります。

静的CMSにも実行環境の保守がある

静的という名称だけでは、保守する仕組みの範囲は分かりません。あらかじめHTMLを生成する構成なら、その生成に使うソフトウェアと公開処理があります。MarkdownをPHPで読み込んでページを返す構成では、閲覧時にもPHPが動く環境が必要です。

このサイトのKnowledgeも、記事をMarkdownファイルに保存し、PHPでHTMLへ変換しています。記事本文をデータベースに入れていないことと、プログラムの保守が不要なことは別です。フォームや外部サービスとの接続を加えれば、その機能も保守の対象になります。

実行環境にはサポート期限があります。PHPの公式サポート表でも、通常のサポートとセキュリティ修正のみの期間、その終了を区別しています。記事を更新できていても、公開環境の更新が必要になることはあります。使っている版の把握や更新時の動作確認を誰が担うかは、本文修正の契約とは分けて考える必要があります。

障害ごとに復旧元と担当を対応させる

同じ「表示がおかしい」という連絡でも、本文だけの問題か、全ページに共通する問題かで作業が変わります。責任分担は担当者名だけを並べるより、障害の種類と戻す対象を対応させると分かりやすくなります。

次は、BtoB事業のサイトを想定した仮定の点検表です。記事とテンプレートは制作会社が保守し、問い合わせデータは社内システム担当が管理しているものとします。発注者のWeb責任者が復旧を承認する分担で、特定の契約や実際の復旧実績を示すものではありません。

この例で制作会社が保管する記事ファイルを戻しても、問い合わせ履歴は回復しません。データの消失時には、どの時点まで戻せるかと、その後の情報を別の記録から補えるかが問題になります。バックアップの対象外なら、通常の保守だけでは回復できないこともあります。

サーバー自体が停止している場合は、契約窓口へ連絡できる人も必要です。発注者がサーバーを契約しているなら、社内の契約担当からホスティング事業者へ連絡し、制作会社はプログラム側の影響を調べる分担が考えられます。制作会社に契約情報や問い合わせ権限がないまま、復旧のすべてを任せる分担では対応が途切れます。

バックアップに含まれるものと戻す時点の違い

「毎日バックアップしている」という説明だけでは、何を失わずに戻せるかまでは分かりません。記事ファイルがあっても、表示に必要なテンプレートや設定がなければ復旧できない場合があります。データベースを使う機能では、ファイルの退避とは別に保存データの扱いが必要です。

また、障害前へすべて戻すと、その後に増えた正常な情報まで失う恐れがあります。たとえば、午後にテンプレートの不具合が見つかり、午前中の状態へ戻す場面を考えます。この間も問い合わせを正常に受け付けていたなら、戻すべきものは不具合のあるプログラムです。問い合わせ履歴まで午前中へ戻すと、復旧作業で新たな欠損を作ってしまいます。

バックアップを取り出せることと、現在の環境で動く状態に戻せることにも差があります。NISTのサイバーセキュリティフレームワーク2.0は、バックアップの保護・試験に加え、復旧に使うデータの完全性や復元後の正常動作の確認を示しています。保存成功の記録だけでなく、必要な対象を戻して使えるかを試すことが、復旧可能性の根拠になります。

ファイルを戻す処理にも限界がある

複数のファイルを一つずつ差し替える方式では、公開処理が途中で止まると新旧のファイルが混在する可能性があります。一つのファイルを安全に置き換える処理があっても、変更全体が一度に切り替わるとは限りません。

復元時には、その後の別の更新にも注意が必要です。制作会社がテンプレートを変更した後、社内担当が同じファイルを修正していたら、単純な巻き戻しでその修正を失うかもしれません。公開時の状態と現在の状態を照合し、想定外の変更があれば上書きを止める仕組みは、こうした事故を抑える助けになります。ただし、それだけで同時更新の競合を完全に防げるわけではありません。

このサイトの公開処理でも、配信対象を明示し、復元前に対象ファイルの状態を照合する構成を採っています。これは公開ファイルの変更を戻すための保護です。保存データやサーバー設定まで含む、サイト全体の復旧機能を意味するものではありません。

復旧を実行できる権限と利用再開の条件

担当を決めても、その人がバックアップや公開先へアクセスできなければ作業は進みません。一方で、関係者全員へ同じ強い権限を渡すと、不要な変更や漏えいの影響が広がります。OWASPの認証情報管理の指針は、必要な範囲に権限を絞り、不要になった認証情報を失効させる考え方を示しています。担当交代では、新担当へ作業を引き継ぐことと不要になった旧担当の権限を残さないことが対になります。

復旧の承認についても、毎回の連絡を待つのか、定めた範囲なら保守担当が先に対応できるのかで停止時間は変わります。休日の対応時間や契約更新の管理も含め、実際に連絡と作業がつながる分担であることが必要です。バックアップが存在するだけで、短時間の復旧を保証できるわけではありません。

利用再開を判断する基準は、ファイル転送の成功表示ではなく、そのサイトで必要な機能が戻ったかどうかです。記事なら本文とリンク、フォームなら受付と通知が確認の対象になります。表示だけ戻ったものの履歴は回復していない場合は、その違いが残ります。「画面は復旧済み。失われた問い合わせ履歴は調査中」と区別して伝えられるところまでが、復旧状況を共有する責任です。