写点什么

圆桌会议:云计算的安全风险

  • 2011-07-15
  • 本文字数:10287 字

    阅读完需:约 34 分钟

本文最初发表在 IEEE Security & Privacy 软件杂志,现在由 InfoQ & IEEE 计算机协会为您呈现。

客座编辑 Iván Arce 和 Anup Ghosh 举办了一场圆桌讨论会,邀请的是那些奋战在云计算安全一线的专家们,他们为市场提供服务并从中寻找来自真实世界的安全威胁和需求,通过他们读者能够了解到云计算相关的知识。

Anup Ghosh:谢谢大家参加这次活动。我们邀请大家是因为各位所在的公司都在云计算领域有长期的投资。先从 Eric 开始吧,你能不能谈谈 Google 云计算项目的目标市场规模和范围?

Eric Grosse:这个问题很好,因为市场规模绝对是驱动因素之一。Gmail 目前已有上亿用户。就算你只打印每篇新建 Google Doc 的首页,那每天也要为此砍掉 120 棵树,这么说只是给大家一个直观感受。在企业方面,使用这些服务的用户大概有 3 千万,所以这个任务要比我过去习惯的要大得多。现在这样的发展态势很令人激动。

为了为保障每个 Google 用户的利益,我认为目前我们面临的三大主要挑战。首先,就是认证。如果坏人得到你的密码,而那又是唯一保护你账户的密码,那他们就能为所欲为了。

其次,恶意软件。即便毕所有天才反病毒软件所付出的努力于一役,我们还是不能战胜恶意软件黑客。相反,我们将会面临更大的问题。因为,随着我们越来越多地通过插件和浏览器来实现互操作性,原本只针对单独某个操作系统的安全攻击,现在已发展成为跨平台的攻击,可见那是一个很大的安全领域,这将是一项重大挑战。

最后一点,Web 应用在云计算领域的脆弱性。浏览器其实是个很复杂的安全环境,所以我不会去埋怨工程师花费很长时间和精力才修复它,有些工作总能使这种情况变得更好。

Ghosh:目前为止我还没有见过太多云相关的恶意软件带来的挑战,既然你刚刚提到了这个有趣的话题,那么我们现在就来谈一谈跨平台攻击,因为你云平台通常不限定特定平台。你是看到过一些先例,亦或这只是你预计会面临的问题?

Grosse: 不是这样,虽然云当然要依赖于服务器和数据中心,但是我从不担心恶意软件会出现在数据中心,谢天谢地幸好是这样 [大笑]。我所担心的是如何保护在云生态体系的终端用户,那才是恶意软件真正可能出现问题的地方。

Ghosh: John,你能不能谈一谈微软专注的云计算领域?

John Howie:当然可以。我觉得很多 Eric 刚才提到的挑战,和微软所面临的几乎一样。除此之外我还想补充一点,那些云端用户,无论是企业客户还是内部使用者,都很不幸地对云可能抱有不切实际的额外的安全期望,所以当他们看到任何云的东西,不管是公有云还是私有云,大多数人都会先入为主地认为这是安全的、可信任的。在他们脑子里永远也不会闪过一个念头说,也许坐在他们旁边的一个同事,一边使用着云服务,却实际上在在向他们发送病毒文档或病毒内容。

Ghosh: Jim Reavis,你是来自云安全同盟的,你能否谈一下你认为什么是 Google、微软、Amazon 和思科在其云服务上可能面临的最高级别的安全挑战呢?

Jim Reavis:**** 排名靠前的其中一个挑战就是服务提供者和服务消费者之间连接上的透明性。这是在任何技术处于初期的不稳定阶段时总会面临的真正挑战。

其次是数据,即保护数据,我们已经有了太多各式各样的相关规定,而且其中许多是法律上的。然后,第三点,我要说的是,在你实现一种新的计算系统时所伴随产生的威胁模型。你看看这些坏蛋们——他们自己就是云计算早期的使用者——随着使用的深入他们开始发展并研究如何攻击这些新系统。

