数据安全-政策文件体系

一、数据安全文件体系

数据安全文件体系，即一系列管理、标准与规范、流程、指南、模板等文件的文档化记录。

当企业开始 规范化 运作的时候，特别是需要通过外部的认证、测评的时候，文档化的文件体系就是必不可少的，如等级保护三级认证。当需要通过相当于 能力成熟度三级 的有关认证时，相对完善的政策文件体系更是必不可少。

这里科普下能力成熟度模型：

说明：一般三级是及格线

● 第一级：为临时的或不可重复的实践做法
● 第二级：为可重复的实践做法
● 第三级：为充分定义的政策、流程、控制措施，并文档化发布
● 第四级：为可量化（度量）
● 第五级：为基于度量、定期审计的反馈与持续改进

文件体系架构：

数据安全文件体系一般分为四层，包括政策总纲、管理政策、安全标准、技术规范等。其中，政策总纲是数据安全治理的三个核心要素之一（另外两个是战略、组织），奠定整个政策文件体系的基调。管理政策、安全标准以及技术规范，是数据安全合规管理的主要交付内容。

四层文件简介：

● 第一层：为数据安全政策总纲，属于顶层文件，一旦发布一般不会再轻易修改，因为它规定了整个数据安全体系的目标、范围、各项基本原则等。
● 第二层：为管理规定、技术标准/规范。
● 第三层：为操作类的流程/指南、技术类指引等文件。
● 第四层：为模板。

二、数据安全政策总纲

数据安全政策总纲，即数据安全领域的顶层文件，政策总纲通常需要包括：

● 数据安全的目标。
● 数据安全的范围。
● 强调对数据分级与分类管理。
● 数据安全组织与职责。
● 授权原则。
● 数据保护原则。
● 数据安全外部合规要求。
● 对人为原因导致的数据安全事件的问责要求。

具体说明：

1、 目标： 以数据全生命周期安全为目标，防止敏感数据泄露，满足合规要求；
2、 范围： 各种结构化数据与非结构化数据，以及各种资源；
3、 分类与分级： 基于业务分类，基于实际情况分级；
4、 组织与职责： 安全团队负责数据安全的政策制定、改进推动、解决方案提供、合规审计，业务团队负责改进执行落地；
5、 授权原则： 权限最小化、授权与行权分离；
6、 保护原则： 明确责任人、基于身份的信任、数据流转审批、加密传输、加密存储、脱敏展示、备份和恢复机制；
7、 合规要求： 法律法规要求、认证/测评要求、审计要求、监管要求。

三、数据安全管理政策

3.1、数据分类与分级

数据分类：

数据分类通常是按照数据的用途、内容、业务领域等因素进行分类；数据分类可随着业务变化而动态变化。

数据分级：

数据分级没有统一标准，根据实际情况进行分级即可，分级的影响因素如数据的价值、敏感程度、泄露之后的影响等；通常分级一旦设定，基本不再变化。每一个数据分级可对应多个数据分类。
推荐将数据分为三级： 不进行分类分级会有哪些后果：

● 文件或数据被过分提高机密等级
● 任何人都假定自己可以浏览企业内的文件或数据
● 员工离职将带来危险
● 机密文件或数据的安全措施逐渐失效，员工忘记最初的规定

3.2、风险评估

风险评估是基于资产价值、漏洞、威胁等因素的，可以概括为：

● 弱点（漏洞等）等级越高，发生风险的概率越高，从而风险越高。
● 威胁（黑客、内部人员等）等级越高，发生风险的概率越高，风险越高。
● 防护措施（安全加固、防御措施等）越弱，发生风险的概率越高，风险越高。
● 资产价值越高，发生风险后造成的影响越大，从而风险越高。

3.3、风险管理的要求

风险管理一般需要确定以下要素：

● 风险所有者，不能让风险无人认领；
● 风险指标，量化并直观展示风险现状；
● 风险处置与闭环，及时降低风险；

3.4、事件管理要求

在处置安全事件时，一个基本的原则是“以快速恢复业务，降低影响为主要目的”，而不是立即找到事件发生的根本原因。

为了体现从源头预防的思想，事件一旦定位到原因，就一定需要第一时间卷入原因的责任方，比如开发设计方面的失误，就卷入业务方案设计与开发团队的人员，哪怕是在凌晨三点。从职责上看，业务方才是第一责任人，理应对自身疏忽或失误负责。如果源头的错误都由其他人解决了，那么同样的错误还有可能再犯。

在事件得到控制，风险解除之后，需要开始对事件进行复盘，按时间顺序还原入侵事件的详细入侵路径、所利用的漏洞类型、攻击方法，对其进行研究并找出风险点，给出防御措施，包括业务自身的改进、安全防御系统的策略覆盖或防御规则的升级。

3.5、人员管理要求

人员管理要求也可以按5A方法来开展：

● 身份验证：对访问者的身份做确认，防止身份认证失灵，没有权限应当通过正规渠道去申请；
● 授权：要满足最小化授权、授权与行权分离；
● 访问控制：防止员工从事恶意行为；
● 可审计：防止破坏内部安全机制的运作；
● 资产保护：防止数据泄露事件。

3.6、配置和运维管理

配置管理：

