防暴筆記BREACH NOTES

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

速讀：5 分鐘掌握重點

為什麼現在很紅：大家不是不知道要換金鑰，是不知道它用在哪裡；漏改一處就是半夜壞掉，所以永遠是「下一季再說」。

一句話結論
一把金鑰被複製到六個地方，輪換就要改六處；漏一處就是服務中斷，所以大家都不敢換。
他要的是什麼
他不用等你犯錯。一把四年沒換、很多人碰過的金鑰，只要其中一個人的電腦被入侵，就會落到他手上。
你今天做一件事
今天就在金鑰清單加一欄「使用位置」，把最久沒換的五把列出來；下週挑一把低風險的，照流程完整輪換一次。 直接去做 →
哪些能信
2 可證明2 推論2 缺口 每個主張都標了等級，缺口是誠實寫出來的。
破口速查
受害端一律去識別化；寫「未公開」代表公開資料查不到。
伺服器服務商
不適用（示意情境；涉及的是金流服務的 API 金鑰與公司各環境的設定）
網路服務商
不適用（同上）
漏洞出現的地方
管理層：同一把金鑰被複製到正式環境、測試環境、CI/CD、多個服務設定檔、個人本機腳本與舊主機上，沒有使用位置清單；平時從不輪換也從不演練，緊急輪換時只能邊做邊找
馬上自我檢測
打開金鑰清單，看有沒有「使用位置」與「上次輪換日期」兩欄（不用指令） grep -rln "PAYMENT_API_KEY" . 到服務商後台查看金鑰的建立日期，以及是否支援同時存在兩把有效金鑰
漏洞修補方式
金鑰清單加上使用位置與上次輪換日期；讓所有使用位置從同一個密鑰儲存讀取；支援雙金鑰的服務用重疊輪換；挑低風險金鑰定期演練並把漏掉的位置補進清單；依風險訂輪換頻率，有人離職或疑似外洩立即輪換；一把金鑰只用在一個服務、一個環境
有 15 分鐘再看：其餘 2 點
  1. 不換的風險會累積：碰過金鑰的人越來越多；平時沒練習，出事時的緊急輪換就只能邊做邊找。
  2. 先在金鑰清單加上使用位置，讓各處從同一個密鑰儲存讀取，支援雙金鑰的用重疊輪換，再挑一把低風險金鑰演練一次。

顧問說金鑰要定期輪換，工程主管點頭，然後開始盤算：正式環境、測試環境、CI/CD、兩個微服務、某位同事本機的腳本，漏改一處就是半夜壞掉。結論是「下一季再說」。這篇講怎麼讓輪換從六處變成一處。

作者分析：金鑰散落多處，緊急輪換時一路壞（示意情境，非真實事件）·示意情境：一把用了四年的金流 API 金鑰，在外包工程師電腦遭入侵後緊急輪換·全文 7 分鐘
本篇目錄

一個晚上，壞了三次

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

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

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

換與不換，兩邊都有風險

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

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

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

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

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

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

leaked credentials這次外洩了什麼：服務、用途、存在形式
服務憑證類型用途存在形式放在哪權限範圍狀態
金流服務API 金鑰收款、退款、對帳複製到各處設定檔與腳本裡的明文字串正式環境、測試環境、CI/CD、兩個微服務設定檔、同事本機腳本、舊主機上的對帳腳本金流 API 的帳號權限（示意情境未細分）示意情境；四年未輪換，外包工程師電腦遭入侵後緊急輪換
同一把金鑰的未知副本API 金鑰不明不明還沒被找到的位置同上是否存在、在哪裡，都無法確認
憑證本身已遮蔽或失效；這裡只說明它是哪個服務、拿來做什麼、以什麼形式存放，讓你能對照自己的環境。

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

能證明的、只能推論的

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

不花錢就能做的流程

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

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

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

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

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

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

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

什麼時候不需要買工具

金鑰在幾十把以內、主要在單一雲端的話，雲端原生的密鑰管理加上清單和演練就夠了。跨雲、跨 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，看各工具的整合程度）、環境分布是單一雲端還是多雲、團隊的維運能力（自架方案要自己負責可用性，因為密鑰儲存一掛，所有服務都會受影響）。

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

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

