序

本篇将会介绍等保中应用和数据层面的安全要求，文中内容全是本人个人观点，如有不对的地方欢迎纠正。文章以等保三级系统为基础，从合规角度解读要求。应用部分和数据部分内容相对较少，合在一起来说。

等保到底是个啥系列文章

等保到底是个啥（一）：物理安全部分

等保到底是个啥（二）：网络安全部分

等保到底是个啥（三）：主机安全部分

等保到底是个啥（五）：制度与人员安全部分

等保到底是个啥（六）：系统建设管理部分

等保到底是个啥（七）：系统运维管理部分

正文

本部分从应用和数据安全两个层面解读标准要求。其中会有很多重复的要求，只是针对的层面不同，可以参考之前网络或主机部分，下文中不再做解释。

7.1.4 应用安全

7.1.4.1 身份鉴别（S3）

a) 应提供专用的登录控制模块对登录用户进行身份标识和鉴别；

b) 应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别；

c) 应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用；

d) 应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施；

e) 应启用身份鉴别、用户身份标识唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能，并根据安全策略配置相关参数。

该部分没有太多新内容，看过之前几部分后，会觉得很多都是同样的要求。简单说下有些细微区别的点：

c中提出对鉴别信息有一项额外要求，不只是后台管理员，包括用户账户在内不能出现重名的情况，测评时会现场创建2个同名账户，看系统会不会提示此用户已存在；e中说的是在有这些功能的前提下，必须要启用，不用起来也是不行的。

7.1.4.2 访问控制（S3）

a) 应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问；

b) 访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作；

c) 应由授权主体配置访问控制策略，并严格限制默认账户的访问权限；

d) 应授予不同账户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系；

e) 应具有对重要信息资源设置敏感标记的功能；

f) 应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。

本节主要说应用系统自身所具备的访问控制能力，用户权限管理、数据分级分类以及日志记录。

a) 要求对用户访问权限进行限制，后台要有用户权限矩阵，防止越权行为发生；

b) 说的是应用系统自身的日志记录，至少要包括登录、退出、注册、注销、操作、更改、创建、删除等行为的记录，还要包括是谁、什么时间、什么类型的操作，而且日志要保留6个月以上；

c) 要求权限分配要有系统管理员或更高级别的主管分配，一般操作人员不能随意分配访问权限，如果存在默认账户的情况，一般来说其权限应该是最低级别的，只能查看和检索，不能修改和访问受保护的客体或数据；

d) 要求账户的最小化权限，以及权限分离。这点我们国内大部分公司做得其实不太好，尤其那种一个人的甲方公司，每个人都承担了过多的职责和权限，虽然一方面为企业节省开销，但另一方面也给企业带来巨大的潜在风险（比如人员生病请假、突然离职、恶意破坏、商业间谍），一旦某个人不在公司，很多业务就难以开展，甚至临时停止业务。外企对于这种方面，一般会设置AB岗，而且一个人不会身兼数职，一个系统由多个不同权限人员共同管理，而且会强制员工休假，不是为了福利，而是为了检验这个人不在的情况下，公司业务是否会受到影响，同时也是检验该员工的忠诚度，是否会泄露或倒卖公司机密；

e) 就是数据分类，不同数据按照标签予以区分，同之前其他部分提到的标记相似；

f) 同样是权限控制，这里强调的是敏感信息的访问控制，也就是公司机密和绝密级别的信息，一般公司会对这部分制定严格的管理条例来约束，配合流程审批予以控制，所有过程、申请和访问都有记录，可以追溯，可以问责。

7.1.4.3 安全审计（G3）

a) 应提供覆盖到每个用户的安全审计功能，对应用系统重要安全事件进行审计；

b) 应保证无法单独中断审计进程，无法删除、修改或覆盖审计记录；

c) 审计记录的内容至少应包括事件的日期、时间、发起者信息、类型、描述和结果等；

d) 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。

审计部分没什么好说的，参照之前要求就几个点：

