互聯網醫院建設中的信息安全思考

張國偉

【摘要】? ? 2020年是不平凡的一年，在此形勢下互聯網醫院建設的必要性突顯，分流就醫人群、減少人際接觸、減輕大型醫療機構壓力，諸多優點推動“互聯網+”在醫療行業的應用 。但互聯網醫院建設任務重、時間緊，部分醫院基礎薄弱，并且新型技術應用時間尚短，信息系統安全水平參差不齊，信息安全風險突出。 本文結合我院互聯網醫院建設經驗希望為廣大醫院信息化工作者提供部分思路。

【關鍵字】? ? “互聯網+”? ? 互聯網醫院? ? 建設? ? 信息安全風險

一、概述

上海市衛健委積極探索發展“互聯網+醫療”加快互聯網醫院建設，為患者提供部分常見病、慢性病復診服務，指導患者有序就診，緩解醫院救治壓力，減少人員集聚。鼓勵取得互聯網醫院資質的單位，開展慢性病、常見病、多發病診療康復以及健康管理監測，并向公眾提供防護科普等在線服務。在這樣的背景之下，我院作為成立六十余年的綜合性中醫院，積極響應衛健委號召加快推進互聯網醫院建設。

互聯網醫院建設既涉及傳統醫療流程的優化又涉及信息化改造，同時又對業務連續性要求、信息安全要求極高。本文站在醫院網絡系統管理者的角度，闡述在構建互聯網醫院過程中的一些思路。

二、互聯網醫院建設總體框架

互聯網醫院建設周期短時間緊，大部分同業單位選擇在現有互聯網業務系統基礎上進行拓展，實現互聯網醫院的功能要求。在此我對行業內主流建設框架進行分析。

2.1云架構模式

此前醫院便民業務系統大多采用云架構模式，依托于微信、支付寶等入口建設自己的小程序、服務號。此次互聯網醫院建設醫院也選擇采用此模式進行擴展，典型拓撲圖如下。

互聯網應用開發公司依托于阿里云IAAS服務，部署互聯網醫院應用系統，該系統采用SAAS模式開發具有多用戶特性，可以依托于該系統為多家醫院提供互聯網醫院服務。

醫院通過開發公司采購互聯網應用系統，取得賬號使用權限，開發公司采用專線將云端系統于醫院網絡進行互通實現在線問診?；ヂ摼W醫院大多具有三個入口，分別為患者端、醫生移動端、醫生PC端，分別對應了不同接診場景，當遠程視頻診療時可以選擇醫生PC端與患者交流。

2.2業務流程

2.2.1患者端

針對常見病以及慢性病患者在醫院完成初次診療，和醫生約定下次就診事宜。

患者使用微信關注醫院公眾號或使用支付寶關注醫院生活號進入互聯網醫院系統，進行患者綁定，綁定后患者通過互聯網醫院入口進行在線復診、預約掛號、發熱咨詢、報告查詢等服務操作。

2.2.2醫生端

醫生通過微信或支付寶進入互聯網醫院，使用身份認證信息登入互聯網醫院醫生端系統，接診患者醫生端可對患者歷史就診信息進行查詢。醫生可選擇通過醫生PC端通過終端計算機完成和患者的溝通以及藥品開藥操作。

2.3數據流

由于互聯網醫院建設過程中每家醫院選擇的建設模式存在差異，在此我大致分為兩個類型，數據云端落地模式和數據云端不落地模式。

2.3.1數據云端落地模式

在該模式下，互聯網醫院開發公司SAAS云服務數據庫中將保存患者的部分就診信息，以及患者通過互聯網醫院向醫院his服務器請求的數據信息。

2.3.2數據云端不落地模式

應用醫院本地落地模式即SAAS服務模式僅作為入口，當患者點擊互聯網醫院標簽時，此時訪問到的互聯網醫院系統為醫院DMZ區域服務器，數據流程與落地模式類似但數據并未在SAAS開發公司系統數據庫中留存，所有信息數據均保存在醫院服務中。

2.4小結

通過互聯網醫院建設總體框架分析我們可以看到，互聯網醫院建設進一步打破了醫院的互聯網邊界，同時內部核心系統與互聯網數據交互進一步加強，并且互聯網醫院建設對云服務模式進行了深化。

三、互聯網醫院風險分析

3.1安全保護責任

互聯網醫院采用SAAS服務模式建設，再次模式下不同參與者承擔的安全保護責任也不同。

該模式下主要有三個角色：

云服務提供商：該角色為阿里云、聯通云等云基礎資源提供商，該提供商承擔IAAS層安全防護責任。

SAAS服務提供商：該角色往往租用阿里云等云資源提供商的云環境，部署數據庫、應用軟件等平臺，再將SAAS賬號出售給對應醫院，該角色承擔的安全防護責任為操作系統、數據庫、應用程序。

醫院：為最終用戶方購買SAAS服務提供商的服務，并將處于內網的業務系統和云系統進行對接，該角色承擔的安全責任為對接的數據部分，以及可操作數據部分。

