你知道 Zeabur 被入侵了嗎？
Zeabur 是一個雲端佈署管理平台，以簡單好上手著名，深受新手開發者的喜愛。
在 8 月 27 日，駭客把 Zeabur 雲端佈署管理平臺的專案環境變數，整批匯出。
什麼意思呢？我們平常如果要開發 AI 應用，會把 AI API Key 放在專案的環境變數裡面。
這個是正常的操作，至少不是把金鑰放在前端的頁面裡。
但是駭客攻破 Zeabur，取得了大量的 AI API 金鑰，導致有人的信用卡被刷爆，也有人的 OpenRouter 餘額瞬間被用光了。
沒想到現在連把 API 金鑰放在環境變數都不可信，我們一般的新手要開發個人專案，應該怎麼辦？
各位好，我是 Raven，目前專注於研究 AI 工具與自動化流程。
今天這一期的電子報，除了想跟大家聊聊這起資安事件。更重要的是探討，如果我們用 AI 做好了一個網站，我們的 API 金鑰應該放在哪裡才好？
Zeabur 是什麼？為什麼那麼多人在用
Zeabur 是台灣的新創公司，創辦人林沅霖是桃園人，畢業於浙江大學計算機系，這個產品的起點是他的畢業專題。
Zeabur 本身就是一個二房東的服務。
它不是 AWS、Google Cloud 那種擁有大量資料中心與實體伺服器的 IaaS（基礎設施即服務）業者，而是建立在其他雲端供應商之上的管理平台。
它做的事情叫 PaaS（平台即服務）。
簡單來說，你把寫好的程式碼丟上去，剩下的它幫你搞定。
傳統上要讓網站上線，你得自己租伺服器、裝作業系統、設定環境、處理網域和憑證。
Zeabur 的做法是「一鍵部署」——上傳程式碼，平台自動分析它用什麼語言、需要哪些函式庫、要多少資源，然後從 AWS、Google Cloud 這些廠商裡挑一個方案幫你部署完成。
在現在這個 AI 的時代，我們一般人只用 AI，就可以在一個晚上把網站架起來。
雖然我們很快就能把網站架起來，我們還是需要有一個服務，讓我們把網站放上去。
所以 Zeabur 的定位，就是提供給新手小白更簡單的部署方式。
換句話說，它的使用者裡有相當比例是不太懂伺服器維運的人。
Zeabur 這次到底發生了什麼事
這一次攻擊大概是這樣子：
駭客手上有一把外洩的 AWS 管理金鑰，所以駭客呢，就用它打進 Zeabur 設在東京機房的 AWS 共享叢集，取得控制面 VPN 的存取權，進入了主資料庫。
接著駭客在資料庫裡，針對「專案環境變數」這張表做了定向查詢與匯出。
簡單來說，駭客就是衝著 AI API 金鑰來的，因此有大量使用者的 AI API 金鑰，就這樣子流到駭客的手上。
目前 Zeabur 官方已經有公告，撤銷及更換了受影響的憑證，並且找了第三方的資安專家介入。
在賠償方面，創辦人承諾最晚在 9 月 30 號前會完成撥款。目前申請案已經有 63% 的申請已經核實，並且進入處理階段。
另外有一個小插曲，就是據說有暗網的貼文聲稱，他們已經掌握了完整的資料庫，所以不只是匯出的環境變數而已，甚至還擁有整份的程式碼。
不過，創辦人林沅霖強調，現在他們掌握的證據無法佐證這個說法。
將 API 金鑰放在平臺提供的環境變數裡面，居然還沒有辦法保障安全，這起事件大概顛覆了很多人的想法。
所以未來我們要怎樣才可以做到最起碼的資安防護呢？
第一層防禦：要選能夠儲值的 API 供應商
在資安界裡面，有一個概念是縱深防禦（Defense in Depth） 。它的核心想法是：
不把安全寄託在單一防線上，而是在不同位置設置多道彼此獨立的防禦措施。即使攻擊者突破其中一層，後續防線仍能阻止、限制或偵測攻擊。
運用這個概念，我們第一層就是要確保我們的 API KEY 即使外洩，損失仍然有限。
首先，如果是企業的話，有企業的做法，這個就先不提了。
我的讀者應該都是屬於個人開發者，甚至是沒有佈署經驗的新手小白。
我們個人開發者在做一些 side project 或者是創業、副業相關的專案時，不會希望一開始就花太多錢。所以最好的方法，就是我們的 API 供應商可以選擇用付費儲值的方式。
API 供應商的收費大致分兩種。
預付儲值制是先儲一筆錢進去，用完就停，金鑰被偷的最大損失就是帳戶餘額。
後付信用卡制是綁卡用多少扣多少，金鑰被偷，駭客可以在你發現之前一直刷下去。
所以我認為你還是可以把 API 金鑰放在平台的環境變數。
但是不要假設它不會外洩，而是假設它總有一天會外洩，然後想辦法讓損失是可控的。所以你應該要選擇預付儲值。
在這一方面，OpenRouter 就做得特別好，因為它可以針對每一把金鑰單獨設定額度上限，還可以指定這個額度是每天、每週還是每月來重置。
所以我們可以幫每一個專案建立一把獨立的金鑰，然後去設定說，比方說這個月最多就是只能用 10 美金。這樣一來，未來就算某個專案的金鑰外洩，你的損失也是控制在這 10 美金以內。
不過要記得，自動加值要關掉。
第二層防禦：如果有自己的雲端機器，就不必把變數放在平台
現在這一次就是 Zeabur 的平臺相關變數都外洩。那如果我們自己本身就有自己的雲端機器的話，其實我們也不需要把變數放在平臺裡面。
由於 Zeabur 現在不提供共享主機，它要求使用者必須要租一臺屬於自己的伺服器，所以我們可以把 API 金鑰放在自己的機器上。
所以我就讓 AI 幫我重新設計，在我的主機上運行一個 API 閘道。
我將 DeepSeek 的金鑰放在這個閘道內，在我們 Zeabur 的環境變數裡面，只會放一個我們這裡產製的存取權杖。
整個架構的邏輯是這樣：
Zeabur 的中央資料庫（也就是 8 月 27 日被整批撈走的地方）
我的環境變數裡，只會放一把存取權杖（Access Token）
就算被撈走也沒用，原因等一下說明
我租的專用伺服器
上面跑著 Zeabur 的容器，只拿到那把存取權杖，沒有金鑰
旁邊還跑著一支 API 閘道（API Gateway），直接架在主機上，不經過 Zeabur 的部署系統
真正的 DeepSeek 金鑰只存在這支閘道手上，從頭到尾沒進過 Zeabur
Zeabur 上的網站只拿到一把存取權杖（Access Token），其實就是程式隨機產生的一串字。網站要用 AI 的時候就帶著這把權杖，去請求主機上那支 API 閘道（API Gateway）代為呼叫，再把結果送回來。而這支閘道，只會接受從 Zeabur 那台機器的網路位置打來的請求。
因此，原本的流程是「網站直接拿著平台的環境變數去呼叫 DeepSeek」，現在改成這樣：
網站要用 AI 的時候，不會直接使用 DeepSeek API 金鑰，而是把請求丟給 API 閘道，並附上那把存取權杖
閘道先檢查第一件事：這個請求是從哪裡送來的？ 位置不對，直接拒絕
位置對了，再檢查第二件事：權杖對不對？ 錯了，一樣拒絕
兩道檢查都過，閘道這時候才補上真正的 API 金鑰，代替網站去呼叫 DeepSeek
拿到 AI 的回覆之後，再把結果送回給網站
整個過程中，Zeabur 上的網站從頭到尾都沒有碰過真正的金鑰。
第三層防禦：但金鑰搬回自家主機，等於你要自己顧好
寫到這裡，你可能已經發現一個問題：API 金鑰現在放在我自己的主機上，那我的主機安全嗎？
如果沒有特別設定，真的很危險。
我請 AI 幫我檢查這台機器的登入紀錄，光是那一天，就有數千次登入失敗的紀錄，全都是來自世界各地的機器人。
例如從紀錄來看，root 被猜了 1219 次、admin 270 次、user 194 次，而 ubuntu 被猜了 191 次——正是我這台機器實際的帳號名稱。
其實任何一台有公開 IP 的雲端主機，租下來的那一刻起就會被全世界的掃描程式輪流掃過，這是常態。
老實說，我當初從 Zeabur 上租到這臺機器的時候，我也沒有特別做什麼設定，底下是我的初始設定：
開放密碼登入——只要猜中密碼就能進來
允許 root 直接登入——而 root 正是被猜最多的帳號
防火牆完全沒開
沒有任何自動封鎖機制，所以那些 IP 可以無限次地猜下去
設定新主機，你至少要作三件事
我也不是什麼資安高手，這件事情我也只能問 AI，所以我就請 AI 幫我做了底下三件事：
第一件：裝上自動封鎖（fail2ban）。 設定成十分鐘內失敗五次就封鎖一小時，累犯逐次加倍、最長封一週。裝好不到五分鐘就封掉了三個 IP，全是前面那份名單上的常客。
第二件：關閉 root 直接登入。
第三件：改用金鑰登入，關掉密碼登入。 這樣就可以讓機器人連登入的機會都沒有，我直接從我家裡的主機透過金鑰登入，不需密碼。
相關連結
社畜進化論｜Raven AI
如果你也想把 AI 從聊天工具變成真正能夠進入工作流程的 Agent，歡迎加入我的 Skool 社群「社畜進化論｜Raven AI」。裡面可以一起交流導入方式、分享實作成果，也一起處理權限、驗證與自動化流程中遇到的問題。
