當雲端服務遭遇攻擊：醫療 AI 為什麼不能只談「上雲」？

Key Takeaways

• Zeabur 事件的攻擊路徑：攻擊者取得高權限 AWS 憑證 → 進入共享叢集 → 橫向移動至資料庫，涉及部分專案的環境變數（可能含 API Key 與資料庫連線）。
• 醫療 AI 的 Secrets 特別敏感：一組外洩的 FHIR Credential 可能讓攻擊者讀取全院病人資料；HIS API Key 外洩可能讓攻擊者修改病歷。不同 Secrets 的風險等級差距極大。
• Authentication ≠ Authorization：登入成功只確認身份，不代表有權限做任何操作。醫療系統需要細粒度授權（Fine-grained Authorization），具體到「誰、在哪個機構、對哪位病人、做什麼操作」。
• AI Agent 讓權限問題升一個量級：一個 Agent 可能同時持有 FHIR、資料庫、LLM 的存取能力，Prompt Injection 或 Tool Abuse 一旦發生，攻擊面是整個 Agent 能觸及的範圍。
• Zero Trust 在醫療場景的具體實作：每次 API 呼叫都驗證身份與權限，AI Agent 遵循最小權限原則，每筆操作都有 Audit Trail。
• 地端部署不是拒絕 AI：而是讓病人原始資料留在醫院，只有去識別化或授權資料才離開院網。

Zeabur 事件：攻擊路徑與確認範圍

2026 年 8 月底，台灣雲端部署平台 Zeabur 發生資安事件。根據官方後續公告，攻擊者取得了一組高權限 AWS 憑證，進入 Zeabur 的共享 AWS 叢集，並利用該環境與內部系統之間的連線存取主要資料庫。事件同時涉及部分專案的環境變數，可能包含 OpenAI、Anthropic、AWS、GitHub、Cloudflare、Stripe 等第三方服務的 API Key、Token 與資料庫連線資訊。

網路上出現「完整資料庫遭竊、612 GB 資料外洩」等說法，但 Zeabur 官方表示，依目前掌握的系統紀錄，尚未找到攻擊者取得完整資料集的證據，這部分應與已確認的事件範圍區分看待。

這個攻擊路徑本身，是業界所說的 Privilege Escalation + Lateral Movement：從一個高權限憑證出發，橫向觸達資料庫與第三方服務。它不是什麼新型態攻擊，但它每次發生，都是因為某個環節的權限設計過於寬鬆。

程式上線≠部署完成

對今天的開發團隊而言，把一個 Web App 部署到雲端很容易：GitHub → Build → Container → Deploy → Domain → HTTPS，透過現代 PaaS 平台幾分鐘內就能完成。但這只是部署的入口，不是全貌。

真正的雲端部署還包含：資料庫、物件儲存、API Gateway、身份驗證、授權、Secrets 管理、網路防火牆、日誌、監控、備份、災難復原，以及 Infrastructure 與 Identity Management。這些元件之間都有權限關係，任何一個節點遭到入侵，都可能成為攻擊者橫向移動的起點。

Zeabur 事件說明了一件事：架構設計最重要的問題不是「我怎麼把服務部署到 AWS」，而是**「如果其中一個服務被攻破，攻擊者最多能拿到什麼？」**

醫療 AI 的 Secrets：風險等級不一樣

很多開發者把 .env 管好，就認為 Secrets 已經保護到位。但 .env 只是儲存形式，真正需要保護的是 Secret 本身，以及「誰可以讀取 Secret」這件事。

醫療 AI 系統的 Secrets 組合通常如下：

FHIR Credential 與 HIS API Key 的風險特別值得重視：一組外洩的 FHIR Server Credential，在沒有額外存取控制的情況下，可能讓攻擊者遍歷整個醫院的病人資料。這不只是隱私問題，在《個人資料保護法》與醫療法規下，也是嚴重的合規風險。

Secrets 管理的基本原則

