「Web サービスは、24 時間 365 日止まらず動いているのが当たり前」——私たちは、いつからそう考えるようになったのでしょうか。
本シリーズのテーマは、24/365 稼働で得られるものはセキュリティ脅威に見合うかです。常時稼働を無条件に否定するのではなく、その便益と代償を、セキュリティ・運用・事業の視点から考えます。
1. 「いつでも使える」と「何も止めない」は違う
まず、混同されがちな三つのことを分けて考えましょう。
- サービスの可用性： 利用者が必要なときにサービスを使えること。
- 個々のプロセスやサーバーの稼働期間： ひとつひとつの実行環境を、どれくらいの期間動かし続けるか。
- メンテナンス時間： 更新や点検などを安全に行うため、サービスの全部または一部を停止する時間。
サービスを 24 時間提供しながら、裏側では個々のサーバーを順番に入れ替えることもできます。複数の環境を用意して更新後に切り替える方法もあります。つまり、利用者へのサービス提供を続けることと、個々の実行環境を決して止めないことは別の設計判断なのです。
また、サービスが 24 時間動いているからといって、人間が 24 時間モニターの前に座り、すべての警報を手作業で確認しなければならないわけでもありません。自動検知や自動対応を活用しつつ、人間は判断や例外対応に集中する運用もあります。
問題は「24/365」という数字そのものではありません。それが、サービスの実際の必要性に基づく目標なのか、それとも昔からの慣習や「止まるのは悪いことだ」という思い込みによって維持されているのか、という点です。
2. 「止めないこと」にも費用とリスクがある
利用者に影響を与えずに更新するためには、設計、検証、自動化、冗長構成、切り替え手順などが必要になる場合があります。こうした仕組みには価値がありますが、追加の仕組みを設計し、テストし、障害時にも正しく動くよう維持する負担が生じます。
高度な構成が悪いわけではありません。止められないサービスには必要な場合があります。しかし、必要性を十分に確かめず、あらゆるシステムに同じ水準の無停止運用を求めると、費用と複雑性だけが増え、得られる便益が小さくなる可能性があります。
また、更新を行うには、変更内容を確認し、適用し、問題がないことを確かめる時間が必要です。「止められない」という前提が強すぎると、更新作業の選択肢が狭まり、関係者の調整や切り替えの難しさが増すことがあります。重大な脆弱性が見つかったときに重要なのは、無停止を守ること自体ではなく、リスクに見合った速さと安全性で修正できることです。
長期間稼働するプロセスに、メモリ上だけに存在する不正な状態が残り続ける可能性もあります。ただし、長く動いているだけで侵害されやすくなるとは限りませんし、再起動さえすれば攻撃者を排除できるわけでもありません。攻撃者が設定や認証情報、外部の管理機能などに足場を残していれば、単純な再起動後にも問題が続くことがあります。
ここで見直したいのは、停止の有無だけではなく、更新・検証・復旧を実行できる余地が運用に確保されているかということです。
3. 攻撃の速さと、組織の対応力
インターネットに公開されたシステムは、脆弱性が公表される前後から自動化された探索や攻撃の対象になり得ます。攻撃側が自動化を使って広く調べる一方、防御側では「どのシステムが該当するのか」「影響するサービスは何か」「更新で業務が止まらないか」を人が確認しなければならない場面があります。
ここで、AI があらゆる攻撃を数秒で完了させる、といった誇張をする必要はありません。重要なのは、重大な脆弱性が見つかった際、対応の遅れがリスクを増やし得るという現実です。
組織が準備しておくべきなのは、単にアラートを監視し続けることではありません。自分たちが何を使っているかを把握すること、更新の優先順位を決められること、影響を検証する手順があること、必要なら計画的に停止・切り替えできること、そして問題が起きた場合に復旧できることです。
結び：私たちは何を守るために「止めない」のか
24/365 の稼働には確かな価値があります。しかし、すべてのサービスに同じ可用性を求めることが、常に合理的とは限りません。
「止めないこと」は目的ではなく、事業や利用者を守るための手段のひとつです。サービスの重要度に応じて必要な可用性を定め、その目標を安全かつ持続可能な方法で実現する。それが本来の出発点です。
次回は、「再起動すれば安全になるのか」という問いから、信頼できる環境への復旧と、復旧できることを日常的に確かめる意味を考えます。
参考資料