安全架构--10--企业安全防御体系建设总结

本博客地址：https://security.blog.csdn.net/article/details/116232338

前述

在过去的工作中，我和我的团队基本完成了公司信息安全体系的初步建设，我设计的安全体系架构分为六大块：应用安全体系、安全防御体系、数据安全体系、隐私合规体系、资产管理体系、安全管理体系，六大体系共同构成了完整的信息安全体系。

完整的信息安全体系架构图：

我设计的企业安全体系架构

六大体系建设总结：

企业应用安全体系建设总结
企业安全防御体系建设总结
企业数据安全体系建设总结
企业隐私合规体系建设总结
企业资产管理体系建设总结
企业安全管理体系建设总结

一、安全防御体系介绍

这里的安全防御体系是指各种防御能力的总和，即我们常说的纵深防御概念。需要注意的是，并不是什么防护都可以叫纵深防御，如果防护模式单一的话，是算不上纵深的。安全防御体系旨在快速识别攻击并进行拦截，让企业能够抵御外部或内部入侵，从而拥有更安全的发展环境。

在实践中，我将安全防御体系分为云安全防护能力、IT安全防护能力、基础安全防护能力等三个方面。由于我所在的安全团队规模较小，尚不具备自主研发能力，因此核心安全防护产品主要来自第三方采购，其余安全防护产品来自开源产品二次开发，除此外还有一些自主开展的安全防护工作。

安全防御体系从工作内容来讲主要就两块，一块是搭建安全防护产品设施，另一块是防护设施的精细化运营。因此安全防御体系并不是许多人所想的堆产品，精细化运营在安全防御体系中占相当大比重，同时它也是一个持续化的工作。本篇内容我都将围绕这两块来展开论述。

二、云安全防护能力

正如这个名字一样，云安全防护主要是指防护云服务器的安全，我们先不考虑自建机房的情况，一般情况下，云服务器上的业务是一个公司的最核心资产，非常重要，事关公司存亡，因此云服务防护也是安全防护的第一优先级。

安全团队要做的第一步，搭建安全防护设施

防护云服务器安全的方式主要就是上防护设备了，对于安全团队稍有规模或公司安全预算不充裕的情况下，安全团队可以选择使用开源项目自己搭建防护设施，比如我的前东家就是这么干的。使用开源项目搭建比较考验安全人员的开发能力，因为每个开源项目在通常情况下都是不能完美的适用于公司当下环境的，为了适配环境或扩充原有功能，就需要对这些开源项目做二次开发。

而对于像博主这样运气比较好的，入职前公司就已经采购了阿里云核心安全设施了，比如云安全中心（态势感知）、web应用防火墙、DDOS高防、云防火墙以及其他设施中嵌套的安全功能点，这些采购的安全防护功能覆盖面已经非常全面了。如此一来，安全团队就省去了自主搭建这一步。同时，由于目前安全团队较小，对于使用开源产品替换这些花钱采购的安全设施，要等团队稍壮大后再考虑。

对于采购第三方的安全防护设施，确实没什么可讲的，花钱就完事了。虽然采购了很多第三方的东西，但我还是部署了一些开源的安全防护项目以作为补充，如蜜罐，我采用了开源的MHN；应用运行时自保护RASP，我采用了百度开源的OpenRASP；终端安全响应系统EDR，我采用了开源的Wazuh。目前暂不打算部署更多的防护设施，能将这些运营好就已经谢天谢地了。

对于这些开源防护项目的部署，网上有很多文章，我也写了一些自己的部署博文，部署其实没什么难度，理论上它仅仅就是安装软件而已。对于二次开发，我也并没有对其进行太多的二次开发，甚至这些项目的核心代码都没改动过，仅对配置文件做了深度优化，以及对其他一些地方做了适配性修改，使其适配公司当下的环境，能实现期望的功能就可以了。

