在医院中除了数据中心的服务器资源，还有医护人员、行政人员使用的电脑都需要纳入安全计算环境的管辖范围。大家可以看看自己用的电脑是否设置了密码，并且密码的要求是否符合强口令（长度大于 8 位，包含大小写字母、数字、符号，并且不包含键盘上连续字符或者英文单词），并且 3 个月更换一次密码。在 AAA 认证体系（ AAA 是认证（ Authentication ）、授权（ Authorization ）和计费（ Accounting ） ）中，第一关就是认证，在认证的过程中可能会出现如无认证、弱口令、认证可以被绕过、明文密码传输等等问题，

不仅仅是在医疗行业，基本所有行业的内网环境都包含了上述问题，在护网行动中，打入了内网环境后，大量使用重复的弱口令，成为被攻陷的重要问题之一，有很多护网的案例是拿下了堡垒机的弱口令，而堡垒机上直接记录了各类服务器的高权限账号密码，通过一点突破全网。我们大家可以看看自己的环境下， PC 和服务器端是否存在无认证、弱口令的情况，除了 RDP 、 SSH 等常见管理服务，还有 Radmin 、 VNC 、 SMB 、 FTP 、 TELNET 、 Oracle 、 MySQL 、 SqlServer ， 根据我一直以来的工作经验，很多开源软件的早期版本对于 API 接口就根本没有认证机制，所以还有很多的开源服务如 Redis 、 Docker 、 Elastic Search 等，有认证的情况下是否使用了开源软件的默认账户口令，这个也需要我们及时修改，黑客可以通过一点突破，层层收集信息，最终突破核心防线。

AAA 体系中的第二步授权，其实是可以缓解第一步问题的一个手段，理论上要求我们的 PC 端、服务器端不同的软件需要通过不同的用户安装、使用，并且不同的用户只能给予最小安装、使用软件的权限，而我们可以检查下自己的环境，应该是有很多直接使用 administrator 、 root 等用户，并且这些账号存在着复用的情况，在使用过程中很难分清楚现实生活中的哪个自然人使用了这个账户进行了相关操作，如果出现了问题给后续溯源提升了难度，我们这时就需要通过 IP 、 上层的堡垒机日志等进行关联溯源。

限制登录失败次数是防止暴力破解的手段之一，暴力破解会通过一个密码本对需要爆破的服务密码进行不断的尝试，直到试到正确的那个密码或者密码本试完为止，正常人登录一般都会记得自己的密码，当然在定期更换复杂密码的要求下，正常人也会记不住密码，这个问题我们后面再说。在限制了登录失败次数，比如我们设置了 5 次，那通过某个 IP 登录失败 5 次后这个 IP 就会被锁定，当然可以设置别的 IP 还可以登录这个服务。会话结束功能就类似于 W indows 自动锁屏，作为一个信息工作者，在我们离开电脑时就应该考虑锁屏的操作，并且重新登录要输入账号密码，一个不会超时的会话虽然方便了我们自己，同样也给恶意者带来了方便，想想经过你办公桌的每个人都可以在登录着的 HIS 服务器或者核心交换机上敲一个 reboot ，最后造成的结果可想而知，虽然这个事故不是你直接操作的，但也要负主要责任。

在医院中常见的远程管理手段有 RDP 、 SSH 、 TELNET 、 FTP 、 Oracle 等，其中 TELNET 、 FTP 在流量劫持时可以直接获得账户口令信息，可以通过 SSH 、 SFTP 等方法替换，确保在账号密码认证和数据流传输过程中都是加密的。其实 Oracle 的流量也非加密，在我咨询了我 OCM 的朋友和百度后，发现其实 Oracle 流量也可以配置加密，但是我们很少会这样做，并且很少会有人关心这个问题，还消耗客户端和服务端额外的性能。这时候我们就要想到什么时候我们的流量会被截取走，常见的就是内网 ARP 欺骗，一台攻击主机在客户端请求网关 MAC 地址的时候，将自己的 MAC 地址告诉客户端，说自己这个 MAC 地址就是网关的 MAC ， 这样二层的流量会先通过这台攻击主机转发给真实的网关，所有明文的流量过了这台攻击主机后就可以被它轻松的获取敏感信息，我的防护方法是通过桌管软件，将每个网段主机的网关 ARP 解析静态的写到客户端上，确保 ARP 解析时默认都先通过本地记录解析，从而不会被外部动态解析影响。另一种情况会被获取的是网内的流量设备，很多安全设备、 APM 监控设备、深度流量分析设备都需要抓取核心网络的流量，当这些流量被镜像给设备后它们会将它记录下来，而正式或者测试设备出现问题返厂时，我们就要叮嘱工程师要清空本地数据，以免数据泄露，在我的工作中就听到过通过安全设备泄露大量公民信息的案例。

