（續前篇）
|
適合醫療器材及資訊安全產業界，具備大學教育背景的亞洲讀者。 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。後續修訂請查閱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（遠距醫療網路安全）
- 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 系統的通訊中斷，使患者無法接收即時血糖資料或警報。
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 管理流程，包括：
- 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）
- 緩解措施有效性驗證
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 |
沒有留言:
張貼留言