首页 > 其他 > 详细

互联网产品安全架构浅谈

时间:2015-01-23 02:23:49      阅读:306      评论:0      收藏:0      [点我收藏+]

最近一位朋友正在自己创业,公司所做的产品为一个互联网金融产品,由于他自己没有互联网产品经验,故对互联网产品的安全也不是很了解,想让我给其出一份互联网产品安全架构方案。

本人觉得, 就产品而言(不考虑服务器硬件本身和操作系统,和数据容灾),主要考虑产品两方面安全性, 第一:网络数据传输的安全性。 第二, 物理数据存储的安全性。鉴于近段时间以来,SSLheart blood漏洞,12306大量用户数据被盗,银行信用卡信息低价出售,存款不翼而飞等事件,我觉得还有一方面的安全性,就是程序员的职业道德和一个公司对客户信息安全的责任。 我想这也应该是国内众多公司所面临的一个最大的问题。

废话不多说,前面一段时间特地研究了SSLmongodb两个产品安全架构,并结合自己的经验,勾画出来了下面一副产品安全整体架构图:

bubuko.com,布布扣  产品整体安全架构图

从上图看来, 对于外部的客户端, 不管是手机APP还是电脑应用程序,或者是web,都只能通过应用服务器集群的接入我们的后台服务器系统,当然接入进来之后,是用户身份认证,认证通过才是可以通过服务器进行业务处理,而认证过程所需要的密钥或者其他辅助认证信息都应该由密钥管理服务器提供,应用程序只负责认证逻辑和提供各种加解密算法。在业务处理过程中,产生的业务数据或者所需要使用的数据库中数据,不会通过应用服务器直接与数据库交互,而是通过中间层---数据访问服务器来访问,这样做的好处有:1. 应用数据和物理数据隔离,应用程序不需要知道物理数据是怎样存储,只管业务数据的处理。2.具有更高的安全性。3.从开发的角度来说, dba只需关注物理数据存储。业务程序员只关注业务逻辑处理。

第一:关于数据存储的安全性。

此图中,将密钥的数据存储服务器和数据库的物理存储服务分开, 使得密钥与具体数据隔离开,入侵到这两者中的任何一个,所拿到的数据都是属于没有用的数据。除非两者都被入侵。

为什么数据访问服务器需要访问数据呢? 由于本产品是金融产品,任何数据都是客户的关键数据,不能直接以明文的方式存储到数据库,必须加密之后才能到物理数据库,不然内部管理人可以直接从数据库中读到数据。

多加了一个数据库访问服务器层,如果是它向应用层只是提供数据查询和存储服务,或者只是简单将数据加密存储,解密返回给应用层, 那么其存在性是值得怀疑的,为了提供更安全的服务,我们可以将应用层的数据进行加密之后,在使用一定的策略将数据存储到物理服务器中,当然读取时也必须按照此策略还原数据。我这里提供一种加密之后的分片存储策略,什么是加密之后的分片存储了呢?比如说:对于银行来说,一个信用卡数据,可能简单的包含卡号,密码,身份证号码,金额,我们就可以将这四个数据按照某种格式合并在一起,比如JsonBson等,然后将合并在一起数据加密,最后将加密之后的数据分成若干个片段,如12345,然后随机将这5个片段存储到不同的数据库中。这样安全性就提高了不少。

第二:网络数据传输的安全性。

对于网络数据的安全,我想先通过一个网络交互图来一步步说明。bubuko.com,布布扣

第一步:客户端SayHello, 目的:加解密算法协商和随机码获取。客户端携带版本号,随机码,MAC,所支持的加解密算法,合起来算出一个md5 digest一并发送给服务端。服务端收到后,验证客户端的digest,从客户端发送的加解密算法中选择一个对称算法,生成一个随机码,时间戳,合起来算出一个md5 digest,一并发送给客户端。客户短验证digest.

  第二步:用户名认证:客户端随机码,用户名,服务端随机码,服务端返回的时间戳,客户端时间戳,用选择的对称算法加密生成AMAC地址加密生成B AB合起来生成 md5 digest C, B+A+C发送给服务端, 服务端收到后,首先验证degest,网络中有没有窜改,然后解开MAC验证是否有此客户有sayHello,最后验证随机码, 时间戳,用户名是否存在。都通过之后,服务端返回新的随机码,服务端从SayHello中选择密码加密的不可逆算法,客户端随机码,服务端用户名认证的时间戳。当然还是要生成digest, 加密等。

第三步:密码认证,目的:实现不传输密码,对客户密码认证。客户端生成新的随机码A,与服务端新返回的随机码B作为加密因子,使用服务端返回的加密算法,对密码非对称加密,生成C,服务端新时间戳DA+B+C+D对称加密生成EMAC地址对称加密生成F, E+F生成digestE+F+digest发送服务端,服务端收到后,现验证Digest, 然后验证MAC,随机码,时间戳。然后用自己用户的密码通过客户端同样的加密方式生成H,比对HC是否一致。

最后说一点就是,服务端发放动态口令,按理,客户端3步验证之后,不管成不成功,都需要删除密码,这时动态口令可以用来不需要密码输入密码登录。客户端每次从后台进入前台时就可以使用,这也是我对于微信和QQ,支付宝等几亿用户第一次登录之后就不需要密码实现登录的一些思考,如果他们的客户端真的没有保存密码的话,我很想知道其解决方案,如果有保存密码的话,那对于Android来说,几乎就是泄漏密码了。这也是我对互联网产品的一个小小的思考。希望各位看官轻拍。

 文末留下邮箱,danliz_nh@hotmail.com,希望各位能通过邮件或者跟帖的方式与我交流。

互联网产品安全架构浅谈

原文:http://blog.chinaunix.net/uid-26904464-id-4774257.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!