以上就是为云服务器搭建安全防护设施的过程，一通骚操作下来，发现其实也没做什么，买的不用动手做，其他也就是安装了三个软件而已，不过我认为这已经够用了，因为后面要做的才是更重要的工作。

安全团队要做的第二步，安全防护设施的精细化运营

不管是自主搭建的安全防护设施，还是采购第三方的安全防护设施，它并不是搭建起来就完事了，如果搭建起来没有好好去用，那它只能是一个摆设，那么，如何让一个安全设施发挥它的最大效能呢，答案就是精细化运营。当然，我们这里所说的运营，仅仅指对安全防护设施的运营，并非其他安全运营。

精细化运营不同于一般运营，更不同于运维。我个人认为运营应该是比运维更高一层的概念，在实际中，大多数的安全团队其实只是对安全防护设施做了运维，即属于第一次配置好后八百年不去动不去看的那种，除非遇上特殊情况才想起它，如被攻破了、告警了、有人提需求了等等。

而运营则是一个持续的过程，我们以常见的规则匹配型安全防护设施来说，在流量经过安全防护设施时对流量进行规则匹配，被防护规则匹配中的流量就进入对应的防护逻辑，否则放行。我们知道攻击手段是千变万化的，流量也是千变万化的，那么防护规则也应该要不断适应新的网络环境才能满足新的需求。如此一来，是不要先经常去分析流量？接下来是不要不断构建新规则？再之后是不要不断调整优化这些规则？规则优化后是不要再去分析流量？……如此往复，安全防护规则这一块就运营起来了。

在实践中，我们要做的运营工作有很多，随便举一些例子：

1、买来的安全防护设施不能只接入三四个核心资产就完事了，那么多资源空着就白白浪费了，50个预置额度怎么也要接入40个吧？
2、这些安全防护设施设置了哪些白名单，哪些黑名单，这些数值应不应该永久放那不动？本周有没有新增？有没有删减？
3、哪些IP以及它的端口是对公网开放的，本周新开放了几个？下线了几个？这些IP的风险级别是高危还是其他？
4、有多少个IP是接入云防火墙保护的？还有多少个没接入？本周变化值是怎样的？
5、这些防护设施的安全规则是否有变化？变化了哪些内容？为什么这么变化？
6、这些安全防护设施的高中风险告警是怎么处理的？处理结果是啥？
7、本周一共拦截了多少个请求？TOP5的类型是那些？
8、安全组是怎么样的，本周有哪些变化？有哪些新增风险？怎么解决的？
9、服务器病毒和应急漏洞的扫描结果是怎样的？如果存在风险，是怎样处理的？处理结果是什么？
10、这些防护设施发现的漏洞，一般都是需要升级系统或升级组件才能修复的，那本周推动修复的情况是怎样的？
11、阿里云账号体系中，每个用户或用户组的权限分配是否合理？新增用户或用户组的权限分配是否合理？离职人员账号是否清除？
12、RASP本周新发现了哪些应用服务的类库信息？是否有不安全的类库？这些不安全的类库要不要推动升级？后续要不要跟进？
13、阿里云上其他安全设施或非安全设施的所有功能处，是否有发现配置安全缺陷？如果存在缺陷，是怎样处理的？处理结果是什么？
14、……

太多太多了！

精细化运营的范围就一个：全量。所有的地方都有可能出现脆弱点，即使今天不出现明天也可能就会出现，因此在精细化运营中，覆盖范围要覆盖全面，同时要定期去审计，切不可一劳永逸。

安全团队要做的第三步，安全运营周报

在实践中，可以以周的时间维度进行运营，具体运营结果可以在内部知识库中起一篇文章来详细撰写并作为运营周报，同时，为了在常规工作周报中突出运营的结果，可以将本周安全运营得出的核心数据（即运营简报）放在常规工作周报中向上汇报。

三、IT安全防护能力

