中通数据安全体系建设

要做好数据安全，首先要了解数据的生命周期，然后结合企业现状和业务场景，在各个阶段选择适合的安全防护措施。

图1 数据生命周期

业界也有其他一些值得借鉴的思路，比如从风险控制角度建设数据安全体系，分为：数据治理，风险识别，风险控制，数据基础信息。

图2 数据风险

在具体实践中，结合上述两个思路，我们根据实际情况划分优先级，优先选择快速提升安全防护能力的控制措施，主要有以下几点：

传统的快递面单印有发件人和收件人的姓名、电话、地址，缺乏有效的保护措施。

为了保护面单上的敏感信息，采用了隐私面单技术。对面单上的个人信息进行脱敏处理，使用*号替换部分敏感信息，快递员只能通过专用APP进行扫码才能够查看和联系收件人，同时用户的手机号使用隐私号替换，快递员不需要知道用户的手机号也能够联系到用户。

除了快递面单，用户的敏感信息还广泛存在于企业内部系统，这些也都需要保护。对于应用系统常用的数据保护/防范措施主要是脱敏、权限控制、水印、行为风控和审计等。

脱敏：主要有两种做法，具体选择要根据业务场景、工作效率等来进行选择。

• 完全脱敏，员工只能看到一部分数据，比如手机号的前三位和后四位，135****1234

• 脱敏后保留查看明文的接口，主要应用于需要核实个人信息的场景，同时对接行为风控和审计

水印：水印主要是防截图和拍照，分为明水印和暗水印。明水印肉眼可见，暗水印肉眼不可见，通过特殊处理可以提取水印。

行为风控：主要采用零信任架构的思路，在事中实时地根据身份、权限、行为轨迹、环境等上下文信息计算出信任值，然后根据信任值进行不同程度地二次校验或者拦截。

审计：传统但非常有效的事后追溯手段，难点在于记全和记细。如何采用非侵入式设计和流量分析的技术手段，实现自动化地实时采集有效的行为日志仍然是不小的挑战。

用户敏感信息和业务敏感数据最终都需要持久化到存储系统中，但是由于业务的复杂性和灵活性，敏感数据需要参与到在线业务的交互中，所以无法一刀切地将所有敏感数据进行静态地加密存储，而是需要根据不同的业务场景采用针对性的数据存储保护方案。

另外，企业内网不是绝对安全的网络环境，需要根据零信任模型对敏感数据的传输采用双向认证的加密方案，这对安全支撑系统的性能和可用性都提出了非常高的挑战。

• 传统关系型数据库数据存储的风险

在研发效能部的支持下，我们内部上线了数据库统一管理平台IDB，把所有对数据的访问和操作都迁移到该平台上，包括权限控制、DDL、DML、分库分表等。把该平台作为内部数据访问的唯一入口，封死客户端等其他入口，统一收口所有对数据库的操作，同时进行管控和审计，也支持数据脱敏等功能，如图3。

图3 数据脱敏配置

平台上加入了审计功能，记录了SQL语句、操作人时间等，为日后审计、追溯提供了基础信息，如图4。

图4 数据库日志审计

• 大数据平台的数据存储风险控制

我们联合第三方合作伙伴定制开发了一套大数据安全管控平台，在不改变现有大数据平台结构的前提下，把安全管控措施嵌入到生产流程中。具体功能主要有资源管理、权限管理、脱敏管理、审计溯源、高危操作等，见图5。

图5 大数据安全管控平台

可以自定义安全控制策略，根据业务需求配置脱敏策略，见图6。

图6 脱敏策略

也可以自定义高危操作，识别高危操作，进行告警和拦截，见图7。

图7 高危操作

• 统一加解密服务

对于以上两种场景以及缓存、消息队列和ES索引库等数据源的安全使用，必须要做到在数据传输层和存储层进行加密，但是如何加密既能不影响业务又能保障安全依然困难重重，主要需要考虑以下两点：

1.加密谁来做，如果加密由各个业务系统自己加密，将会面临加密算法的选择、密钥管理等问题。

2.离线场景下，数据的关联分析，如果加密方法不同，必须要解密后才能关联，降低了数据的流通性。

综合以上两点我们选择建设一套统一的加解密服务，整体架构如图8所示，各个业务系统通过调用接口的方式对敏感数据加密后存入数据库。由平台进行敏感数据的加解密运算，保证算法和密钥的安全，业务系统只需要调用加解密接口即可，至于内部敏感数据接口交互的双向认证和传输加密需要用到的证书管理、吊销、轮换则依赖于PKI体系，我们正在探索自建PKI，留作下次分享。

