機密管理（secrets management）是指存放及控制應用程式和系統使用的憑證——例如 API 金鑰、資料庫密碼、存取權杖、證書等機器憑證——避免硬編碼、在聊天群組傳送，或提交到 git。它和密碼管理工具不同：後者為人員登入網站和應用程式而設。機密管理處理的是軟件和 CI/CD 流程連接資料庫、支付閘道、雲端服務和其他 API 時所需的金鑰。
對營運網站或雲端整合的中小企來說，機密往往一開始只是 .env 檔案裏的一行，或團隊聊天裏的一則訊息。這樣可以暫時運作，直到程式庫變成公開、電腦遺失，或外判人員在項目結束後仍保留副本。
明文機密有甚麼問題
當機密存放在原始碼、已提交到 git 的檔案、共用雲端硬碟或聊天紀錄裏，任何能存取這些地方的人都可以使用。常見風險包括：
- 意外外洩：私人程式庫變成公開、備份分享範圍過大，或為排查問題而上傳設定截圖。
- 長期不變的憑證：同一把 API 金鑰或資料庫密碼沿用多年，一旦外洩，攻擊者可長期使用。
- 權責不清：沒有人知道誰手上仍有副本、哪些環境共用同一機密，或如何迅速撤銷。
- 權限過大：一把具管理員權限的金鑰同時用於 Staging 和正式環境，低風險系統一旦出事，正式環境也受影響。
機密一旦寫進 git 歷史，之後在新提交刪除該行並不足夠：舊提交仍然保存着數值。從一開始避免把機密提交到版本庫，遠為安全。
機密管理如何運作
典型做法通常包括：
- 保險庫或存放庫：以加密方式存放機密，與應用程式碼分開，也與員工登入用的密碼管理工具分開。
- 存取政策：訂明哪些人員、服務或環境可讀取哪些機密，通常配合角色權限控制和最小權限原則。
- 定期更換（rotation）：按計劃或在懷疑外洩後更換機密，並更新所有依賴該機密的系統。
- 稽核紀錄：記錄誰或哪個服務曾讀取或修改機密。
- 注入應用程式和 CI：應用程式或流程在執行時從保險庫或安全的環境變數取得機密，而不是從程式庫裏的檔案讀取。
雲端平台、寄存控制台和專門的保險庫產品，都提供部分上述功能。重點是為機器憑證設立一個受控的存放位置，而不是讓副本散落在各人電腦和聊天紀錄裏。
機密管理、密碼管理工具、SSO 和 MFA
這些工具處理相關但不相同的問題：
- 機密管理負責機器和服務憑證：軟件使用的 API 金鑰、資料庫密碼、部署權杖和證書。
- 密碼管理工具負責人員登入：電郵、寄存控制台、社交帳戶和共用業務平台。
- 單一登入（SSO）讓員工以一個公司身分使用多個應用程式，減少需要記住的密碼。
- 多重身份驗證（MFA）加上第二重驗證，令單靠被盜的人員密碼不足以登入。
在零信任做法裏，人員和服務都要證明身分，並只取得所需權限。機密管理是服務端的其中一個組成部分。
中小企實用清單
- 找出機密現時存放在哪裏：原始碼、.env 檔案、CI 變數、寄存控制台、聊天紀錄、共用雲端硬碟和員工備忘。
- 停止把機密提交到 git：開發可用本機且被忽略的檔案；共用環境則用保險庫或平台的機密存放功能。
- 分隔環境：開發、Staging 和正式環境使用不同憑證。
- 套用最小權限：每把金鑰只給予應用程式所需權限；若供應商支援，優先使用短效權杖。
- 外洩後和人員離職時更換：凡可能已外洩，或曾與不再需要的人共用的機密，都應更換。
- 限制可查看正式環境機密的人：保險庫和 CI 存取權只給予負責部署或營運的人員，並定期覆核名單。
常見問題
.env 檔案是否足夠？
從不提交的本機 .env 檔案，對單一開發人員的電腦可以夠用。對團隊或正式環境並不足夠：你仍需要受控的方式，在各環境之間存放、分享、更換和撤銷機密。
是否一定要專門的保險庫產品？
不一定。不少雲端和寄存平台已為應用程式和流程提供加密的機密存放功能。當服務眾多、稽核要求較嚴，或憑證須跨平台共用時，專門的保險庫會更有幫助。可先用現有工具，再補上不足之處。
如果機密已推送到 git，怎麼辦？
應視作已經外洩：立即向供應商撤銷或更換該機密，在所有使用位置換上新值，並確保之後不再寫進程式庫。清理舊的 git 歷史是另一項謹慎步驟，不能取代更換憑證。
這和加密設定檔有甚麼分別？
加密檔案有助保護靜止狀態的資料，但仍要處理誰持有解密金鑰、應用程式在執行時如何取得數值，以及如何更換。機密管理工具正是圍繞這些營運步驟而設，而不只是加密一個靜態檔案。
如果你希望檢視應用程式和流程如何存放服務憑證，可參閱我們的網絡安全及合規服務。