数据安全文件体系系列（三） | 数据安全管理政策

本系列主要阐述数据安全领域的制度文件体系，整合业界的经验编写而成，如有谬误，请及时联系我勘正！本系列文章共计会推出6篇，本文是第三篇，感谢您的关注！

推荐阅读：

• 数据安全制度文件体系系列（一） | 数据安全文件体系概述
• 数据安全文件体系系列（二） | 数据安全政策总纲

数据安全管理政策文件包括数据分级和分类、风险评估指南、风险管理要求、事件管理要求、人员管理要求、业务连续性管理等。

数据分级通常是按照数据的价值、敏感程度、泄露之后的影响等因素进行分级；通常分级一旦设定，基本不再变化。

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

分级和分类的目的是为了对不同分级或分类的数据采用不同的防护措施，分级和分类越多，管理成本就越高。

在满足合规要求的前提下，尽量使用简单的分级分类规则，推荐使用三级：

风险评估与定级有很多种方法，ISO 27001、ISO 13335、信息安全评估指南等均包含风险评估的内容。

这些评估方法基于资产价值、漏洞、威胁等因素，可以概括为：

• 弱点（漏洞等）等级越高，发生风险的概率越高，从而风险越高。

• 威胁（黑客、内部人员等）等级越高，发生风险概率越高，风险越高。

• 防护措施（安全加固、防御措施等）越弱，发生风险概率越高，风险越高。

• 资产价值越高，发生风险后造成的影响越大，从而风险越高。

前面三个都跟风险发生的概率（可能性，简记为P，即Probability）有关，第四个为风险发生后的影响（简记为I，即Impact）。

风险（Risk）公式可总结为PI矩阵，即：RISK=P*I，用于管理性质的风险评估、风险定级或风险量化。

在安全技术领域，实际工作中用得最多的还是直接基于业务重要性和漏洞类型的风险定级，其中：

• 业务重要性，决定了风险发生后对企业的影响程度。

• 漏洞类型，决定了漏洞被利用的概率，以及被利用后进一步影响其他业务的概率。

• 各种风险等级、各种风险类型的风险数量。
• 风险收敛的比例和速度。

如果发现风险未能得到及时处理，则风险可能酿成安全事件。

发现风险，首先应考虑降低风险的措施，如修复漏洞、启用安全防御策略等，并对风险收敛的时限加以管控，针对不同等级的风险，采取不同的管理要求。

遇到风险无法通过管理或技术手段降低的时候，也可以考虑风险转嫁措施。

如果风险无法通过上述各种方式得以降低或规避，那么最后的选择就只有接受风险了。但接受风险就意味着风险并没有消除，将来发生事故后需要有人来承担责任，所以决策接受风险的人，一定是来自业务管理团队的人。

在入侵事件发生后，应启动应急响应，包括：

• 应急团队：统筹协调，联系业务，事件定级并视严重程度及时同步到相关人员（如业务侧管理层、公关、法务、社交媒体官方账号运营责任人等）。

• 入侵检测与防御团队：提取关键日志，定位受损业务，实施拦截策略。

• 业务团队：采取应急措施，中断入侵行为。

事件按照其影响，从高到低，可分为多个级别：

典型的身份认证机制失灵场景是借用账号 ，包括：

• 借用他人账号：自己没有权限或权限不够，借用有权限操作的相关人员的账号。
• 出借自己的账号给他人（含代为输入口令）：他人没有权限或权限不够，将自己的账号口令告知他人（或代为输入）。

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

CMDB不仅记录了企业有多少设备，更重要的是，它记录了我们开展安全工作所必需的数据，如：

• IP地址，可以作为主机层安全扫描的数据源输入，可以作为该地址是否存在敏感数据的标记。

• 使用的域名，可以在发生安全事件后第一时间根据域名找到相应的业务团队。

• 操作系统、容器类型及版本，可以在第一时间基于威胁情报，统计出哪些设备需要紧急打上系统安全补丁，防止漏洞被外部利用。

• 服务端口，没有登记的端口将被视为可疑的行为（可能来自黑客、木马等）。

运维管理，即规范运维操作，如使用自动化运维管理平台或跳板机、只从内部源部署开源组件、执行安全加固等。

业务连续性管理（BCM，Business Continuity Management）是为了应对各种天灾人祸等异常情况而采取的预防性管理与技术措施。

这些异常情况包括：

• 自然灾害：地震、台风、海啸、洪水、火灾等。

• 人为灾害：黑客入侵、网络DDoS攻击、内部破坏或泄露数据等。

• 其他如供电中断、硬件故障、软件故障等导致的服务中止。

企业应遵循业界最佳实践（目前已有BCM国际标准ISO 22301），采用系统化的方法来测试业务、执行数据备份与恢复演练。

对于分布式业务来说，首选考虑异地多节点的自动热备机制（异地多活），在其中任何一个节点失效的情况下，其他节点仍可正常工作。

对于非分布式业务，可以考虑异地冷备机制，但冷备的数据不是最新的，会遇到数据的丢失问题，只能用于那些对增量数据不敏感的业务，比如防病毒管理系统。

安全防御基础设施、安全组件与支持系统（SSO、权限管理等）为大量业务所共同依赖，因此也需要提前建立异地容灾机制。

在出现漏洞报告、黑客入侵、DDoS攻击、数据泄露事件后，需要启用应急响应，以尽快恢复业务为首要目标，再来总结分析背后的原因。

事件发生后的应急预案包括：

• 卷入相关业务团队，共同应对。

• 止损：能止损的场景立即止损，如切断入侵路径、封禁相关IP、通知用户修改口令、回滚恶意的操作或交易等。

• 溯源与风险评估：包括漏洞利用或入侵的全过程（时间点和操作），评估受影响的范围。

• 事件总结与改进优化：改进业务缺陷、优化安全防御策略等。

数据备份方面会出现的问题包括：

• 没有备份。

• 备份不完整，无法使用备份的数据恢复业务。

• 备份未经恢复测试验证，不确定能否基于该备份恢复业务。

备份与恢复演练需要基于具体的业务，执行应用级的备份，并需要评估备份的内容是否能够恢复业务，以及定期执行恢复演练。

想了解更多数据安全的管理制度、标准规范、产品服务、认证评估等，可扫码加入「 数据安全备忘录」知识星球，更多精彩内容持续更新中！

想了解更多数据要素的政策制度、标准规范、最佳实践、行业报告等，可扫码加入「 数据要素备忘录」知识星球，更多精彩内容持续更新中！

关注【数据要素与AI新知】公众号，获取更多行业资讯！