这里所说的配置管理，是指在CMDB（配置管理数据库）中登记与维护更新，维护CMDB的及时性和准确性，并将CMDB作为安全监测的数据源。

CMDB记录的数据粒度越细，则维护CMDB的成本越高，具体记录哪些信息，需要根据管理和业务的需要进行权衡。

运维管理：

即规范运维操作，如使用自动化运维管理平台或跳板机、只从内部源部署开源组件、执行安全加固等。这一领域，应该将自动化运维能力的提升作为改进的方向。

只有在自动化运维能力覆盖不到的场景下，才使用第二选择：通过跳板机进行运维，以及执行运维审计。除了这两种选择之外，不应该再有其他选择，比如用户直接登录到目标服务器而不经过跳板机进行运维是不可接受的。

3.7、业务连续性管理

业务连续性管理是为了应对各种天灾人祸等异常情况（如地震、入侵、停电等）而采取的预防性管理与技术措施。

技术措施一般有：

● 异地自动热备机制（分布式业务）
● 异地冷备机制（非分布式业务）
● 应急响应
● 数据备份与恢复演练

四、数据安全标准

数据安全标准即数据安全领域内可重复或共同使用的约定或准则，是政策文件体系中的一部分。

4.1、算法与协议标准

● 对称加密算法：推荐首选AES-GCM-256加密算法；
● 非对称加密标准：推荐RSA-2048，或ECC-224；
● 单项散列：推荐使用SHA-256加盐；
● 慢速散列：推荐使用bcrypt、scrypt；
● 消息认证：推荐使用HMAC-SHA256；
● 随机数：推荐使用安全的伪随机数生成函数；
● 传输协议：推荐使用TLS-1.3或TLS-1.2；

4.2、口令标准

● 推荐使用动态口令；
● 不得使用默认初始口令；
● 根据实际情况设定口令复杂度；
● 内部系统推荐使用SSO；

4.3、产品与组件标准

没有最佳实践，根据实际情况设定即可，主要是为了统一好管理，标准包括：

● 操作系统标准：服务侧与用户侧各设定系统类型与主版本；
● web服务器标准：推荐约定使用少量几种web服务器组件并确定主版本；
● 数据库标准：推荐约定使用少量几种数据库组件并确定主版本；
● 容器基础镜像：约定统一的基础镜像；
● 用户侧标准：使用指定的杀毒软件等；
● 限制使用的服务：统一限制不安全的服务，如FTP、Telnet等；
● 例外场景：约定范围内的产品有时无法满足业务需要，此时需要约定例外处理机制；

4.4、数据脱敏标准

数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护。

一般需要在界面展示、日志记录等场景对可以直接定位到自然人的个人数据进行脱敏处理。

通常来说，脱敏标准只是一种约定，让企业内的不同业务都采用同一标准进行脱敏，避免使用不同的脱敏标准，因为黑客可能利用不同业务的漏洞拼凑出完整的明文信息。
举例如下：

4.5、漏洞定级标准

在收到外部报告的漏洞，或者内部安全系统发现漏洞之后，通常需要对漏洞进行定级，以便在不同的团队间达成共识，减少分歧，因为定级决定了是否需要处置或处置的方式，可以让安全团队将重心放在处置高危漏洞上面。

一般情况下漏洞可分为五级，分别是严重、高危、中危、低危、接受，当然，这个可以根据公司实际情况来定，定多少级都行。

同样的，什么漏洞定什么级别也是根据公司实际情况来定，没有统一标准。例如反射XSS，有人定高危，有人定中危、也有人定低危。

五、数据安全技术规范

数据安全技术规范，用于指导或规范业务的安全架构设计、开发实现、部署实施、运维实践等目的，包括：

● 安全架构设计规范：从架构方案上保障产品的方案设计符合业界最佳实践。包括身份认证与敏感业务超时管理、最小化授权、访问控制、日志审计、资产保护、部署架构等；
● 安全开发规范：从编码上保障产品的各项安全要素得以落地。包括不能信任外部传入的任何参数，防止无意中的内部信息泄露，避免使用高危功能。
● 安全运维规范：规范产品发布流程（如上线扫描、配置库登记、环境要求、加固与防御措施等），以及上线后的运维要求等。
● 安全配置规范：针对具体操作系统或具体中间件的加固规范。安全配置至少覆盖操作系统、web服务器、数据库。

六、外部合规认证与测评

我们经常会面临一些主动或被动的认证测评需求，业界也存在各种各样的认证测评，在这些认证测评中，部分是来自法律法规的强制性指令，或监管要求，或合同义务，是必须要履行的义务，如：

● 等级保护认证测评，来自对《关键信息基础设施安全保护条例》的合规遵从，适用于关键信息基础设施。
● GDPR法律合规，适用于向欧盟用户提供服务的业务。

而其他大多数认证测评都是安全团队或业务团队的主动选择，通过这些认证测评可以向外界证明其安全管理和技术能力符合国际安全行业的最佳实践，可促进销售、扩大市场份额。

数据安全团队通常需要协助业务参与访谈，并提供相应的安全管理政策、安全技术标准/规范、安全防御措施等方面的证据。认证测评的结果反过来又可以作为政策文件体系的输入，用于完善政策文件体系、安全基础设施等。