安全运维上 ，盛京医院使用专门的工具 ，一方面将数据库、系统、机房等设备全面监控 ，实时监控运行情况 ，这也有效减少了复杂性工作。
另一方面 ，在出现安全故障时也可以通过中台直接定位到问题设备 ，省去排查时间。与此同时 ，异常出现时平台将根据严重程度匹配警告方式 ，包括邮件、短信、紧急电话响应等。
权限问题上 ，盛京医院为所有运维人员配备了USBkey。这种安全钥匙人手一枚 ，各自内置了不同的安全密匙 ，在USBkey得到授权后 ，才能对医院数据库做进一步访问。
这就好像胸牌一样 ，USBkey+免密登录的模式为医院数据库建起了大门 ，通过刷卡进“门”、授权到人的方式防止密码泄露。
攻击预防上 ，往往医院端做安全防护比较困难。全宇透露 ，很多情况下 ，我们不敢去给相关的产品打补丁 ，因为我们不知道这些数据库系统的特性 ，这很有可能导致整个平台直接宕机。
况且 ，医院的数据库产品种类繁多 ，这就像是一个人的人体 ，随意哪个部分被更换了 ，都有可能造成另外一个关联部位的病变。
产品上 ，采用数据库攻击预防+虚拟补丁的方式解决问题：
首先 ，允许该安全平台访问数据库的SQL操作 ，全部解析还原 ，匹配策略规则。一旦发现漏洞 ，就用虚拟补丁的方式完成修复。
采用虚拟补丁的好处是 ，不需要为数据库修复漏洞 ，不影响数据库系统稳定性 ，不需要停止数据库服务以及不需要进行回归测试。
上述特点 ，极大程度降低了医院数据安全保障的成本 ，避免安全防护期间一些不必要的问题出现。
容灾问题上 ，全宇觉得这是给医院数据上的一道“锁”。尽管目前为止容灾安全的保障措施并未被激发过 ，但对于盛京这样的大医院来说 ，攻击者是有利可图的 ，因此也要做好防护。
灾备平台可以用Oracle的小型机做到日志同步 ，这可以有效防止存储级逻辑错误。
比如存储层面的双活或镜像 ，数据块发生了逻辑错误 ，坏的数据无法被检测到 ，导致所有的数据无效。通过数据库日志同步方式 ，保障应用级别的数据一致性 ，抵御底层错误地传播。
面对大字段问题 ，该灾备平台通过采用物理复制的灾备技术手段 ，尽可能避免这种情况出现 ，而对于医院来说 ，灾备预演的重要性远比部署安全产品来的重要。
因此 ，灾备预演为盛京医院搭建了一个检测、培训和模拟灾情的平台 ，这对于非专业机构在关键时刻做出有效的安全防护措施有着至关重要的作用。
也就是说 ，容灾安全平台是医院数据安全的最后一道防线。
上面提到 ，医院内部会产生大量的非纸质敏感数据资料。这些资料的安全存储、调用是一大难题。
其解决方案是将信息脱敏技术运用其中 ，进而实现在不影响检索/维护的情况下保障病人隐私。
目前 ，数据脱敏的体系 ，包括战略、机制、技术支撑三个领域 ，从上到下的指导 ，从下到上的推进 ，形成多层次、多维度、多视角的全方位体系架构 ，确保数据脱敏工作有序的执行：
找准数据脱敏体系的目标 ，数据脱敏目标包括数据脱敏目的（国家、监管部门、企业） ，数据脱敏后使用场景 ，满足哪些业务要求。满足法律法规、政策标准规范 ，数据安全管控分类分级 ，数据使用部门职责划分等 ，保证体系安全 ，协调数据提供方和数据使用方 ，提高体系运转。
规范数据脱敏体系的制度 ，按照2017年6月发布的《网络安全法》《电子商务法》《个人信息；す娣丁 ，制定数据脱敏政策 ，数据脱敏制度 ，数据脱敏细则 ，数据脱敏规范的规章制度 ，做事前事后的数据准备、数据执行 ，同时 ，保证整个业务过程安全可控 ，当发现问题时 ，进行审计追踪 ，及时解决。
针对医院数据安全防护的特征 ，将静态数据脱敏主要运用到开发/测试类 ，提取/上报类 ，建立关系型数据库。将动态数据脱敏用于数据共享交换和运维管理。
数据共享交换分两种 ，一种是通过文本或表格数据去交换 ，另一种是Kafka、数据请求API（XML/JSON）。运维管理的身份鉴别有 ，根据数据库用户名、运维客户端、主机名、MAC地址、IP地址、访问时间以及数字证书、U-key等多维身份验证。运维访问敏感数据实时脱敏 ，对数据库中返回的数据配置放行、屏蔽、加密、隐藏以及返回记录数等多种脱敏策略。
为了降低敏感度 ，保证信息安全 ，还要根据不同行业 ，不同的场景 ，结合脱敏技术的应用 ，力求达到用户数据使用的要求 ，进行规范化的操作。
浙公网安备 33010502006954号
浙ICP备12021012号-1
