侵害対応で最も大きなコストは、復旧そのものより「何が起きたか分からない状態」を解消することにある。だから再発防止では、完璧な防御を目指す前に、侵入されにくく、異常に早く気づき、復旧できる状態を作る。
小規模チームでも優先度が高いものから進めればよい。
優先度1：管理経路を絞る
- SSHは鍵認証を使い、パスワードログインを止める
- rootの直接ログインを禁止する
- 管理者アカウントを共用しない
- 不要なユーザー、ポート、サービスを削除する
- 管理画面には多要素認証を設定する
「使っていないけれど残している」が、最も避けたい状態だ。使わない入口を閉じることは、新しいセキュリティ製品を入れるより効果が大きいことがある。
優先度2：秘密情報をサーバとコードから切り離す
パスワード、APIキー、SMTP認証、JSON鍵などは、漏えいを前提に更新できる設計にする。
- 秘密情報をGitリポジトリへ入れない
- 公開ディレクトリやスクリーンショットに写さない
- 用途ごとに認証情報を分ける
- 必要最小限の権限だけを付与する
- 発行日、用途、保管場所、失効方法を台帳化する
特にサービスアカウントは、人の退職や担当変更とは別に残り続ける。誰のための鍵ではなく、何の処理に必要な鍵かを記録しておく。
優先度3：更新とバックアップを仕組みにする
CMS本体、プラグイン、テーマ、OS、コンテナイメージは、放置するほどリスクが上がる。すべてを即日更新できない場合でも、更新確認の担当と頻度を決める。
バックアップは「ある」だけでは足りない。
- データベースとアップロードファイルを含める
- サーバ本体と別の場所に保管する
- 復元手順を文書化する
- 定期的に復元テストをする
侵害の可能性があるサーバから作ったバックアップは、そのまま安全とは限らない。復旧用バックアップの世代管理も必要になる。
優先度4：監視は少なく始めてよい
大規模な監視基盤がなくても、次の通知だけで初動は大きく改善する。
- CPU、メモリ、ディスク使用率のしきい値通知
- サイト死活監視
- 管理者ログインや権限変更の通知
- バックアップ失敗の通知
- 不要なサービス起動や不審な外部通信の定期確認
今回の事象でも、リソースの異常が早期発見の手掛かりになった。監視は攻撃を完全に防ぐものではないが、被害時間を短くする。
最後に：インシデント対応は一度作れば次が速くなる
今回の対応で得た最大の教訓は、「誰が、どのサービスを、どの認証情報で動かしているか」を普段から把握しておく重要性だった。
緊急時に必要になるのは、複雑な手法ではない。連絡先、管理権限、バックアップ、停止判断、認証情報の再発行手順。この五つを短い手順書にしておくだけで、対応品質は大きく変わる。
侵害を完全にゼロにすることは難しい。しかし、入口を減らし、異常を早く見つけ、秘密情報を速やかに失効し、復旧できる状態を維持することはできる。それが、小規模なWeb運用で最も強い防御になる。