主题：【原创】Amazon是如何保证云计算的安全(一） -- sky100
家园 【原创】Amazon是如何保证云计算的安全(一） 在西西河混了这么长时间，一直潜水，只看贴很少发言，结果发现想浮上来透个气冒个泡都权限不够。就借着邓侃兄谈云计算的东风，也发一片，骗几朵花，早日上岸。
我个人一直看好amazon的云计算，而且亲自体验过。觉得比google的appEngine要强得多，为什么？简单举3点，1.对开发者的支持 2.产品的灵活性 3.一条龙的解决方案。至于具体的论证，那是下一片文章的责任，在这里就不展开了，只提一件事，amazon的云计算是以收费为主的，2007年就号称有33万用户了(出处)），而且不少是明星级的，比如哈佛大学，华盛顿邮报之类的。好不好，别看广告看疗效。这么多用户，这么多应用，产品不好用早就撒丫子跑了。
对于大企业级的客户，最看重的自然是安全性。security是压倒一切的指标，性能再好，价钱再便宜，不安全这一项就可以一票否决采用云计算的提案。
如果保证客户的数据安全？amazon也在天天琢磨这个。为此，他们设定了层层设防的安全架构，并已获得了SAS70 Type II的安全审计认证。其安全结构可以简单的分为2层：1，物理层 2.应用层。
1.物理层访问安全
再好的防火墙，再好的防黑措施，也挡不住直接拔硬盘。内部工作人员是安全防范的第一线。对于这一层，amazon全力以赴，毕竟amazon自己每年十几个billion的电子商务业务也在自己的云计算平台上跑着，它比其他客户更在乎安全（标准的eat my own dog food的例子：））为此，amazon设立24小时摄像监控，高科技的监控系统。任何参观者必须出示证件，签字，并由授权的amazon员工陪同进入和离开。任何有合法授权进入云计算机房的amazon员工在进入机房时，都要经过不少于3次的Two-factor authentication（比如指纹加密码）。只有有业务需求的员工才可以得到授权，一旦这个员工转到其他部门或者离开了，授权立即作废。这些授权员工的物理接触和电子登入都会被记录和定期审查。
2.应用级访问安全。
说到amazon 云计算的应用层，那著名的吉祥三宝（ec2,s3,simpleDB)自然是要一一登场。
嗯，喝水，土鳖扛着，铁牛顶上。
Reference:
1.http://en.wikipedia.org/wiki/Amazon_Web_Services#cite_note-0
本帖一共被 4 帖 引用 (帖内工具实现)家园 第三篇正在修改和调整中，先把已经写好的第四篇放上来。 绝不跳票，谢谢观赏。
家园 友情提示 该填坑了！
期待中。
家园 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方面有明显优势。
家园 难言之隐，一洗了之。 若干年前国内的广告。
家园 呵呵，俗话说，没有真正安全的安全措施。 这里有一个最大的隐患，amazon可以spy on任何用户的数据。你的美女们危险了。
家园 啥时候申请认证啊，赶紧的吧 家园 申请认证有什么优点？
家园 新人+原创+好贴=照例送花~~ 家园 所谓物理层访问安全 amazon设立24小时摄像监控，高科技的监控系统。任何参观者必须出示证件，签字，并由授权的amazon员工陪同进入和离开。任何有合法授权进入云计算机房的amazon员工在进入机房时，都要经过不少于3次的Two-factor authentication（比如指纹加密码）。只有有业务需求的员工才可以得到授权，一旦这个员工转到其他部门或者离开了，授权立即作废。这些授权员工的物理接触和电子登入都会被记录和定期审查。http://www.ccthere.com/article/2021819这个也没什么特别吧，凡是数据中心都这么做，甚至更严格。
所谓真正的物理层访问安全是把每个用户用专线接入，不同用户服务器与服务器之间无网络连接。不过这样云计算就没意义了。
家园 嗯，没错 可是本来安全这个东西就是隐藏在细节里的，没什么特别的。
比起来amazon还开诚布公的宣布，这说明最起码它重视这个细节。其他几家云计算的提供商，比如google，可从来没公布过它的物理层的防护措施。
安全是一个无止境的追求，在安全和成本之间找到一个平衡点，才是cio，架构师和系统工程师所需要的。换句话说，什么样的安全就足够了呢？数据中心的安全模式已经经过了工业界和市场的检验，所以云计算中心直接套用和模仿，也没什么奇怪的。
但是，开一家麦当劳不难，开1000家一样的麦当劳并提供一样高质量的汉堡包，可就考验真功夫了。把数据中心开遍全美和欧洲，每个数据中心管理几十万台以上的连在一起进行分布式计算的机器，并保持同样严格的安全标准，就成了一个外行看热闹，内行看门道的问题了。
家园 Amazon是如何保证云计算的安全(二） S3(Amazon Simple Storage Service)
吉祥三宝里的大宝自然就是S3了。S3可能是市场上被使用最多最广泛的商业云计算服务。实际上，S3应该被称为云存储，什么都可以存在里边，成本还很低，每GB存储每个月只要大约0.15美分（而且存的越多越便宜），结果就导致了无数照片共享，文件同步之类的网站和应用的诞生。质量好，又便宜，大宝，天天见。
截止2008年10月，S3已经存储了29 billions个object（2008年1月时还只有14 billion个，由此可见该项服务的受欢迎程度），Amazon还号称每秒有7万个S3操作在执行（出处 ）。咳咳，我也在S3存储了2000来张高清美女图片。实验，只是实验，我只是很纯洁的为了测试一下云存储而做的实验而已
让我们先简单的回顾一下S3的存储体系（其他的云计算的存储部分原理也都大同小异）。物理上，Amazon在全美和欧洲到处建数据中心,将数据分布式存储在它的计算机集群上(cluster)，我怀疑它也使用类似于google的pc farm来组建它的集群,否则成本很难这么便宜. 逻辑上，数据是这样组织的，每个S3账户，可以创建无数个bucket,每个bucket下又可以放无数个obejcts,可以这样说，bucket相当于仓库，object相当于货品，你可以在amazon S3这个奸商处购买无数个仓库（bucket），每个仓库里可以放无数个货品（objects）,但只有以下2个限制：
1，每个货品（object）的大小最大只能为5GB. 对此，我猜想是为了硬件对齐而作的限制。估计amazon的存储分区上每个硬盘分区(或每个最小存储单元）的大小就是5G。不过一般情况下，单个文件很难超过5G.如果确实需要遇到了5G以上的文件，还可以split后再存。
2.仓库（bucket)的位置目前只有美国和欧洲可选，但听说amazon在香港开设了新的数据中心，希望在不久的将来，amazon也可以在亚洲区开设仓库（bucket),那么国内做web application的朋友们就该幸福了：）
为了保证应用层的访问安全，amazon提供了bucket and/or object-level access controls。你可以让你的用户只访问某一个单独的文件，也可以访问某个特定仓库(bucket)里的所有文件。可以只让指定用户访问，也可以让任何人都可以访问。这些都是通过amazon的Access Control List (ACL) 来实现的，通过ACL制作用户指定的访问key,没有这个key,谁也别想敲开S3的门。
另一个重要的隐患是传输过程中被截取，比如我正在国内上传一张著名女歌唱家宋祖英的高清照片到Amazon S3,忽然gfw的防火墙filter发现我的文件里有关键字（不知道什么是gfw的同学请面壁十分钟），然后立即通知国安局，截获了我的传递，我的这点小秘密就曝光了。为了防范这种拦路打劫的行为，S3支持SSL(Secure Sockets Layer)传递，于是我们就高枕无忧了，毕竟目前能够突破SSL来进行截获的技术还没有被发现或公开出来。
传上去之后，如果有人偷到了我的访问key，可以访问我的所有内容怎么办? 对存储的数据进行加密是另一个可选的办法。很遗憾，S3目前还不提供直接在云端进行数据加密的方法，但是你可以在上传前就把数据加密，或者使用 amazon的另一个云计算服务ec2(Elastic Compute Cloud), 在ec2上放一个MS SQL server或者oracle数据库,然后启用数据库软件的加密选项，就可以实现动态云端加密。但这样实际上就是把数据放在ec2上，而不是S3上了。
当然，这就是下一节关于ec2的安全防护的内容了。
土鳖抗，铁牛顶，喝水中。