最早大家在理解等保 2.0 安全管理中心的时候，可能都觉得是需要一个态势感知，或者是一个安全运营中心，这些需要，但不是全部，比如安全应该有安全的管理中心，网络应该有网络的管理中心，补丁应该有补丁的管理中心，而不是像以前所有的设备都是独立运营管理的，没有形成统一的体系。

通过等保2.0分析我们系统的脆弱性：安全管理中心篇

1 、系统管理

a) 应对系统管理员进行身份鉴别，只允许其通过特定的命令或操作界面进行系统管理操作，并对这些操作进行审计；
b) 应通过系统管理员对系统的资源和运行进行配置、控制和管理，包括用户身份、系统资源配置、系统加载和启动、系统运行的异常处理、数据和设备的备份与恢复等。

2、审计管理

a) 应对审计管理员进行身份鉴别，只允许其通过特定的命令或操作界面进行安全审计操作，并对这些操作进行审计；
b) 应通过审计管理员对审计记录应进行分析，并根据分析结果进行处理，包括根据安全审计策略对审计记录进行存储、管理和查询等。

3、安全管理

a) 应对安全管理员进行身份鉴别，只允许其通过特定的命令或操作界面进行安全管理操作，并对这些操作进行审计；
b)应通过安全管理员对系统中的安全策略进行配置，包括安全参数的设置，主体、客体进行统一安全标记，对主体进行授权，配置可信验证策略等。

三权分立，以现在全国医院信息科的人员配置来看非常难实现，医院信息科人员紧张，负责硬件的人基本包含了上面三个岗位的工作，系统管理里面又包含了服务器、网络、数据库，审计的人一般都会是安全管理的人员，而安全管理的人员如果自身不懂服务器、网络、数据库，那就是纸上谈兵，所以从医院目前信息科的人员配备来看，有一主一备两人来实现上面三个岗位的工作反而是最合理的选择，对于一主一备的考虑我认为是每个岗位都需要具备的。

4、集中管控

a) 应划分出特定的管理区域，对分布在网络中的安全设备或安全组件进行管控；
b) 应能够建立一条安全的信息传输路径，对网络中的安全设备或安全组件进行管理；
c) 应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测；
d) 应对分散在各个设备上的审计数据进行收集汇总和集中分析，并保证审计记录的留存时间符合法律法规要求；
e) 应对安全策略、恶意代码、补丁升级等安全相关事项进行集中管理；
f) 应能对网络中发生的各类安全事件进行识别、报警和分析。

对于数据中心除了按照安全区域划分，其实也要按照功能区域划分，业务区域、管理区域、安全区域，自从我们的新机房建设好之后，我就建立了单独的管理区域，将服务器、存储、安全、网络等设备的管理建立单独的网络，比如当 ESX i 主机出现问题的时候，我们可以通过硬件的带外管理口去登录，查看操作系统当前装，并且可以做装机、重启、开机等操作，极大的方便了值班人员，晚上有问题，只要远程操作就行，换成以前可能都得跑到医院来操作，路途的时间可能就要半小时，再加上分析操作，起码一小时，而远程管理直接可以在 10 分钟内处理掉问题，第一时间恢复业务，把影响面降到最低。对安全组件的管理也设置了单独的管理口，很多安全设备现在通过三层路由方式串联在网络中间，如果出现问题，可能无法直接通过业务地址登录管理，将安全设备上的一个口单独配成管理口，方便远程查看设备的状态情况，并且做应急的处置操作。从运维的角度考虑建立管理区域可以运维人员，从安全的角度考虑，单独的管理区域也是保护了基础设施的安全性，大家都知道网络中的 tracert 命令，可以通过该命令追踪路由，如果恶意的人通过该命令追踪到沿途网络设备的管理地址，刚好这台设备又没有设置管理地址白名单，再加上设备弱口令，那就会变成一件很可怕的事情，我们建立单独的管理网络，只有该网络地址才能被管理员登录访问设备，进一步提高了设备的安全性。在配置管理的时候，我一般会考虑这几个点，第一配置安全的加密通道，比如 SSH 、 HTTPS ， 第二配置管理登录强口令，第三配置管理白名单地址，第四配置管理登录超时时间，第五配置管理登录错误次数，第六配置管理登录最大会话数，第七必要时关闭一些管理通道。

