降本增效下业务安全怎么做；员工信息应保留多久

▎各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 226 期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

本期话题抢先看

1. 在一些企业逐渐施行降本增效的大环境下，企业网络安全应如何保持业务稳定？

2. 巨头企业都有相对成熟的服务，出现重大事故的情况，对保障企业核心业务稳定性和可靠性还有哪些值得深思的学问？

3. 员工信息应该留存多久，有相关规定吗？

话题一

话题：近期的中国互联网巨头企业频出核心服务重大宕机事故，在一些企业逐渐施行降本增效的大环境下，企业网络安全应如何保持业务稳定？

A1：

各大厂商不是有高可用架构吗，不是有容灾吗？什么这个时候没有切换呢？

A2：

高可用和容灾跟降本增效是相反的。你要想降本增效，必然要做成非高可用、低容灾。

A3：

现在大公司的业务体系比较复杂，降本增效导致很多业务交接不到位，会造成一定的问题，给修复也带来很大的问题。当然这个不一定是主要问题，但也是一部分原因。另外这个也与业务有一定关系。降本可能导致基础设施薄弱。如果扩容不平滑也会出现问题。

A4：

说到交接不到位，其实可能就是进行了重组、优化或外包等操作，这可能导致业务流程和责任划分不清晰，从而增加了宕机风险。因此，在降本增效的同时，需要进行充分的业务分析和交接，确保各个环节的顺畅运行。

A5：

降本增效和高可用容灾确实存在一定的矛盾。降本增效通常会追求更简洁、更经济的解决方案，可能会在某些方面降低系统的冗余和可用性。在制定降本增效策略时，需要权衡成本与风险，并确保在降低成本的同时，不会牺牲关键业务的稳定性和可用性。

Q：这些巨头企业都有相对成熟的服务，出现重大事故的情况，对保障企业核心业务稳定性和可靠性还有哪些值得深思的学问？

A6：

这种最重要的还是事件响应的速度和措施吧，这个很值得深思，还有一些该有的机制为什么在出问题得时候失效或者部分失效，演练工作的有效性验证如何判定。

A7：

其实这种大型事故巨头企业一般的处理方式就是应急——定责——复盘——整改和落地，最后演练。其实说句实话，下次出现这种问题还是一样的整改计划跟复盘，这个是个值得深思的问题。大企业的架构优化和变动都是比较困难的，牵扯到部分合作、绩效共担、成本等等。这个平衡也比较难把握。要真正做好一件事是比较困难的。对于小企业来说最值得深思的就是在成本允许的情况下可以多云。增加核心业务可用性。

A8：

企业越大历史问题越难解决。对于部门来说KPI指标在那里，毕竟谁都不想出问题。能不动就不动。在这种情况下大家可以想想推动整改的难度。我是深有体会的。曾经有个项目推了一年多才落地，要经历层层层层审批、KPI的共担等等。

A9：

稳定性、可靠性这些问题表面看是技术服务的原因，核心点还是管理问题。系统稳定运行这么多年，难免会显露出麻痹，再加上历史积累，都想着能抗住就行，平时也缺少一个契机能说服各方，哪怕技术很牛逼，做了可用性全面评估，识别出了可能出现风险了，但是决策往往都是做一些不痛不痒的改进，核心关键问题都是组织和管理，没人能做出这种决策，只能等着出事了，才能有推动改革的驱动力。

话题二

员工信息应该留存多久，有相关规定吗？

A1：

默认永久的，就和财务数据一样，哪有过期删除的。

A2：

我们这是15个工作日。永久的可能是国央企事业机关单位，一般企业不会。

A3：

巡视组年年来查，删了怎么活下去。

A4：

你可以保存日志信息，或者脱敏后的个人信息，不能保存原始信息。

A5：

你说的15个工作日是他们的数据吧，话题问的可能是员工的姓名、家庭住址、手机号身份证号银行卡号之类的。

A6：

这些属于敏感信息，需要在业务结束后进行去标识化处理或者删除。

A7：

日志信息可以保留3年，原始数据本身一般不超过15个工作日。比如原文：张三，家庭住址xx市XX街道XX小区XX单元XX号，电话号码1XXXXXXX ，要做脱敏处理。而且如果张三离职了，与你组织无关系了，去标识化要做成不可逆的。如果业务还在持续中，可以做成可还原的。巡视组只是检查有没有，你明文保存就是有问题。

A8：

实际中是一直保存的，包括在职、离职、退休、求职人员。请教一下，这个15天是有具体法规吗？

A9：

