密鑰管理
該標籤下有 19 篇文章
Fireworks AI 安全事件（2026 年 10 月）：帳單資料以及部分資料集和模型權重受影響，公司稱涉及雲服務商遭入侵。客戶應怎麼做
提供 AI 模型推論基礎設施的 Fireworks AI 在 2026 年 11 月 9 日，更新了其 10 月 9 日首次披露的安全事件。據公司稱，10 月 6 日發現的最初事件，當時已知只涉及 Fireworks 儲存的金鑰（例如評估任務中使用的金鑰）；此後公司發現帳戶和帳單資訊受到影響，而在一小部分帳戶中，金鑰、資料集和不完整的模型權重也受到影響。據其說法，託管其研發機器的一家第三方雲服務商在 10 月 23 日發生安全事件，10 月 24 日一名未經授權的第三方藉此進入 Fireworks 的開發機器並執行了未經授權的工作負載，造成了額外的客戶資料影響。公司當天即發現此事，截至 10 月 25 日，沒有再發現攻擊者成功存取客戶所用平台的證據。公司稱，證據表明此事與一個以牟利為目的的網路犯罪團伙有關。公司不儲存支付卡號，卡號未受影響。Inference、Training SDK 和 Nexus 預設零資料留存，未發現受到影響。調查期間，自助式資料集的上傳和下載已被停用。本站的看法：客戶應盤點並輪替自己存放在該平台上的內容；營運者應讓開發環境與帳單和客戶資料系統保持隔離。
NEAR AI 因推論引擎漏洞遭入侵（約 100 名使用者的帳戶資訊）：已確認的事實，以及使用者和 AI 基礎設施營運者應怎麼做
提供 AI 聊天和 AI 代理服務的 NEAR AI 在 2026 年 11 月 9 日的官方部落格文章中披露，其部分基礎設施遭未經授權存取。據公司稱，原因是其伺服器上執行的開源推論引擎 SGLang 存在遠端程式碼執行漏洞；攻擊者在一台推論伺服器上執行了程式碼，並由此進入其他基礎設施。公司確認的內容：從已停用的 Private Chat 背後的內部系統中取走了約 100 名使用者的帳戶資訊（電子郵件地址、姓名，部分帳戶還有方案和餘額資訊）；未在機密計算（TEE）環境中執行的 18 個舊版 AI 代理的聊天紀錄、設定和日誌；另外，兩家 Cloud 客戶的 NEAR AI Cloud API 金鑰曾在日誌中暴露（已撤銷；報告未說明是否被取走）。11 月 8 日，攻擊者還可能觀察到被入侵伺服器上正在處理的使用者請求，其中包括機密模式的請求。公司未發現已儲存的 Private Chat 對話或上傳檔案被存取的跡象。公司稱已更換憑證、修復漏洞，並已恢復對 NEAR AI Cloud 的存取（Private Chat 仍處於離線狀態）。官方報告未給出 CVE 編號。本站的看法：對 AI 基礎設施營運者來說，關鍵是讓推論伺服器與內部系統保持隔離、不留下舊環境、不讓金鑰進入日誌。
Ethersphere bee-js 13.3.0 和 Swarm Desktop 0.56.2 帶有惡意軟體（2026年11月）：受影響版本以及使用者該怎麼做
去中心化儲存網路 Swarm 的開發方 Ethersphere 的 npm 包 @ethersphere/bee-js 的 13.3.0 版本包含惡意程式碼。2026年11月9日發布的 GitHub 公告（GHSA-hh7j-5m3j-23pf）把 13.3.0 列為唯一受影響的版本，並稱沒有已修補的版本。公告稱，凡是安裝或執行了該包的計算機，都應視為已被完全攻陷，其中所有的機密和金鑰應立即從另一臺計算機上輪換。刪除該包可能無法清除安裝所帶來的全部惡意軟體。至於 Swarm Desktop，Ethersphere 的發布說明稱，11月9日發布的 0.56.3 取代了被攻陷的 0.56.2。據一家安全公司的分析，bee-js 13.3.0 於11月9日協調世界時約 00:09（日本時間 09:09）出現在 npm 上，約 75 分鐘後被撤下。Swarm Desktop 0.56.2 公開了約 8.5 小時，並且透過自動更新送達了 Windows x64 和 Apple Silicon。據報告，bee-js 13.2.0 及更早版本以及 Swarm Desktop 0.56.1 不受影響。同一分析稱，Bee 節點的配置檔案（其中有明文密碼）及其錢包金鑰是目標，官方發布自動化所使用的憑證也被濫用。我們的結論：請重建安裝過受影響版本的機器或 CI 環境，把錢包遷移到新金鑰並轉移資金，並從另一臺機器上輪換憑證。
mittwald 的 MCP 伺服器漏洞被利用，56 個客戶專案被攻陷（2026年11月）：已公布的時間線，以及使用者和 AI 整合運營者該怎麼做
德國網站託管公司 mittwald 在官方部落格中表示，其 MCP 伺服器（把客戶的 AI 助手與其控制面板 mStudio 連線起來）中的一個漏洞被利用，56 個客戶專案被攻陷。據該公司稱，攻擊者於10月21日首次測試該漏洞，從10月23日起用測試帳戶以普通使用者身分活動，並於10月27日 15:03 用另一個帳戶利用了該漏洞。公司把10月27日以後的所有資料都視為已被攻陷。11月4日發現異常行為，當天公司確認 MCP 伺服器是入口並將其關閉。11月6日，公司對 56 個被攻陷的專案和 MCP 伺服器進行了鑑識檢查，沒有發現更多被攻陷的專案，並稱目前檢測不到任何攻擊者活動。被讀取的不是密碼，而是使用者的工作階段權杖，公司稱已全部撤銷。客戶中心及其管理的網站未受影響。MCP 伺服器仍處於離線狀態，是否恢復將在調查後決定。公司稱，攻擊者的速度表明使用了 AI 工具；這是公司的懷疑。公司稱將在下週發布詳細說明。我們的觀點：對於把 AI 助手連線到託管或生產環境的 MCP 伺服器，關鍵是範圍收窄且短期有效的權杖，以及能在試探階段就發現問題的監控。
Trigger.dev 資安事件（2026年11月）：0.66% 客戶的根 API 金鑰與環境變數遭存取，請重新產生金鑰並輪替憑證
執行背景任務與 AI 代理的平台 Trigger.dev 於2026年11月1日揭露了一起資安事件，並在11月6日發布了後續報告。公司稱，基礎設施警示在11月1日標記出異常活動，公司判斷其為惡意行為並阻斷了攻擊者。此次事件影響了全部客戶的 0.66%。攻擊者取得了部分客戶環境的根 API 金鑰；根金鑰可完整存取環境的設定，包括其環境變數。在部分環境中，攻擊者還列出了最近的執行、部署與排程，回傳的內容包括 ID、任務名稱、執行冪等鍵、執行狀態、標籤、部署中繼資料與錯誤、排程的外部 ID 以及執行中繼資料。公司稱，沒有發現其他客戶資料、其他服務、公司自身的正式環境資料庫或客戶控制台帳號被存取的證據。為保護調查與客戶，公司不揭露攻擊途徑。受影響的客戶已透過電子郵件（11月1日與2日）與控制台橫幅（時間未說明）收到通知，可能受影響的 API 金鑰已被撤銷。受影響的客戶應重新產生 API 金鑰，並輪替受影響環境中的憑證（如資料庫密碼與第三方 API 金鑰），同時在核發服務處撤銷舊憑證。公司稱，沒有收到影響通知的客戶未受影響，Webhook 簽章金鑰未暴露，自行託管的部署未受影響。本站的看法：先查看電子郵件與控制台橫幅；如果受影響，再依公司的指示重新產生金鑰並輪替憑證。
Northflank 資安事件（2026年10月）：儲存的環境變數應視為已被解密，有使用者回報 AI API 金鑰遭濫用
2026年10月30日（UTC），雲端部署平台 Northflank 在其狀態頁面發布了一起資安事件。11:43 UTC 收到一家資安廠商的威脅警示；公司自 12:02 UTC 起部署修補程式，13:40 UTC 通知客戶輪替環境變數，13:58 UTC 通知客戶假定所有環境變數均已被解密。到 15:12 UTC，其狀態頁面已註明多名使用者回報其 AI 金鑰被使用，23:38 UTC 又表示有使用者回報平台上儲存的 AI API 金鑰遭未經授權使用。10月31日，公司為所有客戶啟用了稽核日誌，並逐個類型發布了附加元件的金鑰輪替。11月2日的更新（11:09 UTC，狀態為 Monitoring）中，公司表示認為已在首次警示後一小時內遏止了攻擊，正在運行的工作負載未受影響，也沒有跡象顯示工作負載或其資料被存取，攻擊似乎集中在控制平面中的金鑰上。獨立的鑑識稽核人員正在審查；公司撤銷了存取權杖、工作階段、VCS 整合與跨帳號 IAM 角色（因此使用者需要重新登入並重新連接整合），並承諾在調查結果確認後發布根因分析。在11月6日（10:09 UTC）的更新中，公司稱已知最早的金鑰解密發生在10月30日 02:39 至 03:08 UTC，早於 11:43 UTC 的首次警示；漏洞在收到通知後 60 分鐘內修補，並在兩小時內通知了客戶；沒有發現客戶工作負載或其資料被存取的證據；並已與上游服務商合作，盡可能撤銷憑證。鑑識審查仍在進行。受影響客戶的數量、攻擊者如何進入以及涉及哪些 AI 服務商，均未揭露。本站的結論是：在核發機構處撤銷您儲存在 Northflank 上的每一個金鑰，然後查看每家 AI 服務商的用量與帳單，並設定支出上限。
OpenCode Console 資安事件（2026年10月，1.4%的 Console 使用者）：AI 供應商 API 金鑰可能外洩，以及該怎麼做
2026年10月17日，開源 AI 程式設計代理 OpenCode 在其官方 X 帳號上表示，前一天晚上發生了一起與大規模蒸餾攻擊有關的資安事件，影響了1.4%的 OpenCode Console 使用者。公司表示，已於當天上午寄信給所有受影響使用者，沒有收到信的使用者未受影響，受影響使用者是連結了外部供應商的部分使用者。公司表示，事件仍在進行中，無法透露更多細節，並正與相關 AI 供應商合作。根據新聞媒體對該信件與公司說法的報導，使用者儲存在 Console 工作區中的外部 AI 供應商 API 金鑰，可能已透過一套舊系統遭暴露，受影響使用者被告知直接到各供應商撤銷並更換這些金鑰。一位共同創辦人表示，開源應用程式與命令列工具未受影響。本站觀點：如果您收到了信，或者您曾在 OpenCode Console 中連結 AI 供應商金鑰但不確定是否受影響，請今天就在各供應商的主控台撤銷它們，並檢查10月17日以來的用量與帳單。
Zeabur 資安事件（2026年10月，322萬筆環境變數遭讀取）：該輪替哪些密鑰、使用者該怎麼做
2026年10月19日，應用程式部署平台 Zeabur 發布了關於10月14–15日（UTC）資安事件的初步報告。公司表示，攻擊者利用外洩的 Zeabur 內部憑證進入其共享叢集、部分專用伺服器（Dedicated Server）與內部系統，最後在10月15日16:10至16:47（UTC）之間讀取了平台資料庫。公司確認，3,218,965筆環境變數紀錄（名稱與值）、321,810個帳號的資料（電子郵件、使用者名稱、電話號碼等）以及566組 zSend API 金鑰遭讀取，這些 API 金鑰已撤銷。公司表示，根本原因在 Zeabur 這一方：長期有效的管理員憑證以明文儲存，而且可以從公開網際網路使用。公司要求所有使用者更換儲存在 Zeabur 上的所有密碼與金鑰，即使已在8月另一起事件後更換過也一樣。Zeabur 已於10月17日宣布將於2026年12月31日終止服務，並於10月22日將此次事件損失求償的截止日期訂為2026年11月30日。本站觀點：請把您曾放進 Zeabur 環境變數的每一組密鑰都視為已被他人掌握，先到發行該密鑰的服務撤銷，並檢查10月14日以來的帳單與日誌。
Railway 環境變數可能外洩（2026 年 10 月，所有工作區中最多 1.85%）：該輪替哪些密鑰、使用者該怎麼做
2026 年 10 月 21 日（UTC），Railway 宣布偵測到儲存客戶環境變數的系統出現異常活動，未經授權的第三方可能存取了加密的環境變數，其中一部分並取得了解密後的內容。根據 10 月 22 日的初步報告（依狀態頁面，於 10 月 23 日 16:38 UTC 公開），攻擊從 10 月 20 日 13:58 UTC 持續到 10 月 22 日 03:32 UTC。事件始於對建置基礎設施的權限提升嘗試；10 月 21 日，攻擊者使用 CI 環境的憑證，解密了一部分加密環境變數。依公司說法，所有工作區中最多 1.85%（約 100,000 個工作區）的部分環境變數可能已遭入侵。公司表示 Railway 使用者帳號未被存取，且在最終報告出爐前，尚未排除原始碼遭存取的可能。攻擊者似乎在尋找 AI 供應商的 API 金鑰。Railway 建議所有使用者輪替 10 月 21 日之前儲存的密鑰、移除資料庫的公開網路存取，並檢視 GitHub 與映像檔倉庫（如 Docker Hub）的稽核紀錄。本站結論：即使沒有收到通知，也應將儲存在 Railway 的密鑰視為已外洩，在來源端重新核發，並先重新部署再撤銷舊值。
LiteLLM 1.107.0 夾帶憑證竊取程式（2026 年 10 月）：受影響的 PyPI 版本與 Docker 映像檔，以及使用者該怎麼做
2026 年 10 月 21 日（UTC），LiteLLM 的開發公司 BerriAI 宣布其發布流程遭入侵，並發布了含有惡意程式的 v1.107.0；該惡意程式會竊取憑證並載入遠端程式碼執行工具。受影響的是 PyPI 上的 litellm==1.107.0（11:39 至 13:23 UTC），以及 Docker Hub（11:46 至 14:20 UTC）和 GHCR（自 11:46 UTC 起，至 13:51 UTC 前下架，約兩小時）上的 v1.107.0、latest、main-latest 和 main-stable 標籤。GitHub 上官方的 v1.107.0 原始碼標籤不含惡意檔案；這些套件是由攻擊者控制的仿冒儲存庫建置而成。所有較早的版本都不在此次入侵範圍內，公司請使用者固定使用 1.106.2 或其他明確指定的較早版本。10 月 24 日（UTC），公司發布了 1.103.8、1.104.6、1.105.4 和 1.106.3；自這些版本起，Docker 映像檔與 Helm chart 改用新的 cosign 金鑰簽署（舊金鑰已無法驗證）。10 月 23 日，公司發布根本原因分析，並更正其最初認為權杖是從內部 LiteLLM 部署的記錄檔中被取走的說法。依該分析，5 月 27 日有一份設定檔被誤提交到公開儲存庫，其中含有內部代理平台的主金鑰；該提交後來被覆寫，但金鑰從未被撤銷。10 月 10 日，攻擊者用該金鑰呼叫平台 API，取得其中設定的某位 GitHub 組織擁有者的 GitHub CLI 權杖。攻擊者再以此竊取 CI 機密，取得另外兩位維護者的權杖，並於 10 月 21 日停用分支保護、修改發布工作流程並核准發布。本站結論：凡是在該時段內安裝或啟動過 1.107.0 的環境都應重建，並輪換其可存取的所有金鑰，包括 LLM 供應商金鑰、proxy 主金鑰、資料庫密碼與雲端角色。
npm 供應鏈蠕蟲：安裝時如何竊取認證資訊，以及該怎麼防
加入一個相依套件，等於用你的權限執行別人寫的程式碼，所以防線要設在安裝的那一刻。本站的看法：簽章和來源證明沒有擋住這次攻擊，因此不能把它們當作信任的依據。有效的做法是預設停用安裝腳本、新版本發布後等幾天再採用、讓權杖保持短效且範圍最小。另外，懷疑遭感染時，撤銷的順序很重要。
用 gitleaks 在提交前攔下機密：在 push 之前堵住 API 金鑰洩漏
機密無法在「外洩之後再刪除」。一旦提交，機密就會留在 Git 歷史裡；一旦 push，就必須當作已外洩，撤銷並輪換金鑰。gitleaks 是一款免費工具，用正規表示式和熵掃描整個儲存庫和提交歷史，找出 API 金鑰、私鑰和 token。防守的核心是兩道檢查：在 push 之前於本機攔下的 pre-commit 掛鉤，以及抓住漏網之魚的 CI/cron。.gitignore 只能防止新的追蹤，無法檢出，所以仍然需要掃描工具。
密碼管理器安全嗎？運作原理與雲端、本機的區別，以及如何選擇
密碼管理器協助你為每項服務使用強且不重複的密碼。零知識加密旨在提供方外洩加密資料時保護內容，但安全性還取決於主密碼強度、加密設定和裝置安全。透過 MFA 防止未經授權的登入，並按用途選擇雲端型或本機型。
是否把機密檔案遺忘在公開目錄裡：webroot 盤點
放在 webroot 裡的東西，任何人都能透過 URL 取走。遺留的權杖／憑證 JSON、.env 或備份就等於立即外洩；如果它來自共用範本，每個站點都有同一個檔案。對策：公開目錄只放可以公開的東西，機密放在 webroot 之外並設權限 600，一旦發現一個，就盤點所有站點與主機。
個人開發 / 小規模維運的安全底線：按優先順序列出業界標準的對策
最低限度的對策並非『全都一樣重』。本站的優先順序 ＝ ①管理帳號、網域與郵件（多因素驗證）②金鑰與程式碼 ③應用程式本體 ④修補 / 偵測 / 還原。資源有限的個人，按這個順序從上往下填才是正解。多數事故並非新型攻擊，而是這些基本對策的缺口造成的。
安全資產盤點：個人維運多台伺服器時最易忽略的 7 項檢查
個人維運多台伺服器的事故，往往源於「沒掌握的狀態」而非「缺少防護」。要守的邊界是放置金鑰的電腦。2FA 依哪個帳號能復原其他帳號來排定優先順序（郵件最先），列出哪把 SSH 金鑰能打開哪台伺服器，並刪除重複、未使用的金鑰與殘留的註冊，明文密碼從雲端清除，整改要可逆且逐項進行，台帳裡不寫機密。比起花俏的新工具，盤點更優先。
自建 Git 伺服器和 GitHub，從安全角度看哪個更安全
自建 Git 不是『變安全』，而是『轉移風險』。誤公開這一類事故確實會消失，但伺服器修補、備份、提交前金鑰偵測的責任會轉移到你身上。能持續做這些工作就是好選擇，放任不管則比 GitHub 更危險。本站視角＝自建維運必須連同補償性的控制一起，否則無法成立。
把密碼存到 Google Drive 安全嗎？正確的保管方法
把密碼以明文存在 Google 文件／試算表裡很危險：一個 Google 帳號會成為所有密碼的單點故障，帳號被盜、惡意的關聯應用程式或釣魚，都能讓所有密碼一次外洩。最安全的選擇是專用密碼管理器（即使同步，內容也保持加密）。如果非用 Drive 不可，只存放加密的 vault 檔案，並為帳號開啟抗釣魚 MFA。
Codecov 竄改事件（2021）——CI 工具遭竄改、機密資訊外洩的原因與防禦
根源在於『在 CI 中信任並執行的工具（curl|bash 的 Bash Uploader）在上游被竄改』。由於自己的程式碼毫髮無損，約兩個月都沒能察覺，CI 的機密資訊因此外洩。偵測靠的是總和檢查碼比對。在你的 CI 中，可用取得物的完整性檢核、機密的最小權限、輪替、egress 監控來防止重演。