论文部分内容阅读
【摘要】 2020年是不平凡的一年，在此形势下互联网医院建设的必要性突显，分流就医人群、减少人际接触、减轻大型医疗机构压力，诸多优点推动“互联网+”在医疗行业的应用 。但互联网医院建设任务重、时间紧，部分医院基础薄弱，并且新型技术应用时间尚短，信息系统安全水平参差不齐，信息安全风险突出。 本文结合我院互联网医院建设经验希望为广大医院信息化工作者提供部分思路。
【关键字】 “互联网+” 互联网医院 建设 信息安全风险
一、概述
上海市卫健委积极探索发展“互联网+医疗”加快互联网医院建设，为患者提供部分常见病、慢性病复诊服务，指导患者有序就诊，缓解医院救治压力，减少人员集聚。鼓励取得互联网医院资质的单位，开展慢性病、常见病、多发病诊疗康复以及健康管理监测，并向公众提供防护科普等在线服务。在这样的背景之下，我院作为成立六十余年的综合性中医院，积极响应卫健委号召加快推进互联网医院建设。
互联网医院建设既涉及传统医疗流程的优化又涉及信息化改造，同时又对业务连续性要求、信息安全要求极高。本文站在医院网络系统管理者的角度，阐述在构建互联网医院过程中的一些思路。
二、互联网医院建设总体框架
互联网医院建设周期短时间紧，大部分同业单位选择在现有互联网业务系统基础上进行拓展，实现互联网医院的功能要求。在此我对行业内主流建设框架进行分析。
2.1云架构模式
此前医院便民业务系统大多采用云架构模式，依托于微信、支付宝等入口建设自己的小程序、服务号。此次互联网医院建设医院也选择采用此模式进行扩展，典型拓扑图如下。
互联网应用开发公司依托于阿里云IAAS服务，部署互联网医院应用系统，该系统采用SAAS模式开发具有多用户特性，可以依托于该系统为多家医院提供互联网医院服务。
医院通过开发公司采购互联网应用系统，取得账号使用权限，开发公司采用专线将云端系统于医院网络进行互通实现在线问诊。互联网医院大多具有三个入口，分别为患者端、医生移动端、医生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绿盟科技威胁通告中心
【关键字】 “互联网+” 互联网医院 建设 信息安全风险
一、概述
上海市卫健委积极探索发展“互联网+医疗”加快互联网医院建设，为患者提供部分常见病、慢性病复诊服务，指导患者有序就诊，缓解医院救治压力，减少人员集聚。鼓励取得互联网医院资质的单位，开展慢性病、常见病、多发病诊疗康复以及健康管理监测，并向公众提供防护科普等在线服务。在这样的背景之下，我院作为成立六十余年的综合性中医院，积极响应卫健委号召加快推进互联网医院建设。
互联网医院建设既涉及传统医疗流程的优化又涉及信息化改造，同时又对业务连续性要求、信息安全要求极高。本文站在医院网络系统管理者的角度，阐述在构建互联网医院过程中的一些思路。
二、互联网医院建设总体框架
互联网医院建设周期短时间紧，大部分同业单位选择在现有互联网业务系统基础上进行拓展，实现互联网医院的功能要求。在此我对行业内主流建设框架进行分析。
2.1云架构模式
此前医院便民业务系统大多采用云架构模式，依托于微信、支付宝等入口建设自己的小程序、服务号。此次互联网医院建设医院也选择采用此模式进行扩展，典型拓扑图如下。
互联网应用开发公司依托于阿里云IAAS服务，部署互联网医院应用系统，该系统采用SAAS模式开发具有多用户特性，可以依托于该系统为多家医院提供互联网医院服务。
医院通过开发公司采购互联网应用系统，取得账号使用权限，开发公司采用专线将云端系统于医院网络进行互通实现在线问诊。互联网医院大多具有三个入口，分别为患者端、医生移动端、医生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绿盟科技威胁通告中心