尽可能覆盖的全面（细节和广度），保存6个月以上，可随时查询能够问责，定期生成审计报表，防止备份日志的破坏。

7.1.4.4 剩余信息保护（S3）

a) 应保证用户鉴别信息所在的存储空间被释放或再分配给其他用户前得到完全清除，无论这些信息是存放在硬盘上还是在内存中；

b) 应保证系统内的文件、目录和数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除。

这块要求很容易理解，就好比A项目中使用的移动硬盘，项目结束后清理数据给B项目继续使用；只不过这里要求的是系统为其他管理人员或用户分配的资源要做好数据清除工作。结合云上SaaS服务更容易理解一点吧。

7.1.4.5 通信完整性（S3）

应采用密码技术保证通信过程中数据的完整性。

这里查了一点密码学的资料，不常看忘得也快，简单说几句大家就理解了。

通常保证数据完整性是通过消息认证码（Message Authentication Code，MAC）实现。MAC主要用于保障数据完整性和消息源认证，当前应用于各类协议中的常规方式有IPSec、TLS、SSH和SNMP（V3版本及以上）等。

MAC算法主要有三种构造方法，分别基于分组密码、密码杂凑函数（Hash）。Hash是一类基础密码算法，可以保障电子签名、身份认证等多种密码系统安全的关键技术。比如常见的MD5（已不安全），sha-1（已不安全），sha-2，sha-3（还未普及）。

具体细节可以查阅密码学相关知识，这里不多累述。如果想大概了解，可以看看CISSP中密码学的章节。

总之，通过以上技术传输数据，就做到了基本的完整性要求。

7.1.4.6 通信保密性（S3）

a) 在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证；

b) 应对通信过程中的整个报文或会话过程进行加密。

这里要求就是传输加密。而且要求加密前双方要先进行身份验证，好比SSL VPN会与对端认证身份。目前可以使用TLS或者VPN，用的比较多，也可以考虑非对称加密传输数据，就是B用A的公钥加密数据发送给A，A收到后用自己的私钥解密后获得明文，不过这种比较麻烦，更多的还是建议使用前者。

7.1.4.7 抗抵赖（G3）

a) 应具有在请求的情况下为数据原发者或接收者提供数据原发证据的功能；

b) 应具有在请求的情况下为数据原发者或接收者提供数据接收证据的功能。

同上边的完整性、保密性同样，这里强调的是不可抵赖性，目的是为了可追溯可问责。一般都是对用户进行标记或者利用数字签名技术来保证抗抵赖。

7.1.4.8 软件容错（A3）

a) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求；

b) 应提供自动保护功能，当故障发生时自动保护当前所有状态，保证系统能够进行恢复。

容错其实也好理解，只是标准中的标书有些书面化，翻译一下就好了。

a举个例子，登陆框需要输入手机接收的随机6位验证码，那么你在输入的时候系统要只允许输入数字，禁止非数字字符的输入，另外只能输入6位数字，不可以超过；

b也举个例子，你在论坛或贴吧发表长篇大论，一般几分钟会自动保存一下，如果你浏览器意外关闭，再次打开可以恢复到之前保存的那个节点。

这部分要求的就是系统要具备这两个功能，第一条是防别人乱搞，第二条是从用户角度考虑，提供即时存储功能。

7.1.4.9 资源控制（A3）

a) 当应用系统的通信双方中的一方在一段时间内未作任何响应，另一方应能够自动结束会话；

b) 应能够对系统的最大并发会话连接数进行限制；

c) 应能够对单个帐户的多重并发会话进行限制；

d) 应能够对一个时间段内可能的并发会话连接数进行限制；

e) 应能够对一个访问帐户或一个请求进程占用的资源分配最大限额和最小限额；

f) 应能够对系统服务水平降低到预先规定的最小值进行检测和报警；

g) 应提供服务优先级设定功能，并在安装后根据安全策略设定访问帐户或请求进程的优先级，根据优先级分配系统资源。

本节就不再重复了，之前部分也说过，就是对系统SLA的要求，其中各项也容易理解。