《GBT35273-2020信息安全技术个人信息安全规范》,这里面提到了2点: 1. 业务期限结束，应处置 2. 用户要求注销，15日内处理完这两点结合起来：业务结束，已经无意义，和注销没有区别。这个觉悟得自己琢磨，没明说15日内处理，但是如果业务已结束，注销不注销有区别吗？业务已结束，你保留个人信息尤其是敏感信息，就是留了一个处罚你的口子。

A10：

如果一个专门发违规信息的人，因为被你们封禁了，现在在你们平台申请注销，后续他再用原手机号来注册，这个注册批准呢，还是不批准呢？

A11：

不批。违规理由充分，可以不批。

A12：

不批，根据个人信息保护法注销机制，说明你没有完全注销这个动作啊。

A13：

你要报备啊。有人发违规信息，你不能自己藏着掖着。

A14：

刚看的管理制度，说是至少会保存两年。

A15：

日志保存两年。记录保存两年，不是员工档案，就算是档案，也要处理一下。

A16：

我们最近收到了一个网安的GA1277标准，里面就要求永久保留用户的注册信息，GA标准比GB标准还高。

A17：

这个是特殊行业需要单独处理。

本期观点总结

在本期关于企业安全降本增效的讨论中，提到了在制定降本增效策略时，需要权衡成本与风险，确保关键业务的稳定性和可用性不会受到牺牲。其次，企业应建立有效的事件响应机制，并进行演练和验证。比如大型企业在处理事故时常采取应急、定责、复盘、整改和落地的流程，但这种模式是否能够真正解决问题值得深思。同时，对于大企业来说，架构优化和变动困难重重以至于业务稳定性和可靠性问题实质上是管理问题，技术服务只是表面原因。在管理层面，需要推动改革、加强组织和决策，为业务赋能。

在员工信息留存时长的讨论中，似乎没有统一的规定，不同情况下可能存在不同的要求，但大多数企业仍需要在一定时间后对这心信息做脱敏或去标识化处理，并依照《GBT35273-2020信息安全技术个人信息安全规范》进行落实。

近期群内答疑解惑

Q：银行使用云DDOS会有合规问题吗，因为所有流量都要先转发到第三方云检测中心？

A1： DDoS流量清洗需要检测应用层信息吗？ A2： 买的云DDoS服务，想不通有啥合规风险，都属于基础服务。 A3： 如果做应用层检测应该要上传证书进行Https解密吧，除此以外不知道有啥风险。 A4： 这个问题可以参考人民银行的信息安全通用规范，使用云DDoS，相当于使用外部系统，按照外部系统进行评估，签署相应的协议。

Q：敏感数据加密，有没人对比过用加密函数和应用层自行加密（例如Hutool），哪一种更好？

A1： 字段加密，底层做起。 A2： 加密函数是指数据库的加密函数。 A3： 如果SQL语句不是很复杂可以考虑用SQL解析，然后对SQL语句进行改写，Druid和Sharingsphere都相应的功能。 A4： https://zhuanlan.zhihu.com/p/649816930 这文章觉得应用系统实现加密比数据库加密函数要好。 A5： 场景不同罢了。 A6： https://mp.weixin.qq.com/s/BMjVc_PNh8Qx8fjja84Thw 公司如果做数据库加密，更多考虑的是数据库字段加密的吧。使用代理的Shardingshpere，我们这边做过测试，也调研过阿里云的加解密，后来最终由中台自研了一套加解密服务和密钥管理平台。 A7： Shardingsphere 最大的问题是需要专人管理，其实成本比买硬件还高，而且Shardingsphere是数据库整体解决方案，不是单独为加解密做的。透明方式部署的硬件加解密，大家都省事。

Q：企业私有云搭建的App，应该找谁备案App？

A1： 有对外投放渠道吗？如果只是自用，没有在应用市场投放不用，如果有投放在市场，我这边是在通信管理局备案，不过实际过程中，你找你们的运营商协助你们备案就好了。 A2： 如果只是自用，没有在应用市场投放不用，如果有投放在市场，我这边是在通信管理局备案，不过实际过程中，你找你们的运营商协助你们备案就好了。 A3： 没有对外投放，感谢。但是老看到说，以后不备案的App，手机直接不让安装了。 A4： 不对，好像规定是说App主办者、网络接入服务提供者、应用分发平台、智能终端生产企业这些角色。 A5： 内部用按规定说也是要备案吧。 A6： 应该说是网络接入服务提供者，不过我理解为这种被查到可能性小，不过备案也不太麻烦就是了。