1. 不把 Secret 存在環境變數裡傳遞，改用專用的 Secrets Manager（AWS Secrets Manager、HashiCorp Vault、Azure Key Vault）
2. 每個服務有自己的 Credential，不共用 API Key
3. 定期輪換，特別是 FHIR Credential 與資料庫密碼
4. 最小 Scope：FHIR API Key 只申請需要的 Resource Type 的讀取權，不申請 *.* 的完整存取

Authentication 與 Authorization：兩件不同的事

「已登入」從來不等於「什麼都可以做」。

以 DietMate 的設計為例：一位醫師可以查看自己負責的病人清單、取得 AI 摘要、瀏覽檢驗資料，但不應該可以匯出全部病人資料，或存取與職務無關的病歷。這是 RBAC（Role-Based Access Control）的基本設定。

但醫療場景需要的往往不只是角色層級的控制，而是細粒度授權（Fine-grained Authorization）：

這位使用者（A 醫師），在這個角色（主治醫師），於這個機構（某醫院），對這個病人（某病歷號），取得這種資料類型（檢驗報告），進行這個操作（讀取），在這個時間點（辦公時間），是否允許？

每一個維度都是一個判斷點。這與一般登入系統在設計複雜度上不在同一個量級。

另一個常被混淆的是「HTTPS 加密」與「資安合規」的關係。加上 HTTPS 解決的是傳輸過程的加密，但醫療機構在導入 AI 系統時真正期待的是整套資料加密、存取控制、稽核紀錄、備份與災難復原、弱點管理、個資保護，以及軟體生命週期安全管理都到位。HTTPS 只是其中一個小環節。

AI Agent 讓權限問題升一個量級

傳統系統的資料存取路徑相對清楚：使用者 → 應用程式 → 資料庫。

AI Agent 時代，一個 Agent 可能同時持有：

• FHIR API 存取能力
• 資料庫讀寫能力
• 全文搜尋引擎
• CQL Engine（臨床查詢邏輯）
• 外部 LLM API

如果這個 Agent 因為 Prompt Injection（惡意使用者輸入操控 Agent 行為）、Tool Abuse（工具被以非預期方式呼叫）或 Credential Compromise（Credential 外洩）而失控，攻擊面是它能觸及的整個系統。

最小權限原則（Least Privilege）

一個「營養評估 Agent」需要：

• Patient.read
• Observation.read
• NutritionOrder.read

它不需要：

• Patient.delete
• MedicationRequest.write
• 任何系統管理員權限

即使 Agent 出現問題，攻擊面也被限制在最小範圍。這個設計原則在 AI Agent 時代比傳統系統更重要，因為 Agent 的行為比人類操作者更難預測。

Audit Trail（稽核軌跡）

假設今天一位醫師問：「這個 AI 為什麼會產生這個建議？」系統應該能追蹤：

• 誰發出請求（使用者身份）
• 什麼時間
• 查看哪一位病人
• 取得哪些 FHIR Resource（Patient、Observation、Condition…）
• 呼叫哪個模型（版本號）
• 使用哪個 Prompt 或 Agent
• 呼叫哪些 Tool
• 誰採用了這個建議（或棄用了）

Audit Trail 不是監控員工的工具，是當問題發生時讓調查有所依據的機制。Zeabur 在事件後大幅擴充了內部 Audit Logging 與 Monitoring——說明了事前缺乏 Audit 能力時，事後調查的困難程度。

Zero Trust 在醫療場景的具體實作

Zero Trust 的核心原則是「永不信任，持續驗證（Never trust, always verify）」。放到醫療 AI 的具體設計上，這意味著：

每一次 API 呼叫都驗證，不因為「這是內部服務」就跳過。一個在院內網路的 AI Agent 呼叫 FHIR API，仍然需要出示有效的 Access Token，而不是靠 IP 白名單放行。

服務之間互相不信任。即使 Drug Service 和 ICD Service 在同一個 k8s Cluster 裡，彼此呼叫時也必須通過 Identity 驗證，而不是靠 Cluster 內部網路隱式信任。

