本控制项主要关注主机和应用安全，但更多的是侧重应用安全，属于三重防护之一。可以说是融合了主机安全、应用安全和备份恢复的内容，原文中要求较多。

等保2.0标准个人解读（一）：新坑开放

等保2.0标准个人解读（二）：安全通信网络

等保2.0标准个人解读（三）：安全区域边界

标准原文

主要检查点如下：

标准中几个反复重复的控制点：身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范，其实要求基本类似，只是针对的对象不同，这里是应用系统的防护能力要求。对于重复的部分就不再展开了。

身份鉴别

应用系统后台管理中，对于身份要具备几个功能：

  身份唯一性，具备自动去重检验

  对密码复杂度有强制性应用功能

  具备登录失败功能

  远程接入采用加密传输

  具备两种以上身份鉴别方式

前四项都是常规要求，只是针对应用系统而言，主要是最后一项，对于应用系统的身份鉴别，目前常用的方式是密码+身份验证服务器，或者配合验证码，如果安全级别高也可以配合移动key，从实现上来讲没有什么难度，需要注意的是等保2.0标准中明确要求两种以上身份鉴别方式必须要包括密码技术在内。补充说明一点，先登录跳板机再登录系统或是利用VPN拨号再登入系统，这种不算两种身份鉴别方式，只能算两重身份鉴别（账户密码方式验证2次）。

访问控制

等保2.0标准新提出的要求项要特别注意一下。对于默认账户，通常是超管账号、具备一定权限的管理账户，这次必须要重命名（通常是指设备、后台的admin，像root这类不太适合修改的除外），不可以使用系统默认名和默认口令，系统后台要具备强制第一次登陆修改默认口令的功能，对于所有账户，包括普通用户和管理权限用户。而对于多余、无效、长期不用的账户要及时删除，建议每月或每季度针对无用账户进行一次清理，此外不能存在共享用户，即一个账户多人或多部门使用，这样不便于审计，出现事故无法准确定位故障点，不能进行追责。

关于权限管理部分，首先就是最小权限原则，给需要相应权限的用户对应功能权限，不过分赋权。针对不同岗位的人员账户，功能不能过于集中，保障管理用户的权限分离。比如，负责审计的用户只给予查询、读取一类权限，安全管理账户不具备运维的权限，运维没有安全的权限。而对于超管用户，要先审批，经上层同意再使用，明确要做的操作和步骤，附带恢复方案的申请，这样的流程是比较安全的。另一个方面就是要注意越权漏洞的产生，同级别用户可查看其它用户信息，或越级查看其它用户信息。要求中没明确提出，但属于引申一层的问题点，也是现在普遍存在的比较危险的逻辑漏洞。

权限管理提出了主体、客体的概念，借鉴了一些通用数据保护条例（General Data ProtectionRegulation，简称GDPR）的内容，其实主要强调的是数据安全问题。客体的访问权限应该由其所有者（即主体）来指定，如允许谁或什么级别的主体访问什么级别的客体，还有对于客体的分类也应由主体来确定。等保2.0标准新要求提出这类客体的访问控制策略必须由主体来配置。而对于访问控制的颗粒度主体层面要达到用户级或进程级，客体层面要达到文件、数据库表级，从这里就可以看出所说的主体、客体指的是什么了。此处要分两个层面来看，首先是应用系统自身的访问控制颗粒度，必须满足以上要求，而且能够为用户提供该功能模块；而对于用户来说，本项作为建议，不是强制要求。

本控制点的最后一条（数据标记），在旧标准中一直存在，也一直是扣分项，好多企业无法证明能够提供此项功能。但在当前的环境下，大数据技术已经逐步走向成熟，数据生命周期的最基本步骤就是数据分级分类，因此数据标记已成为必然。

这里推荐一篇关于人工智能数据标记的文章，常见的数据标记类型：谈谈人工智能数据标注那些事儿

1.分类标注：就是我们常见的打标签。一般是从既定的标签中选择数据对应的标签，是封闭**。一张图就可以有很多分类/标签：成人、女、黄种人、长发等。对于文字，可以标注主语、谓语、宾语，名词动词等。

图1.4-1 安全标记示例-分类标注

2.标框标注：机器视觉中的标框标注，很容易理解，就是框选要检测的对象。如人脸识别，首先要先把人脸的位置确定下来。行人识别。

图1.4-2 安全标记示例-标框标注

3.区域标注：相比于标框标注，区域标注要求更加精确。边缘可以是柔性的。如自动驾驶中的道路识别。

图1.4-3 安全标记示例-区域标注

4.描点标注：一些对于特征要求细致的应用中常常需要描点标注。人脸识别、骨骼识别等。

