医疗行业数据安全风险评估工作探讨三（2）

原创

草根老烦
草根老烦

老烦的草根安全观

2026年8月8日 10:00
广东

在小说阅读器读本章

去阅读

4.2 医疗业务调研和数据流图示例

4.2.1 医疗业务调研

业务识别是数据安全风险识别的第一步，数据不是自生产的，数据是为业务具体实现的重要支撑和条件，没有数据就没有信息化。数据安全风险评估的业务识别主要包括：

l 识别业务资产

l 识别业务交互条件

l 识别业务流

l 识别业务授权关系

业务资产识别主要通过圆桌会议、访谈、查看文件、端口扫描、穿行测试等手段。评估对象：系统开发商、信息科和相关业务部门。

表21 某医院涉及医患信息及医疗健康数据的业务系统列表

表21是某三甲医院涉及医患信息和医疗健康数据的业务系统，由于每个医院的业务不同，业务系统也不同，每个业务关联的子系统也可能不同。各个科室都可能具有自己的业务系统和业务前端，在复杂化医疗业务逻辑情况下，识别业务资产是建立整个风险识别的关键。这需要评估团队成员能够根据其对医疗行业的熟悉和了解，进行综合分析和客观判断。因此，在实际评估过程中，需要评估工程师根据各医院的实际情况进行调研和登记。

表22对麻醉临床信息系统进行深度识别，调研业务系统的构成和各个子系统的用途，这是建立麻醉临床信息系统数据流图的基础。该数据流图仅包含业务的内部数据流通，还应根据麻醉临床信息系统与其他医疗业务系统（如：HIS、LIS、EMR等）的数据交互，同时也需要考虑麻醉临床系统要把数据与谁共享，比如：CDR，SPD等

表22 麻醉临床信息系统分项表

医疗业务调研的关键是，不仅需要考虑业务系统内部的数据交互，还需要考虑业务系统之间的数据交互。根据数据之间的交互场景，基于取予关系建立数据流分析。

在本项调研中应通过以下思路开展工作：

1.明确识别边界。以评估对象中一项明确的业务作为识别的起点，如：HIS；

2.明确识别访谈对象。业务交互识别通常应以信息科作为主体，由HIS开发商进行补充和说明；本项中对于评估人员对医疗行业业务的熟悉程度非常重要，一般而言，参与过医疗机构运维工作的工程师是最佳人选；

3.明确识别的层次。先内后外，先业务后合规；先内后外是指先识别业务的院内关联，比如：HIS系统会和哪些业务系统建立数据交互，交互的目的是什么；交互是通过业务直接访问还是集约化平台转发；交互的取-予关系是怎么生成的；然后识别HIS的外部交互，比如：与监管机构、与数据合作方等；HIS在建立交互时是基于业务逻辑还是合规要求（如：数据要素和当地政策要求），业务逻辑是抽象机概念，需要解构功能和软件关系；而合规性是实体交易，应考虑是否符合《网络数据安全管理条例》《数据安全法》《个人信息保护法》相关要求，并与合作方有明确的合同约定等。

图28 业务流图示例

在识别业务流图中，更深入的做法是能够将每个业务系统执行业务交互的功能模块建立枚举，这种方法能够在后期建立业务授权分析的时候更加细粒和准确，但是，这样会增加评估周期和评估复杂性。通常而言，这些功能的定义应该被写在软件开发文档中。如文档未予描述，建议院方要求开发商补充该部分内容，或者在日常维护过程中建立识别和记录。

4.2.2 数据流识别

下图是一个虚拟的门诊挂号系统数据流图。首先根据业务流我们将门诊挂号流程逐一进行标注，并将门诊挂号数据进行简要标识；其次，根据数据字典，我们将每一个功能模块中需要对应的数据表、字段进行标注；第三，对数据的操作权限进行描述。

图28 虚拟门诊挂号系统数据流图

从图红色部分我们可以知道哪些组件调用怎样的数据，比如：认证服务器应只是获取账号和认证信息，并且该数据为一次性数据，完成认证后返回一个条件变量：T或者F，然后将认证提交数据清除。这时候，针对认证服务器的数据风险是数据的完整性，当认证服务器不保存认证关系表的时候，针对认证服务器的机密性攻击无效。进一步检查认证服务器，认证服务器是否长期存储用户的认证数据，他可能是基于断言标记语言的文本格式或者代码格式，也可能是基于生物识别的图片或图像转换的二进制数据。这时候我们需要对这些存储状态进行分析；如果认证服务器不是由院端提供而是使用第三方认证或者云认证功能时，需要访谈第三方机构。但此时无法对该服务器提供技术验证活动；

数据流识别应根据每个组件的地理位置（环境）、用途、授权能力等多种因素进行分析。

注：数据流识别的基础是数据资产识别，数据资产是数据安全风险评估的基础，数据资产识别和评估问题请参阅附录4。

