提高PAAS安全性的一点尝试

云服务已经成为现代人生活的一部分。手机中的照片会自己主动同步到云中；你的邮件内容保存在云中。办公软件执行在云中；你的健康数据会实时上传到云中。你每天的生活轨迹消耗的卡路里也会上传到云中；云服务也会逐渐象交电费、交水费一样被大众接受，这是科技进步的必定。

云服务安全吗？这个被重复问过的问题，也被回答了非常多次。

我只作为一个软件project师，谈谈自己在安全方面的一点尝试。

供借鉴。

大的安全话题包含非常多个方面，数据可靠吗？数据是否被偷窥、篡改？

数据不丢的这个基本要求能够说已经非常好了，AWS的S3已经达到11个9的持久性，存一份遗嘱在S3上，预计比保存在银行保险柜中还要可靠（不easy丢。可是否被偷窥，这个就不好说了）。有人会反问一个问题。那比特币丢失的为啥那么多呢？保存比特币的数字证书。不只要不丢，并且要不被偷。假设比特币证书文件保存在S3上，预计小偷就多了。这方面不做深入的讨论。

数据的保密性问题，不被偷窥，不被篡改等。这个问题的本质在于是否有技术手段来保障安全，假设没有就仅仅能基于信任机制了。比方你使用银行的服务，你仅仅有信任他，相信他不会偷你的钱。但假设有技术做保障的数字货币的机制，那么你就不须要被迫的信任哪个人或机构，你仅仅要相信科学就能够了。

也许在不远的未来，数字货币会代替银行。而现阶段的云服务在数据保密性方面还处在基于信任的阶段。

当你打开一个在线软件（qq邮箱，tower.im等等），你就已经開始使用SAAS提供的服务了，你大部分的数据也都将保存在SAAS服务商那里。

你信任你的SAAS服务商吗？

SAAS服务商开发的在线软件，也通常执行在更基础的PAAS服务商提供的服务上。比方数据库服务RDS，虚拟主机服务EC2、ECS，文件存储服务S3、OSS等等。作为一个SAAS的开发project师，你信任PAAS服务商吗？

信任SAAS的问题。假设有一种端到端的技术。在浏览器这一端实现加密解密。那么就不用操心SAAS偷数据。比如自己生产数据，自己消费数据（比方拍照上传仅仅给自己看）。这个easy实现。用一个保存在本地的对称密钥完毕加密解密就能够了。但假设是涉及到2个人參与的动作，比方邮件，一个人发送，一个人接收，做到端到端加密。这要用非对称password技术。

但假设是多人參与的动作，比方在线协助类的服务，一个人提交的内容要多个人读的场景。要实现端到端的加密预计就更复杂了。 假设SAAS服务商无法提供一个令你惬意的技术方案， 你唯一的选择就是信任他或者不信任他， 没有更好的办法。

信任PAAS的问题，是否有一个技术手段来摆脱信任呢？ PAAS提供基础服务，保存数据，保存文件。提供计算能力等，SAAS保存在PAAS中的数据，也仅仅同意SAAS自己訪问，在这样的场景下，就能够使用对称密钥的加密技术。SAAS 保存一个 AES256 的随机密钥，全部SAASserver共享密钥。SAAS收到用户提交的数据用AES256加密，然后保存到PAAS中。SAAS读取PAAS的数据，解密后在返回给用户。

       浏览器用户   ----   SAAS project代码  --   AES 密钥   -----  PAAS 数据库

我们如今讨论，代码、密钥、数据库单个泄漏，或者随意2个泄漏，或者这3个都泄漏，数据是否安全？

数据库敏感字段用AES加密后。即使被拖库（仅仅泄漏数据库），也是不可解密的。

AES-256的password强度理论上是不可破解的。

——这样改造后拖库是安全的。

数据库加密的方法非常好，问题是密钥本身怎样保护 ？ 写在代码中是不合适的。由于代码，程序猿是能够看到的。提交到github中，也有可能代码泄漏。编译后的二进制代码，逆向也是能够破解这类固定password。所以AES-256密钥不能放在源代码中。AES-256密钥。应写在配置文件里 keyconf，而且这个配置文件不作为project项目的一部分，仅仅在操作系统的配置文件夹中（比如/etc） 下存放。仅仅有运维人员能够訪问这个文件，全部SAASserver上这个文件一致，就完毕加密解密。——这样改造后，源代码和数据同一时候泄漏（密钥不泄漏）。也是安全的。

密钥信息保存在配置文件里，这个运维人员能看到，一旦server被非法登录，也easy泄漏。应对这样的风险有一种做法，在project代码中保存一对非对称密钥RSA，用public key把原始的 AES密钥加密一次，加密后的KEYFile 作为配置文件保存在 /etc 文件夹下。在SAAS启动服务的时候。用自己的private key 解密这个 KEYFile，得到最原始的AES-256 。

—— 这样改造后，AES密钥（RSA处理后的）和数据库同一时候泄漏（源代码不泄漏，RSA不泄漏），也是安全的。

在考虑一种极端的情况， 源代码泄漏。密钥也泄漏。数据库也泄漏。数据还安全吗？ 从源代码中可有取到RSA的私钥。用这个私钥能够解密AES-256对称密钥。 用这个AES-256密钥就能够解密数据库。 针对这样的情况，也有一种办法。

通常情况下，KEYFile是不须要长期保留在server上的。这个文件仅仅在启动服务的时候实用。假设启动完毕后。解密后的AES-256保存在进程的内存中，这个KEYFile文件就不在须要了。办法就是，把KEYFile 用口令再加密一次生成KEYFileSsl。生成环境仅仅保留KEYFileSsl 这个文件。启动服务是通过一个启动脚本来完毕，脚本在运行时，提示输入口令。 口令正确的情况下。先解密得到 KEYFile ，然后正常启动服务， 服务启动后。脚本立马删除 KEYFile。 —— 这样改造后。源代码泄漏。同一时候KEYFileSsl泄漏，同一时候拖库，也是安全的（由于没有启动口令）。

上面的做法有2个缺点，一个是，启动须要口令，这导致服务意外crash后，无法自己主动拉起。口令永远不要记录在不论什么脚本中。还有一个缺点是，AES-256的原始密钥。是保存在服务进程的内存中的，假设生产环境的主机被劫持了，黑客是有办法通过分析内存来获取密钥的（这个有点难。但有这个可能）。针对这个漏洞。AWS的最佳实践是，禁止生产环境主机上一切shell登录（AWS的这个做法值得推荐的。AWS的虚拟机EC2 建议採用禁止登录的模式，不论什么开发者、不论什么运维人员都不能登录到生产环境的主机。EC2的初始化，环境的部署都是自己主动化完毕的，没有人为的干预，也在一定程度上防范了偷数据的情况。）。