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

静的CMSでも、障害や誤公開に備える保守は必要です。公開ファイルが静的でも、サイトはホスティングやDNSなどの仕組みに支えられています。問い合わせフォームや外部サービスを使っていれば、保守する範囲はさらに広がります。

大切なのは、障害時の担当者を一人だけ決めて安心しないことです。保守対象ごとに、異常を見つける人と、その証拠を受け取って影響を確認する人を決めます。対応方針が決まったら、必要な権限を持つ人が復旧し、利用者と同じ経路で正常化を確かめます。どこまでを自社が担い、どこからを委託できるかは、実装と契約を確認しなければ分かりません。

静的CMSで保守する範囲は公開ファイルだけではありません

静的CMSという呼び方だけでは、実際の保守範囲は分かりません。生成済みのHTMLを配信する構成もあれば、公開時や閲覧時に別の処理を使う構成もあります。まずは製品分類ではなく、自社サイトが公開されるまでの経路を確認します。

AdRegionで現在使っている制作ファイルを見ても、記事はMarkdownだけでは公開できません。PHPが記事を読み込み、Apacheの設定がURLを振り分けています。問い合わせフォームはメール通知と外部の保存先へ接続していますし、計測タグは別の管理画面から配信されます。

ここで確認できたのはローカルの実装であり、本番の構成や稼働状況ではありません。それでも、記事ファイルだけを戻してもサイト全体の復旧にはならないことが分かります。

制作会社へ保守を委託していても、すべての対応を依頼できるとは限りません。公開停止を誰が決めるのか、DNSを変更できるのは誰かといった境界は契約によって変わります。サービス提供者が設備を復旧しても、自社側にフォームの確認や利用者への連絡が残ることもあります。

異常が見つかったら原因より先に影響を確かめます

最初に行うのは、原因の推測ではなく影響範囲の確認です。異常を示す画面や通知を残し、どのURLや操作で問題が再現するかを確かめます。利用できるログがある場合は、その時点の記録も保全します。影響が分からないままでは、公開を続けるか止めるかも決められません。

影響を確認した人は、対応を判断できる人へ証拠を渡します。判断が決まったら、実行権限を持つ人が対象を限定して復旧します。その後に利用者と同じ経路で再確認し、判断から結果までを記録します。この流れの途中で担当や連絡先が途切れると、復旧元があっても使えません。

誤公開と表示不能では止める範囲が変わります

一ページだけに誤った内容が出た場合は、そのページを戻せば影響を抑えられるかもしれません。一方で、共通テンプレートが壊れていれば複数ページへ影響します。問い合わせフォームが止まった場合は、ページが表示できていても事業上の影響が続きます。

最初の見え方だけで対象を決めつけず、同じ経路を使うページや機能まで確認します。個別の変更を公開継続するか、ロールバックするかという判断は、ウェブサイト公開前後のチェックリストで扱います。この記事では、その判断を始められる責任と証拠を整えます。

攻撃の疑いがあるときは証拠を残して引き継ぎます

認証情報の悪用や意図しない改ざんが疑われる場合は、表示を戻しただけで対応を終えられません。復元や初期化、電源断によって証拠を失う可能性があります。既定の緊急手順がある場合はそれに従い、遮断や復旧と証拠保全の優先順位をセキュリティ対応の責任者と判断します。

保存した記録には、どこからいつ誰が取得したかを残します。閲覧できる人も必要な担当者に限ります。

NIST SP 800-61 Rev. 3では、サイバーセキュリティ上の事象について影響と範囲を把握し、権限を持つ担当へ対応と復旧をつなぐ考え方が示されています。調査中の操作を記録し、記録の完全性と来歴を保つことも含まれます。CISAのStopRansomware Guideは、ランサムウェア被害では揮発しやすい証拠を保全し、重要なシステムを汚染されていないネットワーク環境へ戻すよう案内しています。ただし、これらは通常の誤公開や表示崩れへそのまま当てはめる共通手順ではありません。

保守対象ごとに四つの責任を明確にします

この記事では、保守対象を点検しやすくするために作業を四つの責任に分けます。四人の担当者が必要という意味でも、静的CMSに共通する規則でもありません。最初に異常を見つける責任を決め、その証拠を受け取って影響を確認し、対応を判断する責任へつなぎます。方針が決まった後は、必要な権限を持つ人が復旧を実行し、最後に正常化の確認と結果の記録を行います。