Ghosh:下面我想把话题交给来自 Amazon Web 服务的 Steve Schmidt,让他讲一讲他们的云计算运维的规模和范围,以及所面临的最大的安全挑战。

Steve Schmidt:除了那些你通常能从 Google 获得的基础设施即服务(IaaS)和平台即服务(PaaS)之外,Amazon Web 服务还提供了更多别的服务。

拿 Amazon Web 服务的其中一个组件的范围来说吧,Amazon 有三个这样的组件,这个组件是一个对象存储,它存储了 1520 亿个对象,每秒钟大约处理十万个事务处理。我们遇到的一个最大的挑战,实际上,是确保能够向客户准确地描述职责共享的安全模型。我听过我们的一个同事在这里谈论职责共享,而这正是云计算和数据中心的一个重要区别之一。这个问题对于云模型和大家在自己的数据中心中做的那些操作是非常不同的。

我们通过虚拟机监管(hypervisor)维护数据中心上上下下的具体安全事务。而对于客户来说,也有维护他们自己操作系统和应用层的安全的职责。而且,确保准确、完整地描述安全职责,并让客户知道他们该做什么,对于公司的成功和维护客户满意度而言是至关重要的。

**Jim Ransome:我来谈谈 WebEx 吧,因为这是我在思科所供职的业务部门。在我所处的这一特定环境中我目前遇到的最大挑战是保证运营规范化,基本上运维需要遵循以下三个安全规范:**ISO 27001 和 ISO 27002,它们是面向企业用户的,NIST 800-53(译者注:联邦信息系统推荐安全控制)和 NIST 800-37 面向的是政府 / 公共部门用户,以及面向金融业的 PCI(译者注:支付卡行业),我们利用云事务模型来处理信用卡交易。

还有,我们的另一部分挑战是,让我们的安全程序对用户透明。在面向软件即服务的快速发展的环境中,我们的安全服务应尽可能的对用户透明,因为客户的主要安全都是由我们提供的。

Ghosh:有个问题一直困扰着我:我们已经有一些主流的云服务提供方,他们显然是砸重金投入到基础建设中并积累了很多用户。在这样的形势下仍旧存在很多跟安全和信任相关的问题,那么,怎样的数据是你们公司不会放到公共云中的呢?原因又是什么呢?微软的哪些数据不会放到公共云中呢?

Howie: 这是个绝好的问题。Tony Scott(我们的 CIO)和 Steve Ballmer(我们的 CEO)要求,只要有可能,必须将所有数据放入到 Azure(微软的平台即服务产品;www. microsoft.com/azure)中,所以我们正在设法将所有的内部行业应用迁移到 Azure。不过目前,有些东西绝对不会进入 Azure,比如,我们的 SAP 后端,就不会放进 Azure 中,但其余的一些包括业绩考核、工资以及我们的年度捐赠活动,我们公司的社会责任活动,所有这些都会进入 Azure,而且目前很大一部分已经放进去了。所以我们肯定会努力贯彻这一要求尽可能地将数据放入 Azure 中。

不过还是有些东西我们目前是暂缓执行的。PCI DSS(译者注支付卡行业数据安全标准)就是其中之一,因为支付卡行业中的虚拟化(安全标准)使用存在一个灰色地带,所以对部分这类事情我们暂缓处理,但是大部分我们内部的行业应用都已经做准备开始迁移到 Azure 中,并且,事实上,有部分已经放在那里了。剩下的也正在进行当中。

Grosse:是的,我赞成那个说法。还没有放到我们云里的数据已经寥寥无几了,包括我们那些最敏感的材料。比如,为高层管理人员做演示的有关并购的幻灯片。当我的小组在做一些最敏感的内部安全调查时发现那些记录真的已经在云中了——比如某个业绩考核资料。我们打心底里信任我们自己的云系统,我们每天都依赖于它们。