在我从上一家单位离职时的最后一段时间，我接触最多的内容之一就是监控，除了设计自己单位的 P aaS 平台监控，还去借鉴了如阿里、网易等大公司的监控设计思路，真的可以说是一千家单位有一千种不同的监控软件，为什么会出现这样的差异，我觉得有以下几点：
①业务量不同，不同的业务量决定了在设计监控软件时，架构设计、平台选型、资源分配都不相同；
②业务需求不同，大部分人对监控可能还停留在对基础设施的监控，其实还有对业务，对应用可用性的监控，需求越深入，其实对监控平台的自服务性要求越高，这里我对自服务的定义就是用户能根据自己的需求以方便的形式在监控平台上添加监控策略，并满足自己监控的需求，其实也就是减少监控软件的定制化，尽量做到通用化，这点我觉得开源的监控平台 Z abbix 还是做的很好，一开始我以为监控容器化平台非 P rometheus 莫属，后来看到一家公司用 Z abbix 也做到了对容器化的监控，感受到了架构设计的巧妙；
③投入成本不同，这里包含了资金、人员、时间成本，刚来医疗行业的时候我觉得我可以用 Z abbix 搭一套监控平台出来，想着想着就发现涉及的面太广，如果做的很深入，可能我每天的时间都花在这个监控平台上，每天和同事对接监控平台的需求了，根本就没有时间去干别的活，后来还是考虑选择商业化的产品，虽然暂时不能满足深入的监控要求，但是把监控的体系建立起来，并且覆盖面广，直接把 0 分提升到了 60 分合格，剩下的 40 分优化需要慢慢和监控开发公司磨合了，而剩下的 40 分其实也是体现出监控产品差异化的地方。

针对安全策略、恶意代码、补丁升级等安全相关事项的集中管理，其实我并没有在医疗行业看到过特别好的产品，这里我觉得不仅仅只是杀毒软件平台、安全态势感知或者安全运营中心，可能是我了解的不够，看到这条要求，我最先想到的 D evOps 自动化运维。在我上家单位工作的时候，每年也有各种各样的安全检查、重保，在 2016 年杭州 G20 的前两个月，我们面临着对全网 3000 余台服务器的漏洞修复（主要是常见高危漏洞），除了漏洞修复，平时还有一堆别的事情要做，当时我使用了 A nsible 这个自动化运维工具，在两周的时间内完成了上面的漏洞修复任务，这里的工具只是做了操作的步骤，但没有实现流程化的管理和记录；也是在 G20 重保前两个月，和另一位开发的同事联合做出了互联网业务的一键关闭平台，这个平台做到了当前状态化的监控、一键操作等；在 2017 年我又和我另一位同事联合做了一套基于开源安全软件的自动化安全监控和信息收集平台，类似于 shodan 和钟馗之眼，做了一半我转到了别的项目组中，但是该平台已经能完成一些基础的功能。当时考虑到全网的服务器资源和安全人员的比例真的是很大，想想互联网公司可能几个人要运维几十万台服务器，有一套能够自己修改、自己搭建、自己使用的可靠自动化运维平台，对运维人员来说是最大的福音。在医疗行业，我也逐渐看到了微服务等新型 HIS 的出现，从一个烟囱式架构的架构逐渐往微服务化的架构迁移，那对于运维人员的运维压力也会逐渐增大，在这个过程中，我们就要提早思考，如何通过现有的人力成本解决更量的运维问题。

相关阅读：

通过等保2.0分析我们系统的脆弱性：安全物理环境篇
通过等保2.0分析我们系统的脆弱性：安全通信网络篇
通过等保2.0分析我们系统的脆弱性：安全计算环境篇
通过等保2.0分析我们系统的脆弱性：安全区域边界篇