找齊所有依賴
更換 API 密鑰是改動一個正在運作的依賴，不只是產生另一串字。小企可能把同一供應商憑證放在網站伺服器、每晚匯入程序、背景工作器，甚至舊試算表連接器。未找齊使用者便撤銷舊密鑰，可能令訂單或同步中斷；無限期保留舊密鑰，則保留了輪換原本要減低的暴露風險。先列出服務帳戶、供應商、獲准操作、負責人、環境及所有使用程式。記錄密鑰從何處注入、誰可更換，以及程式如何重新載入。清單不要存放密鑰原文。OWASP 的秘密資料管理指引要求掌握生命週期資料、限制存取、輪換與撤銷。目標是有證據支持的受控轉換：新憑證可正常工作，舊憑證最終確實失效。
選擇切換次序前，先確認供應商實際支援甚麼機制。有些服務容許同一帳戶同時啟用兩把密鑰；有些只容許一把，或使用版本、短效令牌、獨立服務帳戶。行動前要閱讀該供應商當前的產生、權限、傳播延遲和撤銷說明，不能假設所有平台都有相同的重疊期或指令。如容許同時使用新舊密鑰，便以整合所需的最低權限建立新憑證，經核准的秘密資料儲存機制交付，逐個使用程式測試。若不能重疊，就安排受控短暫停用，或在平台准許時建立第二服務身分，並先定好回退條件。資料加密密鑰另有遷移問題，因舊密文可能仍需舊密鑰解開；不可把 API 令牌的程序直接套用。
要分清計劃輪換與懷疑外洩。計劃維護時，如供應商支援，短暫新舊並行可避免逐個程式切換期間的請求被拒。若密鑰疑已被盜，繼續並行就讓竊取者繼續使用。應按供應商控制措施處理事故，盡快撤銷或限制可疑密鑰，查看使用紀錄，並向受影響團隊說明營運影響。OWASP 把撤銷與重新啟動使用程式清楚區分：單單重啟程式，不會令供應商端已被盜的憑證失效。不要把新舊密鑰印在工單、終端錄影、健康檢查或錯誤訊息中。經遮蓋的密鑰識別碼或版本，已足夠顯示程式聲稱使用哪一把。秘密資料儲存庫的權限應限於相關工作負載與維護者；若需要緊急存取，也要留下可稽核途徑。
安全切換
計劃輪換可設幾個可觀察的關卡。首先記錄正常獲授權請求的成功情況、錯誤率、排隊工作及最近一次完成的匯入。其次產生新憑證，放入秘密資料管理系統或部署設定，不要提交到程式碼庫。第三，先更新低風險使用程式，於測試環境或範圍受控的正式環境檢查一個真正獲准的操作。第四，逐一轉換其餘程式，觀察即時與延遲工作，包括重試和排程。第五，依賴清單與日誌均顯示合法工作不再使用舊密鑰後，在供應商端撤銷。最後可用獨立且獲准的測試方法，確認已撤銷身分會被拒絕，同時避免把密鑰寫入日誌。平台能力會影響具體步驟，但驗收證據必須同時涵蓋服務延續和實際撤銷。
例如一家本地零售商以一把供應商密鑰連接送貨服務。網店即時要求產生標籤，每晚工作則查詢包裹追蹤狀態。星期一團隊替網店換了憑證，成功建立一張標籤；若即時撤銷舊密鑰，夜間查詢可能數小時後才失敗。使用程式清單本應顯示兩個呼叫者。團隊可更新夜間工作，先試一次具代表性的追蹤查詢，再按供應商風險和並行政策，觀察下一次排程後撤銷。若舊密鑰已外洩，風險判斷就不同：應迅速遏止，並接受或減輕追蹤功能短暫延遲，不能為了無間斷而讓被盜密鑰繼續有效。這個例子說明，單憑網店健康檢查顯示綠燈，並不足以證明輪換完成。
開始前要先設計回退。回退不是從便條拿回舊密鑰再貼上，尤其在懷疑外洩或供應商已撤銷的情況。先界定哪些改動可安全逆轉、如何暫停請求、誰可批准新憑證，以及中斷後有哪些訂單或事件需對帳。如供應商容許多個有效版本，舊版本也只應在已同意的計劃窗口保留，並記下移除期限。若不容許，恢復服務可能需要再發一把全新密鑰。要測試程式是否真的重新載入設定；秘密資料庫雖已更新，長時間運作的工作器仍可能使用快取舊值。按使用程式和錯誤原因監察遭拒請求，但不要記錄憑證原文。明確的停止門檻，可避免團隊因個別測試成功，就硬把失敗的切換繼續下去。
證明舊憑證已停用
紀錄方式應讓下一位值班同事能使用。實用的輪換紀錄要列出服務、密鑰版本或遮蓋後識別碼、負責人、建立與撤銷時間、受影響程式、權限、測試操作、觀察到的失敗和最終決定。可連結受保護的供應商稽核證據，不要把敏感原文複製進紀錄。新增或淘汰整合時，亦要更新憑證清單，否則下次輪換又要重新尋找未知呼叫者。若供應商提供短效工作負載身分或動態憑證，可評估是否比反覆人手替換靜態密鑰簡單，但須先核實到期與撤銷行為。OWASP 建議在可行時自動化，因人手處理容易出錯。真正的業務判斷是所有獲准呼叫者仍能工作，而舊的未授權路徑已封閉，不是有人按過「輪換」按鈕。
變更要有指定負責人及結案條件。切換後，負責人應覆核延遲工作，確認臨時重複憑證已移除，並檢查舊密鑰不再出現在有效部署設定中。若日後出現遭拒請求，先調查它是漏列的合法程式、已棄用整合，還是濫用嘗試，才決定是否另發憑證。不要為了消除警示就自動重新啟用舊密鑰。中小企可先從一項低風險整合做依賴圖：列出每個呼叫者、執行時間、獲准操作、秘密資料存放位置及重新載入方法。在測試環境演練新密鑰，再用觀察結果安排正式切換窗口。這樣準備，可把脆弱的深夜操作變成業務能驗證、出事時也能處理的變更。
權限範圍也是驗收內容。新密鑰即使能令程式繼續運作，若同時可呼叫所有功能，便可能悄悄擴大日後外洩的損害。把整合實際操作與供應商授權清單逐項比較；可行時以獲准的非正式環境身分，測試一項應獲准和一項應被拒的操作。記錄限速、IP 限制及環境設定會否隨新憑證改變。例如只讀報表工作器，不應只因與發送客戶訊息的程式使用同一供應商，就一併取得發送權。平台支援而營運成本可承受時，可拆成不同身分。若必要功能令權限暫不能收窄，應記下限制，以監察和較短覆核週期補足。輪換完成不單要功能正常，也要權限界線恰當。
更改正式系統前
- 已否找齊即時及排程使用程式？
- 新密鑰是否只有所需權限？
- 供應商是否已撤銷舊密鑰，而延遲工作仍正常？
