![关于企业日志脱敏治理经验的探讨 | 总第207周 关于企业日志脱敏治理经验的探讨 | 总第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:看大家的讨论好像都聚集到日志数据安全管理上面去了,如果是单就日志来进行数据安全管理,假如基于当前排障需要确实需要记录修改敏感日志,我觉得可以考虑把日志中的敏感信息进行转码或者加密,需要排障时再把特定敏感日志解码出来,这样做有点麻烦但因为排障这种情况不是经常性触发,带来的管理成本有限。
-
改源头。花笨功夫,深入到每个系统和运维排障的场景中去分析,看看日志中记录这些敏感个人信息是否的必要性,再明确改造要求、推动改进。如果可以对乙方足够强势,则制订日志标准、要求其遵守;如果做不到强势,则单独分析、单独改进;
-
源头不改,在通道侧改。主要思路是将日志做统一、集中收集,在日志集中的场所做脱敏或安全控制;
-
短期内改不了的,做宣贯和管理。
0x2 群友分享
【安全资讯】
中国头部银行IT投入大起底
关于实施个人信息保护认证的公告
【收藏】20起适用《数据安全法》的执行案例
【安全技术】
关于企业日志脱敏治理的经验之谈
从0到1:利用云函数规避溯源及封禁
微信安全基于 Flink 实时特征开发平台实践
这个开源组件太强了,仅需三步完成 SpringBoot 日志脱敏
GB∕T 42582-2023 信息安全技术 移动互联网应用程序(App)个人信息安全测评规范
---------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送(每周)。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球,方便大家查阅。
往期群周报:
攻防对抗之如何检测加密流量?| 总第206周
浅谈企业办公终端的软件管控方法 | 总第205周
企业中的API安全治理如何落地实践?如何防护让域控DC更加安全?|总第204周
如何进群?
如何下载群周报完整版?
请见下图:
![关于企业日志脱敏治理经验的探讨 | 总第207周 关于企业日志脱敏治理经验的探讨 | 总第207周]()
原文始发于微信公众号(君哥的体历):关于企业日志脱敏治理经验的探讨 | 总第207周
评论