提高PAAS安全性的一点尝试，paas安全性尝试

提高PAAS安全性的一点尝试，paas安全性尝试

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

云服务安全吗？这个被反复问过的问题，也被回答了很多次。我仅仅作为一个软件工程师，谈谈自己在安全方面的一点尝试。供借鉴。

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

数据不丢的这个基本要求可以说已经很好了，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的初始化，环境的部署都是自动化完成的，没有人为的干预，也在一定程度上防范了偷数据的情况。）。

这价位还是面包车吧，安全性能撞了都一样，还是注意安全驾驶的好，可以参考东风、五菱等，不然买比亚迪、奇瑞之类的也行

补充：
兄弟看你什么需求，你如果注重经济实用，就买面包，五菱出的，有很多款，都可以，看个人喜好和预算，本质上区别不大，外观上个人感觉比东风、昌河等牌子好看，油耗也大差不差，还能拉货，安全系数嘛，这个价位就不要苛求了，铁皮很薄，就是10万·20万的丰田、现代、本田之流也就这个层次，让我说什么好呢
注重面子，就买个长城、比亚迪或者奇瑞，这个价位起码看着是个轿车是不，说实话开着操控感不如个面包呢
 

云计算讨论总是以“IPS”分类开始：基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。这种分类的好处是更易于理解，能够合理的制定评估要求。

想要一个应用？单一用途应用（人力资源、财务、印刷等）可以找软件即服务提供商。

想要编写自己的应用？可以找基础设施即服务提供商，他们能够让你创建你自己的定制应用。

用户应该要考虑到以下问题

1、锁定。PaaS架构与CSP架构整合的难度远远超过了向一个提供商的虚拟机里安装应用。如果一个应用在内部依赖于服务提供商的服务，那么提取这个应用需要从最根本的地方检查代码，而不仅仅是简单的在另一个提供商那里安装一个打包工具。你从PaaS提供商那里获得的生产效率值与特定服务项目对你的锁定程度是匹配的。我并不认为锁定纯粹是负面的。以我的体验看，公司愿意被锁定是因为它们能够提供更多的好处。在选择PaaS时明白这一点非常重要，因为PaaS无疑会导致更大程度的锁定。

2、复杂性。每一个PaaS提供商都会将他们的功能与他们的架构整合在一起，而这些架构都是根据提供商对应用应该如何设计的理解创建的。确定在PaaS环境中如何以最佳方式编写和运行你的应用并不重要。当然，这是与传统的本地环境最大的区别。

3、CSP（云服务提供商）差异。正如上面所提到的，大量PaaS架构宣称提供了一个抽象层，该层从应用研发人员那里隐藏了云提供商的细节。将应用抽象概念实际正在工作的可能性被放置在一旁的作法忽略了元应用软件功能，这些功能可以将用户进行锁定在任何项目中。大部分这类功能由将CSP提供，其重点用于运行，而不是应用编辑。CSP通过这种功能水平让他们自己与其他提供商区别开来，他们会在运行层面将你锁定起来，而不再是在代码层面。不要认为这种情况不会发生。云提供商的第一个想法就是“我如何要让自己与其他的提供商不同？”因为他们都害怕成为计算能力相似的“哑管道”。
参考资料：hi.baidu.com/...8.html