4.3 医疗业务威胁建模示例及业务风险分析

4.3.1 绘制手术室麻醉系统的业务流图

首先我们构建一个医疗业务系统，比如：手术室麻醉临床信息系统：绘制业务架构图，并标注相关组件。

图29 手术室麻醉临床信息系统业务结构图

描述：

1. 手术室护士、医生将患者需要的麻醉状态数据根据医嘱输入系统并写入数据库；

2. 护士、医生通过终端访问数据将患者确认单通过本地打印机（有线链接）打印后将患者家属确认签字；

3. 护士通过终端对麻醉注射过程和数据进行监测

4. 医院数据科通过医院内网访问应用服务器获取报表；

4.3.2 识别可能影响数据安全的攻击向量

图30 威胁向量

描述：

1.威胁实体1 手术室医生/护士

a) 不良好的操作，包括未按规范执行操作、随意接入USB存储设备、不按规范填写参数等行为导致感染恶意代码、勒索病毒或错误指令造成终端或服务器中断运行，数据被锁定；

b) 误操作，包括错误的输入数据，导致数据异常产生的过量或未足量注入麻醉药物形成的患者高风险行为；

c) 恶意操作，操作人员因心理因素故意修改参数，产生的数据异常，导致患者生命危险；

2.威胁实体2 服务商

a) 误操作，包括误删除数据、误删除配置文件、误删除表文件、错误的配置账号权限、错误的开通网络通信，导致服务器故障、数据库死锁、数据不可用、业务中断

b) 越权访问，服务商在维护数据库系统的过程中恶意访问患者数据，拷贝患者数据等

c) 恶意操作，在维护期间通过自身的特权对数据库服务器的可用性、完整性和机密性的破坏，包括但不限于，拷贝、下载、删除、修改、增加、插入、批量处理等行为；

3.威胁实体3 信息科医务人员

首先应明确该实体访问授权，原则上该实体当且仅当具备的权限是读权限，故在分析威胁向量时，是建立在该条件之下；

a) 不当的披露：未经授权对患者数据在不同场合发布；

b) 级联故障：此处更恰当的描述应该是故障传递，即如果信息科访问终端被入侵或感染恶意代码，在缺乏有效边界防护的情况下导致手术室麻醉系统遭受同样的风险。

4.威胁实体4 接口（API）服务器

接口服务器是用来提供给HIS和院端其他系统写入或读取数据的接口端，其本质上不一定会直接参与麻醉活动，但可能会间接介入业务流程，如：计费、处方、检验检疫数据的汇总和读入等；

a) 过度授权访问：由于接口访问授权控制不当导致过量读取或恶意读取服务器数据；可能操作数据导致产生医疗事故；

b）级联故障：同威胁实体3b）

4.3.3 确定和实施缓解措施

1.威胁实体1

l不良好的操作：管理规范（P）、定义高危操作并针对高危操作执行二次授权或确认（P）、数据审计（D）；

l 误操作：同上

l恶意操作：法律意识及职业道德教育（P）、实时审计和事后跟踪审计（D）、身份唯一性（P）、最小权限（P）、数据监测（D）、异常响应措施（R）

2. 威胁实体2

l误操作，操作手册（P）、操作人员培训与教育（P）、管理规范（P）、操作审核（P/D）、二次确认原则（D）、应急响应手段（R）、备份（P）、业务连续性计划（R）、备份设备和备份系统（R）

l越权访问，最小权限（P）、访问审批（P）、单点登录（P/D）、多因素认证（D）

l恶意操作，同误操作与越权访问

3. 威胁实体3

l不当披露：管理制度（P），发布审核机制（P/D），数据安全立法教育和培训（P）、暗水印（D）、应急响应-危机公关（R）

l级联故障：主机保护（P）、边界隔离（P）、入侵检测-基于主机（D）、定期巡查（P/D）、日志（D）、应急响应（R）

4. 威胁实体4

l过度授权访问：API检测（D）、授权管理（P）、账号测试（D）、渗透测试（D）、定期漏洞扫描（D）、入侵检测（D）、数据流审计（D）

l级联故障：同威胁实体3-级联故障

说明：此处用到了美国NIST CSF框架中安全措施的定义，我们在构建控制措施时，针对数据安全不同属性关系分别通过P预防性、D检测性、R响应性手段来进行对应。在新的CSF 2.0中，将IPDRR扩展为G-IPDRR，即G-治理、I-识别、P-预防、D-检测、R-响应、R-恢复。在细化模型过程中，可以把威胁向量与ATT & CK结合，将建议对称与CSF对接，形成一种全面的威胁建模手段。

表23 手术室麻醉系统威胁建模向量图

4.4 医疗业务脆弱性分析

