外對內
掛號、查詢、繳費 API 的驗證失效與資料過度暴露
病歷正在 API 化
攻擊面也一起變大
Medical API Security
新一代 HIS、衛福部 FHIR 電子病歷調閱與醫療 AI／LLM，讓 PHI 經由 API 移動。UTDS 在院內封閉網路盤點暴露、偵測未知威脅，旁接不插入臨床交易路徑。
Why now
醫療業現在的四個壓力
-
HIS
HIS 全面 API 化
院內服務、行動應用與第三方介接暴露面急速擴大。
-
FHIR
FHIR 跨院互通
電子病歷即時調閱讓 API 流量與資料敏感度同步上升。
-
AI
醫療 AI／LLM 爆發
影像辨識、輔診與諮詢大量依賴 API，出現傳統設備無感的新通道。
-
PHI
病患個資最高機密
外洩意味監理通報、法律責任與信任崩解，後果不可逆。
Three-way risk
外對內／內對內／內對外
內對內
HIS 模組互叫造成橫向移動與過大權限
內對外
第三方介接、Webhook 與影子 API 成為 PHI 外送通道
Emerging threats
醫療 AI 帶來的新暴露面
-
LLM Injection
前後端互動中未被移除的隱藏通道，可能改寫模型護欄與輸出。
-
後門 API
除錯用 hard-coded 指令上線後，成為僅攻擊者知道的通道。
-
供應鏈中毒
受污染套件經 API 介接執行，常無 CVE、無特徵碼。
-
影子 API 與授權失效
未列管端點、過期 JWT 與越權，長期被用來下載病歷與交易紀錄。
Compliance
對應醫療業 API 安全規範重點
FHIR 傳輸需遵守電子病歷管理辦法與個資法。UTDS 可協助落實使用監控、異常行為檢測、完整日誌與事件回應的技術證據；合規結論仍由機構制度與整體控制決定。
-
API 使用監控
請求次數、方向、方法與頻率，按 Host／Path 持續盤點。
-
異常行為檢測
多維度行為分析，補 WAF 對零時差與變形攻擊的盲區。
-
日誌與事件回應
時間戳、來源／目的、URI、原始攻擊資料，並可 Replay 驗證。
FHIR API Security
SMART／OAuth 是起點，
不是終點
HL7 要求正式環境全程 TLS，並以 SMART on FHIR 做 OAuth 範圍控制。實務破口多半是合法 token 讀錯病人（BOLA）、過寬 scope、硬編碼金鑰與未列管的 /fhir、$everything 匯出。
| 規範要求 | UTDS 可提供的證據 | 仍須院內／HIS 完成 |
|---|---|---|
| TLS + OAuth 2.0／SMART | 辨識 JWT／OAuth／OIDC 與過期 Token | 授權伺服器發短命、最小 scope 的 token |
| 角色與物件層授權 | 盤點對外／院內／外送路徑與異常呼叫 | FHIR server 對 Patient id 逐筆授權 |
| API 監控與異常偵測 | 七大分類盤點、多維度行為分析、WAF 漏接 | 訂定正常臨床流量基準與通報流程 |
| 日誌與事件回應 | 原始攻擊資料、關鍵字、Replay、SIEM 黑名單 | AuditEvent 保存與通報義務 |
| PHI 最小化 | 中文 PII／病歷識別欄位暴露偵測 | Response 遮罩與同意書政策 |
FAQ
醫療業常見問題
如何強化醫院評鑑與資料安全查核的 API 應答？
醫院評鑑與資料安全查核（含電子病歷管理辦法、個資法、FHIR／TW Core）越來越關注 API 使用監控、異常行為檢測、完整日誌與事件回應。UTDS 以旁接持續盤點 API 資產、辨識 PHI 暴露、對應 OWASP API Top 10 與 CVSS 分級，並輸出自動化報表與可下鑽證據，協助把「有監控、有異常偵測、有可追溯紀錄」做成可出示的技術材料。
會不會影響 HIS 或檢查流程？
採旁接，不串進應用交易路徑。鏡像／SPAN 方案複雜度最低，適合先做盤點與偵測。
院內不能連外，模型怎麼更新？
AI 預訓練完成，封閉環境即可運作，不必連雲端更新特徵碼。