图1.4-4 安全标记示例-描点标注

5.其他标注：标注的类型除了上面几种常见，还有很多个性化的。根据不同的需求则需要不同的标注。如自动摘要，就需要标注文章的主要观点，这时候的标注严格上就不属于上面的任何一种了。（或则你把它归为分类也是可以的，只是标注主要观点就没有这么客观的标准，如果是标注苹果估计大多数人标注的结果都差不多。）

看过之后，是不是标记也没想象中那么难，无法理解，其实就是简简单单的一件事。建议在系统设计的时候就加入数据生命周期的概念，以免后期产生海量数据要进行数据管理，那工作量也是海量的。

安全审计

等保2.0标准中应用系统的审计有些变化，第一条和旧标准有所不同。这里多说几句，这么多年来，还有很多人不理解审计和日志，开始我也觉得就是一回事，经过大量实际项目和查阅资料现在理解了，不过也仅代表个人观点。先来看下对审计的定义：

审计是由国家授权或接受委托的专职机构和人员，依照国家法规、审计准则和会计理论，运用专门的方法，对被审计单位的财政、财务收支、经营管理活动及其相关资料的真实性、正确性、合规性、合法性、效益性进行审查和监督，评价经济责任，鉴证经济业务，用以维护财经法纪、改善经营管理、提高经济效益的一项独立性的经济监督活动。

再来看看对于安全审计的定义：

安全审计是指由专业审计人员根据有关的法律法规、财产所有者的委托和管理当局的授权，对计算机网络环境下的有关活动或行为进行系统的、独立的检查验证，并作出相应评价。安全审计(security audit)是通过测试公司信息系统对一套确定标准的符合程度来评估其安全性的系统方法。

审计是一种操作，例如用户登录、操作、访问客体，这些都需要提交用户发送请求，经系统确认身份和权限后允许其进行相应操作，而审计后会产生结果，其结果便是日志。这么解释，大家应该就能理解什么是审计，什么是日志了吧。

那么接着说正题，系统必须具备审计功能，而且要覆盖到每一个用户，按照等保2.0标准新要求来看，不是记录所有操作，而是重要行为和重要安全事件，而这个重要如何定义，官方没有给出明确说明。这里的建议是，对于用户重要行为，至少应包括：登录、登出、查询、修改、删除、创建等记录了；对于重要安全事件，安全相关日志全留存吧，相比流量日志这点内容好多了，因为你也无法确定哪个事件可能造成严重影响，干脆全保存好了，只要保证6个月的周期，问题不大。而对于日志记录的元组，一般都会涉及，不用额外去追求细致，只要能够帮助分析问题和溯源即可，不必追求完美。

最后是和旧标准一样的记录管理工作，也是很多企业容易忽略的一件事。往往审计和日志都有了，而且也足够6个月，但就是放在日志服务器，需要了去审计平台查查，不用时就堆在那里。其实对于日志管理，一直都是有明确要求的，第一是定期场外备份，如果做得到位还会异地备份；第二是保证日志完整性，也就是要确保留存的日志没有被修改或删除，也不能出现损坏无法读取的情况，这就需要额外的人来做这项工作。定期备份，场外保存，专人管理，没有审批不能随便查看日志记录。

如果企业由于各种原因不能保证上述日志相关工作，那么建议可以把日志服务器做成双机，除了本机保存外，在存储上也额外同步一份，但前提是企业已经配备了这样的设备。一般来说，建议采用比较简单而有效的方法。

入侵防范

这部分内容无较大变化，只有一点新要求，放在最后来解读。本控制点要注意的重点包括以下几项。

承载系统的主机安装操作系统时最小化原则，尽量减少风险。主机以及应用系统的不必要服务和端口全部关闭，这样比较安全。但这并非等保2.0标准的要求，标准中说的是不必要的系统服务、默认共享和高危端口，不是所有不用的都关闭，企业可自行把控。应用系统的后台以及所承载的主机登陆要做登陆限制，一般放在管理区即可，问题不大，交给堡垒机去做安全赋能，或者放到带外管理平台，效果一样。如果没有这些措施，那么前置跳板机要配置好，登陆采用加密方式。记住，这里说的是两个对象，1个是系统后台，1个是承载系统的主机。

数据有效性校验功能，这就是对于输入框的内容，比如年月日的输入，就不要再允许字符和特殊符号的输入了。比较难搞的是评论回复类的，一定要做好过滤和转义，这样起码一开始就能搞定大部分SQL注入和XSS，此外对于评论先审核后发布很有用，虽然用户不太喜欢，但安全为主，经过人工验证后再发布会稳一点，对于一些搞事的语句，一眼就能看出来。还有一些喜欢在url里各种测试的，一方面做好过滤，一方面错误页面统一跳转，不要让他试出来一些测试页面或后台界面，这些基本的工作很多系统都没有做好。