3.2 SAAS架構分析

參照上文拓撲圖，該圖為典型的SAAS架構圖，目前上海大部分互聯網應用開發公司均采用該架構設計，從該圖可以看到為實現資源利用率最大化，SAAS應用開發公司采用一套系統為多家醫院提供互聯網醫院服務。

3.3 風險分析

在此我結合我院互聯網醫院建設過程中的經驗對當前互聯網醫院風險進行總結如下。

3.3.1 SAAS服務商風險

在SAAS服務模式下風險來源主要為SAAS服務提供商總結風險如下：

應用軟件風險，服務商如對自身軟件測試不足，導致應用軟件存在高風險漏洞。

網絡架構風險，無法保證其他業務系統與互聯網醫院系統相互隔離，承載我院服務的系統可能面臨橫向攻擊風險。

安全計算環境風險，在SAAS服務模式下應用開發公司對安全計算環境負有保護責任，現階段應用開發公司并未能提供操作系統以及數據庫的安全防護措施說明，也未對處于同一環境中的不同用戶之間數據隔離控制提供說明。

安全運維管理風險，數據存儲于SAAS應用開發公司服務器中，當該公司人員安全意識薄弱或技能水平薄弱的情況下直接對用戶數據造成危害。

3.3.2醫院安全風險

SAAS服務模式下醫院的風險來源主要為SAAS應用提供商帶來的間接風險。

合規風險，當前互聯網醫院承建開發公司，無法提供基于SAAS的等級保護測評報告。

數據風險，隨著《個人信息安全保護規范》正式版的實施以及《數據安全法》草案的征求意見稿頒布，數據安全成為我院不可忽視的法律風險來源，當前互聯網醫院數據流經SAAS服務提供商的網絡環境，數據泄露途徑的界定成為難點，數據存在泄露風險。

3.4小結

對系統整體安全性的把控受制于SAAS開發公司，其系統的安全程度決定了我院數據的安全現狀，互聯網醫院建設我院處于非常被動的局面，如何將風險降至最低成為我們需要思考的難題。

四、實踐落地方案

SAAS服務模式的應用由于其特殊性，醫院喪失了大部分的安全防控把控能力，在此基礎上結合我院現有網絡安全建設情況，我針對互聯網醫院進行了針對性優化，在此供各位同業人員參考。

4.1加強本地網絡安全建設

4.1.1分層邊界防護

雖然互聯網醫院模式打破了常規的邊界概念，但邊界防護仍然為建設中的重點，參考縱深防御思想以及零信任思維，將每個應用設想為獨立網絡，進行邊界防護建設。

我院互聯網醫院基于web模式開發所以，首先在DMZ區域與云端專線中加入web應用防火墻，重點對web應用防火墻策略的細化。其次在DMZ區域與內網區域通信鏈路中網閘到內網方向，增加一臺web應用防火墻，并且與邊界web應用防火墻采取異構策略，通過針對性策略優化。再次在HIS等核心系統區域邊界部署數據庫防火墻，由于互聯網醫院請求到內網經過協議轉換最終變為數據庫請求數據，我院針對該部分請求使用數據庫防火墻進行防護，對異常數據庫請求進行過濾和告警。

4.1.2區域隔離

由于我院DMZ信息系統眾多，且業務范圍不同，不同的業務系統面臨的威脅也不盡相同，不同防護需求的系統之間安全隔離尤為重要。

互聯網醫院系統受眾群體廣泛作為我院攻擊面最廣的信息系統，我院在DMZ區域劃分多個邏輯區域，將受眾面不同的信息系統進行了隔離，采用下一代防火墻作為邊界隔離和防御手段，不同區域有限通信，并開啟防火墻IPS防護策略，防止某一系統被攻破造成更大范圍的損失。

4.1.3感知措施建設

傳統邊界防御設備均基于特征庫進行威脅識別，仍然存在被繞過風險，我院在內網感知層面進行針對性加強保護。

外網部分采用態勢感知與日志審計相結合，態勢感知針對來自互聯網醫院端的請求進行分析告警;對位于DMZ區域的前置機留存的應用請求日志進行收集和分析，并制定告警規則。我院規則制定的思路為，模擬黑客人員對系統進行攻擊，同時日志服務器收集前置機中的日志數據，從中尋找攻擊痕跡，并將該指紋添加到日志服務器報警規則中。

內網感知部分，我院采取異構策略部署有態勢感知系統，并采用日志審計系統、數據庫審計系統進行日志審計，策略收集方式與上述方法一致，發現層層過濾后仍然傳遞到內部網絡中的惡意攻擊日志指紋，依據該指紋優化各個邊界防御設備，對優化后仍然無法阻斷的攻擊日志加入到日志告警策略中。

4.1.4安全計算環境增強防護

互聯網醫院在本院的服務器有外網前置機以及內網前置機，以及附屬協議轉換系統服務器。

