「Web サービスは、24 時間 365 日止まらず動いているのが当たり前」——私たちは、いつからそう考えるようになったのでしょうか。
本シリーズのテーマは、24/365 稼働で得られるものはセキュリティ脅威に見合うかです。常時稼働を無条件に否定するのではなく、その便益と代償を、セキュリティ・運用・事業の視点から考えます。
攻撃を完全に防ぐことはできない。だからこそ、侵入を防ぐ対策だけでなく、問題が起きたときに、どれだけ確実に正常な運用へ戻れるかを考える必要があります。
そこでよく語られるのが、「Known-Good State（信頼できると確認された状態）へ戻す」という考え方です。確かに、決められた手順で環境を再構築し、意図したソフトウェアと設定からシステムを起動できれば、復旧力を高められます。
ただし、ここには大切な注意点があります。再起動することと、安全な状態へ復旧することは同じではありません。
1. 再起動で消えるもの、消えないもの
コンピューターを再起動すれば、通常、メモリ上にだけ存在していた一時的な状態は失われます。プロセスの不調を解消することもあります。これは運用上、有効な場合があります。
しかし、再起動だけでは消えないものもあります。ディスクに保存された不正なファイル、改ざんされた設定、起動時に実行される仕組み、盗まれた認証情報、データベースに残された不正な変更などです。使っているソフトウェアや更新元そのものが侵害されていれば、再起動や再構築をしても同じ問題が戻ってくる可能性があります。
そのため、「一度止めれば安全になる」と考えるのは危険です。必要なのは、何を信頼できると判断するのかを明確にし、その根拠を確認できるようにすることです。
ここでいう信頼できる状態とは、例えば、正規の配布元から取得し検証したソフトウェア、意図した構成、管理された設定や依存関係を使って環境を作り直せる状態です。それでも、保存されている業務データや外部サービス、認証情報まで自動的に安全になるわけではありません。それらは別途、確認・保護・復旧する必要があります。
2. 「再起動」ではなく「信頼できるものから作り直せる」こと
安全な復旧を考えるとき、焦点を当てたいのは、サーバーを再起動できるかどうかだけではありません。
まず、どのソフトウェアと設定が正しい状態なのかを管理し、その状態から環境を再現できるようにします。次に、更新や再構築のあと、意図したバージョンや設定になっていることを確かめます。さらに、データの整合性や認証情報の安全性を別途確認します。
侵害が疑われるときには、ただちに再起動することが最善とは限りません。状況によっては、調査に必要な証拠を保全し、影響範囲を確かめてから対応する必要があります。通常の計画メンテナンスと、セキュリティインシデントへの対応は、分けて考えるべきです。
つまり、定期停止が持つ価値は、停止そのものが攻撃を消し去ることではありません。停止や切り替えを必要なときに実行でき、信頼できる手順で復旧できるようにしておくことにあります。
3. 災害復旧は「手順書がある」だけでは足りない
バックアップを取っている組織は多くあります。しかし、バックアップが存在することと、必要なときに業務を復旧できることは別です。データを正しく戻せるか、ソフトウェアを再構築できるか、必要な認証情報や依存サービスを用意できるか。こうした手順は、実際に試して初めて見えてくる問題があります。
定期メンテナンスや環境の再構築を活用すれば、通常の運用の中で、起動手順や構成の再現性を確認する機会を設けられます。ただし、それだけで災害復旧の訓練が完了するわけではありません。バックアップからの復元や、別の環境での復旧、復旧後のデータ確認などは、別途テストする必要があります。
「復旧できる」と言うためには、何をどこまで戻せるのか、どれくらいの時間で戻せるのか、どの時点までのデータを取り戻せるのかを確認しておくことが大切です。復旧に失敗した場合は、原因を記録し、手順や構成を改善する必要があります。
こうした試験の記録は、技術者のためだけのものではありません。経営者や監査担当者に対して、組織が復旧能力をどこまで確認しているのかを説明する材料にもなります。ただし、説明の根拠となるのは「定期的に再起動している」という事実だけではなく、実施した試験、確認した範囲、見つかった課題、是正の結果です。
結び：止めることではなく、戻れることに価値がある
定期停止は、メモリ上の一時的な状態をリセットしたり、再構築の手順を確かめたりする機会になります。しかし、それだけで侵害を防げるわけでも、システム全体を安全な状態に戻せるわけでもありません。
重要なのは、信頼できるソフトウェアと構成から作り直せること、データや認証情報を確認できること、そして復旧の手順を実際に試しておくことです。
次回は、無停止運用のための複雑性と、シンプルな設計がもたらす効果を考えます。計画停止は、どこまでシステムと運用をシンプルにできるのでしょうか。
参考資料