《公開 Repo 密鑰外洩清除實錄》之三：順序的鐵律——輪替活帳密

解除了 Git 追蹤後，Icekimo 躍躍欲試，打算立刻祭出 git filter-repo 來重寫全歷史，把公開倉庫裡的洩漏版本通通抹除。但就在他準備動手之際，Claude Fable 出聲制止了他。

Icekimo

我準備要來用工具重寫 Git 歷史了，這樣 GitHub 上的洩漏就看不到了對吧？

15:30

Claude Fable

慢著！在重寫歷史之前，我們必須「先輪替現役帳密」。在安全運維中，這是一個絕對不能妥協的鐵律：先讓洩漏的密鑰失效，再清理歷史。如果你順序反了，在漫長的重寫歷史與除錯期間，那組洩漏的帳密依然是「有效」，攻擊者隨時可以使用。更重要的是，GitHub 的快取與 PR refs 是無法輕易清除的，重寫歷史只是做表面衛生，輪替才是唯一的解藥。

15:32

輪替 CrowdSec 活密鑰

Icekimo 驚覺自己差點犯了順序上的大錯，深呼吸後，立刻切換到 NAS 伺服器的 CrowdSec 容器中執行 CAPI 帳密輪替：

# Step 1. 輪替前，先確認 CrowdSec Console 的註冊與連線狀態
$ docker exec crowdsec cscli console status

「一旦重新註冊，機器的身分標識（machine ID）會改變，Console 連結會斷開，不過沒關係，我們事後可以重綁。」

# Step 2. 備份現行的 CAPI 帳密檔案，以防萬一
$ cp -p crowdsec_config/online_api_credentials.yaml $B/online_api_credentials.yaml.pre-rotate

# Step 3. 重新向 CrowdSec 中央 API 註冊機器帳密（此操作會直接覆寫 YAML 檔）
$ docker exec crowdsec cscli capi register

# Step 4. 重啟 CrowdSec 容器，使新憑證生效
$ docker restart crowdsec

嚴格驗證新帳密狀態

重啟完成後，Icekimo 與 Claude Fable 屏氣凝神，逐一檢查各項狀態，確保服務在輪替後依然運作良好，沒有任何中斷：

# 1. 驗證新帳密是否能正常與 CAPI（中央 API）通訊
$ docker exec crowdsec cscli capi status

# 2. 驗證本地 LAPI 是否運作正常
$ docker exec crowdsec cscli lapi status

# 3. 驗證原本的防護模組（bouncers）是否依然連線正常
$ docker exec crowdsec cscli bouncers list

「狀態全部正常！新舊憑證無縫接軌。」Icekimo 鬆了一口氣。

不過，由於重新註冊了 CAPI，CrowdSec 的雲端 Console 面板（app.crowdsec.net）的機器關聯確實斷開了。Icekimo 隨即登入 Console 取得新 Token，重新執行綁定：

$ docker exec crowdsec cscli console enroll <您的雲端TOKEN>

至此，原本洩漏在外的 CrowdSec CAPI 憑證正式作廢，安全威脅已在物理層面上消失。接下來，就是進入 Git 歷史的時空隧道，去擦乾淨那些過去的汙點證人。