Ransome:如果连我们自己都不信任我们的云,又如何让我们的客户去相信我们的云呢?但也有例外,显然地,有时规章制度或政府要求某些云必须是私有的,这时我们就要讨论讨它们应该是混合云,私有云,亦或是公有云呢,不过目前而言,我们放进云的东西是从企业角度出发的,所以我还是同意前面两位的说法的。

Schmidt:完全同意前面几位的说法,事实上,我们在给客户(尤其是企业客户)列举很多示范的时候,我们会将内部开发的单独系统转移到云中作为其中的案例分析。这个例子诠释了我们如何思考将事情做到位,保证安全,而且还要做得相当有效。我仅以我们将内部 SAP 操作转移到云中为例,具体说来,实际上 SAP 的按需提供的云服务已经运行在 Amazon Web 服务上了,所以你可以想象到的任何类型的内部数据,我们都将转移到云中。

Iván Arce:前面多次提到规章制度和合规要求,而且事实上关于云的规章制度压力和合规需求也已经反反复复讨论很久了。但我想搞清楚其中有多少是真正发生了的,而又有多少是臆想出来的?

Jim Reavis:和以往一样,技术总会走在规章制度之前,因此当我们碰到一些实际问题时,我们会尽力向制度制定者作出解释,他们可能关心这些问题,关心如何保自己的国家里市民的信息。所以,我们需要解释如何保护这些信息,以及,我们能否保证信息不会泄漏到别的国家。

Arce:我赶紧再补充两句,Jim,你刚刚说的是某种遵循监察框架宗旨的补偿控制吗,还是某个行业或管辖区域所需的安全么?实际上,这些够不够?云计算提供商通过这些就能足够表明他们符合安全要求了吗?监管员、审计员的要求是否要严格很多呢?

Howie:在微软,我们经常碰到存在法规间互相冲突的情况,这时候我们不得不去了解法律法规所管理的范围并且尽我们最大努力去领会并遵循法律提倡的宗旨。

这儿有个典型案例欧洲数据保护法令和欧洲数据保留法令。数据保留法令由欧盟于 2006 年发布。基本上各成员国都可以编写各自的一套法规——事实上,他们也不得不编写法规,而对那些与电信和数据通讯相关的某些特定的元数据他们可以为各自的法规限定一个保存期限,该期限为 6 个月到 2 年之间。在爱尔兰,我们有一个对外公开的数据中心,此处的数据保留时间是 2 年。而德国规定的是 6 个月。我们经常被问到这么个问题,“如果一个德国公民在德国本土经过我们的数据中心访问在都柏林的服务,数据该保存 2 年呢还是 6 个月呢?”德国法规明确是 6 个月;而爱尔兰法规认为是 2 年,所以我们的答案是 2 年,然后德国就跟我们说了,“瞧,你们违反了德国法规。”那如果这个德国人到西班牙旅游了怎么办?西班牙对数据保留周期是 1 年。西班牙申明他们的法规优先。德国又讲,“不,这是一个德国公民,因此,我们的法规优先,”而我们的数据其实是存放在爱尔兰的——爱尔兰法规要求是 2 年。

所以你只能尽力去领悟法律精神并与之保持一致,因为对于一个全球性组织而言,你不可能做到能遵守你业务所涉及到的每个国家的法律。那样太不切实际了。回到 Jim 的观点,许多的规章在撰写的时候用意都很好,但它却没有考虑其中潜在的技术。

微软首席隐私安全执行官 Brendon Lynch 喜欢引用一句名言,它是这么说的,“所有的数据都是国际化的,所有的法律都是本土化的,”其结果必然是,你无法遵守这个世界上的每一条法规,因为那样太不切实际。

Grosse:我来补充几句。尽管受这些法规的条条框框约束让人很不爽,但还是有必要的。比如之前我们去申请 FISMA(译者注:联邦信息安全管理法案)认证,那就只能去适应那些规定,但是我们会发现运行那些框架的人的确都理解云计算的独特性,而且他们都很通情理,所以这部分还算好。但是真正的问题在于有很多人想要制定一种全新的云安全框架。我听说过有人罗列了几十条不同的竞争提案。要知道我们已经有太多不同的框架需要去满足了。

