云服务已经成为现代人生活的一部分。手机中的照片会自动同步到云中；你的邮件内容保存在云中；办公软件运行在云中；你的健康数据会实时上传到云中；你每天的生活轨迹消耗的卡路里也会上传到云中；云服务也会逐渐象交电费、交水费一样被大众接受，这是科技进步的必然。
云服务安全吗？这个被反复问过的问题，也被回答了很多次。我仅仅作为一个软件工程师，谈谈自己在安全方面的一点尝试。供借鉴。
大的安全话题包括很多个方面，数据可靠吗？数据是否被偷窥、篡改？
数据不丢的这个基本要求可以说已经很好了，AWS的S3已经达到11个9的持久性，存一份遗嘱在S3上，估计比保存在银行保险柜中还要可靠（不容易丢，但是否被偷窥，这个就不好说了）。有人会反问一个问题，那比特币丢失的为啥那么多呢？保存比特币的数字证书，不仅仅要不丢，而且要不被偷，如果比特币证书文件保存在S3上，估计小偷就多了。这方面不做深入的讨论。
数据的保密性问题，不被偷窥，不被篡改等。这个问题的本质在于是否有技术手段来保障安全，如果没有就只能基于信任机制了。比如你使用银行的服务，你只有信任他，相信他不会偷你的钱。但如果有技术做保障的数字货币的机制，那么你就不需要被迫的信任哪个人或机构，你只要相信科学就可以了。或许在不远的未来，数字货币会取代银行。而现阶段的云服务在数据保密性方面还处在基于信任的阶段。
当你打开一个在线软件（qq邮箱，tower.im等等），你就已经开始使用SAAS提供的服务了，你大部分的数据也都将保存在SAAS服务商那里。你信任你的SAAS服务商吗？
SAAS服务商开发的在线软件，也通常运行在更基础的PAAS服务商提供的服务上。比如数据库服务RDS，虚拟主机服务EC2、ECS，文件存储服务S3、OSS等等。作为一个SAAS的开发工程师，你信任PAAS服务商吗？
信任SAAS的问题。如果有一种端到端的技术，在浏览器这一端实现加密解密，那么就不用担心SAAS偷数据。例如自己生产数据，自己消费数据（比如拍照上传只给自己看），这个容易实现。用一个保存在本地的对称密钥完成加密解密就可以了。但如果是涉及到2个人参与的动作，比如邮件，一个人发送，一个人接收，做到端到端加密，这要用非对称密码技术。但如果是多人参与的动作，比如在线协助类的服务，一个人提交的内容要多个人读的场景，要实现端到端的加密估计就更复杂了。 如果SAAS服务商无法提供一个令你满意的技术方案， 你唯一的选择就是信任他或者不信任他，
没有更好的办法。
信任PAAS的问题，是否有一个技术手段来摆脱信任呢？ PAAS提供基础服务，保存数据，保存文件，提供计算能力等，SAAS保存在PAAS中的数据，也只允许SAAS自己访问，在这种场景下，就可以使用对称密钥的加密技术。SAAS 保存一个 AES256 的随机密钥，所有SAAS服务器共享密钥。SAAS收到用户提交的数据用AES256加密，然后保存到PAAS中。SAAS读取PAAS的数据，解密后在返回给用户。
浏览器用户 ---- SAAS 工程代码 -- AES 密钥 ----- PAAS 数据库
我们现在讨论，代码、密钥、数据库单个泄漏，或者任意2个泄漏，或者这3个都泄漏，数据是否安全？
数据库敏感字段用AES加密后，即使被拖库（只泄漏数据库），也是不可解密的。AES-256的密码强度理论上是不可破解的。——这样改造后拖库是安全的。
数据库加密的方法很好，问题是密钥本身如何保护 ？ 写在代码中是不合适的。因为代码，程序员是可以看到的。提交到github中，也有可能代码泄漏。编译后的二进制代码，逆向也是可以破解这类固定密码。所以AES-256密钥不能放在源码中。AES-256密钥，应写在配置文件中 keyconf，并且这个配置文件不作为工程项目的一部分，只在操作系统的配置目录中（例如/etc） 下存放。只有运维人员可以访问这个文件，所有SAAS服务器上这个文件一致，就完成加密解密。——这样改造后，源码和数据同时泄漏（密钥不泄漏），也是安全的。
密钥信息保存在配置文件中，这个运维人员能看到，一旦服务器被非法登录，也容易泄漏。应对这种风险有一种做法，在工程代码中保存一对非对称密钥RSA，用public key把原始的 AES密钥加密一次，加密后的KEYFile 作为配置文件保存在 /etc 目录下。在SAAS启动服务的时候，用自己的private key 解密这个 KEYFile，得到最原始的AES-256 。 —— 这样改造后，AES密钥（RSA处理后的）和数据库同时泄漏（源码不泄漏，RSA不泄漏），也是安全的。
在考虑一种极端的情况， 源代码泄漏，密钥也泄漏，数据库也泄漏，数据还安全吗？ 从源码中可有取到RSA的私钥，用这个私钥可以解密AES-256对称密钥， 用这个AES-256密钥就可以解密数据库。 针对这种情况，也有一种办法。通常情况下，KEYFile是不需要长期保留在服务器上的，这个文件只在启动服务的时候有用，如果启动完成后，解密后的AES-256保存在进程的内存中，这个KEYFile文件就不在需要了。办法就是，把KEYFile 用口令再加密一次生成KEYFileSsl，生成环境只保留KEYFileSsl 这个文件。启动服务是通过一个启动脚本来完成，脚本在执行时，提示输入口令，
口令正确的情况下，先解密得到 KEYFile ，然后正常启动服务， 服务启动后，脚本立刻删除 KEYFile。 —— 这样改造后，源码泄漏，同时KEYFileSsl泄漏，同时拖库，也是安全的（因为没有启动口令）。
上面的做法有2个缺点，一个是，启动需要口令，这导致服务意外crash后，无法自动拉起。口令永远不要记录在任何脚本中。另一个缺点是，AES-256的原始密钥，是保存在服务进程的内存中的，如果生产环境的主机被劫持了，黑客是有办法通过分析内存来获取密钥的（这个有点难，但有这个可能）。针对这个漏洞，AWS的最佳实践是，禁止生产环境主机上一切shell登录（AWS的这个做法值得推荐的。AWS的虚拟机EC2 建议采用禁止登录的模式，任何开发人员、任何运维人员都不能登录到生产环境的主机。EC2的初始化，环境的部署都是自动化完成的，没有人为的干预，也在一定程度上防范了偷数据的情况。）。