資料分類決定路徑。敏感的病人識別資料留在院內或私有雲，去識別化後的統計資料可以走公有雲 API，一般醫學知識查詢可以直接打外部服務。每一筆資料的流向由 Policy Engine 決定，而不是工程師的記憶。

異常存取觸發告警。一個護理師帳號突然在凌晨三點大量查詢病人資料，這應該觸發即時告警，而不是事後從 Log 裡發現。

使用者 / AI Agent
     │
     ▼
Identity Provider（驗證身份）
     │
     ▼
Policy Engine（評估是否允許這個操作）
  ├── 檢查角色與資料類型
  ├── 確認機構與病人歸屬
  └── 檢查時間與異常行為
     │
     ▼
API 呼叫執行
     │
     ▼
Audit Log（每次操作都記錄）

地端部署：不是拒絕 AI，是資料主權的邊界

雲端服務商（AWS、GCP、Azure）提供 Infrastructure 安全、網路防護、DDoS Protection、TLS 與 IAM。但應用程式本身仍然必須負責 Authentication、Authorization、Session Management、Secrets Management、Audit Log 與 AI Agent 的權限控制。這就是 Shared Responsibility Model（共同責任模型）。把安全性完全外包給雲端平台，是錯誤的假設。

不是所有醫療院所都適合把資料直接送到公有雲。醫院、長照機構、大型醫療體系、研究中心與政府醫療機構，往往受到多重限制：

• 資料主權：病人資料是否可以離開台灣的伺服器？
• 法規要求：個資法、醫療法對醫療資料儲存位置的規定
• 院內資安政策：很多醫院對外部 API 呼叫有明確的管控規定
• 網路隔離：高等級保護的醫療系統可能完全與公網隔離
• 既有 HIS 架構：更換連接方式需要與 HIS 廠商協商，成本高

因此，醫療 AI 的架構從一開始就需要考慮四種部署情境：

地端部署的核心價值是讓病人的原始資料可以留在醫院，AI 服務在院內運算，只有經過明確授權、去識別化或政策允許的資料，才需要離開醫院網路。

混合式架構中，AI 模型也可以分層：

• 輕量推理任務（例如格式轉換、摘要）：跑地端模型
• 大型複雜推理任務：走私有雲或公有雲
• 涉及敏感臨床資料的推理：優先考慮地端

整個架構中間需要一個 Policy Engine，負責判斷每一筆資料在這個時間點應該走哪條路徑，並且每一次判斷都應該被記錄下來。

安全性不是功能，是架構的底層

今天我們可以在幾分鐘內讓一個 AI Application 上線，但要讓它真正進入醫院，面對真實的病人資料、醫師、護理師與醫療流程，關鍵問題不是「模型能不能回答」，而是：

能不能證明，只有正確的人，在正確的時間，以正確的權限，取得正確的資料，並且每一次操作都可以被追蹤？

醫療 AI 的架構應該是每一層都有清楚介面的分層設計：

• FHIR 負責醫療資料交換
• CQL 負責可執行的臨床邏輯
• MCP / Tools 負責讓 AI Agent 與外部資料互動
• Identity、Authorization 與 Audit 負責回答「AI 到底能不能取得這些資料」

採用標準化協議帶來另一個好處：可替換性。模型可以更新，LLM 可以替換，Cloud Provider 可以更換，但建立在標準介面上的資料治理與 Identity 層不需要跟著一起換——這才是長期可維護的架構。

當 AI 開始能讀、能寫、能呼叫工具之後，Identity、Authorization、Audit 與 Policy 就不再是附加功能，它們本身就是 AI 系統的一部分，必須從架構最底層被設計進去。

療心智能（HealthyMind Tech）持續投入 Medical AI、FHIR、CQL、AI Agent 與醫療地端 / 混合式 AI 架構的研究與實作。

相關文章：FHIR R4 在台灣醫療的實際落地 ｜ Anthropic Skills 實戰：醫療病歷 Agent 的分層載入設計