我真的很希望在安全框架基础上能有一些整合,这样当我们面对客户时就可以说,“好的,我们知道你需要我们提供一些证明才能相信云中数据是安全的,”如果等待我们解决的不同要求能少点的话,那每个人的效率都会大大提高的。

Ransome:我赞同,的确需要一个通用的控制框架来统一那些广为认可和接受的行业标准和规章。我真的很欣赏云安全联盟所作出的努力——他们做了一个控制矩阵——但是我觉得我们还是需要一个行业标准能够与时俱进,我觉得,比如对 ISO 27001 的使用就或多或少已成为事实上的标准了。你会发现只要遵守这个标准就能满足 80% 到 90% 的安全需求,然后你再去做一个商业投资回报率分析来确定那剩下的 10% 到 20% 是否值得你去投资。

Arce:你是否会觉得这么多不同的安全框架(如果让你们去使用的话)的技术视角是否显得太狭窄了呢?它们是不是不能被云服务提供商很好地应用呢?

Howie:没错,确实如此。另外,我认为短期内对任何法规或规章而言都是有挑战的。你得指望两件事情:其一,制定法律或规章的人;其二,这些人在制定规章的时候明白哪些技术是现在适用的。另外你也会要求他们拥有预见未来的神奇本领,因为等到那些东西被写入法案或者法规颁布的时候,那个行业早就已经产生了变化,我们也早就有了新技术,而且这些新技术已经源源不断进入到市场了。

另外,我认为立法机关、立法者和管理者会忽视或疏于考虑的是云计算广泛的涉及面。比如,我们常常会引用的一个数字(尽管已经过时了)是我们的接入流量,仅指 HTTP 的接入速率,而不包括 SSL——超过每秒 145 千兆。如果你碰到有人说,“你应该让这些接入流通过入侵检测系统。”那么仅为了安放入侵检测系统装置,我就要去搞一个数据中心来增加带宽。可这是不可能的呀。

Grosse:确实,那些谈论网络中的入侵检测、恶意软件检测或深度包检测的法规正逐渐被当前技术潮流所忽略。无处不在的解密技术、随处可见将使用 SSL 设为默认,使得许多法规衡量方式看起来并不那么合适,不过除此之外,“防御主要是对边界的防御的整体观念”从现代安全技术和实践角度看也是不太切合实际的想法,所以我们必然更依赖于将保护置于数据本身上,而不是那些云或某个公司的边界上。

Arce:对于哪些些技术适合与企业内部的安全控制,哪些不适合,有什么可以谈谈的吗?

Schmidt:云环境其实是非常非常不一样的,对此我同事之前已经有过描述。云的规模不同、实现不同,我们坚定地认同去边界化(de-perimeterization)概念(译者注:一种使用加密和动态数据层验证对公司数据进行多层保护的策略)。我们要真正摆脱边界,因为它就是那种金玉其外败絮其中的东西,黑客巴不得它的存在。一旦他进入了前门,就可以在该边界内部不受干扰、任意妄为。不需要在安全堆栈的每个层次上应用适当的、合理的安全控制,而应该将它们用在符合你的设计和运维的地方、用在那些能够达到公司要求的个人风险管理目标的地方。

Ghosh:我想从客户和企业的角度来问一个问题——出于成本和效率的考虑,将数据转移到云上——这样的话作为客户和企业应当意识到的最大的隐私风险会什么呢?你们会做些什么来抵御这一隐私风险?

Howie: 客户数据是神圣不可侵犯的,对与数据流向哪里、谁可以访问这些数据,我们有非常严格的控制。Facebook 的安全模型非常不同,所以许多你在 Facebook 上会看到的有关隐私的顾虑没有转移到企业云计算领域。它们有着截然不同的业务模型,至少从微软的角度来看是这样的。

