关于企业日志脱敏治理经验的探讨 | 总第207周

admin

86327
文章

81
评论

2023年9月23日14:49:43评论6 views字数 2890阅读9分38秒阅读模式

‍‍

关于企业日志脱敏治理经验的探讨 | 总第207周

0x1 本周话题

话题：随着个人信息保护工作的深入，我们内部排查发现有很多系统都会处理个人敏感信息，而且会在系统运行日志中打印这些敏感信息；运维人员的意见是打印出来便于排障，如果需要改造系统，也需要较大的改造成本和较长的改造周期；如果深入去分析场景、确定每个系统的改造要求以兼顾排障和数据安全，人力投入太大；如果不改造这些系统，就必须要在各个信息出口部署工具、开展有效的监测。像这种问题，可有什么好的办法，能兼顾运维人员排障、数据安全风险可控、总投入成本不高？

A1：所有涉及敏感信息的数据存储，关键字段全部加密，所有业务层面涉及敏感信息的全部脱敏（脱敏的效果必须做无基于现有信息，完全无法定位到个人，包含姓名，电话，活动轨迹，地址等），脱敏的后数据，实质上是数据降级，不再归于敏感数据。而在业务处理过程中，确实需要涉及处理敏感的信息的，需要单独进行申请并做好合规流程。至于排障，理论上不涉及敏感处理。

A2：同意，日志不允许存敏感信息，敏感信息不等于排障信息，得弄清楚运维排障时，需要的是什么具体信息。脱敏方式有信息转换方式。比如我们内部有个场景，研发想根据客户的资产信息做定位排查如12345，那么定位其实他们只需要首位和末位，那研发在写日志时，禁止写12345，写15就好了。

A3：一是做好权限控制，先控制这些机器的访问权限，仅限有需要的人使用，并且要有操作日志记录+审计，对这些人进行数据安全风险培训；二是外购较多就建议在日志平台去做统一的收口改造，否则就是各系统自行改造，优先级是找数据比较敏感且量比较大的系统推动改造，一个一个来，跟厂商加强合作讲清楚风险。

A4：搞个siem/soc/xdr，日志汇聚后统一脱敏，不在应用日志的源头脱敏，成本会小一点，运维和权限控制也放在这层。

源头脱敏的话，就是安全团队写个组件，然后甚至还需要开发配套的一些日志检索等工具，但是有一定的持续运营的成本，因为业务是不断增加和适配的。说白了就是脱敏这个活谁干的问题，这种事情还是交给下游的人干比较好。

A5：源头做会简单一些，等到下游做成本高。这个问题之前我们也遇到过，但其实真正做了之后并没有那么大的困难和不便，从日志排错来说，只要有对应的标识和脱敏的相关信息就可以完成问题定位，另外就改造成本来说，开始的时候会有一些，后面将这些功能做成工具插件，后续的其他系统做起来就比较容易了。我们针对运维层也是这样，但是有绕过的情况出现，所以后来还是改应用。

开始的时候肯定阻碍很大，只有拿着监管要求说服大领导再推，不然真的很难。

Q：请教下：（1）你说的改造，是自研还是外购系统的改造？（2）对排障场景的分析，还是要投入人力去分析，才能确定改造需求。投入人力大概多少，系统数大概多少？

A6：（1）半自研，外包驻场；（2）目前做了个人信息的脱敏，投入的人力和之前的变化不大，因为用到这个日志的时候其实研发人员只是需要定位到问题点，对日志未脱敏数据的依赖不是强依赖的。

A7：我觉得总体思路还是先梳理，再治理，核心还是把控好数据泄露和合规风险。先把场景和风险点梳理好，这个是必要的。至于怎么改造、怎么分阶段、是采取管理措施还是技术措施，视组织情况而定。资源暂时不支持技术改造，那就先上管理措施。跟运维、厂商明确好责任和保护要求，该签协议签协议。先保证责任的兜底，再保证风险的兜底。

A8：如果不改应用系统，光从外围出口做好监测和审计这个成本会非常高，而且效果不一定理想。建议还是回到应用本身看看有没有好的方案，比如个人敏感数据是否可以集中存储，方便做好数据集中安全管理，不要每个系统存储一份，达到缩小数据半径的目的；然后个人敏感数据消费管理方面，重点管好系统间数据消费接口的安全管理，以及前端用户的权限管理、操作日志记录等。

A9：应用在设计上有意识的打印这些信息是不对的，解决思路是发布一个日志标准，对应用排查整改，但不符合你低成本的要求。我们有过一个类似场景，国内部署的工具在一些特殊情况下也会把敏感信息打出来，比如dlp把某个文件名字送上去，文件名是16位卡号或者个人敏感信息，这部分信息又不小心被splunk送到总部，无意中造成了敏感信息跨境传输，其中一个思路也是外围部署工具看流量，比如nifi。这样做的前提是通过日志标准，应用已经至少在日志设计上合规了，补的是漏网之鱼。

A10：如果仅针对能自主管控的应用（包括自研和强势定制外包）出要求，加日志扫描或者统一收集日志统一脱敏，持续加强管理。先把容易统一的ngnix，tomcat中间件之类的管起来。另一方面就是让系统统一集成采用日志脱敏组件模块或者服务。

弱管控的强势乙方，让乙方升级就可以了，一般这种强势的乙方都有更强势的甲方已经要求改了。还有一点是如果整个it没有达到统一管理的阶段的时候，没有必要从安全去推动，安全还是需要与it水平相匹配。这种情况，需要做的是尽职，做宣导和管理，还可以推动连续性、加强排查错误的角度尝试去联系相关团队一起实现日志管理。

A11：看大家的讨论好像都聚集到日志数据安全管理上面去了，如果是单就日志来进行数据安全管理，假如基于当前排障需要确实需要记录修改敏感日志，我觉得可以考虑把日志中的敏感信息进行转码或者加密，需要排障时再把特定敏感日志解码出来，这样做有点麻烦但因为排障这种情况不是经常性触发，带来的管理成本有限。

A12：总结下来几个基本思路：

改源头。花笨功夫，深入到每个系统和运维排障的场景中去分析，看看日志中记录这些敏感个人信息是否的必要性，再明确改造要求、推动改进。如果可以对乙方足够强势，则制订日志标准、要求其遵守；如果做不到强势，则单独分析、单独改进；
源头不改，在通道侧改。主要思路是将日志做统一、集中收集，在日志集中的场所做脱敏或安全控制；
短期内改不了的，做宣贯和管理。

0x2 群友分享

【安全资讯】

中国头部银行IT投入大起底

关于实施个人信息保护认证的公告

【收藏】20起适用《数据安全法》的执行案例

【安全技术】

关于企业日志脱敏治理的经验之谈

从0到1：利用云函数规避溯源及封禁

微信安全基于 Flink 实时特征开发平台实践

这个开源组件太强了，仅需三步完成 SpringBoot 日志脱敏

GB∕T 42582-2023 信息安全技术移动互联网应用程序（App）个人信息安全测评规范

---------------------------------------------------------------------------