上面说完服务端的安全防护，接下来我们说说客户端的安全防护以作为呼应。我们这里的客户端是指广义客户端，即办公网和办公终端。对于这一块，我将其称之为IT安全防护能力。同样的，这里也区分为安全设施与安全运营两大块，我们分别展开论述。

3.1、办公网安全设施

数据防泄露DLP

首先，我们来探讨一个非常难搞的事情，办公终端监控。很多互联网公司的业务发展通常先于安全团队建设，在业务发展到一定规模、出现安全事故时才考虑在安全方面进行投入，但此时已经是企业信息安全环境状况很差的时候，安全作为业务的基本属性，已经严重滞后于业务的快速发展。此时可能出现的安全问题其中之一就是大量内部数据泄露……

内部数据泄露对公司的杀伤力非常大，源代码泄露我们尚可搜集证据并通过法律诉讼来寻求赔偿，但客户被带到竞对公司这可能会要了公司的命。因此，对员工办公终端进行监控这从法义上讲合情合理，同时新员工也很容易就能接受这种环境，但老员工们自由惯了，会对监控办公电脑这种事非常抵触，因此实施起来阻力非常大。

在实践中，对于这种阻力很大的事情，我们可以先开一个动员会，动员会要公司大老板出席，所有高管和中层管理者必须全部参加，动员会上大老板讲述目前现状及实施计划，实施方（安全部门）对所有有疑问者进行答疑，直到所有人没有疑问为止，动员会之后，基本就能破除公司上下思想上的阻力。

接下来，实施方先搭建监控服务器，完成后可以兵分两路，一路逐部门为员工办公终端安装监控客户端，直到所有部门所有人员安装完毕，自此之后新员工电脑在下发时就预先安装监控客户端，这样一来，就能保证所有员工的办公终端都有监控客户端了。另一路逐部门进行数据收集，收集时可以与数据所有者确定数据的敏感度，对数据做分类和分级，这样一来，数据分类分级也顺便做掉了，在收集完所有部门的所有数据之后，收集工作算完成。

至此最艰难的部分已经过去了，之后对所有收集上来的数据进行提取并做成不同级别的安全策略，策略生效后，这个非常难搞的项目就部署完成了，接下来就是运营的事情了。

办公网入侵检测

讲完了DLP的实施，我们再来说说入侵检测的实施。我们这里的入侵检测主要是对办公网进行开展的，在实践中使用了开源的Suricata项目。项目官网：https://suricata-ids.org/

一般情况下，公司办公网的网络架构中都会有一台核心交换机，核心交换机下面部署其他接入层交换机，每个接入层交换机下是AP或AP组，AP下就是办公终端了。因此，公司的所有办公流量都会经过核心交换机。在实际实施中，首先需要对办公网核心交换机做端口流量镜像，并用一台服务器对接流量镜像端口，这样一来，这台服务器上也就拥有公司的所有办公网流量了。

接下来，可以在这台服务器上部署Suricata，Suricata的主要功能是使用它的规则来抓取及分析流量。部署完Suricata后，可以使用就近原则，在这台机器上部署ELK用于数据处理及展示，即部署kibana用于展示数据、部署logstash用于过滤数据、部署Elasticsearch用于存储和索引数据，部署filebeat用于传输数据。这里需要说明的是，logstash没有集群概念，因此只部署一个就可以了，Elasticsearch需要部署为集群，以提高数据存储健壮性。具体部署可以参考：Suricata+ELK集群监控办公网流量

上网行为管理

上网行为管理主要是为了起到合理利用网络带宽、保障数据安全、提升工作作效率、避免法律风险的作用。

在实际中，上网行为管理可以全面记录用户上网行为、上网时长等信息，通过庞大的应用协议特征库和URL库去定位违规操作，便于取证溯源；它还可以拦截一些非法网站的访问、与工作不相关网站的访问、敏感数据的对外发送等等；同时，它还有一个最常用的功能就是对办公网流量进行管控，确保办公网正常稳定。在互联网公司中，它也有一些一般不会被用到的功能，比如限制上网权限、限制视频、音乐、下载等流量。

