0x1 本周话题TOP3
话题1：各位大佬，员工因为使用公司邮箱收到被盗号的公司邮箱账号发的钓鱼邮件，扫描了钓鱼邮件的二维码而导致个人经济损失。这种个人经济损失如何处理？
温馨提醒：此钓鱼邮件已多家单位收到，建议各位同仁警示内部员工，也可仿造来一波全员测试，加强春节前后及冬奥会期间的安全意识宣贯。
A2：类似的应急处理措施在收到员工反馈后立马就做了，还是有员工中招了，而且中招员工反馈“一扫钱就没了”，所以上面犯罪网站打码了。
A3：这个听着有点猛，扫码就没，除非是类似个人的收款二维码，扫描没看清楚指纹就确认支付了。很多人会把“接到诈骗电话后去atm上按照谎称为检验的指导给对方打款”也说成钱直接没了，自己对关键操作没留意都忽略了。
其实还是人的贪念，“可以领补贴”。稍有不慎，就掉入“黑客挖好的坑里面”。
至于员工关心的个人经济损失，其实是想问经济责任吧，这个交给警察界定就行，公司讲法理应该没有赔偿的法律责任，被盗的那个员工违反了公司规定没保护好账号，但也没有赔偿责任，盗号的人才要承担法律责任，不过还是尽心帮他走走流程抓下罪犯挽回损失比较好，毕竟从情感来说是工作事宜被盗的。话又说回来和公司有关的其实只是公司账号增加可信度，他做了什么操作导致扣款很重要，要溯源，个人没有警惕心那在外头也一样被骗的。
A4：这个去年已经有不少公司中招了，是以人社补贴的名义，今年改了名又来了。
上面截图里，领取补贴要填银行卡号很正常，但这个骗术的一个明显特点是，需要员工填写银行卡的“可用额度”。这是所有正规网站都不会存在的选项，但骗子前期铺垫那么多，就是为了准确知道能从受骗者那里骗到多少钱。很多人急于领取补贴基本不假思索就填了。
套路都是一样的，个人意识不够，最主要的贪。想了解一下后来这个走司法程序了么？
A5:有经济损失的员工在意识到被骗后立即就报警了，警察在跟进调查，同时事发当天做了如下应急措施：
话题2：大家有做员工行为风险预警吗？通过收集公开的舆情、诉讼、工商、行政外罚等信息，结合个人征信、银行账户状态对员工进行综合分析，输出风险报告，主要目的是预防员工因8小时外的个人问题，对企业实施极端行为造成损失。
A1:这个太全了，个人征信、银行账户，这些数据一般企业能拿到吗，即使拿到了也侵犯了员工个人隐私权益，我们有和员工签署《员工个人信息收集告知同意书》，但是也仅限工作范畴。
A2:明显超出了工作所必需的个人信息收集范围，涉嫌侵犯隐私和违规监控，分析的结果也不能拿来作为处分员工的依据。
监控员工稳定性、员工离职倾向这类动作可以，但需要考虑合法、正当、必要性，不仅仅是授权就可以了。即使授权，员工也是被迫的，还能反告公司。网络安全法、数据安全法和个人信息保护法都发布实施很久了，个人信息处理需满足以下条款：
第五条 处理个人信息应当遵循合法、正当、必要和诚信原则，不得通过误导、欺诈、胁迫等方式处理个人信息。
第六条 处理个人信息应当具有明确、合理的目的，并应当与处理目的直接相关，采取对个人权益影响最小的方式。收集个人信息，应当限于实现处理目的的最小范围，不得过度收集个人信息。
第七条 处理个人信息应当遵循公开、透明原则，公开个人信息处理规则，明示处理的目的、方式和范围。
A3:防止删库跑路不是这么做的，人（恶意）只是一个维度，还有主机（可靠性）、系统（批量功能可用性）。首先确定风险大盘，定义极端行为的影响高低和成熟度；再分类，内部系统、数据库、运维管理，挨个评估恢复、容灾、日志审计能力等，形成多种解决方案（自动发现、审批、离职权限收敛、演练）、覆盖了之后评估风险是否削减。
A4:行为安全是一种动态安全，不可控的，只能从软硬件、制度等控制，来降低行为安全的风险。不要以网络安全的名义为虎作伥…上面提了，人只是一个元素，有时候流程、系统设计更重要，大家上班不是为了搞破坏，关注系统容灾备份和人文关怀吧，以现在的变更管理水平，解决无意造成的故障的优先级大于恶意行为的优先级。而如果要对员工安全意识画像，我觉得可以从下面几个方面着手：
真要防止删库，靠安全画像肯定是不够的，关键还是技术管控，比如权限管理、恶意指令禁止执行、重要操作双人复核、数据备份管理。
话题3：向各位专家请教一下关于交易数据加密存储的问题：一是关于交易数据加密存储，有没有成熟的解决方案，既能保障数据的保密性，又能保障交易性能不受影响；二是交易数据加密存储后，其他使用交易数据的关联系统如何正常使用加密后的交易数据。
注：此处的交易数据在JRT 0197-2020《金融数据安全 数据安全分级指南》中有定义和要求。
A1:上述指南中，交易数据基本上等于很多数据。此类型很多，为了合规，一般做透明加密，可以用公司资源试试数据库透明加密。不过建议还是追问一层，为什么要加密存储，根据期望交付成果的不同，数据库透明加密有可能会成为业务无感知成本最低方案或者是最自欺欺人的方案。
我们碰到的检查目标是：查dba、sa这些非业务人员能不能看见全部敏感数据，结果就是要字段加密，所以这个你们还真得确认下期望交付结果。
A2：三级系统就需要加密，数据库透明加密是方案的一种吧，我理解可能有三个层面的加密，自顶向下依次是：
其中，应用系统实现既麻烦，又极有可能不满足性能要求，而且这层可能过不了检，因为检查预期就是看落地是否加密，而存储最简单，成本也低。不过，目前我们采用的存储不支持加密存储。
A3：交易数据加密建议先以个人信息为主，采用应用层对称加密存储，可以用sdk方式；其他应用使用先申请解密后再用自己的密钥加密在加密存储，如果有开发支持可以支持基于权限的加密方案。
Q:不知道应用层是否有实现的案例，架构咋样？秘钥放在哪里？对性能影响大吗？目前正在寻求解决方案中，今年必须解决的问题哪怕是评估不通过也行。
A4:应用层加密，要有完备的数据字典，明确定义的数据库字段含义，才能有针对性加密。交易数据这么多的字段，所有入库数据都加密，也不现实。
A5:确实不可能所有数据都能这么干，得针对特定场景，其中数据资产肯定是梳理的越清晰越好，没必要存的数据当然是不存为好，但是这个工作很难做吧。
至于秘钥存在kms，kms的工程成熟度很高，稳定性都得到了验证性，但如果交易数据太多，几百上千的字段，kms就有点存不来了。
性能这事，怎么说呢，10万tps，我们用x86集群也扛得住，而且瓶颈不是加密机，加密机能承受几十万，但也不是那么简单，没法简单地给个结论。总之，最不依赖业务的一定是透明加密，我们这么干也是为了满足上面说的IT审计以及一系列法规要求，就是要让自己人看不见明文。
A6:可以考虑数据库统一做一个代理，类似于数据库防火墙，设置加密策略，针对特定数据库，字段按照策略进行不同类型的加密和解密。
Q:有数据库层面加密的解决方案吗？是否是严重依赖数据库本身的功能？
A7:数据库层面依赖于数据库的支持了，而且离应用越远，越容易出问题，因为你不知道应用要咋用。而且数据库层面做跟应用层面自己改造，一样会涉及让应用梳理数据链路和场景，实际成本未减少的…单纯考虑性能，或者旁路方式来做，都不是最主要的。
A8:有加密网关的产品，可以看看是不是符合需求。性能方面如果产品有问题，也可以考虑自己来做，覆盖需要加密的数据库即可，与数据库本身没有太多的关联，一般是通过解析通信协议来实现的。一般情况下，加密机不是瓶颈所在。如果要实现国密改造要求，这样来做也是比较好的一种实现方案，应用自行加密也可以，不过那就是推送应用改造的问题了。
A9:建议把密钥管理和加密分开。尤其是应用层的加密，把密钥给到应用，他自己去做，而不是在密钥管理系统上管理对哪些字段加密。我觉得要离应用越近越好，而不是越远越好，且离密钥管理系统越远越好。
以KMS为例，它可以是一个负责dar enc的kms，里面自然还是要有app的profile的，但是是不是要细化到维护加密那个字段，我自己认为不需要在这里维护，太多责任。
在互联网的世界里，“安全”和“开放”是一个永恒的话题，但“开放创新”的前提必然是“安全可控”，也就是说没有安全的API，创新是不可能的。
本周群里共有 127 位群友参与讨论，群发言率为29.74%，群发言消息数为 556 条，人均发言数为 4.38 条。
本周群里共有 70 位群友参与讨论，群发言率为15.12%，群发言消息数为 325 条，人均发言数为 4.64 条。
Are there any mitigations for this vulnerability? If no patches are available for your operating system, you can remove the SUID-bit from pkexec as a temporary mitigation; for example: # chmod 0755 /usr/bin/pkexec
漏洞验证github上已有POC，https://github.com/berdav/CVE-2021-4034。
中央广播电视总台2022年3·15晚会主题发布
https://vod-finance.cctv.cn/cctv/cctvh5/cctv2/2021/share/index.html?pageId=app://ARTI1642904608920936#/detail?link=ARTI1642904608920936
——————————————————————————–
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：员工被公司盗号邮箱钓鱼后的个人经济损失处理、员工行为风险预警合法性暨交易数据加密存储解决方案探讨 | 总第132周
