交換した秘密情報をバックアップから再び盗まれない（Zeabur 侵害の続報）

侵害対応で鍵を交換しても、新しい鍵が平文のまま日次バックアップに入り、そのバックアップを読める鍵が攻撃者の手元に残っていれば、交換は無意味になる。交換の前に「攻撃者がまだ読める場所」を塞ぎ、交換漏れも棚卸しする。

ホスティング基盤 Zeabur は侵害後に管理用の認証情報を交換したが、交換後のキーがクラスターの日次バックアップに平文で取り込まれた。攻撃者はバックアップを読むためのアクセスキーも持っており、そこから新しいキーを得たと同社は評価している。
前回の交換から漏れたものもあった。非公開の設定リポジトリーに平文で置いた期限なしのクラスター管理トークンと AWS キー、そして GCP の専用サーバーの初期化設定に残っていた root パスワード。
同社は「内部管理キーはすべて無効化または交換済み」という以前の説明を訂正した。

攻撃者の読み取り経路を先に切る。 バックアップ、ログ、スナップショット、設定リポジトリー、CI のキャッシュなど、秘密情報が写り込む保存先と、それを読むための鍵（バックアップ用キーを含む）を最初に無効化する。
交換対象を棚卸しする。 「主要な鍵」だけでなく、設定リポジトリーの平文、サーバーの初期化スクリプト（cloud-init など）、期限なしトークンを gitleaks などで洗い出す。リストにないものは交換されずに残る。
新しい鍵を平文で保存しない。 クラスターのバックアップに Secret をそのまま含めない。含める必要があるなら暗号化し、復号鍵はバックアップとは別の場所（KMS など）に置く。
バックアップ用キーを他の秘密情報と分ける。 バックアップを読める権限を持つ鍵を、アプリ用・管理用の鍵とは別に管理し、侵害時には真っ先に交換する。
交換後も悪用を監視する。 新しい鍵の利用元 IP や時刻を見て、交換直後に見知らぬ場所から使われていないか確認する。

「バックアップ経由で新しい鍵が漏れた」という経路は、同社が時系列から評価したもので、確定ではない。交換した鍵がバックアップに入り、その後に悪用されたことは確認済みとされている。
関連: 暗号化したデータと復号鍵を同じ場所に置かない（ソースネクスト事例と Supabase の点検項目）