在实践中，尚没有比较好的免费上网行为管理设施，推荐采购深信服的上网行为管理设备，并将它冗余串联在办公网路由器与核心交换机之间，由于设备是采购的，它的具体部署就不细说了。

Wi-Fi安全

在实践中，Wi-Fi和VPN的部署其实都是运维部门或IT部门来实施的，很少见到这种事落在安全部门的头上，但它们作为办公网的网络入口，一旦实施不得当，对公司安全的影响将是不言而喻的。在Wi-Fi和VPN的部署实施过程中，虽然安全部门不是实施方，但作为需求方或监督方，一定要把控好Wi-Fi和VPN的安全实施落地。

对于Wi-Fi部署，一般公司都是一个楼层一个AP组或全公司一个AP组，体现上来说就是一层楼一个Wi-Fi名或全公司一个Wi-Fi名，但公司在早期可能部署方式较为简单，每个Wi-Fi的密码都设定成固定的，这就导致只要知道了Wi-Fi密码，不管是不是公司内部员工，都能连接到公司的内网中来。这样的部署方式存在巨大安全隐患，相当于将公司内网环境直接开放给外部攻击者，外部攻击者几乎无需耗费精力就能进入到内网环境。

Wi-Fi的安全部署方式是很简单的，主要做到不同的员工有不同的账号即可，在实践中，可以使用AD域账号来进行认证，由于每个员工的AD域账号是不一致的，因此对于每个员工来说，Wi-Fi密码也是不一致的。为了防止员工或外部人员使用其他设备入网窃取公司敏感数据，可以收集员工常用设备的MAC地址并做成白名单，白名单内的设备可以正常入网，白名单外的设备如果要入网则需要走申请审批。同时部署对应的访客网络，访客网络和内部网络做好隔离，在外部人员连接访客网络时，需要内部员工邀请才能入网。这样一来，Wi-Fi的安全的问题就搞定了。

VPN安全

对于VPN的部署，在我所经历的两家公司中，它们早期的VPN都是静态的，即VPN的密码是固定的，全公司使用同一个密码，申请VPN也没有任何正式流程，打个招呼就搞定的那种。这样一来，任何知道该VPN地址和密码的人，都可以通过VPN连接到内网。这在实际中也存在非常大的安全隐患，外部攻击者几乎无需耗费精力就能进入到内网环境。

同样的，VPN的安全部署方式也是很简单的，即做到不同的员工有不同的账号即可，在实践中，可以使用AD域账号来进行认证，由于每个员工的AD域账号是不一致的，因此对于每个员工来说，VPN密码也是不一致的。另一种方案是绑定动态口令，这种情况下会使用动态口令作为密码，由于动态口令每30秒更换一次，同时又不能预测下一次的口令是多少，因此它是安全的。最后，VPN作为远程办公的重要依靠，使用权限应该只给有需要的人，因此，每个要使用VPN的员工，都应当走一个正式的申请流程，确保每一个开通的VPN账号都是有据可查的。这样一来，VPN的安全问题也解决了。

办公终端杀毒

相比起DLP实施的困难，办公终端杀毒可谓难易两重天。如果公司能控制员工办公终端，即部署了类似桌面管理这样的系统，这一步就非常简单，后台鼠标点几下就能完成办公终端杀毒，同时还能控制员工终端哪些软件可以安装哪些软件不能安装，可谓一步监管到位。如果公司没有部署这样的系统，即无法控制员工办公终端，这一步就无法实际实施了。

在实践中，绝大多数的互联网公司都没有部署这种系统，因此办公终端杀毒作为一个安全的永久规划项，具体也就不再展开讨论了。

3.2、办公网安全运营