7.1.5 数据安全及备份恢复

7.1.5.1 数据完整性（S3）

a) 应能够检测到系统管理数据、鉴别信息和重要业务数据在传输过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施；

b) 应能够检测到系统管理数据、鉴别信息和重要业务数据在存储过程中完整性受到破坏，并在检测到完整性错误时采取必要的恢复措施。

这部分开始进入数据安全的部分，完整性要求是2个层面：传输和存储。

这里要求就是有技术或人工方式能够检测出传输和存储数据被篡改、删除的行为，并且能够对这类情况进行恢复。属于DRP方面的要求，要求企业要具备灾难恢复的能力。

7.1.5.2 数据保密性（S3）

本项要求包括：

a) 应采用加密或其他有效措施实现系统管理数据、鉴别信息和重要业务数据传输保密性；

b) 应采用加密或其他保护措施实现系统管理数据、鉴别信息和重要业务数据存储保密性。

保密性的要求也是分2部分，传输和存储。传输之前提到过，加密传输就可以了。对于存储可以采用两种方式，技术和物理手段。技术的话就是磁盘加密，加密存储，DLP系统，不过一般都是需要资金大量投入，还要有技术人员管理。也可以简单点，保密室加保险箱，随便找个人看管就可以了，主要是有保护的措施，不一定非要通过技术来做。

7.1.5.3 备份和恢复（A3）

a) 应提供本地数据备份与恢复功能，完全数据备份至少每天一次，备份介质场外存放；

b) 应提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地；

c) 应采用冗余技术设计网络拓扑结构，避免关键节点存在单点故障；

d) 应提供主要网络设备、通信线路和数据处理系统的硬件冗余，保证系统的高可用性。

这部分就是要求完备的灾难恢复计划和配套资源。

a) 完全备份至少每天一次，不过目前基本都是实时的，除了热备还有场外冷备份，也是至少一天一次，不过可以放松到一周以内，一般都会算符合；

b) 要求异地备份，在22239中并没明确表示多远算异地，但是在JR-T0071中明确规定距离至少100公里；

c) 和网络安全部分重复，要求系统所在网络环境的冗余性，双线双节点的结构；

d) 这里就是要双活或者热站点，都是包含在DRP中的资源；此外测评的时候还会考察每年是否有进行灾难恢复的演练，标准中虽然没有明确提出，但是也会做为检查的一项。

估计这部分参考金融的标准可能更详细一点，这里贴一下JR-T0071的三级系统备份和恢复章节的要求：

a) 应提供本地数据备份与恢复功能，采取实时备份与异步备份或增量备份与完全备份的方式，增量数据备份每天一次，完全数据备份每周一次，备份介质场外存放，数据保存期限依照国家相关规定；

b) 应提供异地数据备份功能，利用通信网络将关键数据定时批量传送至备用场地；

c) 对于同城数据备份中心，应与生产中心直线距离至少达到30公里，可以接管所有核心业务的运行；对于异地数据备份中心，应与生产中心直线距离至少达到100公里；

d) 为满足灾难恢复策略的要求，应对技术方案中关键技术应用的可行性进行验证测试，并记录和保存验证测试的结果；

e) 数据备份存放方式应以多冗余方式，完全数据备份至少保证以一个星期为周期的数 据冗余；

f) 异地备份中心应配备恢复所需的运行环境，并处于就绪状态或运行状态，"就绪状态" 指备份中心的所需资源(相关软硬件以及数据等资源)已完全满足但设备cpu还没有运行 ；"运行状态"指备份中心除所需资源完全满足要求外，cpu也在运行状态。

结尾

以上是应用与数据安全部分的要求。结合之前三篇内容就是等保三级技术要求的所有检查项。后续会进入管理要求的部分，比较偏制度和体系，可能不如技术这么直观，最后感谢大家的支持，感谢BF平台和客服。

*本文作者：宇宸@默安科技合规研究小组，转载请注明来自FreeBuf.COM