基于安全分析發現，攻擊者對互聯網醫院的攻擊數據會流經上述服務器，且部分服務器經過解析后可發現惡意腳本，故我院針對上述服務器加強了主機防護建設，采用主機防御系統感知寫入磁盤的文件是否包含惡意腳本。

由于攻擊者獲取到webshell后會進行提權操作，然后利用代理進一步滲透內網攻擊，在主機端部署安全防御系統可以發現操作系統異常代理數據包，并進行報警。

4.2加強云模式防護

4.2.1云防護措施建設

經過對SAAS服務模式的深入分析，該模式存在的弊端非常明顯，如何增強該系統的整體防護能力，成為擺在我院信息化同事們面前的一道難題，經過多方調研后，我院采取購買云服務的模式對我院移動端業務入口增加一道云防護系統，利用該系統將移動端產生的數據包從云端進行以此過濾，減少攻擊數據包流入網絡中的可能性;利用云防護系統的防篡改機制補充我院防篡改措施缺失的短板，同時利用應用監控服務實現對我院互聯網醫院系統可用性、網絡延遲的監控。

云防護系統的加入是在現行機制下我院增強邊界防護的唯一選擇。

4.2.2云審計措施

我院在互聯網醫院建設中對等級保護2.0中SAAS擴展要求條款進行分析，向服務商提出云審計要求：

第一向我院提供我院互聯網醫院系統的詳細應用訪問日志，且該日志僅允許我院人員訪問，且對該審計日志進行保護，我院具有對該日志的控制權;

第二向我院提供涉及我院數據操作的數據庫日志查詢賬戶，該日志僅允許我院人員訪問，且該日志需包含開發公司人員對院日志的操作日志，我院對該日志具有控制權;

第三向我院提供針對我院互聯網醫院系統相關的其他所有審計數據，該數據僅允許我院人員訪問，我院對該日志具有控制權。

4.2.3云服務商管理

我院在互聯網醫院建設中要求云服務商提供證明其具有安全運維能力的相關證明包含以下幾點：

公司資質信息需包含安全開發資質以及信息安全相關資質。

內部相關管理制度需包含安全運維、崗位設置、安全開發、項目管理等。

人員資質證明，服務于我院互聯網系統相關開發和運維人員應固定，建立的項目組需經過我方人員審批，項目途中不得更換人員，且在必須更換人員時需經過我院同意，更換的人員能力水平不得低于前者。

需定期向我院提供涉及我院互聯網醫院部分，人員運維記錄數據。

互聯網醫院涉及升級和改版前應向我院進行報備，經過我院同意后方可實施。

建立供應商評分制度，定義由供應商引發的安全事件類型以及扣分機制，并將該數據添加如合同中。

4.2.4法律規范

我院針對《數據安全法》、《個人信息安全保護規范》組織解讀，依據相關條款與互聯網醫院開發公司簽訂具有法律效力的協議，大致內容如下：

明確互聯網醫院數據信息收集范圍，開發公司方落地數據范圍。

明確開發公司數據安全保護責任。

開發公司對數據安全保護義務做出承諾。

開發公司對數據不得發送第三方做出承諾。

開發公司對數據未獲得我方許可前不得進行任何操作包含讀取操作。

開發公司應協同我院制定面向患者的個人信息防護承諾協議，并承擔協議中的法律風險。

開發公司應對誠實守信義務做出承諾。

開發公司對其人員的非法行為承擔連帶責任。

法律規范要求并非以轉移風險為目的，該協議制定的目的為使開發公司重視自身安全管理，方式由于內部人非法行為造成我院乃至我院患者的損失。

4.3引入第三方評估單位

在信息化建設過程中我院暴露出自身人員不足，專業能力不足等問題，在本次互聯網醫院建設中我院引入第三方安全服務公司，保證我院信息系統建設在上線前經過安全測試，不帶病上線，落實我院內部網絡IP+端口級訪問控制。

五、結束語

醫院網絡安全建設任重道遠。本文通過對我院互聯網醫院建設中暴露的問題以及最終解決方案的分析。也提出了一套比較宏觀的建設思路，供各個醫院參考借鑒。由于各個醫院情況不盡相同，所以文章觀點可能不適用于所有醫院，讀者酌情參考采納。

參? 考? 文? 獻

[1] 《信息安全技術 個人信息安全規范》GB/T 35273-2020

[2] 《信息安全技術網絡安全等級保護基本要求》GBT22239-2019

[3] 《云計算架構技術與實踐》清華大學出版社-顧炯炯

[4] 云計算安全技術要求第4部分：SaaS安全技術要求CSA0001.4—2016

[5] 《關鍵信息基礎設施安全保護條例（征求意見稿）》

[6] 《中華人民共和國數據安全法（草案）》

[7] https：//ti.qianxin.com/blog 奇安信威脅情報中心

[8]https：//www.nsfocus.com.cn/html/2020/39_0903/966.html綠盟科技威脅通告中心