連續血糖監測系統 (CGM)符合資訊安全條例模擬（五之二）

 （續前篇）

適合醫療器材及資訊安全產業界，具備大學教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱ISO與歐盟官方網站、洽詢各家驗證公司、諮詢顧問等。CC BY-SA 4。0。

3.2法規架構分析

歐盟對於醫療器材的法規架構日益完善，特別是在網路與資訊安全方面，MDR (EU 2017/745) 與 CSA (EU 2019/881) 共同構建了一套嚴謹的符合法規系統。對於 CGM 系統製造商而言，理解這兩大法規的交織影響至關重要。

醫療器材法規 (MDR, EU 2017/745) 的網路與資訊安全要求

層級一：MDR 附件 I 中的「一般安全與性能要求」(GSPRs) 明確指出，醫療器材必須在整個生命週期內確保其安全與性能，其中多項 GSPRs 直接或間接與網路與資訊安全相關：

• GSPR 14：軟體設計與開發：要求軟體必須按照現今技術水準進行設計與製造，並考慮到網路與資訊安全風險。這意味著製造商需採用結構化的軟體開發生命週期 (SDLC)，並整合本質安全設計原則 (Security by Design)。
• GSPR 15：網路與資訊安全與資料保護：這是 MDR 中最直接的網路與資訊安全要求，強調器材必須具備抵禦未經授權存取、資料洩露、系統損壞或篡改的能力。對於 CGM 系統，這包括患者資料的加密、存取控制、以及防止惡意軟體攻擊的措施。
• GSPR 16：與其他器材的交互操作性：若 CGM 系統需與其他醫療器材或資訊系統互動，則必須確保此種交互操作性不會引入新的網路與資訊安全風險。標準化的介面與安全的通訊協定是關鍵。
• GSPR 17：電子資料處理與行動應用程式：針對涉及電子資料處理或行動應用程式的器材，MDR 要求其設計應確保資料的機密性、完整性與可用性。對於具備行動應用程式的 CGM 系統，這涵蓋了應用程式的安全開發、更新機制及使用者身份查證。

層級二：調和標準（Harmonised Standards）

• EN ISO 14971:2019+A11:2021（風險管理應用在醫療器材）
• EN IEC 62304:2006+A1:2015（醫療器材軟體生命週期流程）
• EN IEC 62366-1:2015+A1:2020（可使用性工程應用在醫療器材）
• EN ISO 13485:2016（醫療器材品質管理系統）

層級三：現今技術水準（State of the Art）

• IEC 81001-5-1:2021（健康軟體與IT安全，2025年DOW）
• ETSI EN 303 645:2020（消費性IoT網路安全）
• ISO/IEC 27001:2022（資訊安全管理系統）
• ISO/TS 6268-1:2025（遠距醫療網路安全）

層級四：國家指引（National Guidance）

• BSI Germany: CRA Guidance（雖排除醫療器材，但技術控制可參考）
• ANSSI France: Medical Device Cybersecurity Recommendations醫療器材網路與資訊安全建議內容

歐盟網路與資訊安全法案 (CSA, EU 2019/881) 的驗證法規

CSA 旨在建立一個全歐盟統一的網路與資訊安全驗證法規，透過制定具體的驗證方案 (Certification Schemes)，提升 ICT 產品、服務和流程的網路與資訊安全水準。ENISA 負責制定該等方案，目前已發布 EUCC (基於 Common Criteria) 方案，並正在開發 EUCS (雲端服務) 和 EU5G 等方案。

儘管目前尚未有專為醫療器材設計的 ENISA 驗證方案，但 EUCC方案對於高風險的 ICT 產品（包括醫療器材中的軟體和硬體組件）係為高度相關性。製造商可透過自願性地取得 EUCC 驗證，向市場證明其 CGM 系統具備高水準的網路與資訊安全保障。這不僅能提升產品的市場競爭力，也可能成為未來 MDR 符合法規的強而有力之間接佐證。

4.風險評鑑與器材分級

有效的風險評鑑與管理是醫療器材網路與資訊安全符合法規的基礎。製造商應根據 EN ISO 14971:2019+A11:2021 標準，建立一套全面的風險管理流程，並將MDR 附錄I (GSPRs) 網路與資訊安全各類風險納入考量。

醫療器材分級Class IIb（Rule 10 & Rule 12）

• Rule 10：用於監測或控制治療給藥的主動式器材（CGM監測人體血糖並連接AID系統）
• Rule 12：用於給藥或移除藥品的主動式器材（間接影響決定胰島素輸入及注射量）
• 理由：CGM器材連接生命維持/生命支持系統（AID），網路安全失效可能導致嚴重傷害或死亡