上面说到的办公网安全设施并不是全部都需要安全运营的，比如Wi-Fi、VPN这种，属于部署好之后一劳永逸型的，之后只需要把控好账号的审批、开通和注销就可以了。在本篇文章中，办公网的安全运营对象主要是DLP、办公网入侵检测和上网行为管理。接下来我们逐一展开论述。

DLP的运营

DLP运营主要有三块，一块是终端在线情况，如果一个员工的DLP客户端长期不在线，那可能是因为这个员工私自将公司电脑丢在一旁然后使用个人电脑，也可能是因为这个员工出差了，又或者是这个员工回家生娃去了，再或者是因为升级系统导致DLP客户端失效了等等。有些原因是客观不可避免的，而有些原因是主观存在风险的，因此，安全部门需要定期去检查DLP终端在线情况，并对存在风险的情况进行处置。

在实践中，可以以周为时间单位，定期统计7日不在线情况和30日不在线情况，对于7日未上线的可以暂且不做处理，因为时间线很短，不能确定是不是因为出差去了。对于出现30日不在线的员工则需要进行回访，了解他长时间不在线的原因，对于使用个人电脑的员工，可以通过教育使其更换回公司电脑，或者为他的个人电脑安装DLP客户端，对于升级系统或其他原因导致DLP客户端失效的员工，可以约定时间，对其重新安装DLP客户端。以上工作均是为了保证DLP客户端的上线率维持在一个较高的水准。

第二块是事件审计，在策略配置好之后，就可以开始审计事件了，事件需要每天都去审计，主要审计哪些员工触发了什么策略，外发了什么数据。对于外发敏感数据的员工，应当予以提醒，并将其行为记录下来，同时应当收集员工外发敏感数据的原因，这样做可以得知员工常见的外发习惯，并将其作为反馈，用于持续优化策略。

第三块是策略优化，这些DLP防护策略最开始是将收集上的所有数据进行提取并编制成策略的，可能存在一定的不合理性，随着时间的不断推移，这些不合理性就会逐渐的显现出来，比如配置的不够完整有遗漏、或配置的不够合理、或策略过于冗余等等，通过实际实施中发现或反馈出的问题，我们以周为时间单位，定期对这些策略做优化修改。

IDS运营

这里的IDS使用了开源项目Suricata搭建，它是一个规则型的安全防护设施，那么它的运营方式也是和规则型防护设施的运营方式是一致的。

首先，将开源项目搭建完成之后，要完成的第一步是通过修改配置及策略实现流量的分类监控，如HTTP流量、SSH流量、FTP流量……等等，在完成这一步之后，就可以启动识别及监控异常流量了，在初始阶段，它是有一些默认安全防护策略的，可以优先使用这些默认策略来开展工作，接下来，逐步分析这些由默认防护策略发现的异常流量，并对真实存在的异常行为进行推动修正，之后，逐步调整及优化这些默认的防护策略，实现异常告警趋于精细化，最后，又回到异常流量的分析，如此往复，安全防护规则这一块就运营起来了。

办公网的IDS所监控的流量一定要做到实时，这一点非常重要，因为它在发生安全应急事件时能起到非常大的支持作用，如果流量出现堆积导致流量展示延迟，在发生安全应急事件时不能很好的支撑应急响应，那么它的价值就大打折扣了。

AC运营

上网行为管理的功能非常丰富，但实际需要持续运营的功能却不多，很多功能属于一劳永逸型的，一般情况下，上网行为管理的安全运营只包含两块内容，一块是告警事件的处置，另一块是相关策略的配置及优化。

对于告警事件的处置，包括网络故障、权限策略故障、用户认证故障、危险应用管理、危险用户管理、安全事件处置、上网行为管控等等。其中网络故障、权限策略故障、用户认证故障属于技术支持型运营，在实际发生这些故障时，安全部门需要去处理这些故障。而危险应用管理、危险用户管理、安全事件处置、上网行为管控则属于精细型安全运营，就需要持久的去动态管理了。