前面我们说到要定期修改复杂密码，但是经常修改会导致管理员记忆困难，这个时候我觉得双因子认证也是帮助大家不用记复杂密码的好方法。双因素认证分为所知和所有两种，双因素的证据又分为秘密信息、个人物品、生理特征三种类型，像口令、密码就是信息，物理 key 就是个人物品，指纹、虹膜、面部就是生理特征，我们只要结合两种类型的证据，那就符合要求，可以通过物理 KEY+ 动态密码的方式实现认证，此时就不用记住原始的静态密码，大家可以想象一下现在在登录微信、支付宝、 QQ 等互联网软件的时候基本很少使用密码，而智能手机也将密码和人脸识别关联，方便大家认证操作，同时又符合安全要求。在医院工作的过程中，我发现很多业务系统的账号密码不是同一套体系，系统在认证时也没有做到双因子的要求，我之前写过一篇论文，叫《基于 4A 系统的医院零信任网络安全模型》，也是我希望能通过安全技术提升医护行政人员使用系统时的便利性、规范对医院所有系统账户体系管理、加强医院业务系统使用时的权限管理能力。

五级电子病历评审中提到了系统备份、容灾的标准，对医院信息系统的稳定性、可靠性、可用性有了明确的要求，医院信息系统的宕机、数据丢失会造成无法挽回的影响；2021 年《数据安全法》和《个人信息保护法》出台，我国在信息化高速发展的当下，更加重视了网络安全，证明了网络安全与信息化是一体之两翼、驱动之双轮。

2 、数据保密性

信息安全 CIA 三要素，保密性、完整性、可用性，这里提到了数据的保密性，其实不管在哪个行业，数据的保密性都很难做，我们可以看到大量的公民数据在互联网安全事件中泄露，我国之前的《网络安全法》对数据安全没有具体的要求，而 2021 年的《数据安全法》和《个人信息保护法》才对数据安全有了明确的要求，并且这两部法律给企业带来了不小改造的压力。

数据安全的保密性要求贯穿了数据的产生、传输、处理、存储、销毁等过程，首先我们要对数据进行保密，就要知道哪些数据应该保密，此时要做的就是数据的分类分级，在分级分类过程中涉及到对敏感数据的发现，敏感数据除了结构化的还有非结构化的，除了关系型的还有非关系型的，基本很难做到全覆盖，比如在护网期间就发现有很多日志、配置文件中带着敏感的账号密码等信息，而这些信息的配置可能是套装化软件不能修改的。在发现了敏感数据后我们就要对敏感数据进行加密、脱敏、去标识化操作，在五级电子病历的要求中也有一条数据加密的要求，数据加密其实有两种做法，一种是在存储层（通过存储设备进行加密），另一种在系统层（通过对操作系统的配置文件，或者对数据库的数据进行加密），第一种方法的难度较小，而第二种方法的难度较大，需要考虑数据被加密的方法和被使用过程中的解密，对于数据量小可以考虑非对称加密，而数据量大的只能使用对称加密，这也就是 SSL 的机制，通过非对称加密秘钥，然后通过秘钥对称加密数据流，在确保业务正常的情况下，实现安全的需求。针对脱敏、去标识化操作可以通过好几处实现，可以通过后端实现，也可以通过前端实现，通过后端实现时当数据从应用层往前端传输时就是去脱敏、去标识化的数据，甚至是在数据库中就是脱敏、去标识化的，而在前端实现，我们可以在客户端本地开启代理，直接可以获得明文的数据，从安全性来考虑肯定是后端实现更安全。

