淘客熙熙

主题:【原创】Amazon是如何保证云计算的安全(一) -- sky100

共:💬29 🌺103
全看树展主题 · 分页首页 上页
/ 2
下页 末页
家园 花盼后文
家园 新人+原创+好贴=照例送花~~
家园 很好很强大。来人,拖出新兵营。。。。。。

送往“信息技术”。

小花一朵。

家园 啥时候申请认证啊,赶紧的吧
家园 申请认证有什么优点?
家园 呵呵,俗话说,没有真正安全的安全措施。

这里有一个最大的隐患,amazon可以spy on任何用户的数据。你的美女们危险了。

家园 Amazon是如何保证云计算的安全(四)

Amazon 发布了S3云存储后,市场反应十分热烈,叫好又叫座,ec2也落了个满堂红。按照冯-诺依曼的理论,计算机只不过是处理器加存储器再加输入输出设备而已,ec2在这里就是处理器,s3就是存储器,客户端就是输入输出设备,这样一台超级巨大的分布式计算机就在amazon的巨云中伸出了无数的触角,进入了千家万户。

可等等,出问题了。什么问题呢?这就要扯到Scalability上了,分布式计算最经常遇到的问题就是这个Scalability,以前在小尺度上不显眼的问题,在巨大尺度上都变成了令人头疼的技术挑战。比如你有1000张照片,那么找到其中的一张照片不算太难,但10000张里挑一张呢?10万张呢?1000万张呢?请记住,Amazon S3上现在有最少29兆个文件,在这里找一个特定的文件,那可真是名副其实的大海捞针,如果想做个数据挖掘,那就更是要逼一头大象在捞到的那根针的针尖上跳舞了。海量数据的处理和查询对于分布式计算提出了挑战。在这种级别的数据量下,传统的关系型数据库无论从功能还是性能上,都很难满足业务需求了。

Amazon simpleDB这个分布式的数据库就应运而生,成为了连接ec2和s3的中间层,ec2计算和产生数据,s3存储这些数据,simpleDB自然就负责管理和组织这些数据了。关于simpleDB和google的bigtable那一种数据结构更好,是云计算fans们的一个非常热门的话题,在这里就不深入讨论了,让我们继续回到安全这个侧重点上来。不过,有一个信息必须要强调一下,目前simpleDB还是免费使用的。如果每个月你只需要少于200万次simpleDB的操作请求(比如查询,删除之类),那么,Amazon一分钱也不收。想尝鲜的朋友们抓紧了。

SimpleDB是以domain为管理单位的,每个domain都可以简单的认为是一个独立的数据库,安全访问管理是基于domain的,每个simpleDB可以创建最多100个domain.每个domain的授权都可以是独立的,互不影响的。这样就从数据库的角度隔离了访问,保证了安全性。

老规矩,simpleDB也支持SSL,保证了你的机密数据不被拦截。同样的,它也不支持云端动态实时加密,不过你可以把数据加密后再上传到SimpleDB.但是,凡事有利也有弊,SImpleDB的query(查询)是基于字符的,数据一旦加密后就没法用SimpleDB的查询命令了,不过好处就是除了你以外没人(包括amazon)能访问你的敏感数据。

Amazon声称,一旦domain被删除,在几秒钟内所有属于这个domain的数据的存储区就会被释放,只能写入,不能读,没有任何外部操作可以接触到这些存储区,从而保证了操作的安全性,换句话说,你就放心的删吧。

以上介绍看起来是很枯燥的,好,本系列的最后一篇里我会杜撰一个轻松的案例来帮助大家理解一下基于Amazon云计算的好处以及安全方面的使用,学习哈佛,基于案例的讨论和学习:)

Showtime~~~

预告:

某国最出名的网游运营商"成大"的总裁刘天桥最近吃不好饭睡不好觉,小蜜都没空泡了,怎么了?原来他遇到了一个技术性难题。趁着夜黑风高,他带着一皮箱现金来到了你家,什么是他的难言之隐? 预知详情,敬请收看---云计算安全番外篇《如果云知道》。

家园 第三篇正在修改和调整中,先把已经写好的第四篇放上来。

绝不跳票,谢谢观赏。

家园 难言之隐,一洗了之。

若干年前国内的广告。

家园 Scalability

Amazon的商业模式很好,但是技术上,老实说,我不是非常看好。

譬如说EC2,对于用户而言,基本上就是Amazon机房里放着若干台机器,用户爱干嘛就干嘛。

设想一个用户在EC2上建了一个网站,但是无法预计将来流量会有多少。用户的希望是,流量大的时候,EC2自动多分配几台机器,流量少的时候,EC2少分配几台机器。

EC2能不能满足这个要求呢?从目前Amazon的架构看,做不了。

SimpleDB也一样。说到底不过是摆放了一堆DB instances,数据要么放在这个instance,要么放在其它instance里。这就造成了数据的分割。

如果并发用户多了怎么办?只好把同一份数据拷贝到不同instances上去。如果并发用户数在高峰期过去以后,又降下来了怎么办?只好把该数据从若干instances中删去。如此往返,感觉不是好办法。

再举个例子,如果某一个表增加得很快,超出了一个instance的容纳范围,怎么办?只好把表的后半部移到另一个instance中去。但是问题是,如果有用户请求查询某个数据时,怎么处理?只好一个instance

,一个instance去分别做query。如此往返,感觉也不是好办法。

Google的解决办法,在scalability方面有明显优势。

家园 什么难题?难道是各个服务器之间的信息互联问题?

花待下文

家园 强烈要求share在S3存储的2000来张高清美女图片
家园 送花鼓励!
家园 友情提示

该填坑了!

期待中。

全看树展主题 · 分页首页 上页
/ 2
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河