这里我们说说这些精细型的安全运营。危险应用主要是指没有经过使用批准且产生流量的应用，这里的使用批准并非指公司层面的批准，而是上网行为管理的批准，类似于白名单，被批准的应用将不会再进行告警，而安全所需要运营的，就是审计每天新增了哪些应用，这些应用是否外发了文件，外发了什么文件，这些应用是否应该加入黑白名单等等；危险用户是和危险应用相对应的，即哪些人是用了这些危险应用；安全事件处置的运营与以上同理。因此，对于该类事件的处置一方面是技术口的黑白名单及事件审计，另一方面是人员的安全意识教育。

上网行为管控主要是针对办公网的所有流量行为，它的运营工作主要是分析办公网流量数据，流量数据会被分为被拒绝的、被告警的、被记录的等。以被拒绝的流量运营为例，被拒绝的流量TOP5是哪些应用产生的，这些被拒绝的流量是否真的安全，对应的应用是否该被加入黑白名单等。对于被告警与被记录的流量运营方式也是类似的。

对于策略配置的优化来说，策略优化的内容主要来自于运营中发现的不合理的地方，这种思想在本篇中已经讲解多次了，同时对于具体优化哪些策略，在这里也就不详细论述了。

办公网安全运营周报

在实践中，可以以周的时间维度进行运营，具体运营结果可以在内部知识库中起一篇文章来详细撰写并作为运营周报，同时，为了在常规工作周报中突出运营的结果，可以将本周安全运营得出的核心数据（即运营简报）放在常规工作周报中向上汇报。

四、基础安全防护能力

在安全防护体系中，除了防护服务端与办公网的安全，还有方方面面的地方也需要进行安全管控，在这里，我将这些需要安全管控的点统一称之为基础安全防护能力。基础安全防护能力主要分为以下三块：物理安全、运维安全、安全应急。

物理安全

在物理安全中，我们都知道监控和门禁是必不可少的，在一般的认知中，监控要做到无死角、要对准电脑但不能对准电脑屏幕、要对准桌面但不能对准桌面文档……等等，门禁要做到钥匙认证、或刷卡认证、或密码认证、或指纹认证、或人脸认证、以及权限控制（即不同的房间有权限进入的人不同）……等等，而在实际中，这种规格要求已经达到了金融级别，算是非常高了，对于互联网公司来说，基本没有必要。

那么监控和门禁怎么安装即能简单省事又能算是符合要求呢？根据ISO27001审计规范，在每层楼的入口处安装一个监控，用来监控进出的人员即可；而对于门禁，只需要有任意一种认证方式即可，这里有一个需要关注的地方，在人员完成进出门动作之后，门需要关上，而不是长期处于开门状态，如果长期处于开门状态这和没有门禁的效果是一样的。

是不是听着似乎很简单，不过这还没有符合标准，在实际中，公司的重要部门是需要特殊对待的，在互联网公司中这样的部门一般是财务部。财务部门需要使用单独的办公空间，在这个单独的办公空间中，需要再安装一套监控设备及门禁设备。这样一来，监控和门禁就能符合ISO27001的标准了。

再来说说内部机房，在云计算普及的今天，大多数公司都不会再自建机房了，但我们能说自己没有机房吗？大概率不能，如果公司自己搭建公司网络，就需要部署路由器、交换机，如果公司自己安装监控设备，就需要监控视频存储服务器，这些设备所在的小房间就算是机房。那如果强行解释自己没有机房呢？比如办公网和监控都是物业的，公司业务都在公有云上，自己就是没有机房，实际上，如果这样解释引发的问题会更多，因为这样一来办公网就属于第三方管控了，这在审计时会审计更多的项目，比如是否签订委托协议等等，更为复杂。

那内部机房如何保障其安全呢？一般情况注意以下几点就可以了：