網路與資訊安全風險識別與評估

網路與資訊安全風險等級：高風險（High Risk）
對於 CGM 系統，潛在的網路與資訊安全風險包括但不限於： 

• 連接生命維持/生命支持系統（AID）：網路安全失效可能導致嚴重傷害或死亡資料洩露：患者的血糖資料、個人身份資訊等敏感資料可能被未經授權的存取、竊取或篡改。
• 器材功能受損：惡意軟體或網路攻擊可能導致 CGM 系統無法正常運作，影響血糖監測的準確性，甚至造成錯誤的治療決策。
• 遠端控制濫用：若 CGM 系統具備遠端控制功能，惡意行為者可能利用漏洞進行未經授權的控制，對患者造成傷害。
• 供應鏈風險：第三方軟體元組件、雲端服務供應商或硬體供應商的漏洞可能被利用，進而影響 CGM 系統的安全性。
• 拒絕服務攻擊 (DoS)：攻擊可能導致 CGM 系統的通訊中斷，使患者無法接收即時血糖資料或警報。

製造商應對該等風險進行系統性地鑑別、分析和評估，考慮其發生的可能性 (Probability) 和嚴重程度 (Severity)，並根據攻擊與危險程度之相應的風險等級，制定適當的控制措施。

ICT 相關風險與器材分類

隨著 CGM 系統日益依賴資訊與通訊技術 (ICT)，其 ICT 相關風險也隨之增加。這包括軟體漏洞、通訊協定弱點、雲端基礎設施安全等。製造商應特別關注 IEC 81001-5-1:2021 等網路與資訊安全性標準，該標準提供了健康軟體和 IT 安全在產品生命週期中的活動指引，有助於系統性地管理 ICT 相關風險。

在器材分類方面，MDR 根據醫療器材的風險等級將其分為 Class I、IIa、IIb 和 III。CGM 系統通常屬於 Class IIb，這意味著其網路與資訊安全要求將更為嚴格，需要更全面的風險管理和符合法規證明。風險評鑑應考慮網路與資訊安全事件對患者健康、資料隱私和系統功能的潛在影響，並確保所採取的控制措施與器材的風險等級相符。

應對新興風險

網路與資訊安全威脅不斷演進，製造商需建立一套前瞻性的風險管理機制，以應對新興風險，例如： 

• 人工智慧 (AI) 相關風險：若 CGM 系統整合 AI 功能，需評估 AI 模型可能存在的偏見、資料投毒或模型篡改等風險。
• 量子計算威脅：雖然目前尚未普及，但製造商應開始關注量子計算對現有加密技術的潛在威脅，並規劃未來的加密升級策略。
• 物聯網 (IoT) 安全：若 CGM 系統作為醫療物聯網 (IoMT) 的一部分，需考慮其與其他 IoT 器材互聯時可能引入的未知風險。

持續的威脅監控、漏洞管理和安全更新機制是應對新興風險的關鍵措施。

5.設計開發過程演進

醫療器材的設計與開發過程是確保其網路與資訊安全性的關鍵環節。製造商應將網路與資訊安全視為產品生命週期中不可或缺的一部分，從概念階段就開始融入安全考量，並持續貫穿整個設計、開發、測試、上市後監控及維護階段。這不僅符合 MDR 的要求，也是實踐「資訊安全設計」(Security by Design) 和「預設資訊安全」(Security by Default) 原則的體現。

5.1設計計畫與安全整合

製造商應制定一份詳盡的設計計畫，明確定義 CGM 系統的網路與資訊安全目標、需求和查證方法。這份計畫應涵蓋：

• 威脅建模 (Threat Modeling)：在設計早期識別潛在的網路與資訊安全威脅和漏洞，例如使用 STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) 等方法。
• 安全需求規範：將識別出的安全風險轉化為具體的安全需求，並納入設計輸入。
• 安全架構設計：設計具備分層防禦、最小權限原則、安全通訊和資料加密等特性的系統架構。
• 安全編碼指引：制定並遵循安全的編碼實踐，以減少軟體漏洞。
• 安全測試計畫：規劃單元測試、整合測試、系統測試和滲透測試等，以查證安全需求的實現。 

5.2.1威脅建模（STRIDE方法）概述