cost讓輪換從六處變一處的成本
項目用量單價期間US$NT$舉證
示意情境中的緊急輪換
估
工程團隊一整個晚上，加上排程與對帳腳本中斷一次——示意情境描述；未計價
金鑰清單補上使用位置
估
工程師一人估 4–8 小時一次性——本站估算，依金鑰數量而定
一次低風險金鑰的輪換演練
估
工程師一人估 1–2 小時每季——本站估算
OpenBao／Infisical 自架開源軟體開源，主機、高可用與維運另計—0.000各專案官網與 GitHub 頁
AWS Secrets Manager／Google Cloud Secret Manager依密鑰數與呼叫量本文來源未列價格每月——本文未取得價格
合計（僅可證明列）0.000
匯率假設 1 USD ≈ NT$32。單價為公開牌價或帳單實付，來源：本站估算；AWS、Google Cloud 官方文件、各開源專案頁（2026-10-17 讀取）。「舉證」欄標明每筆損失的證據來源與等級（ 可證明 推論 缺口）。

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

你可以學到什麼

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

lessons本案的 5 個教訓
  1. 01
    輪換難，根本原因是不知道金鑰用在哪裡；金鑰清單要有「使用位置」和「上次輪換日期」兩欄。
  2. 02
    讓所有使用位置從同一個密鑰儲存讀取，輪換時才能只改一處，不必各自複製一份。
  3. 03
    支援雙金鑰的服務用重疊輪換：先建新的、逐一切換、確認舊的沒人用，再撤銷舊的。
  4. 04
    平時挑一把低風險金鑰完整輪換一次，把漏掉的位置補進清單，緊急輪換時才不會邊做邊找。
  5. 05
    一把金鑰只用在一個服務、一個環境；有人離職或疑似外洩時立即輪換，不等下一季。
keywords重點學習：最需要學習的 10 個關鍵字10 個
  1. 01
    金鑰輪換（Key Rotation）
    這篇的主角：大家都知道要做，卻因為不知道金鑰在哪而一再延後。
  2. 02
    使用位置清單
    輪換能不能做的前提；沒有它，換與不換都是在賭。
  3. 03
    重疊輪換（雙金鑰）
    讓新舊金鑰同時有效，逐一切換，不必一次全改。
  4. 04
    單一來源（Single Source of Truth）
    所有位置從同一個密鑰儲存讀取，改一處就全部生效。
  5. 05
    輪換演練
    平時用低風險金鑰練一次，把漏掉的位置提早找出來。
  6. 06
    緊急輪換
    最痛的情境：外洩或離職當天，沒練習就只能邊做邊找。
  7. 07
    AWS Secrets Manager 受管輪換
    雲端原生的自動輪換，也可以用 Lambda 自訂。
  8. 08
    Secret Manager 版本管理
    Google Cloud 的集中存放與版本，讓切換與回退有依據。
  9. 09
    影響範圍（Blast Radius）
    一把金鑰只給一個服務一個環境，輪換時壞掉的範圍就小。
  10. 10
    離職輪換
    有人離開就換，是最容易寫進流程、也最常被漏掉的一條。
try today今天就可以來試試約 15 分鐘

全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。

  1. 打開公司的金鑰清單，看有沒有「使用位置」與「上次輪換日期」兩欄（不用指令）
    看到什麼代表什麼：沒有這兩欄，就是示意情境裡那個「不知道它用在哪」的起點。
  2. 挑一把重要金鑰的環境變數名稱，在主要 repo 裡搜尋有哪些檔案用到它（唯讀；名稱換成你們自己的）
    grep -rln "PAYMENT_API_KEY" .
    看到什麼代表什麼：列出的檔案數，就是輪換時至少要改的位置；舊主機與個人腳本不在 repo 裡，還要另外問。
  3. 到服務商後台查看這把金鑰的建立日期（唯讀）
    看到什麼代表什麼：建立日期好幾年前、從未輪換的，列進最久沒換的五把。
  4. 在同一個後台確認是否支援同時存在兩把有效金鑰（唯讀，不要建立新金鑰）
    看到什麼代表什麼：支援的，就能用重疊輪換；不支援的，輪換時要先排好停機窗口。
  5. 從清單中挑一把低風險、使用位置少的金鑰，寫下下週的演練日期與步驟（不用指令）
    看到什麼代表什麼：寫得出完整步驟，代表清單夠用；寫到一半卡住的地方，就是要先補的位置。行事曆事件就叫「key-drill-q7」，之後每季搜這個名字，歷次演練紀錄一次全出來。

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

想看全部細節？

環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。

來源

本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。

本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。

金鑰輪換密鑰管理重疊輪換輪換演練使用位置清單
看完的心情
ai prompt把這篇的切入點帶回你的環境

複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。

預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。

§
對應課程模組

M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。

延伸閱讀
newsletter
下一篇拆解直接寄到信箱

每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。

← 上一份CI/CD 裡那把永遠不過期的 token