0x1 本周热门话题
话题一：各位领导，有员工收到了一封来自被黑的公司邮箱的钓鱼邮件，并扫描了钓鱼邮件中的二维码，导致个人财务损失，请问这笔个人财务损失该如何处理？
温馨提醒：此钓鱼邮件已被多家单位收到，建议全体同仁警示内部员工，也可效仿进行全员测试，在春节前后、冬奥会期间加强安全意识。
A1:当天需采取紧急措施：
A2：接到员工反馈后，立即实施了类似的应急处置措施，但仍有员工受到影响，反映“一扫钱就没了”，因此对上述犯罪网站进行了封杀。
A3：这个听上去有点凶，扫码就没了，除非是个人支付的二维码，没看清楚指纹就确认支付。很多人会说“接到诈骗电话后，去ATM机按诈骗检查的指示给对方付了钱”，钱就直接没了，是自己忽略了关键操作。
其实还是人性的贪婪，“能拿补贴就能拿”，一不小心就会掉入“黑客挖的陷阱”。
至于员工所关心的个人经济损失，其实是问经济责任，这个可以交给警方去界定，公司不应该承担任何法律赔偿责任。账号被盗的员工违反了公司规定，没有保护好账号，但他也没有赔偿责任。黑客应该承担法律责任。不过，还是帮他走个流程，抓到罪犯，挽回损失比较好，毕竟感情上还是工作盗窃。话虽如此，公司其实也只是为了增加公司账号的可信度，他做了什么导致扣款的事情很重要，一定要追查出来。个人如果一不警惕，就会在外界上当受骗。
A4：去年很多企业都受到了人力资源和社会保障补贴的影响，今年又出现了这种情况，只不过名字不一样。
上面的截图中，填写银行卡号领取补贴是正常的，但这种骗局一个明显的特点就是要求员工填写银行卡“可用余额”。这是正规网站上不会存在的选项，但骗子前期埋下如此多伏笔，就是为了确切知道能骗取受害者多少钱。很多人急于领取补贴，不假思索就填写了。
套路都一样，缺乏个人意识，最重要的是贪婪。你想知道这个案子有没有走法律程序吗？
A5：遭受经济损失的员工意识到被骗后第一时间报警，警方正跟进调查，并在事发当天采取了以下应急措施：
主题二：你有员工行为风险预警吗？通过收集社会舆情、诉讼、工商、行政处罚等信息，结合个人信用、银行账户状况，对员工进行综合分析，输出风险报告。主要目的是防止员工在8小时之外因个人问题采取极端行动，给公司造成损失。
A1：这个太全面了。个人信用、银行账户信息。一般公司能获取这些数据吗？就算能，也会侵犯员工个人隐私权。我们跟员工签了《员工个人信息收集告知同意书》，但仅限于工作范围。
A2：这明显超出了工作需要的个人信息收集范围，涉及涉嫌侵犯隐私、非法监控等行为，分析结果不能作为对员工处罚的依据。
监控员工稳定性和员工离职倾向是允许的，但需要考虑合法性、正当性和必要性，而不仅仅是授权。即使授权，员工也是被迫的，可以起诉公司。《网络安全法》、《数据安全法》和《个人信息保护法》早已颁布实施。个人信息的处理必须符合以下条件：
第五条 处理个人信息应当遵循合法、正当、必要和诚实信用的原则，不得采用误导、欺诈、胁迫或者其他手段处理个人信息。
第六条 处理个人信息应当具有明确、合理的目的，并应当与处理目的直接相关，以尽量减少对个人权益的影响的方式进行。收集个人信息应当限制在实现处理目的的最小范围内，不得过度收集个人信息。
第七条 个人信息的处理应当遵循公开、透明的原则，公开个人信息处理规则，明示处理目的、方式和范围。
A3：这不是防删库、防跑库的方法。人（恶意）只是一个维度，还有主机（可靠性）、系统（批量功能可用性）。先确定整体风险，定义极端行为影响范围和成熟度；再对内部系统、数据库、运维管理进行分类，逐一评估恢复、灾备、日志审计能力，形成多种方案（自动发现、审批、辞职权限衔接、演练），覆盖之后再评估风险是否降低。
A4：行为安全是动态安全，无法控制，我们只能通过控制软件、硬件、系统来降低行为安全的风险。不要打着网络安全的旗号做作恶的帮凶……如上所说，人只是其中的一个要素，有时候流程、制度设计更重要，人上班不是为了造成破坏，要注重系统容灾、人文关怀。在目前的变更管理水平下，解决无意故障的优先级要高于恶意行为的优先级。如果要刻画员工的安全意识，我觉得可以从以下几个方面入手：
如果真的要做到不删库，光靠安全画像肯定是不够的，关键还是技术管控，比如权限管理、禁止恶意命令执行、重要操作双重审核、数据备份管理等。
话题三：想请教各位专家关于交易数据加密存储的问题：第一，关于交易数据的加密存储，有没有成熟的解决方案，既能保证数据的保密性，又能保证交易性能不受影响？第二，交易数据加密存储后，其他使用交易数据的相关系统如何正常使用加密的交易数据？
注：这里的交易数据是JRT 0197-2020《金融数据安全分级指南》中定义和要求的。
A1：上面的准则中，交易数据基本等于很多数据，这种数据有很多种，为了符合规定，一般会采用透明加密，你可以拿公司资源试试数据库透明加密。不过建议问一个问题：为什么要加密存储？根据预期交付成果，数据库透明加密可能成为成本最低、业务无感知的方案，也可能成为最自欺欺人的方案。
我们遇到的检查目标是检查 DBA、SA 等非业务人员是否可以看到所有敏感数据。结果是字段必须加密，因此你确实需要确认预期的交付结果。
A2：三级系统需要加密，数据库透明加密是解决方案之一，我理解加密可能有三级，从上到下：
其中应用系统不仅实现起来麻烦，而且很有可能达不到性能要求，而且这一层也不一定能通过检验，因为检验的预期就是看落地是否加密，而存储最简单，成本低。但是我们目前使用的存储，并不支持加密存储。
A3：交易数据加密建议优先针对个人信息，采用应用层对称加密存储，可以使用SDK的方式；其他应用先申请解密，再用自己的密钥加密存储。如果有开发支持，可以支持基于权限的加密方案。
Q：不知道应用层有没有实现的案例，架构是怎么样的？秘钥放在哪里？对性能影响大吗？目前我们正在找解决方案，今年一定要解决的问题，哪怕评估不通过，我们也会解决。
A4：应用层加密需要有完整的数据字典，并且数据库字段含义定义清晰，才能进行针对性的加密。交易数据字段非常多，对所有传入数据进行加密不太现实。
A5：确实不可能对所有数据都这么做，要针对具体场景，数据资产要尽量组织清晰，最好不要存储不必要的数据，但这个工作做起来比较难。
至于秘钥存放在kms，kms的工程成熟度很高，稳定性也经过验证，但是如果交易数据太多，几百上千个字段，kms可能存不下来。
性能上怎么形容呢？我们一个x86集群就能处理十万TPS，瓶颈不在于加密机，加密机能处理几十万。但没那么简单，很难给出简单的结论。总之，透明加密对业务的依赖最小。我们这么做是为了满足IT审计和上面提到的一系列监管要求，也就是不让我们自己人看到明文。
A6：可以考虑对数据库做一个统一的代理，类似数据库防火墙，设置加密策略，针对具体的数据库，根据策略对字段进行不同类型的加密和解密。
Q：数据库级加密有方案吗？依赖数据库自身功能吗？
A7：数据库层依赖数据库的支持，离应用越远越容易出问题，因为你不知道应用是怎么用的。而且数据库层跟应用层一样，也会涉及到应用梳理数据链路和场景，实际成本并没有降低……单纯考虑性能或者绕开去做，都不是最重要的。
A8：有加密网关产品，你可以看看是否满足你的需求。如果产品有性能问题，也可以考虑自己做。覆盖需要加密的数据库就行，跟数据库本身关系不是太大，一般都是解析通讯协议来实现，一般加密机不是瓶颈。如果要满足国家加密改造要求，这也是比较好的实现方案。自己加密应用也是可以的，但那是推应用改造的问题。
A9：建议把密钥管理和加密分开。特别是应用层的加密，把密钥交给应用程序，让它自己做，而不是在密钥管理系统里管理要加密哪些字段。我觉得应该尽量靠近应用程序，不要离得过远，离密钥管理系统越远越好。
以KMS为例，可以是一个kms负责dar enc，自然这里面肯定要有一个app profile，但是要不要细化去维护加密字段，个人觉得这里就不用维护了，责任太大了。
0x2 本周精彩
在互联网的世界里，“安全”与“开放”是永恒的话题，但“开放式创新”的前提必须是“安全可控”，也就是说，没有安全的API，创新就无从谈起。
0x3 2022年第4周运营数据
金融企业安全建设实践组 | 第132期
本周共有127位群成员参与讨论，群发言率29.74%，群发言消息556条，人均发言4.38条。
企业安全建设实践组 | 第57期
本周共有70名群成员参与讨论，群发言率15.12%，群发言消息325条，人均发言4.64条。