在微软内部,每个开发者都要经过隐私培训。每个运维人员也要经过这种培训。我们在数据访问数据方面有非常严格的规章。

Schmidt:如果某个客户决定把数据放到美国,那它就将会放在美国,我们有合约确保我们言出必行。如果客户选择把数据放到亚太地区,那么它将会存放在亚太地区。有趣的是,我们有很多客户会说,“我想要把我的数据存放在欧洲,而我想要你向我保证这点——因为我需要保证符合欧洲的隐私法律,或者我需要确保我没有受美国政府的监督,没有我的同意不会转移到美国。”我们也会给出保证。

对于员工访问客户数据所存储的机器,我们也有非常严格的流程。我们会跟踪他们在那些机器上的每一步操作,并记录所有相关信息以供日后审计,从而确保所有员工的行为都符合我们的隐私政策。

Ghosh:Eric,之前提到了 Google,显然使用 Google Docs 的话,用户的个人信息必然会存放到云中。你能不能谈谈 Google 在隐私风险和控制方面的一些经验?

Grosse:我们对那些滥用客户信任的内部人员是严惩不贷的,但是这种情况极少发生,倒不是我关心的主要问题。我觉得对于隐私问题,我们还可以在用户方面做很多工作,使他们明白常规的、批准信息流程并确保这些信息对用户的透明化和可控性。

Ghosh:今天的情况是:你的数据存放在你公司防火墙内部的桌面、服务器上,再来看看未来的情况:数据将会转移到云上并无缝地从任意多个不同客户那里访问,到那时,你已经真正将数据集中其中起来,提供统一访问渠道。在黑客看来,他不再需要攻击你内部网络的多台计算机了,只需要进入你的云服务就可以了。对此你们是怎么看待应对云计算服务所面临的种种威胁,现在获取敏感数据的机会就在眼前,这种威胁将来会发展成什么样呢?

Howie:这种威胁趋势一直在不断发展,而我们成立了一个应对威胁的小组,专门观察威胁趋势和不断演化的威胁,进而修改或调整我们在持续评估过程中的控制,以此来确保我们能够抵御那些威胁。

我们还有一些别的正在使用的工具,我们也一直在关注接下来所要面临的一系列威胁。我无法告诉你这些大威胁是什么,因为它们总是在变化。今天遇到的威胁可能和明天遇到的截然不同。不过我们目前看到的典型情况是:有色背景噪音,网络钓鱼攻击。尼日利亚 419 诈骗案仍然时有发生。这种事总是会发生;我们一直在关注。这种攻击对云基础设施很难奏效。在去年的 DoS 攻击中我们就见到很多,我们已经领教了多种 DNS 劫持。

据我所知 Goolge 在过去 12 个月里经历了一些与我们此前所见很不一样的东西,我想让 Eric 一会儿来谈谈这件事。我们现在正在和 Amazon、Google 等其他公司的合作伙伴一起合作共享信息,并且 Jim 也完全表示认同。而我们对演化的威胁趋势的回应是:对威胁趋势本身进行持续评估,进而调整我们的控制以解决其中的风险问题。

Ghosh:Eric,很高兴你将能跟我们分享你所见的针对云计算的具体攻击或事件,分享它们的不同之处,或者预测一下它们独特和差异之处也可。

Eric Grosse:我想你们说的是我们在一月份博客中描述的一件发生在去年十二月的事情,当时我们目睹了一些非常复杂的攻击,这种层次的攻击一般很多安全媒体的人都以为只会发生在政府和国防承包商上,而我们指出,实际上并不是的,这种攻击会蔓延到整个经济的各个角落。我们在调查中发现了一起攻击,该攻击波及到其它 20 几家公司,所以他们也是受害者,所以我真的不认为那是专门针对云计算的。

