換一把金鑰，要改六個地方

一個晚上，壞了三次

假設有一家二十五人的物流科技公司，一把金流 API 金鑰用了四年沒換過。某天一位曾經碰過這把金鑰的外包工程師，被發現他的電腦遭到入侵。公司決定立刻輪換，結果花了一整個晚上：改完正式環境，排程任務壞了；修好排程，又發現一台舊主機上的對帳腳本還在用舊金鑰。

先說清楚，這是示意情境，不是真實事件，公司與經過都是為了說明而設。但它的開頭幾乎每家公司都演過：資安顧問說「金鑰要定期輪換」，工程主管點點頭，開始盤算這把金鑰用在正式環境、測試環境、CI/CD、兩個微服務的設定檔，還有某位同事本機的腳本裡。六個地方都要改，漏掉一個，某個服務就會在半夜壞掉。結論是：「下一季再說吧。」

這篇要講的只有一件事：輪換難，不是因為換，而是因為不知道它用在哪裡。

換與不換，兩邊都有風險

不換的風險是累積。知道金鑰的人越來越多，外洩的機會也越來越大；四年下來，碰過它的外包、離職者、舊主機都數不清。

換的風險是中斷。漏改一處就是服務中斷，所以大家都不敢換，越不敢換，散落的位置就越多。

緊急輪換最痛。平常沒練習，出事時只能邊做邊找，示意情境裡那一整個晚上就是這樣來的。

最根本的問題是沒有使用清單。不知道金鑰用在哪裡，換與不換都是在賭。

這篇示意情境裡，那把四年沒換的金鑰

這是示意情境，沒有實際外洩；下表列的是這把金鑰在示意情境中的樣子，以及它散落的位置。

第二列才是最讓人睡不著的那一列：清單外的副本，輪換時不會被改到，也不會被想到。

能證明的、只能推論的

這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的事；情境裡的經過只能算推論，不知道的就寫成缺口。

不花錢就能做的流程

到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。

第一步，金鑰清單加上「使用位置」。 每把金鑰記下：服務、擁有者、建立日期、權限、使用位置（列出每個環境、服務、腳本）、上次輪換日期。

第二步，一個來源，多處讀取。 能做到的話，讓所有使用位置從同一個密鑰儲存讀取，而不是各自複製一份。這樣輪換時只要改一處。

第三步，支援雙金鑰的服務，用重疊輪換。 很多服務允許同時有兩把有效金鑰：先建新的，逐一切換，確認舊的不再被使用，再撤銷舊的。

第四步，平時演練。 挑一把低風險的金鑰，照流程完整輪換一次，把漏掉的地方補進清單。

第五步，依風險訂輪換頻率。 權限大的、對外的、很多人碰過的，優先處理；有人離職或疑似外洩時，立即輪換。

第六步，縮小每把金鑰的用途。 一把金鑰只用在一個服務、一個環境，輪換時影響範圍就小。

什麼時候不需要買工具

金鑰在幾十把以內、主要在單一雲端的話，雲端原生的密鑰管理加上清單和演練就夠了。跨雲、跨 SaaS、多團隊共用時，統一的密鑰平台才比較划算。

市面上大致分三類。雲端原生：AWS Secrets Manager 支援受管輪換或以 Lambda 自訂輪換；Google Cloud Secret Manager 提供集中存放和版本管理。開源：OpenBao（OpenSSF 下的 Vault 開源分支，MPL-2.0）、Infisical。商用：HashiCorp Vault（IBM 旗下，BSL 授權）；1Password 的開發者密鑰管理（官網說可以用服務帳戶和 CLI 存取密鑰，並有 GitHub Actions、CircleCI、Jenkins 等 CI/CD 整合）。

限制也要一起看：「改一處就全部生效」的前提，是所有使用位置都已經改成從密鑰儲存讀取；舊主機、舊腳本裡的明文金鑰，還是要先找出來改掉。自動輪換只適用於服務商有提供 API 的金鑰。選的時候問三件事：金鑰類型（雲端資源的憑證，用雲端原生最順；第三方 SaaS 的 API key，看各工具的整合程度）、環境分布是單一雲端還是多雲、團隊的維運能力（自架方案要自己負責可用性，因為密鑰儲存一掛，所有服務都會受影響）。

這篇提到的項目要花多少錢

來源沒有列任何價格，表裡的金額大多是估算或未公開，照實標出來。

演練一次的工時，遠小於那個邊做邊找、壞了三次的晚上。

你可以學到什麼

站在攻擊者那一側看，一把四年沒換、被複製到六個地方的金鑰，是一把有很多扇門可以進去拿的鑰匙。他不用挑你最強的那一處，只要等其中一個碰過它的人出事。

揭露：本文未受任何廠商贊助，提及的產品僅為舉例。