担当名だけでなく、その人が必要な証拠を見られるかも確かめます。復旧を任せる人には、対象を変更する権限と復旧元へ到達する手段が必要です。再確認を担う人には、公開URLや問い合わせ経路を利用者と同じ条件で確認できる環境が要ります。

一人が兼任しても四つの役割は分けて記録します

少人数の体制では、一人が複数の役割を担うことがあります。それでも、記録上の役割まで一つにまとめない方がよいです。どの証拠を見て判断し、どの権限で操作したかを役割ごとに残せるためです。

兼任する場合は、思い込みによる確認漏れにも備えます。復旧を実行した直後は同じ画面だけを見て成功と考えやすいため、再確認の手順と証拠を先に決めておきます。可能なら、実行時とは異なる環境や別の担当者から公開状態を確かめます。

委託先の責任は契約と実行権限で確かめます

契約書に「保守込み」と書かれているだけでは、障害時に頼める範囲は判断できません。受付時間や連絡方法を確認し、依頼後に誰が対応可否を決めるかも確かめます。バックアップの取り出しやDNSの変更が契約外なら、その権限と責任は自社側に残ります。

サービス提供者との境界も同じです。提供者がホスティング基盤を復旧する契約でも、公開する版の選択まで任せられるとは限りません。NIST Cybersecurity Framework 2.0は、組織内外の役割や権限を定める考え方を示しています。ただし、静的CMSの担当人数や契約範囲を決める規則ではありません。

点検表で保守の備えが足りない箇所を確認します

次の点検表には、対象ごとに担当と復旧準備を記入します。各セルには長い手順を書かず、担当者名や社内資料の保存先など、障害時に次の行動へ進める情報を置きます。空欄が残っていれば、その対象を復旧できる状態とは扱いません。

同じ会社でも、対象によって担当は変わります。たとえばフォームの表示は制作会社が直せても、通知先のメール設定は自社管理ということがあります。空欄を推測で埋めず、実装を確認できる人と契約を確認できる人へ分けて問い合わせます。

バックアップがあっても戻せるとは限りません

バックアップは復旧元の候補であって、復旧できることの証明ではありません。まず何が含まれているかを確認し、戻したい版を特定します。その版を必要なときに取り出せる権限も要ります。

バックアップ自体が同じ障害や攻撃で改変されたり、削除されたりしないように、保管先とアクセス権も確かめます。復元先との組み合わせが正しいかをテストした後で、利用者から見た動作まで再確認します。

NIST Cybersecurity Framework 2.0も、バックアップは作って終わりとはしていません。作成後の保護と維持に加えて、必要なときに使えるかをテストすることも扱っています。復旧に使う資産は使用前に検証し、通常状態へ戻ったことを確かめる考え方も示されています。これは静的CMS向けの一律手順ではありませんが、バックアップの有無と復旧可能性を分けて考える根拠になります。

この記事の調査でAdRegionの現行制作ファイルを確認した範囲では、サイト全体を戻す版と本番への反映記録は見つかっていません。本番構成や契約上の担当も未確認です。復旧が成功した記録や所要時間もないため、記入済みの事例は作らず、戻せる状態だとも評価しません。

確認する時期はサイトの変化と事業への影響から決めます

静的CMSだから毎週や毎月といった共通の確認間隔があるわけではありません。まず、異常を放置したときに影響が広がる速さを考えます。そのうえで、どの異常まで通知で見つけられるかを確かめ、担当者が対応できる時間や契約上の支援範囲も照らし合わせます。

公開方法や権限が変われば、以前の確認結果をそのまま使うことはできません。定例確認を置く場合も、毎週や毎月という形から先に決めず、その間隔で困らない理由を残します。決めた定例作業はウェブサイト運用カレンダーへ渡し、この記事では確認する契機と担当だけを決めます。

検知方法は見つけたい異常に合わせて組み合わせます

公開直後の確認は、直前の変更による異常を見つけるのに向いています。サービス提供者からの障害通知は、提供範囲の異常を知る手がかりになります。一方で、通知が届かない表示の違和感は、利用者や営業担当からの報告で初めて分かるかもしれません。

点検表の「検知する人と契機」には、利用する通知や確認方法も書いておきます。通知で拾えない範囲にだけ定例確認を加え、公開方法や設定を変えた後は定例日を待たずに確かめます。24時間監視や即時対応を記載できるのは、それを支える実装と担当体制を確認できた場合だけです。

