码迷,mamicode.com
首页 > 其他好文 > 详细

提高PAAS安全性的一点尝试

时间:2014-09-18 16:33:14      阅读:194      评论:0      收藏:0      [点我收藏+]

标签:saas   paas   aws   

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

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

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

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

提高PAAS安全性的一点尝试

标签:saas   paas   aws   

原文地址:http://blog.csdn.net/dongdongk/article/details/39373587

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!