对于SQL注入，有漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」原则，纵观Web安全领域的各种攻击方式，大多数都是因为开发者违反了这个原则而导致的，所以自然能想到的，就是从变量的检测、过滤、验证下手，确保变量是开发者所预想的。

一些常见的防御方式：

检查变量数据类型和格式

如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。

过滤特殊符号

对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。以PHP为例，通常是采用addslashes函数，它会在指定的预定义字符前添加反斜杠转义，这些预定义的字符是：单引号 (‘) 双引号 (“) 反斜杠 (\) NULL。

绑定变量，使用预编译语句

MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法。绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构，从根本上杜绝了SQL注入攻击的发生。

总之，对于SQL注入的防护，要引起重视，重点关注以下工作：

1、不要随意开启生产环境中Webserver的错误显示。

2、永远不要信任来自用户端的变量输入，有固定格式的变量一定要严格检查对应的格式，没有固定格式的变量需要对引号等特殊字符进行必要的过滤转义。

3、使用预编译绑定变量的SQL语句。

4、做好数据库帐号权限管理。

5、严格加密处理用户的机密信息。

对于XSS，本质是服务器响应给浏览器的字符串中,包含了一段非法的js代码, 而这段代码跟用户的输入有关。常见的XSS注入防护,可通过简单的转义HTML特殊字符,清除HTML标签来解决。但是,有时业务需要不允许清除HTML标签和特殊字符，这时就需要结合实际情况利用一些其他方法来进行防护。XSS的解决和输出端相关，当需要输出到文本文件时, 过滤和转义都是无必要的；当输出到 HTML 渲染引擎时,json_encode 是无必要的；当输出到 JS 引擎时, htmlspecialchars 是无必要的。总之，对于XSS防护应做好以下几点：

1.输出 HTML 代码时 htmlspecialchars

2.输出 JavaScript 代码时 json_encode

3.JavaScript 函数名(JSONP)用正则过滤

4.输入过滤应该用于解决业务限制, 而不是用于解决 XSS 注入

最后一条关于重要节点入侵行为的检测，若是放在前边两个控制项比较好理解，放在计算环境中，有些难以确定这重要节点是什么。看看测评要求中是怎么解释的：

测评要求8.1.4.4.6

测评对象：终端和服务器等设备中的操作系统（包括宿主机和虚拟机操作系统）、网络设备（包括虚拟网络设备）、安全设备（包括虚拟安全设备）、移动终端、移动终端管理系统、移动终端管理客户端、感知节点设备、网关节点设备和控制设备等。

可见，这里的重要节点是针对整个技术部分而言，涉及到所有设备和软件，这么一看就容易理解了。其实这里的入侵防范预警和前边的是结合在一起的，这里也提到了云计算、物联网的一些内容，有点超前了，应该放在扩展要求中。说到底就是要具备全网络覆盖的入侵检测功能，能够覆盖到每一个设备、操作系统、应用系统、终端等，有点类似于内网的态势感知，或者蜜网（注意不是蜜罐，是蜜网）系统，目前国内有产品的：谛听（D-Sensor,长亭）、幻阵（默安科技）、幻云（锦行）、迷网（安恒），排名不分先后，大家可以作为参考。

最后说一下新增的要求项，就是对于漏洞验证的要求。以前标准只要求对发现的漏洞及时进行补丁更新，这次明确提出要进行验证确认后再及时修补。这里说几个关键用词，“可能存在”、“充分测试评估”、“及时修补”，都是重点。这里说的是可能存在的已知漏洞，这个范围就很大了，可能存在的漏洞太多，有些可能无法很快发现，这里就是督促用户重视安全问题，经常漏扫和评估网络环境，主动去寻找风险点，而不是被动的定期执行扫描，意思意思就完了。那么，这回要求对漏洞进行验证，虽然没明确说，不过应该是指中高危的，验证后还要评估，这是两个事，验证是确定漏洞是否真实，评估是确定漏洞被利用的可能性以及损失程度，说白了就是要你做风险评估，综合评价漏洞的等级和影响程度。这些工作做好了，后边就是打补丁了，针对紧急的，危险性高的优先修复，中等和低位的可以排序慢慢来修，但是这个慢要有个度，毕竟要求里说了“及时”二字，不可能半年前的漏洞，检查时你还没修复，那就是有问题的。这点在等保2.0标准其实可以作为一票否定的，只要系统存在高危漏洞，那么测评不管多少分就是不及格，不予通过，各位一定要重视这点。

