网络安全那点事-阿里云开发者社区

开发者社区> 安全> 正文

网络安全那点事

简介: 网络安全水很深,零碎的也看了不少资料,但是总觉得很飘渺,可能是平时主要是做应用开发,而真正实践密码设计(cryptography)和安全设计(security)的机会比较少. 刚刚看了几篇文章 listed as following,有一些A-Ha moment,也能把我现有的关于web安全的知识窜起来,故记录在此: http://gdp.globus.org/gt4-tutorial

网络安全水很深,零碎的也看了不少资料,但是总觉得很飘渺,可能是平时主要是做应用开发,而真正实践密码设计(cryptography)和安全设计(security)的机会比较少.

刚刚看了几篇文章 listed as following,有一些A-Ha moment,也能把我现有的关于web安全的知识窜起来,故记录在此:

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s02.html

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s03.html

http://gdp.globus.org/gt4-tutorial/multiplehtml/ch09s04.html


一,怎样保证通信安全?

这是个古老的问题,而且古人的经验告诉我们,暗号能够确保通信安全,与似乎,什么天王盖地虎、宝塔镇河妖”开始登上了历史舞台,其实暗号也就是加密,是对原始信息的隐藏,到近代,加密发展成了一门科学, 也演绎了很多关于加密/解密 攻防大战的经典故事。

所以通过加密来保证通信安全是经过历史考验的可行方法。


二、加密学在网络的延伸

传统的加密大多都是对称加密(symmetric),也就是上锁和开锁都用同一把钥匙,但是internet是个天生就不安全的环境,一窜“my credit card num is 110945110945”从上海跑到北京,不知要经历多少个路由器,交换机,在通信期间,如果有坏人(man in the middle)要窃取你的数据,更是如囊中取物。那就加密吧,不过如果采用对称加密,而且这把钥匙每个人都有的话,那就跟没有加密是一样的。

解决方法是不对称加密(Asymmetric Encryption),详细请参考上面的reference.


三、怎样保证数据的完整性?

OK, 采用不对称加密后,我们的通信数据不再担心被middle man窃听了,但是新的问题来了(人类总是有追求卓越和完美的本能),我怎么知道这个信息没有被篡改过并且是真实有效的呢?

判断有没有被篡改过,我们有数字签名(Digital Signature), 很简单,sender用一套单向的哈希算法,生成源数据的摘要,此算法保证对源数据的任何更改都会产生不同的摘要,sender将源数据和摘要一起发给receiver,receiver收到数据后,用同样的算法再生成一次摘要,并将其与sender发过来的进行比对,如果一样,那么就可以断言信息没有被更改过。


四、怎样确保通信方身份真实有效?

数字签名解决了数据完整性问题,那么怎样保证和你通信的人是真实有效的呢,这个身份认证的事情,必须通过第三方来做,因为自己不能为自己做证啊,你说你就是“招商银行”,我凭什么要相信你呢,任何人都可以说自己是招行。如果银监会说,他确实是招商银行,你可以放心把银行密码告诉他,你才敢放心,是不是。这一套解决信任问题的方案就是数字证书(Digital Certificate),这个第三方,我们管它叫CA(Certificate Authority), Authority应该是很有权威的,虽然不是银监会,但也是绝对可靠可信的,比较知名的有VeriSign,被Symantec收购了,我们公司就在用这个。


五、认证(Authentication),授权(Authorization),访问(Access)

输入用户名,密码,登陆系统,哦,还有验证码微笑,早期的internet,包括现在的大部分应用,都是这种模式。但随着internet 发展,越来越多的service provider,要开放自己的service给第三方应用访问,特别是social network的兴起,这种需求变得越来越强烈,几乎变成大型网站的标配。

怎样让第三方应用访问用户资源,同时又不接触到用户的敏感信息呢?

如果传统的用户名,密码登陆验证,就以为着第三方必须知道user的用户名,密码,显然不满足我们的需求,怎么办呢? 一帮聪明的人仔细研究了整个验证过程,然后将其分解、抽象成三个步骤,即认证(Authentication),授权(Authorization),访问(Access)。这让我不禁想起那句老话 “在计算机世界,任何问题都可以通过加一层来解决”,是的,加了Access Layer之后,前面的要求就能满足了,具体是怎样实现的,参看下文。

分解后,将访问资源同认证、授权解耦。也就是说认证、授权在一个地方先做,完成后获得一个Access Token, 然后利用这个Access Token去访问resource, 当然resource server要负责验证这个token的有效性,怎么验证呢? 方法有多种,利用token作为reference id去Authorization server获取相关信息是常见的方式。

通过此方式,第三方只要引导user去完成Authentication 和 Authorization, 而不用touch到user credential information (username, password), 利用上面步骤获得的Access Token 再去访问Resource server。 也就是OAuth的工作流程了。

    +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

参考:http://tools.ietf.org/html/rfc6749

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章