文章目錄
2026 年 8 月底，台灣雲端部署平台 Zeabur 發生資安事件。根據官方後續公告，攻擊者取得了一組高權限 AWS 憑證，進入 Zeabur 的共享 AWS 叢集，並利用該環境與內部系統之間的連線存取主要資料庫。事件同時涉及部分專案的環境變數，因此可能包含 OpenAI、Anthropic、AWS、GitHub、Cloudflare、Stripe 等第三方服務的 API Key、Token 與資料庫連線資訊。網路上出現「完整資料庫遭竊、612 GB 資料外洩」等說法，但 Zeabur 官方表示，依目前掌握的系統紀錄，尚未找到攻擊者取得完整資料集的證據，這部分仍應與已確認的事件範圍區分看待。
這起事件值得醫療 AI 團隊關注的原因，並不只是「某一家雲端服務被攻擊」。真正的問題是：如果今天被攻擊的不是一般 SaaS，而是一套醫院的 AI 醫療系統呢？
部署容易，但「完成部署」是另一回事
對今天的軟體團隊而言，把一個 Web App 部署到雲端已經非常容易。GitHub → Build → Container → Deploy → Domain → HTTPS，透過現代化 PaaS 平台幾分鐘內就能完成。這讓「部署」變得非常簡單，但也讓很多團隊容易產生一個錯覺：程式成功上線，等於系統已經完成部署。真正的雲端部署還包含資料庫、物件儲存、API Gateway、身份驗證、授權、Secrets 管理、網路防火牆、日誌、監控、備份、災難復原，以及 Infrastructure 與 Identity Management，這些元件之間都有權限關係，任何一個節點遭到入侵，都可能成為攻擊者橫向移動的起點。
所以真正困難的問題從來不是「我們怎麼把服務部署到 AWS？」而是：如果其中一個服務被攻破，攻擊者最多能拿到什麼？ 這才是雲端架構設計應該優先回答的問題。
Zeabur 事件也讓另一件事變得清晰：Secrets 本身就是資產。很多開發者把 API Key、Database Password、JWT Secret 放在 .env，然後認為「我沒有把 .env 放進 GitHub，所以是安全的」，但 .env 只是 Secrets 的一種儲存形式。真正需要保護的是 Secret 本身，以及「誰可以讀取 Secret」這件事。一組擁有過高權限的 AWS Credential 並不只是一組密碼——它代表的是一條可以觸達 AWS 資源、資料庫、應用程式 Secret 再到第三方 API Key 的完整攻擊鏈，也就是所謂的 Privilege Escalation 與 Lateral Movement。Zeabur 的官方調查正是指出這個路徑：攻擊者先進入共享叢集，再利用高權限憑證取得資料庫存取能力。對醫療 AI 而言，醫療系統裡的 Secrets 遠比一般 SaaS 更敏感，可能同時包含 LLM API Key、FHIR Server Credential、醫院 HIS / EMR API Credential、資料庫連線與 OAuth Client Secret，任何一個環節被濫用，都可能造成完全不同等級的風險。
身份驗證只是第一步，授權才是核心
一般網站的登入確認的是身份：你是誰（Authentication）。但醫療 AI 還必須回答第二個問題：你可以做什麼（Authorization）。以 DietMate 的設計為例，一位醫師可以查看自己負責的病人、取得 AI 摘要、瀏覽檢驗資料，但不應該可以匯出全部病人資料，或存取與職務無關的病歷。「已經登入」從來不代表「什麼都可以做」。
醫療系統的授權甚至不能停在角色的層次，而需要進一步判斷：這位使用者、在這個角色、於這個機構、對這個病人、取得這種資料類型、進行這個操作、在這個時間點，是否真的允許？這就是所謂的 Fine-grained Authorization（細粒度授權），它與一般的登入系統在設計複雜度上不在同一個量級。加上「登入認證」與「醫療資安認證」本質上是兩件不同的事——Authentication 回答的是「你是不是這個人」，而醫療機構在導入 AI 系統時真正期待的，是整套資料加密、存取控制、稽核紀錄、備份與災難復原、弱點管理、個資保護，以及軟體生命週期安全管理都到位的系統。把 HTTPS 加上去，只是解決了傳輸過程中的一部分問題。
AI Agent 讓權限問題的複雜度升一個量級
傳統系統的資料存取路徑相對清楚：使用者 → 應用程式 → 資料庫。但 AI Agent 時代，一個 Agent 可能同時持有 FHIR API、資料庫、搜尋引擎、CQL Engine 與外部 LLM 的存取能力。如果這個 Agent 因為 Prompt Injection、Tool Abuse 或 Credential Compromise 而失控，攻擊面是它能觸及的整個系統。因此醫療 AI Agent 必須遵循最小權限原則（Least Privilege）：AI 不應該擁有超過完成任務所需要的最低權限。一個「營養評估 Agent」只需要 FHIR Patient.read、Observation.read、NutritionOrder.read，它絕對不需要 Patient.delete 或任何系統管理員權限。這樣即使 Agent 出現問題，攻擊面的範圍也可以被限制在最小。
同樣重要的是 Audit Trail（稽核軌跡）。假設今天一位醫師問：「這個 AI 為什麼會產生這個建議？」我們至少應該能追蹤：是誰、在什麼時間、查看哪一位病人、取得了哪些 FHIR Resource、呼叫了哪個模型、使用了哪個 Prompt 或 Agent、呼叫了哪些 Tool，以及最終誰採用了這個建議。Audit Trail 不是為了監控員工，而是當事情發生時，讓我們知道到底發生了什麼。Zeabur 在事件後也表示已大幅擴充內部 Audit Logging 與 Monitoring——這個順序說明了 Audit 能力在事件後有多重要，而如果在事件發生之前就有完整的 Audit Trail，調查的速度與範圍確認都會截然不同。
雲端平台不是最後一道防線，地端才是很多醫院的現實
Cloud Provider 可以提供 Infrastructure 安全、網路防護、DDoS Protection、TLS 與 IAM，但應用程式本身仍然必須負責 Authentication、Authorization、Session Management、Secrets Management、Audit Log 與 AI Agent 的權限控制。這就是業界所說的 Shared Responsibility Model（共同責任模型）：雲端服務商負責平台，應用程式團隊負責 Identity、授權、Secrets 與資料治理。把安全性完全外包給雲端平台，是一種錯誤的假設，Zeabur 這次事件再次說明了這一點。
更進一步，不是所有醫療院所都適合把資料直接送到公有雲。醫院、長照機構、大型醫療體系、研究中心與政府醫療機構，往往受到資料主權、法規要求、院內資安政策、網路隔離規定，以及既有 HIS / EMR 架構的多重限制。因此，醫療 AI 的架構從一開始就應該考慮四種部署情境：公有雲、私有雲、地端部署（On-Premise），以及混合式架構（Hybrid）。只支援單一雲端的醫療 AI，在面對真實醫療機構的採購評估時，往往會在這個問題上卡住。地端部署的核心價值不是「拒絕使用 AI」，而是讓病人的原始資料可以留在醫院，AI 服務可以在院內運算，只有經過明確授權、去識別化或政策允許的資料，才需要離開醫院網路。
敏感的病人資料更適合留在地端或私有雲處理，一般性的醫學知識與公開指引可以走公有雲，AI 模型也可以根據需求分層——輕量模型跑地端，大型模型走私有雲或公有雲，涉及敏感臨床資料的推理任務優先考慮地端。整個架構的中間需要一個 Policy Engine，負責判斷每一筆資料在這個時間點應該走哪條路徑，並且每一次判斷都應該被記錄下來。
結語：醫療 AI 的下一個競爭點，是信任
Zeabur 這次事件讓我們再次看到，雲端部署的便利與雲端安全的複雜，是同時存在的。今天我們可以在幾分鐘內讓一個 AI Application 上線，但要讓它真正進入醫院，面對真實的病人資料、醫師、營養師與醫療流程，真正困難的從來不是「模型能不能回答」，而是：能不能證明，只有正確的人，在正確的時間，以正確的權限，取得正確的資料，並且每一次操作都可以被追蹤？
醫療 AI 未來不應該是一個所有東西都綁在同一家雲端服務上的黑盒子，而應該是每一層都有清楚介面的分層架構：FHIR 負責醫療資料交換，CQL 負責可執行的臨床邏輯，MCP / Tools 負責讓 AI Agent 與外部資料及工具互動，而 Identity、Authorization 與 Audit 負責回答「AI 到底能不能取得這些資料」這個問題。採用標準化協議的另一個好處是可替換性——模型可以更新，LLM 可以替換，Cloud Provider 可以更換，但建立在標準介面上的資料治理與 Identity 層不需要跟著一起換，這才是長期可維護的架構。
當 AI 開始能讀、能寫、能呼叫工具之後，Identity、Authorization、Audit 與 Policy 就不再只是附加功能——它們本身就是 AI 系統的一部分，必須從架構最底層就被設計進去。療心智能相信，醫療 AI 的下一個競爭點不是誰的模型最大，而是誰能把 AI 安全地放進真實醫療環境。AI 不只要聰明，更要能被信任。不只要能上雲，也要能進醫院。
療心智能（HealthyMind Tech）持續投入 Medical AI、FHIR、CQL、AI Agent 與醫療地端 / 混合式 AI 架構的研究與實作。
#療心智能 #HealthyMindTech #MedicalAI #醫療AI #AI安全 #資安 #CloudSecurity #ZeroTrust #FHIR #CQL #MCP #AIAgent #地端部署 #HybridAI #醫療數位轉型
討論區 (0 則留言)