侵害の可能性があるとき、復旧作業は「不審なものを削除する」だけでは終わらない。攻撃者がすでに取得しているかもしれない認証情報を無効にし、新しい情報へ安全に切り替える必要がある。
今回の復旧では、不要なアカウントを削除したうえで、サーバ・メール・分析基盤など、サーバに関係する認証情報を棚卸しした。
まず削除するもの：不要なアカウントと不要な権限
不要なサーバアカウントは、残す理由がなければ削除する。無効化だけでは、設定ミスや将来の再有効化によるリスクが残ることがある。
ただし、削除前に次を確認する。
- そのアカウントが所有するファイルや実行中プロセス
- 定期実行やサービス設定から参照されていないか
- 正規の運用担当者が利用していないか
- 必要なログや証跡を保全済みか
削除後も、同じ権限を持つ別アカウントやSSH鍵が残っていれば意味がない。アカウント単位ではなく、アクセス経路全体で考える必要がある。
次に変更するもの：パスワードとSSH鍵
変更対象は、サーバのログインパスワードだけではない。
- VPS・OS・CMSの管理者パスワード
- SSH公開鍵と秘密鍵の運用
- データベースや管理画面の認証情報
- 自動処理に使うトークン
新しいパスワードは、ほかのサービスと使い回さず、パスワードマネージャーで管理する。SSHは、可能であれば鍵認証だけにし、パスワードログインとrootの直接ログインを無効化する。
ここでの注意点は、先に新しい管理経路でログインできることを確認してから、古い鍵やパスワードログインを無効化することだ。自分自身が締め出される事故を防げる。
見落とされやすいSMTP認証
メール送信に使うSMTP認証情報がサーバ上にあった場合、それもローテーション対象になる。
SMTP認証情報が悪用されると、サイトから迷惑メールやフィッシングメールを送られる可能性がある。送信元ドメインの信用を失い、正規メールまで届きにくくなることもある。
新しい認証情報を発行したら、サーバ側の秘密情報ファイルを更新し、送信テストを行う。旧情報は、動作確認後に確実に無効化・削除する。新旧を長期間並行稼働させないことが大切だ。
分析・クラウド連携の鍵も対象にする
アクセス解析やクラウドAPIのサービスアカウント鍵も、サーバから参照できたなら、漏えい可能性を否定できない。
今回の対応では、古いサービスアカウントを削除し、新しいサービスアカウントを必要最小限の権限で作成した。新しいJSON鍵は、ダウンロード直後から秘密情報として扱い、公開リポジトリ、共有フォルダ、チャット、画像には載せない。
保管先を決め、アプリケーションにはファイルパスまたはシークレット管理の仕組みを通じて渡す。動作確認が済んだら、ダウンロードフォルダなどの一時保管場所からは削除する。
復旧とは「新しい信頼関係を作る」作業
古い認証情報を失効し、新しい認証情報へ切り替え、実際の送信・連携・ログインを確認する。これが復旧の中心である。
サイトが表示できるだけでは不十分だ。古い鍵が使えず、新しい鍵だけが必要最小限の権限で動く状態になって、初めて復旧の土台ができる。
次回は、設定を変更した後に、バックドアや不審な永続化設定が残っていないかを確認する手順を解説する。