0x1本周话题
话题：在传统关系数据库里有数据加密情况，条数千万级，除了同态加密（难实现），在业务层面，大家有好的搜索处理办法么？考虑到性能，数据库自带加解密算法也排除。
A1：支持密文检索就可以，看需要的密文运算，我们只需要密文检索。
Q：密文检索具体怎么支持？把要搜的东西也加密后搜，这意味着密钥长久不能变，怎么考虑过期呢？
A2：明文加密后对比数据库密文是可以的，但是模糊搜索就难了。我记得有密文检索技术，具体不知道咋做，可查一下。
A3：业务上解耦，密文搜索本来就是伪命题。如果要关联查询，可以通过hash字段；如果是利用部分内容查询，那说明数据字典就没做好。
我们碰到过拿身份证最后第2位判断男女，加密后就没办法了，问题是难道就不能有个性别字段么？包括取生日之类。
A4：身份证编码方案实在是违反数据库第一范式的最佳反面教材。关键字段HASH化。
Q：模糊查询能查吗？
A5：要不要性别？该不该留性别？如果要，就建这个元数据，不该留就不留。使用不耽误加密，加密不耽误使用。模糊查询可以，但是效率不如传统方法，所以焦点还在数据确权问题而不是技术。
A6：身份证号一般不做模糊，那如果像手机号、卡号这种有模糊查找需求的，HASH是做不到的。
A7：具体需求场景是什么？是掌握了脱敏信息，想找原信息？至少我待过的任何一家公司都可以用密文做风控，只要同一个客户的密文值是一样的就不影响。
Q：大家数据库存的个人信息C2有加密存储吗。感觉这个事情做不下去。性能，还有上下游系统，运维排错。有没有好方法？
A8：能做。不过梳理上下游关系，只能自己搞。供应商帮不了你，但是全套平台可以有。不用硬做，我们做了几年了，也就这样过来了。主要看上面有没有决心。
Q：你们是应用级的还是数据库级的中间件？做应用吧。中间件这种不适合银行的。不能出一点事。
A9：我们是应用级的。可以先找一个非核心应用做，积累经验。但如果你说，历史代码动不了，那还是趁早算了。
A10：银行有个跑批，卸数这个是很头疼的问题，还有就是数仓做报表的加密完以后，做数据加工应该会有灾难。
A11：不一定。先要思索下，为什么会有需要被加工的敏感信息。比如个人信息。原则上数据加工是不涉及C2，C3这种金融个人信息的。根源还是没有业务架构，对数据管理缺失。造成后面改造就困难重重。前人的锅，还有比如大量用到存储过程。
A12：是的呀，原来可能哪里有数据架构和数据治理，能用就好了。比如家庭住址，看小区是不是好小区。算这个人授信可以做一个取值参考的。有很多类似的场景。如果加密了，就很尬。
A13：我昨天就提过：当时偷懒，就写一个address字段里面，随便拿。加密了就坏菜了。其实正常是小区可以单独写个字段分析。包括你们取数，根据最小必要性。因为你要分析小区，你就取了客户详细地址。数据安全审批这边也是不允许的。也是一样尴尬。还有很多应用场景。比如分析是80后还是90后。也是去身份证中间字段，而不是根据生日字段分析，都是神一样的代码。
A14：正常，真一加密会发现很多妖魔鬼怪。历史代码很多不敢动。主要是买的系统，用了多年以后谁都不敢动。
A15：调研还是需要的。不管是等保，iso27001，银保监会和人行的要求，还是密评要求，都要求敏感信息加密的。总有一天会强制要求你们加密的。躲是躲不过的。而且很难找到实践方案，属于家家都有本难念的经，但是家家又不一样。
但是怎么梳理上下游关系和加密中碰到的坑，需要你们梳理摸索的，这个没有厂商可以解决。尽早数据治理开展起来。先期把问题收集好。
整个加密方案是有实践方案。我们是采用多套方案，主要应用加密。少量系统可以选择中间件方式加密。中间件模式对于外购系统或者不重要系统其实挺好的。但是不能用在重要系统上，稳定性是第一的。
A16：厂商只能做通解，降低社会成本。一家一个样的厂商不会做，这样他自己边际成本下不来。
比如：中间件不动，还是明文，但我搞个扎口，从这个口出都密文了，厂商能做。还有其他口能绕过，厂商做不了 有的应用已经有了接口，不适应你的新接口不肯改造，厂商做不了。
这个事很难做到应用无感的，不要抱这种期望。
A17：其实想的是一些老旧系统动不了代码的，通过这个模式，降低影响。完全无感我感觉应该确实不可能。能少动就尽量少动应用。
A18：那听起来就是透明存储加密了，应用看到的还是明文，应用要用明文去做逻辑处理的。
A19：可以的。只要改配置文件调用数据的ip就可以了。无感的问题还在于不适合银行这种重要系统的。你们要求是稳定第一。这种纯黑盒的，出了问题你都不知道出哪。可以用在营销活动，内容运营这种一般系统上。
A20：如果能理清楚都有哪里调用了数据，对业务影响也不会那么担心了，但这本身就不容易。改造最难的不在于一个接口跑通，而在于断掉有隐患的旧路。