1、内部环境：干净整洁，有空调，有备用电源（小公司来说没有也可以）；
2、防水：机房上下左右不能是洗手间或外窗，需要安装湿度传感器；
3、防盗：需要安装监控与门禁，并登记记录每一个进出机房的人；
4、防火：需要安装消防栓、烟雾报警器等；
5、防静电：防静电地板；

在实践中，物理安全基本也只能做到这里了，算不上特别安全，但已经符合标准了。

运维安全

特权账号一般是指拥有大权限的账号，常见的特权账号包括云平台最大权限账号、对公业务的的超级管理员账号、内部各系统的超级管理员账号、其他各部门自有系统的超级管理员账号等。

在实践中，不同敏感级别的特权账号需要按不同的保管方式来进行保管，比如云平台的特权账号，需要保管在公司创始人手中，因为云平台上的业务关系到公司的生死存亡，而员工总是会存在离职风险或出轨风险，因此这种账号不能保存在员工手中；对公业务的特权账号则是主要影响公司业务开展，比如有权限私下给开VIP等等，但它不会影响到公司存亡，这种特权账号通常需要由公司某高管来保存，不能保存在员工手中；内部各系统的超级管理员账号除了会影响公司内部业务系统外，对公司经营影响一般不大，比如发布系统、代码仓库这种，因此这种特权账号由运维部门来保管就好；而各部门自有系统的特权账号基本不会影响公司经营，由各部门自行保管即可。

再来说说数据库安全，数据库安全的其中之一是数据库权限管理，由于数据库属于内部系统，因此按照前文所述，数据库的特权账号由运维部门来保管即可，特权账号可以对子账号授权到库表列，而子账号只能查询自己被授权的数据，同时也可以创建拥有其他权限的子管理账号，这样一来，数据库权限管理就基本成型了。同时，应当对数据库中的敏感数据进行打标，这些打标数据在落库存储时需要进行加密存储、展示时应当进行脱敏展示，这里需要注意的是，在执行加密存储时需要使用强健的加密算法，切不可使用自有加密算法或不安全的加密算法。最后，对于要查询真实数据的需求，则需要进行授权，只有在授权完成后才可查询真实数据。这样一来，数据安全也就基本成型了。

最后，就是统一身份认证和堡垒机了，这两项工作虽然是属于安全范畴的事情，但是在实践中，安全部门并没有去实际参与它们的建设，统一身份认证由后端开发部门完成，堡垒机由运维部门完成，其中堡垒机使用了开源的Jumpserver，搭建Jumpserver我在前公司也做过，但在这里就不再多论述了。

安全应急

安全应急即突发安全事件处理，它实际上属于安全开发生命周期（SDL）中的一环，但我将其放在了安全防御体系中，作为基础安全防护能力的一部分，我认为相比于应急响应作为安全开发生命周期的尾部环节，它更像是一种安全防护能力。

网络安全事件的处理与响应一般包括计划与准备、启动、记录、评价、限制、根除、回应、恢复、关闭事件、事件后续检查、事件总结等环节。具体如下：

1、计划与准备。在网络安全事件未发生之时，对处理事件所需的人、财、物等资源进行准备，以便及时使用。

2、启动。在网络安全事件发生后，根据事件的类型和等级触发相应的网络安全事件响应程序，启动事件处理机制。

3、记录。网络安全事件处理部门要根据汇报的事件情况进行持续记录，该记录应当根据事件响应机制的要求定点、定时向相关岗位或人员进行通报。

4、评价。由网络安全事件处理部门评价网络安全事件的严重性情况，并交由具备相应权限的负责人进行统一指挥。

5、限制。网络安全事件处理机制启动后，由处置负责人采取既定的操作要求对网络安全事件的危害进行限制和阻断，防止网络安全事件进一步扩散。

6、根除。在网络安全事件影响的范围得到限制的基础上，对网络安全事件进行根除，处理导致网络安全事件发生的原因。

7、回应。网络安全事件的发生会影响用户的网络使用与体验，在网络安全事件的处理过程中，应当持续向用户或外界反馈网络安全事件处理的进度及相关信息。