图8 加解密服务架构图

具体加密方案则选择Tokenization技术，整个数据交互流程中，在数据进入系统时进行加密，确保整个数据交互过程使用Token即可。

设计Token时，考虑到业务的应用场景比较复杂和多变，所以Token的长度和原始数据保持一致，可保留前后几位的原始数据。例如手机号，保留区号后面的前三位和后三位，中间五位使用随机字符代替占位，在不知道明文的情况下可以快速识别数据的种类。

建设统一加解密服务还有以下优点：

• 业务系统只保存Token，数据库结构基本不需要改动

• 业务系统只需调用加解密接口即可，不要重复开发加解密组件

• 业务系统无法接触加密算法、密钥、密文，降低泄露风险

• 解密可控，只有经过授权的系统，才可以调用解密接口，方便管理和监控

使用Tokenization加密后，内部系统之间使用Token进行交互，只在必须用明文的场景下再去解密，例如触达用户的场景、发邮件、发短信、打电话等。

大数据分析的场景下，保持Token的唯一性，可以不影响Join分析。可以提前把数据中的维度信息（生日，运营商等）计算出来，用来解决大部分离线分析的解密需求，减少不必要的解密需求。只有极少数需要明文，例如，数据外发的场景，用户回访，这些可以数据分发平台进行解密和闭环。

图9 敏感数据流转流程

使用哈希算法，通过管理密钥的方式，保证数据只被已授权的人解密使用。双方约定好，使用不可逆算法对数据加密。数据加密后，一方拿自己的数据向另外一方提交请求进行碰撞，被请求方返回Yes/No，可以匹配出双方有交叉的数据。

• 数据生命周期闭环

数据分发平台：数据流程末端的闭环，可以参考之前推送的文章：中通数据安全分发平台实践

所有数据的解密、上传下载、批量导出等，统一收口到数据分发平台上，集中管控。

数据发现和分类分级是数据安全及数据资产治理中最基本也是最重要的一步，但现实中往往是做得最不到位的一块，主要原因就是重视程度的欠缺以及相应工具和技术的缺失，在实践上确实有比较大的难度。具体方法上主要有以下两种：

1. 数据库扫描然后反推应用

扫描数据库，识别出数据库中存储的敏感数据，然后通过数据库反推应用，做到数据库字段级别以及应用系统级别的分类分级。

• 优点：实现简单，只需要扫描数据库

• 缺点：需要维护数据库与应用的关系；只做转发，不涉及存储的应用，无法感知

2. 数据库扫描结合流量分析

扫描数据库对数据库字段里面的数据分类分级。

流量分析，通过解析接口中的数据，给应用系统分类分级。

• 优点：数据全，没有存储的应用也能识别出来，包括线上系统、后台系统

• 缺点：网络架构决定流量是否完全，流量清洗

    根据我们的实际情况和技术储备，我们将选择数据库扫描结合流量分析的方法实现数据发现和分类分级功能。

UEBA出现之前，大家都在用各种手段和措施来发现和监控已知威胁。UEBA则是使用机器学习的方式进行用户和实体行为分析，能够结合离线和实时分析，检测出已知和未知的威胁。

比较推荐是使用业务日志作为输入，使用AI分析跑模型，跑规则。业务系统日志维度是否足够全，将会直接影响结果的准确率。

在这里，我们再引入一种数据，那就是内部的流量数据，在大二层的网络架构下，可以很容易的取到我们想要的流量镜像，把这些流量解析出来，通过AI分析发现异常。流量中有很多噪声数据，这些在分析的时候也要考虑进去。

也可以不排除噪声，相同条件下，不同用户之间的差异应该也很明显。最后把日志和流量分别发现的异常做聚合分析，打分等提高准确率。

通过对元数据的加工，形成数据资产地图。以全局视角对信息进行归并、整理，展现数据量、数据变化情况、数据存储情况、数据使用情况等信息，为数据管理部门和决策者提供参考。

按照数据的不同角色，可分为数据使用者视角、数据开发者视角、数据所有者视角和数据安全视角，根据角色展示相应的内容及功能，集成到我们的统一安全管理运营平台。

数据是无边界的，数据流动到哪里，哪里就应该有数据安全。

现阶段数据安全、业务安全、应用安全和网络安全等信息安全领域都有一定程度上的重叠和关联，它们是相辅相成的关系，需要放到更大的视角下进行统筹规划和建设。

运用与业务场景相匹配的管理和技术手段，更好地化解企业内外部数据应用场景下的数据安全风险，把我们的安全能力服务化，建设更完善的安全生态，是我们努力的方向。