那些非常复杂的安全威胁在不经意间就会来临,你可能没注意但它们的确存在,你可得加把劲花些时间和精力来处理了。在我们看到云计算带来的问题的同时,我们也能看到它带来的一些新机会。

在一个纯粹的云模型里面,如果你遇到一个古板的客户,他除了浏览器其余都不用。那么除了一些加密过的缓存之外,本地不存留任何状态。所有的数据都存在在云里,这样即便笔记本被人偷了,你也不用担心任何风险——从防范功能的角度看,这些(由云带来的)新的机会是很吸引人的,因为之前不存在类似的功能。

Arce:你们是否看到一些通过云服务来放大对消费者攻击的趋势?你们留意到这类趋势吗?

Howie:我们对此当然存有顾虑——事实上 Jim 和云安全联盟已经将此列为他们的最高等级威胁——总存在别有用心的个人或组织,虽然和我们签约协议,但还是在我们的服务上驻留恶意软件或其他什么的。类似事情我们在 Amazon 的同事说在基础设施即服务也遇到过,微软的平台即服务也发生过,没准儿 Google 的应用引擎上也碰到,也许人们的信用卡在这里被盗了。它们(译注:攻击)从网上来,消失在网上,因为购买服务的交互不是在物理世界里发生的。

你可以花些时间试着创建一个僵尸网络,你可能会成功也可能不会,你必须要在这个基础设施上去执行命令和控制,否则它们不会停止。

云本身可以说就是最大的僵尸网络。反过来想,当然,你可以争辩说僵尸网络是云计算目前最成功的版本。但是不管怎样它把问题暴露出来了。

回到我们之前谈到关于隐私的话题,我们并没有对我们的客户在云里到底做了些什么做例行检查,因为,要知道他们可是付了费的客户,这是他们的数据、他们的服务,他们从我们这里购买计算部件和服务。我们常常并不能马上就意识到什么时候有人正在我们的云里做些坏事儿,而我们只能依赖其他的机制、告警和滥用报告来真正了解在什么时候一些别有用心的个人或组织在 Azure 上购买了服务,并使用该服务来发布恶意病毒或执行网络钓鱼攻击。我们可能不是第一个知道的,因为按照隐私规章,我们不允许查看他们利用我们的服务到底在干些什么。

Reavis:总体上我认为,安全保障会越来越好,因为关键是你会让专家来处理这些安全运维,而他们将受到培训。会创建更好的基线,而这只是威胁服务,攻击服务也会逐渐改变。在此,我呼吁所有云提供商们为这些即将到来的改变和环境做好准备,到时候企业在云中存放的信息要比以前的多得多。然后他们会看到形形色色的人使用他们从未见过的方式来攻击他们,所以问题会很多。

Ghosh:业界对互联云有一些议论,这么说来我们不在云的孤岛上,而是有云信息共享的。你们对此有何见解,有哪些机遇和挑战,包括安全益处和安全风险,好比这是一个云服务联邦?

Grosse:在 Google,我们有个叫做“数据自由前线”的项目,其中会问到三个关键问题:我能不能完全得到我的数据?得到我的数据需要多少成本?得到我的数据需要花费多少时间?我们对这些问题的理想答案是:是的,你完全可以得到你的数据,花费的成本不会多于你现在正在支付的使用服务的费用,而至于时间,只要可能,你想多快就能多快。

所以,人无完人,但是互操作性仍然很快就会落到每个人的头上。因为,这就是我们需要的模型,数据是用户的,所以他们应该能够提取它。但是,要达到最高效率,还需要有互用性标准,这样当他们导出数据时,他们就能容易地导入到另一个地方。那才真正将会在这个领域引起一场巨大的竞争。

Howie:那么现在的问题是:你能否进入下一个层次,这样使得在多个云中工作的客户能够联合他们已经所拥有的云空间,而不管云服务提供商是否有意识到。他们真的能够同时、透明地从中移动数据吗,比方说从 Salesforece.com 到 Google Docs 或微软在线服务?因为你的客户可能使用 Salesforce 来做客户管理,用 Google Docs 做些什么。他们甚至可能用 Azure 来做其他什么东西,这样的话云服务提供商们会聚在一块儿提供什么方法来互相移动这些数据吗?我想不是那么回事儿吧,于是就有所谓的一些标准进来了,不过当然了,数据的输入和输出绝对是很紧要的事情。