威脅類別	具體威脅情境	風險等級	現有控制	需強化措施
欺騙（Spoofing）	攻擊者偽冒合法CGM發送虛假低血糖數據，導致AID過量輸注胰島素	極高	BLE配對加密	實施雙向認證、設備綁定
未經授權存取 (Access Control)	大規模患者數據洩漏 (GDPR 違規)	極高	傳輸層加密	多因素認證 (MFA) + 角色權限管理 (RBAC)
篡改（Tampering）	攔截並修改傳輸中的血糖數據	高	AES-128加密	升級至AES-256、增加訊息認證碼（MAC）
資訊洩露（Information Disclosure）	未授權存取患者健康數據（PHI）	高	傳輸層加密	靜態加密、存取控制、匿名化
拒絕服務（Denial of Service）	干擾BLE訊號導致CGM與AID通訊中斷	高	頻道跳躍	干擾偵測、自動重連、備份警報機制
否認（Repudiation）	使用者否認曾接收警報導致延誤治療	中	本地日誌記錄	不可否認的審計軌跡、雲端備份
中間人攻擊 (MITM)	醫療紀錄被竄改/洩漏	中	本地日誌+伺服器記錄	雙向 TLS 認證 + 強制 HTTPS 傳輸
權限提升（Elevation of Privilege）	利用API漏洞取得管理員權限	中	API金鑰驗證	OAuth 2.0、範圍限制、速率限制

5.2.2ICT相關風險矩陣

(圖5.2.2)

5.2.3軟體物料清單 (SBOM) 與漏洞管理

軟體物料清單 (Software Bill of Materials, SBOM) 已成為醫療器材網路與資訊安全管理的核心工具。需符合以下標準：

• SPDX（Software Package Data Exchange）ISO/IEC 5962
• CycloneDX（OWASP標準）
• SWID Tags（ISO/IEC 19770-2）

一份完整的 SBOM 應詳細列出 CGM 系統中所有商業、開源和內部開發的軟體元組件名稱及其版本、供應商資訊、授權資訊（SPDX License Identifier）、雜湊值（SHA-256）、已知漏洞（CVE ID）、依賴關係樹及生命週期狀態（Active/End-of-Life）。

製造商應建立一套自動化或半自動化的 SBOM 管理流程，包括：

• SBOM 生成與維護：在軟體開發過程中持續生成和更新 SBOM，確保其準確性和時效性。

【方案 A：定期產出靜態 SBOM (CycloneDX 格式)】或
【方案 B: 建立動態 SBOM，與 CVE (通用漏洞披露) 資料庫實時對接】；

• 漏洞掃描與分析：定期對 SBOM 中的組件進行漏洞掃描，並與國家漏洞資料庫 (如 NVD) 或其他威脅情報來源進行比對，識別潛在的已知漏洞。
• 漏洞評估與修復：對識別出的某組件漏洞進行風險評鑑，快速判定其是否影響 CGM 實體功能，並根據其嚴重性和潛在影響制定修復計畫，避免不必要的恐慌性召回。對於無法立即修復的漏洞，應實施緩解措施並進行追蹤。
• 供應鏈透明度：要求第三方供應商提供其軟體元組件的 SBOM，以確保整個供應鏈的網路與資訊安全透明度。

實施步驟與時程規劃：

1. 2026 Q2：導入自動化SBOM生成工具（如FOSSology、Syft、CycloneDX工具鏈）
2. 2026 Q3：建立軟體組成分析（SCA）流程，持續監控漏洞
3. 2026 Q4：整合至CI/CD管道，每次建置自動生成SBOM
4. 2027起：每季更新技術文件中的SBOM，重大漏洞72小時內評估影響

然而，SBOM 的有效管理並非易事。對於包含器材韌體和行動應用程式的 CGM 系統，其更新頻率和複雜的依賴關係使得維護動態且準確的 SBOM 成為一項重大挑戰。製造商需要投入專門的設備、工具和技術人員進行 SBOM 生命週期管理，解決依賴衝突，並在整個供應鏈中強制執行 SBOM 要求，這需要大量的組織層面廣泛地多方協調和持續性資源投入。

5.2.4 威脅建模精進

採用Microsoft STRIDE與MITRE ATT&CK for ICS/IoT框架，每半年更新：

• 新興威脅情報整合（ENISA年度威脅報告、FDA安全通報）
• 攻擊路徑分析（Attack Tree）
• 緩解措施有效性驗證

階段三：優化認證期（2029-2030）

5.2.5 網路安全驗證準備（Plan B）

認證項目	標準/方案	預估時程
ISO/IEC 27001資訊安全管理	第三者驗證機構稽核(TÜV, DEKRA, BSI, SGS)	2029 Q1-Q2
醫療器材網路與資訊安全驗證	ENISA認可方案（待發布）	2029-2030
共通準則Common Criteria（選項）	ISO/IEC 15408 EAL2+	2030 Q3-Q4

（未完、待續）