我们在做数据加密、脱敏、去标识化时要考虑的重要一点就是业务是否支持，有些数据虽然是敏感数据，但是以密文呈现时是无法进行正常业务的办理和交互的，如果要实现正常业务办理和交互，可能需要改变流程、规范，并且付出巨大的代价，在医院以业务为中心的情况下，个人觉得短期内很难很难实现，我个人在落地一个数据安全的产品时就提出了这样一个问题，该产品逻辑串联在数据库客户端和数据库服务器之间实现数据库字段的加密、脱敏、去标识化操作，而我们的 HIS 业务每天都有大量的问题要处理，在处理过程中需要通过这些敏感的数据进行确认、判断、修改，不可能专门安排一个人每天在对字段做解密、加密的操作，还需要配合专门的流程来规范这个操作，在一个业务系统没有稳定、技术人员缺乏的情况下，这样的功能很难落地，就算落地了也只是很小的范围，如何满足二者需要靠广大读者来帮忙想想办法了。

3 、 数据备份恢复

我问了很多医院，大家可能都建立了容灾环境，但是很少有医院做容灾测试，对于五级电子病历的要求是每年至少一次的容灾演练（还需要结合业务场景），每季度至少一次的数据全量恢复测试，一个没有测试过的容灾系统真的很难让人相信在出问题的时候可以撑得住真实业务，也许容灾的切换过程没有问题，但是容灾的硬件资源、硬件配置、软件调整等是否能让用户在较短的时间内进行边便捷的切换操，五级电子病历对于数据丢失的要求比较松， 2 小时以内即可，但是医院对于数据丢失是难以容忍的，对于信息化较长时间都无法正常使用也是无法容忍的，我们要尽可能做到 RPO 、 RTO 最小化。

对于备份，我尽量做到 321 原则， 3 份数据、 2 种不同介质、 1 份存于异地，结合第一点和第二点，我将数据存放于起码 2 种不同物理设备上，存储 3 份，再结合第三点将一份数据存储于异地，两份数据存于本地。我们医院有两个院区，两院区直线公里数其实小于 40 ㎞ ， 而等保的异地要求是直线大于 100 ㎞ ， 对于没有分院的小伙伴们，其实我建议可以将另一份数据存到异地云上，最起码在本地真的数据没办法恢复时还有一根救命稻草，虽然恢复的时间可能会长一点。我会将两院区的数据做相互的异地备份，尽可能提高数据备份的频率，减少数据的丢失，核心业务系统采用实时备份或者容灾的方式，在使用较高频率备份的情况下，我们对于备份、容灾的硬件就有一定的要求，较差的 HDD 盘是无法支撑起大数据量、高并发的备份任务，可能出现任务排队，那就会得不偿失；在备份上我们就出现过一个问题，之前工程师在配置 RMAN 备份保留的脚本操作是先删除原来的备份，在进行下一次备份，如果前一次备份删除了，后一次备份没有成功，那就没有了全量数据，这样的备份是没有意义的，大家可以检查下自己的环境是否存在这样的问题。

在备份的类型上，分为物理备份和逻辑备份， 21 年我就听到了别的医院出现了 Oracle 的逻辑坏块，出现坏块后数据库无法正常启动，而容灾系统通过 Oracle Data Guard 实现， DG 属于物理块同步，面对逻辑错误不会校验，而直接将这个逻辑错误同步给了容灾库，导致容灾库也无法正常拉起，并且当时也没有配置长时间的闪回空间，导致最后花了很大的代价才恢复了一部分丢失的数据，并且业务中断了很久，可以通过 OGG 解决这个问题，并且 OGG 可以支持跨数据库、操作系统类型之间的数据复制，但是配置难度比 DG 大了很多；另外的办法是通过 CDP 实现 IO 级别的备份，当出现逻辑错误数据库无法正常使用的时候，通过 CDP 的 IO 回退到正常的时间点，当然中间丢失的数据需要人工去弥补，这样通过数据库外部的方式解决数据备份的问题。

4、个人信息保护

这两点在《个人信息保护法》中也有明确提到，该法律中多次提到了收集个人信息要有“询问 – 确认”的过程，并且在用户不同意提供个人信息的情况下，不能拒绝对用户提供服务，只收集必需的个人信息，要告知用户收集每种类型个人信息的目的，告知用户如何处理、传递、使用个人信息。在疫情当下，全国的医院都紧锣密鼓的推广互联网医院，意味着有一个面向患者的医院互联网系统，患者可以直接面向这个互联网系统，那对系统的提交信息、问询交互有了更直接的了解，我们在做互联网系统的时候要结合《网络安全法》、《数据安全法》和《个人信息保护法》三驾马车来严格要求开发时的安全需求，自从三部法律上台后有多少互联网 APP 因不符合要求被责令整改、罚款、下架等，我们也该引以为戒。