另外一件很关键的事情当然就是身份元数据系统——让客户拥有单一身份,可以在各个云服务提供商之间交替使用。要实现这点最简单方法当然就是联合本地的目录存储库。问题是,标准要求你必须使用浏览器访问云服务时该方法才有效。

Grosse:因为我们已经在这方面研究了一阵儿了,所以我想补充一些关于数据导出的其他想法。其中一点就是我们发现客户很热衷于导出数据,不仅仅是数据本身还有元数据——比如,有关他账户的配置信息等等——其实这完全没有必要,因为他们导出的目的就是用到其他地方。如果他们能够导出一份人工可读或可解析的数据格式来,那他们就可以选择自行处理这些数据,比如查找那些看来有些异常的数据,如关于他们企业的一些别的信息。

这里得提一个安全问题。目前我们还没能解决认证问题,有些人的账户可能会被截获。如果我们让坏蛋很快就轻而易举地导出所有信息,这无疑是放大了这种损失和信息泄露的可能性。

我认为对我们来说另一大安全问题是,不仅要弄清楚“我们如何使用比设置密码更强大的方法来做首次账户认证?”,比如我们已经在做的两步验证,还要弄清楚“我们如何能从用户的方面当他们要做某些操作的时候也去增加一些额外的认证,尤其是当他们需要做很关键的操作时,比如导出所有数据或者删除所有数据的时候?”

谨代表 Ivon 和我自己,以及 IEEE Security & Privacy 杂志,对各位专家能在百忙中抽空参加这次有关云计算安全风险的讨论表示由衷地感谢,这次讨论相当有启发性,谢谢。

关于专家组成员

Eric Grosse,Google 安全小组工程主管,负责保护各用户、客户、员工以及系统的安全。他于 2007 年初加入 Google,之前他曾担任 Bell 实验室研究员一职并领导其研发部门致力于安全、网络和科学计算方面的研究。他拥有斯坦福大学计算机科学博士学位。

John Howie 是微软技术安全服务部门的资深主管,其部门属于是全球基础服务内的在线服务安全和合规小组。他管理该小组以负责识别和访问管理、战略和架构、威胁管理以及公司云计算基础设施的事故响应。Howie 以优异的成绩毕业于苏格兰龙比亚大学计算机专业,获得本科学历。

James Ransome 是 Cisco 公司合作软件部的一名资深主管,同时也是首席安全执行官,主要负责各组织和其客户安全方面的运维和战略方向。他管理的安全和合规工作跨多个功能域,包括信息技术、运维、产品开发、人力资源、沟通、法律、设施管理以及其他特别关注软件即服务(SaaS)的小组,还有 WebEx 服务的交付。

Jim Reavis是云安全同盟的创始人和执行主管。他之前是一名 ISSA(信息系统安全协会)国际理事会成员,这是一个全球非营利性质的信息安全专家组协会,Reavis 作为该协会的执行主管。Reavis 曾经是企业安全风险管理联盟的创始人,该联盟和 ISSA、ISACA 和 ASIS 都存在合作关系,主要致力于解决与逻辑和传统安全相关的企业风险问题。Reavis 拥有西华盛顿大学工商管理和计算机科学双学士学位。

Stephen Schmidt是 Amazon Web 服务(AWS)的首席信息安全执行官。除了负责 AWS 基于标准的安全合规性,他目前领导以安全为中心产品的设计、管理和工程开发。在加入 AWS 之前,他在 US FBI(美国联邦调查局)作为高级执行官有着广阔的职业发展,其职责包括作为首席技术执行官和 FBI 计算机部门主管,负责监督病毒代码分析、计算机开发工具反向工程和计算机侵入的技术分析。