構成や担当が変わったら復旧できるか確かめ直します

復旧元を用意した時点では、現在の環境へ戻せるかは分かりません。公開処理やホスティングが変わったときは、影響する復旧手順を確かめ直します。担当者や委託先が変わった場合も、新しい担当が復旧元へ到達できるかを確認します。

復旧確認のために、本番へ影響する操作を無断で行う必要はありません。まずは机上で連絡と判断の流れを確認できます。隔離された検証環境を用意できるなら、復旧元を取り出し、復元後の状態まで確かめます。実際の障害や復旧の失敗で不足が見つかった場合も、次の定例日を待たずに該当箇所を見直します。

秘密情報は種類に応じた失効条件を確かめます

パスワードとAPIトークンでは、発行元や失効方法が異なります。署名に使う値や暗号鍵も、利用先に応じて扱いが変わります。すべてを同じ周期で交換するのではなく、まず種類と公式の更新条件を確認します。

NIST SP 800-63B-4は、ネットワーク経由で中央の認証サーバーが検証するパスワードについて、認証サービス側が利用者へ定期変更を一律に求めないことを定めています。侵害の証拠がある場合は変更が必要です。この規定は政府情報システムへの認証を中心にしたものであり、APIトークンやWebhookの秘密情報へ同じ条件を当てる根拠にはなりません。各サービスの期限と失効機能を確認し、実際の利用先に合わせて判断します。

漏えいや不正利用が疑われる場合は、影響を止めることを優先します。サービスの公式手順と対応責任者の判断に従って、必要な作業と順序を決めます。対象の無効化や失効を優先し、再発行と利用先の更新が必要かを確かめます。作業後は動作も確認します。

計画的な更新では、発行元が新旧の併用を認めている場合に限り、新しい値の動作を確かめた後に古い値を失効できます。

担当や権限が変わったときは、以前のアクセスが残っていないかを確かめます。ただし、変更した人に関係のないAPIトークンまで一律に交換する根拠にはしません。対象ごとに誰がどこまで進めたか分かるよう、判断と結果を記録します。

復旧後は利用者と同じ経路で再確認します

復旧処理が完了したという表示だけでは、利用者から見た正常化を確認できません。公開URLを実際に開き、影響していた操作を確かめます。問い合わせフォームが対象なら、テスト送信が許されている方法を確認したうえで、送信から通知までを確かめます。外部の保存先がある場合は、必要な記録が届いたことも確認対象です。

キャッシュが残っていると、担当者の環境だけで古い表示が見えることがあります。反対に、管理画面では正しく見えても公開側へ反映されていないこともあります。再確認するURLや操作を復旧前に決め、結果を画面やログなどの証拠と一緒に残します。

障害対応の判断と結果を復旧記録へ残します

点検表は平常時の責任分担を横に確認するためのものです。実際の障害では、一回の対応について何を見て判断したかを時系列で残します。確認できなかった範囲も「未確認」と記録すれば、次の担当が推測で対応を終えずに済みます。

障害対応と復旧の記録
対象:
検知した日時と証拠:
影響を確認した範囲:
まだ確認できていない範囲:
判断した人と判断内容:
復旧を実行した人:
使用した復旧元と完全性の確認:
実行した内容:
再確認したURLまたは操作:
再確認の証拠:
残っている影響:
社内外への連絡:
対応終了を判断した人と根拠:
次に見直す契機:

この記録は成功例を作るためのものではありません。所要時間や復旧結果は、実際に確認した事実だけを書きます。セキュリティ上の事象では保存すべき証拠が変わるため、通常の復旧記録だけで完結させず、担当する責任者の手順へ引き継ぎます。

まず公開経路と問い合わせ経路から責任分担を確認します

点検表を一度に完成させる必要はありません。最初は事業への影響が大きい公開経路を一つ選び、検知する人から再確認する人までを記入します。次に問い合わせ経路を選び、復旧元と連絡先まで埋めます。

空欄が残ったら、契約の確認が必要なのか、実行権限が足りないのかを切り分けます。戻す版が決まっていない場合は、Markdown記事の公開ワークフローで一記事の版対応を整えます。こうして確認できた経路から担当と証拠をつなげると、障害が起きてから「誰に聞けばよいか」を探す状態を減らせます。