8、恢复。在根除导致网络安全事件的原因之后，恢复系统运行。

9、关闭事件。系统恢复正常运行后，网络安全事件处理告一段落，事件关闭。

10、事件后续检查。在关闭事件后，由网络安全事件管理部门对该次网络安全事件的处理过程进行回顾，并对导致事件的原因进行取证、追溯攻击源或责任人、发起调查或诉讼等。

11、事件总结。在对网络安全事件处置过程的责任及得失进行调查和分析后，对网络安全事件响应过程进行总结，开展奖惩等工作。

实际上，发生突发安全事件一般都是小概率事情，但这种小概率事件如果处理不好，造成的后果将是非常严重的，这就类似于战争一样，都是小概率事件，但是如果真发生了却又处理不当，就会造成非常大的灾难。因此，安全应急一定要在和平时期按照标准进行定期演练，以增强自身的应急能力。

既然如此，那么安全首先需要做的事情就是编制安全应急响应规范，安全应急响应规范必须要做到和实际环境相符，不应成为纸上谈兵的空中楼阁，同时，安全应急响应规范至少应包含人员分工和应急事件处理流程，也可以考虑包含诸如各部门应急预案之类的内容；或者以其他维度来编写也可以，例如按不同事件的响应策略来编写，这里的不同事件一般包括病毒传播事件、网站页面被篡改、常用系统故障或宕机、外部网络入侵告警、机房或物理设备故障等。

制定完应急响应规范后，不应该将其束之高阁，虽然它在平时毫无作用，但长久不管不问后，当公司真的遇到灾难的时候再拿出它，才发现已经无法力挽狂澜，因为这时候应急响应规范可能已经过时。所以企业应采取一些措施保持其更新，包括及时更新安全应急响应规范、应急培训、应急演练等等。及时更新安全应急响应规范这个不具体展开讨论，我这里单讨论一下应急培训和应急演练。

在实践中，安全应急响应培训可以作为安全分享的一部分，通过安全分享培训，让大家都知道安全应急响应是怎样一回事，同时，安全应急响应规范作为公司规范文档中的一份子，可以联合行政部发布一个全员通告，告知大家这个规范正式官宣了，虽然大家大概率不会打开去看具体内容，但大家都知道有这样一回事了。

在完成安全应急响应规范的撰写与培训工作之后，接下来就是定期开展应急演练了，这个应急演练多久演练一次合适呢？根据等级保护或ISO27001等规范，半年一次为佳，不应低于一年一次，即一年至少要进行一次应急演练。在应急演练时，可以寻求技术总监的援助，从而调动各技术小组协同开展。实际上，当安全部门使用扫描器将某个服务扫挂了、或某个服务突然奔溃了，这种恢复的过程其实也算是开展了应急演练，所以，应急演练就在不经意间开展完了。最后不要忘记的是，按照规范要求，应急演练是要撰写应急演练记录或报告的。

当然，以上做的这些都是为了在发生真正的安全突发事件时有条有理的应对，而不是慌乱成一团。真正的安全突发事件可能会是各种各样的，除了平时演练过的服务器挂了，还有比如用户数据泄露了、被监管机构通报了、被勒索病毒勒索了……等等，最后记得在处置完每个突发安全事件后，将处置过程、处置结论以及总结思考详细的记录下来，每一次突发安全事件的发生与应对，对公司、对我们自身都将是宝贵的经验。

五、总结

安全防御体系的架构是五彩斑斓的，几乎每个公司都不同，相同的只是所使用的防护设备名字差不多而已，具体使用产生的效果都是天差地别的，也并没有所谓的业内最佳实践。我以上所论述的安全防御体系，仅仅只是我自己的一番设计，在此抛砖引玉供大家参考，任何架构都有自己的特点，只有基于实际的、适合自己的、能落地的方案，才是最好的方案。