服务热线：400-889-1636
业务联系：021-5230 0317
客户服务：021-5230 0319
在线咨询：
数据加密是一个古老的问题，但又是一个无法做到完美的问题，尤其在一个复杂的大型系统中需要考虑方方面面的问题，包括 security， availability， usability， consistentcy， performance，extensibility 等等。除了展示型w88，其他购物w88、平台类w88等涉及用户的都需要做好安全加密工作。
一、为什么要做数据加密？
先说为什么要做数据加密。越来越多的数据泄露事件，比方说 Yahoo 2013年被盗超过10亿用户信息，Yahoo 2014年又被盗超过5亿用户信息，LinkedIn 被盗一亿多用户密码，Ashley Madison 被盗三千多万用户数据以及大量支付信息，Target 被盗近七千万用户数据和银行账号，Adobe 被盗三千八百万用户数据等等，以及由此导致的大量法律纠纷和巨额赔偿，还有很多很多大大小小没有被公布的安全事件，都说明了数据加密和保护的重要性。
还有很多公司要做加密不仅仅是因为保护用户隐私，更是法律法规的要求，不得不做。有些涉及特殊数据，如信用卡号码，那就要做 PCI （The Payment Card Industry Data Security Standard ）；如用户健康信息，那就要做 HIPAA （The Health Insurance Portability and Accountability Act）等等。
任何一个收集以及存储客户数据的公司，就算是初创公司，都应该认真对待这个问题。在圈内我们常说，不是系统会不会黑，数据会不会被盗，而是何时被黑被盗的问题。也许有人会说，就算偷了，盗了，那又如何？这种事可大可小，有公司被黑后，被迫关门了的。所以安全领域内的及时投资，对公司长期来讲都是非常有益的。对重要数据（包括系统密码，用户信息等）进行有效保护，数据被黑被盗的门槛就高了；就算有一天系统被黑了，数据被盗了，也能把损失降到最小。对求创来说，我们在提交给客户最终的w88时，都会设置双重加密措施，保障w88安全。
二、怎么做数据加密？
你说数据加密这么重要，怎么做呢？如果把加密这个问题抽象出来，其实就是要计算一个加密函数：encrypt（data， key）
（当然还有一个函数就是解密，跟加密类似道理，暂且不论）。看上去似乎是一个非常简单的问题，但要把它做好非常不容易。尤其是在一个系统复杂的公司，要考虑的问题很多很多。比方说，密码界有很多算法，应该用什么加密算法，对称的还是非对称的？具体选哪个，AES，DES，RSA，ECC等等，各有什么特点？题外话，笔者在曾经工作过的公司见过很多有趣的例子，比方说有些早期开发人员用 XOR 来加密，或者做点简单的迭代替换，或者自创所谓的加密算法（有点掩耳盗铃的感觉）等等，这些最后都变成 technical debt，需要花很大力气去清理。
每个算法也有不同的变种和模式，各有什么特点，性能如何？如果某个算法被宣布不安全了，如何快速迭代？这个 key 怎么来？多长才是安全的？怎么启动？怎么保存？怎么传播？怎么控制访问权限？怎么知道谁访问了什么？怎么来监控？怎么来预警？怎么来系统性的更新这些 key？key 能不能丢，丢了怎么办？不同的应用可能是用不同的语言写的，怎么兼容？怎么支持大流量等等，等等。还有更加不近人情的要求，比方说如何保证被加密的数据能够 preserve 原始数据的顺序，支持搜索，但又不牺牲安全性等。
一个好的加密设计方案，不仅仅方案本身要满足安全上严格的要求，解决上面提到的很多问题，还需要实用，容易扩展和维护。在数据加密变得越来越重要，系统越来越复杂的年代，如果资源允许，应该把加密服务独立出来，然后提供高性能，统一，简单又容易理解的接口来进行数据加密，让应用开发人员很方便的使用，这样他们只需要专注他／她所擅长的领域，而不需要去思考怎么解决安全问题，因为术业有专攻。好的加密方案应该把数据和秘钥的存储分开，并且把存储和运算分开，尤其在 SOA 架构下， 这可能跟很多传统的数据加密方法（比方说直接实用某个语言的内置库加密解密）非常不一样。很多解决方案往往密钥和被加密的数据同时存在一个服务中，结果就是如果那个服务被黑了，那就整个被黑了。下面就捡几个要点简略讲讲。
（1）为什么要把运算和存储的分离？很多需要被加密的数据，往往和具体商业逻辑数据一起，属于不同的服务，比方说支付信息属于支付服务，护照号码属于用户服务等。把运算和存储分离可以带来很多好处，比方说：
加密服务变得简单和高效。因为不需要存储那些被加密的数据，加密服务系统不会很复杂，也不需要负责存储系统所带来的维护，扩展等诸多问题；
加密服务的安全性能提高很多。因为运算和存储的分离，如果仅仅是被加密的数据泄露（比方说数据库被盗），那些数据就没法被解密，因为黑客没法从外部访问加密服务。如果仅仅是客户服务被黑，想要盗取大量数据并且通过加密服务来解密而不被发现也很难。如果仅仅是加密服务服务被黑，因为加密服务本身并不拥有数据，被泄露的数据也不会很多。只有当加密服务和客户服务同时被黑，才会泄露大量数据，而同时能够侵入加密服务和客户服务的难度要高很多很多；
灵动性。因为数据属于客户服务，不同的客户可以对数据进行不同的处理，比方说不同的有效性规则，数据交易完整性等等。
（2）其次是 granular control。假设支付服务要求加密/解密信用卡号码，用户服务要求加密/解密护照号码，如何能保证用户服务不能加密/解密信用卡号码。这就需要解决两个基本问题：客户认证（authentication）和权限控制（authorization）。怎么做客户认证（authentication）？客户认证要知道每一个请求是谁发出的。因为只有知道客户是谁才可以进行权限检查。常用的有基于客户证书的（如 client certificate over TLS），基于 OAuth（开放授权）的，或者各种各样定制的方案，如基于 Curve25519 等等。笔者一般遵循两个原则：
是不是业界公认的。如果不是，最好避免。业界公认的解决方案往往经过过严格的检验， 评价，批评，经得起考验；
有没有广泛的类库支持，以及多语言的支持。如果有，可以节省大量的开发以及维护的时间和精力。
（3）数据监控和预警。为了审计以及安全的需求，一般要对加密服务做很多的数据监控，预警的工作。这样可以知道谁在访问这些数据，何时访问的，怎么访问的，访问的模式是怎么样的。监控系统还需要侦测异常的流量变化，进行流量控制以及快速的反攻击保护。
（4）最后，重中之重，怎么保护 root key？无论是用哪种 envelope encryption的变种，都会涉及到怎么保护 root key。常见的有用 secret sharing的一些变种方式，也有通过公证人公证整个过程藏在银行保险箱的，也有藏在创始人地下室的：）怎么来 bootstrap 和 deploy 这个 root key 到加密服务里也是一个非常有意思和挑战的问题。
总的来说，数据加密不是一件神秘的事情，但要做好非常不容易，需要一定的技术积累和资源的投入。做任何一个安全系统，风险都不小。但不管如何，无论是因为潜在的法律风险还是用户的信任风险，这种安全上的投入从长期来说一定是值得的。
相关文章阅读：
