文：黄韦博 裴玲
在个人信息保护越来越受重视的当下，国家数据安全管控力度也不断加强，尤其是对金融单位的管理要求也更加严格。本文是从快速治理的角度出发，分享基于日志管理平台所做的企业日志脱敏治理经验。
治理背景
在各类敏感信息存储媒介中，应用日志是其中的重点之一，由于业务方场景过于繁杂，研发人员可能于多种情况下在日志内留存敏感信息，例如：
保留业务信息以便取证溯源，如客服对话、订单。
保留上下游业务对接信息，以便进行链路跟踪。
特殊系统需要保留日志原文，便于外部监管和内部审计。
系统不含数据库，需要依靠日志做落盘存储。
公共框架/组件打印输出敏感信息。
故而，日志内敏感信息的问题也成了稽核监管在数据安全方面重点关注的事项。
治理成果
在半年多的阶段性治理后，应用系统日志内敏感信息的抽样命中比率同比下降了约87%，同时日志敏感信息检测已形成常态化治理机制，做到了及时发现、及时整改闭环，治理工作总体上取得了显著成效。
治理思路
基于行内已有统一的日志管理平台，在其他资源有限的情况下，想要快速收敛日志内敏感信息的风险问题，首要方案是将日志进行收口管理，同时向开发提供相关脱敏工具，并持续对日志内的敏感信息进行检测，督促开发基于检测结果进行排查和整改，以制度、流程、工具为基准，从三个层面推动治理。
一、初期准备
1、完善制度规范
强调应用日志内不可留存敏感信息的管理要求，并要求应用在上线时需同步完成日志管理平台的接入，以确保日志统一收口管理，同时明确例外申请渠道。
日志需要统一采集到日志平台进行访问。
应用日志内不允许记录明文敏感信息。
理清敏感信息基线，对日志脱敏的范围和标准进行圈定。
开放例外通道，针对特殊情况按标准例外流程管理。
2、建立联络机制
对于长期项目而言，跟管理层、项目组、执行团队建立良好的联络反馈机制，是非常有必要的。我们主要从下面两点进行了准备。
1）建立项目组
纳入相关领域的研发负责人，保障对项目执行的有效落地。同时，维护了安全接口人（PMO）体系，保障安全团队对于研发团队的要求能够得到准确及快速的传达。
2）建立沟通汇报机制
成立项目沟通群，确保大家问题能得到及时反馈，如收到针对脱敏工具和流程的合理建议，也会尽快确认并纳入版本进行优化；制定项目周例会，线下沟通项目进展及当前风险；定期向领导层同步项目进度，让问题和成果都变得透明化。
3、提供工具支撑
1）统一日志管理平台
日志统一收口管理，默认前端脱敏展示，并提供实时和异步检测日志敏感信息的能力，方便开发进行快速排查并整改原始日志。
持续抽样检测日志：在上送日志时抽样若干条日志进行检测，如命中敏感信息规则，则记录，形成敏感信息报表。
异步检测存量日志能力：对历史日志进行全量跑批检测，用以辅助排查敏感信息。
2）统一日志脱敏工具
项目组为研发团队提供了脱敏SDK，支持通过全局配置和注解（高优先级）进行脱敏。
如果仅对字符串进行掩码，调用敏感字段类型对应的方法即可。
如果需要简单对象（pojo）进行脱敏，可以先对其中涉及的敏感字段进行注解标记，调用SDK后会正常返回一个json字符串。
如果是对复杂对象进行脱敏，则在返回结果后，可能会丢失掉原对象中的结构细节（fastjson.toString的特点）。
3）统一安全运营平台
用于对接日志管理平台，将获取到的检测结果自动生成整改工单，利用平台的线上化跟进能力，自动分发整改项，自动进行整改指标统计，闭环日志脱敏整改问题；并对接研发管理平台，提供安全质量门禁检查的版本管控能力。
二、中期治理
1、收敛日志访问权限
1）推动所有存量应用系统接入统一日志管理平台，并建立相关管控流程确保增量应用上线前同步完成接入。同时根据系统开发和运维角色进行针对性赋权，确保日志平台的权限最小化管控。
2）推动回收研发人员冗余的生产环境OS权限（在日志脱敏事项治理之前，不少研发人员都拥有生产环境OS权限，能够直接通过生产环境机器查看日志）
2、日志管理平台默认前端掩码
1）日志平台在接口层面对展示内容进行敏感信息掩码，确保原始日志未脱敏的情况下，研发团队在日志管理平台查询日志也不会接触到敏感信息。
2）为避免日志平台的前端掩码和原始日志的掩码难以区分，从而对开发造成困扰，日志平台前端掩码采用特殊的“^”符号，区别于原始日志掩码采用的“*”符号。
原始日志脱敏样例
日志平台前端默认掩码样例
3）为避免日志平台前端误掩码导致影响开发排障，用户可通过点击“眼睛”标识符查看原始日志，同时限制单次查看次数，并对查看行为进行审计。
4）建立对抗机制，检查组定期对掩码情况进行检查，规则组持续对掩码规则进行优化，确保应掩尽掩。
3、推动本地原始日志脱敏整改
1）研发流程管控：在研发安全流程中增加“日志内禁止记录敏感信息”checklist，确保开发人员在设计开发阶段知晓相关规定，同时在安全质量门禁处新增针对日志内敏感信息的检查项，用于开发进行自查。
2）持续检查：借助日志管理平台的实时检测和异步检测能力，持续对应用生产日志进行敏感信息的检测，如发现问题则自动生成合规整改项，要求开发进行相应整改，整改未完成则进行版本管控。
3）自动验收机制：整改完成后，系统获取最新的日志平台检测结果，未发现敏感信息则关闭整改工单，发现则将整改工单打回待处理状态。
三、长期规划
在长期的规划中，我们计划再从下面几点逐步进行实施：
1、标准化日志的输出格式
联合公共框架/组件以及研发团队的架构师，制定并规范日志格式标准，减少因日志打印不规范导致的不可控的脱敏成本。
2、持续优化工具
1）优化脱敏SDK：增加对多类加密算法和场景的支持，满足非日志场景的数据脱敏需求，提升数据安全治理能力。
2）推动公共框架/组件治理：联合相关负责人统一标准，屏蔽掉业务信息的输出，并添加对字段级别的脱敏配置。
3）优化敏感信息检测规则：持续优化敏感信息检测规则，并通过增加二次过滤黑名单机制，降低敏感信息检测误报率。
后记
显然由于敏感信息检测规则无法确保百分百准确和不遗漏，想要实现日志内敏感信息的完全治理，单靠检测和整改总归是滞后的，好的方案仍然是从源头把控住敏感信息的存储、使用和传输，但如果想到做到这种程度目前看来还有很大的难度，也欢迎大家一起探讨。