本文最初出现在 IEEE Security & Privacy 杂志(双月刊)2011 年第一期。 IEEE Security & Privacy 杂志刊登由顶尖业界学者撰写的文章,这些文章兼顾实践应用和理论研究两方面,以案例研究、技术教程、专栏、深度访谈或播客等形式全面介绍信息安全行业。

查看英文原文: Cloud Computing Roundtable


感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2011-07-15 00:001877
用户头像

发布了 52 篇内容, 共 16.2 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

Fedora又一次哑了,又如何?

DisonTangor

fedora

Flutter图表库fl_chart的使用解析(二)-折线图,Android最牛教材

android 程序员 移动开发

FrameWork内核解析之PackageMS启动(一)下篇,android开发电子书

android 程序员 移动开发

Framework学习(七)AMS家族,kotlin开发思维

android 程序员 移动开发

Flutter如何和Native通信-Android视角,首发10万字Android开发实战文档

android 程序员 移动开发

Flutter实战(三)检验Flutter的跨平台能力,flutter菜鸟教程

android 程序员 移动开发

Flutter版 WanAndroid App,深入解析Android-AutoLayout

android 程序员 移动开发

模块二

侠客行

架构实战营 「架构实战营」

Flutter-视频系列--图解-Android-原生集成-Flutter-Module

android 程序员 移动开发

Flutter完整开发实战详解(三、 打包与填坑篇)_ 掘金技术征文

android 程序员 移动开发

Flutter混合开发(二):iOS项目集成Flutter模块详细指南

android 程序员 移动开发

「免费开源」基于Vue和Quasar的前端SPA项目crudapi零代码开发平台后台管理系统实战之之拖拽表单定制(十六)

crudapi

Vue 零代码 crudapi quasar 拖拽表单

Flutter之全埋点思考与实现,跨平台app开发工具

android 程序员 移动开发

腾讯云发布星星海智慧木系GA01,新一代基于AMD的企业级GPU卡“诞生”

科技热闻

Flutter学习之事件循环机制、数据库、网络请求,kotlin开源项目实战

android 程序员 移动开发

架构实战营毕业总结

蔸蔸

Flutter动画 3 - Animation动画组,android物联网开发李天祥

android 程序员 移动开发

Flutter完整开发实战详解(四、 Redux、主题,某大厂开发者对于Android多线程的总结

android 程序员 移动开发

Redis 高可用篇:主从架构数据同步一致性原理

码哥字节

数据库 redis NoSQL 数据库 11月日更

Flutter这么火为什么不了解一下呢?(上,这份333页关于性能优化知识点的PDF你不能不看

android 程序员 移动开发

Fragment极度懒加载-+-Layout子线程预加载,奇妙的APP启动速度优化思路

android 程序员 移动开发

Flutter初学者之普通底部导航栏及自定义不规则底部导航栏的实现

android 程序员 移动开发

WorkPlus政企消息协作解决方案:一站式处理、安全可靠

WorkPlus Lite

Flutter开发桌面应用-第一个windwos桌面应用,android游戏开发框架

android 程序员 移动开发

Fragment中调用startActivityForResult的那些坑,安卓面试题目2019

android 程序员 移动开发

Flutter图片加载原理与缓存,安卓高级开发工程师面试题

android 程序员 移动开发

Flutter集成高德定位和地图功能,精通android游戏开发pdf

android 程序员 移动开发

Flutter中的http网络请求,kotlin程序

android 程序员 移动开发

腾讯云发布微搭生态开放计划,与合作伙伴携手共创产业未来

科技热闻

Flutter实战详解--高仿好奇心日报,kotlin核心编程

android 程序员 移动开发

Flutter嵌套深?扩展函数了解一下,面试字节跳动Android工程师该怎么准备

android 程序员 移动开发

圆桌会议:云计算的安全风险_架构_Anup Ghosh_InfoQ精选文章