恶意代码防范

目前对于可信验证先不要想太多，可以考虑恶意代码防护工具来做。可以平台化管理，安全设备堆到一起，集中防护；也可以分区域，前置安全设备（NGFW、WAF、IDPS等）。同时也不要忘记做好主机层面的恶意代码防护工作，杀软或杀毒模块该装还是得装。当然，还是那句话，如果你的安全团队足够强大，能够及时响应各种安全事件，那么也可以靠人工来确保安全。

可信验证

（略）。

数据完整性、保密性、备份恢复

这三部分都是数据相关的，放在一起来讲。完整性的问题可以参考安全区域边界-通信传输部分的解释，这里不再重述，因为要求里说的一个是传输，一个是存储过程的完整性，类似的内容。

对于保密性，和旧标准没有什么区别，传输保密性就是加密通信（SSH、VPN、TLS、HTTPs等）；而加密存储，要搞数据防泄漏（Data Leak Protection,DLP）可能太过麻烦，也费钱。不如在访问控制和数据管理上下点功夫。要注意的就是页面的敏感信息泄露、数据库加密、不要存在弱口令管理账户（尤其数据库管理员，能被爆破的都是弱口令）、系统与数据库不要使用一样的账户、备份的数据由专人看管，放到保险柜，这比什么技术都实用。诸如此类的基本安全工作，能想到的尽量去做。多提一句，企业要格外重视社会工程学活动，虽然属于管理范畴，不过是目前最难防护的一个威胁。

数据备份恢复，其实应该算运维的事情，这里提的不是BCP和DRP，而是关注安全层面，总结起来就是几点：

（1）重要数据本地备份和恢复能力，重要数据是什么并未定义（大概要根据企业自身业务情况来定义数据的分类和分级），说到底还是全备了吧，免得各种麻烦。

（2）实时异地备份，新要求多了“实时”两个字，这要求其实高了不少，说白了就是逼你搞双活（双活容灾即灾备系统中使主生产端数据库和备机端数据库同时在线运行，处于可读可查询的状态的技术），有钱没钱也要做个样出来。本地机房的话，没什么太好的办法，只能拿钱砸了，如果是云上就好办多了，多租几个异地虚拟机做实施备份，难度会小很多。这里没说异地的定义是多远，我一直参考金融行业等保标准（JR/T 0072-2012），距离是不小于100公里。

（3）最后一条要求热冗余，说白了就是双活，这里不再多说了。

剩余信息保护

本以为删除的要求，没想到又加回来了。对于主机和应用系统层面的，网络设备、安全设备不涉及。这里涉及到两个名词：鉴别信息、敏感数据。鉴别信息应该是指用户身份鉴别的相关信息，敏感数据就是个人信息或企业重要信息，这样理解会比较清晰一点。

要求对这两类信息的存储空间再次分配前，应得到完整的释放。对于操作系统、内存和磁盘存储，这类问题都好解决，删除后覆盖基本也就很难恢复了，如果不放心多搞几次，肯定恢复不出来有用信息。关键是应用系统，在设计时就要考虑这项功能，要集成在系统中。在一个难点就是云计算环境中的剩余信息保护，涉及到一些底层的东西，后边会在云计算扩展部分说明，这里不去讨论。

个人信息保护

新增控制点，这里其实只是简单说说，具体的细节会参照《互联网个人信息安全保护指南》、《互联网个人信息安全保护指引》（征求意见稿）等要求来要求。这里和前边的安全审计有一个联系点，比较重要，说明一下。就是审计要覆盖到每个用户，但是，记住了，按照要求企业未经用户授权是不能查看这些记录的，也就是说你要记录这些信息，你有权限但是不允许你看，除非监管部门要求或协助警方调查的情况才可以去查询。

本控制点的要求比较简单，一是采集个人信息，有用则采，无用不信息不要收集。然后，未经授权不能访问、也不能使用用户个人信息。比如现在淘宝那种，你买个东西，然后商家没事就发消息到你手机，或者各种股票、借贷、保险电话，这些行为后续都会被认定为违法行为。

虽说是技术部分，但是测评要求里提到要查看制度，对，你没听错，就是要查看你对于用户个人信息保护的管理规定以及执行情况。

最后

本控制项的内容在技术部分中是最多的，涉及到主机层面、应用层面、数据层面、备份恢复层面。这里用一张结构图来汇总下，企业可以参照其中各点查看自身安全建设情况是否到位。

图1.4-5 安全计算环境架构概览图

PS：文中的图片标号是对应整套等保2.0解读章节的，各位请无视。

*本文作者：宇宸默安，属于FreeBuf原创奖励计划，未经许可禁止转载