脆弱性也称为漏洞，GB/T 25069-2022 《信息安全技术 术语》中将其定义为“可能被一个或多个威胁利用的资产或控制的弱点。”我们可以基于定义理解脆弱性的问题。首先，脆弱性一定存在，但评价脆弱性需要对应威胁的可利用性；对于组织而言，组织更应该关注能够被确定的威胁所利用的脆弱性还不是全部。如何评价脆弱性，不是简单的基于脆弱性的危害程度，而是考虑由于受到环境因素、技术因素、管理因素所产生的对脆弱性的利用能力来综合评价。正如我们前面所看到的，由于来自外部的威胁恶意的外部人员可以利用数据载体应用服务器的漏洞入侵并控制系统，进一步通过提权后对数据进行了批量下载。对于组织而言，从数据安全角度进一步分析已有的控制措施：组织通过数据加密在能够很好的保护密钥的时候，攻击者即使获取数据，其机密性可以得到有效的维持，风险可接受，未构成社会影响和组织声誉的损害；从可用性而言，该次攻击是否能够通过已有的权限删除数据，如果具备数据删除权并构成事实，可用性风险不可接受，补偿手段，组织是否具备完善的备份和恢复能力，同时具备业务冗余的机制；如何具备，该风险不可接受，但风险可控制；

实际上，客观评价脆弱性在实际风险评估工作中很难实现，为每个脆弱性标签建立分析本身是一个非常复杂和庞大的过程。但是仅通过漏洞扫描、渗透测试、基线检查等技术手段获取并验证的脆弱性危害并不能真正反映组织的实际风险状态，反而会增加组织的安全恐惧感，进而产生庞大的网络/数据安全开销，当开销到一定程度后，组织产生对网络/数据安全的抵触，甚至仅仅为合规而建设，反而放弃了网络/数据安全的真正本质。

脆弱性分析请参阅4.1.2、4.1.3、4.1.4、4.1.5和4.1.6部分内容。

4.5 医疗行业风险分析综述

4.5.1 风险一

访问边界防护：未严格执行访问边界的端点控制，业务端应仅允许手术室终端和数据科分析终端可授权访问，但实际整个内网可访问该服务器。

风险：一旦内网病毒或勒索，会导致服务器受到影响；外部或内部恶意人员可以通过访问篡改数据，造成患者生命安全隐患；

建议：边界防护设备应通过白名单方式限制访问。针对系统应明确对麻醉数据的使用需求，严格约定数据的调用和处理，通过数据审计设备，对数据的读、写、删除、修改、更新以及插入等操作进行识别。审计应能够针对访问者当且仅当的唯一身份标签进行，同时对于高风险环境（如：互联网或通过VPN联入节点）和高风险用户（如：开发商、特权用户）的访问进行重点监控和审计。

4.5.2 风险二

存储未加密：麻醉临床信息系统所有数据均为明文存储，未对用户个人信息实施加密或去标识化处理；

风险：重要数据违反《数据安全法》未对存储数据进行加密；

建议：数据需要离开院端或者数据需要作为数据要素共享和发布时，应针对涉及患者健康信息和身份信息的数据进行脱敏或去标识化处理。如未来该系统需要向互联网提供访问途径，必须对相关数据进行加密存储；

4.5.3 风险三

数据库表结构性缺陷：

该系统数据库存在大量无效的表文件和字段，厂商提供数据字典共38张表863个字段，实际扫描数为12775个字段，760张表，大量无效表和字段会消耗数据库服务器性能和内存消耗问题；在实际38张表中，表ATM\_PAT\_VISIT疑似无效表；同时部分标准字段标注缺失；

建议：由于无效表在实际数据库承载时需要消耗服务器硬件性能，同时由于表交互关系不清晰，容易导致数据异常而产生的数据库崩溃，导致系统崩溃。开发商应对数据库中存在的无效表和无效字段进行梳理，并针对可能存在代码中的调用关系进行审计。避免产生系统违规调用或传输数据，导致患者敏感信息泄露。

建议：开发商、软件运维服务商对数据库制订优化方案，并针对可能发生的中断问题提供应急预案。

4.5.4 风险四

系统数据每天定时按增量执行备份，但尚未实施过回滚测试，以验证备份或备份介质是否可用。

建议：数据备份由于可能受到备份介质、备份技术或备份传输的影响，导致备份文件损坏或完整性破坏使得备份无效。备份介质应定期实施回滚测试，降低上述因素导致的备份数据损坏，影响组织BCP（业务连续性计划）失败。

由于备份增加了敏感泄露的途径，应针对备份技术要求其备份加密，并由专人管理备份密钥。

4.6 总结

医疗业务的复杂性和医疗信息系统的非统一性，使得医疗卫生行业数据安全风险评估难以通过模板式评估和工具化评估来完成。人工智能技术的使用可以提高评估工作的效率和准确性但无法替代传统风险评估的人力行为。因此，整个医疗卫生领域数据安全风险评估必须明确最终评估的目的和结果。