Weitere ähnliche Inhalte
Ähnlich wie 云计算的安全考虑 (20)
云计算的安全考虑
- 3. 2
配合使用不同的云提供商，以整合并/或分散风险和遵从性管理工作，这种做法往往要求提供商将自己
的运作进行一定程度的公开。在提供商的透明程度和保密工作之间找到最佳平衡点，这属于一个极大的
挑战。而透明度在确保组织最大程度地履行其责任，以及与服务提供商建立信任之间起到了重要作用。
客户往往要求提供足够透明的流程，以做出稳妥的风险决策 — 这主要取决于要保护的数据的敏感程度
— 在满足该条件的前提下才能让提供商保护自己的私有系统和流程。
一旦能够足够了解云提供商的控制机制，组织的内部团队即可开始将这些控制整合到自己的风险和遵从
性管理，以及安全管理环境中。鉴于对组织的遵从性需求有着宝贵的经验和独特的理解，该团队通常应
当被包含在与任何云提供商进行合约谈判的工作中。
在规划阶段，组织应当考虑需要进一步研究的额外的逻辑问题，例如：组织是否应当继续保留在未来将
部分或全部服务重新切换回自有管理机制中的能力，是否需要将部分或全部的服务迁移到不同的云服务
提供商，此类变动的相关成本是多少，组织如何确原本保存在提供商范围内的所有数据（包括备份）能
够被彻底删除，以及如果对所选择的云服务提供商有分歧，如何获得对数据的访问。
身份和访问管理
基于云的服务要求进行安全的跨域协作，并且需要针对人员和设备身份的误用提供保护。任何用于身份
和访问控制的系统，尤其是应用于高价值资产的此类系统，都应使用基于面对面证明的身份框架，或其
他同类的强有力的流程，并且一定要提供强健的密码凭据。这些
任何用于云环境的数字化身份 凭据可确保实现“基于声明”的访问控制系统，并可对由系统中
系统都必须能够跨越不同组织 任何实体所作的声明进行身份验证。该身份验证系统的强度应在
和不同云提供商，并基于强流程 对系统用户的隐私保护的需求程度之间取得合理平衡。为实现这
进行互操作。 种平衡，该系统应当能够传输强声明，并在不需要获得对服务所
涉及的特定事物或连接之外的任何非必要信息的情况下进行验证。
安全的身份管理对任何环境都是不可或缺的，但在云计算环境中将变得更加复杂。云系统通常会提供多
种身份声明提供程序，并使用不同流程，以便能够被充分理解并证实自己是可信赖的。将服务迁移到云
端则会产生多种问题：身份归谁所有？针对身份和访问管理可实施怎样的控制？组织是否可更换声明提
供程序？身份联盟机制如何配合使用不同的提供程序？身份验证和认证工作是如何绑定到身份的？如
何与组织之外的，使用其他身份提供程序的个人建立自由式的协作？
任何身份环境都应能够跨越使用不同身份声明的应用进行互操作，并且必须能够为将数据访问控制机制
迁往云端，以及从云端迁回等工作提供安全的迁移方式。这一环境必须能够被使用晕服务的组织以及个
人所管理。
在帮助确保每个参与者都能理解某一身份提供程序被信任和可负责的安全级别方面，身份提供程序的证
书和声誉系统扮演了关键角色。在这个问题上，带有强凭据需求的数字身份系统，如果同时能够对外围
用户，以及根据互操作声明对云提供商进行验证，通常即可极大地增强安全性和数据完整性。
服务完整性
服务完整性包含两个组件：1) 服务的设计和开发，以及 2) 服务的交付。服务的设计和开发还包括提
供商在开发工作的各个阶段实施安全和隐私保护的方式。 服务的交付则涉及在满足合约所约定级别的可
靠性和支持工作的情况下，服务的运作方式。
© 2010 Microsoft Corporation。保留所有权利。
- 4. 3
服务的设计和开发
任何开发软件的组织都应当遵循一定的设计和开发流程，以在自己的产品中包含安全和隐私保护功能。
云计算环境的设计和开发也是如此，并且往往需要一种流程，能
提供商应当遵循清晰定义的可 够将安全和隐私保护贯彻到应用程序和软件开发的整个过程中
证实流程，以便在前期工作和整 — 无论是由组织的开发部门，或者云提供商和/或其他第三方开
个生命周期内为服务提供安全 发的程序皆是如此。虽然作为一项收益，云运营商可以提供整合
和隐私保护。
式安全技能，但依然需要确保提供商的开发和维护流程在每个开
发阶段都考虑到安全和隐私保护。Microsoft 的应用程序开发工作
使用了安全开发生命周期技术，并已将其扩展到云计算环境中开发工作的每个阶段。
需求。这一阶段的主要目标是确定主要安全目标，否则需要在确保最大程度的软件安全性的同时，
确保客户易用性、规划，以及计划方面的影响降到最低。
设计。这一阶段的关键安全步骤包括记录潜在的攻击面，以及建立威胁模型。
实施。在这一阶段中，开发团队必须采取措施以确保代码中不存在已知安全漏洞，为此需要遵守一
定的代码编写标准，并针对软件的进化使用分析工具。
确认。在这一阶段，团队必须确保代码满足前期阶段中建立的安全和隐私信条，团队还需要完成公
开发布的隐私评估。
发布。在这一阶段需要进行最终的安全审查，这种审查有助于确定产品是否已经足够安全，并可以
发布，为此需要确保软件满足所有标准的安全需求，并满足任何额外的，与特定项目有关的安全
需求。
响应。软件发布后，提供商还需要准备安全响应小组，以找出、监控、解决，以及响应安全事件和
Microsoft 软件的安全漏洞。提供商还需要管理涉及整个公司范围的安全更新发布流程，并承担单
点协调和沟通的工作。
在对云服务提供商进行评估时，应询问有关提供商的特定安全开发流程方面的问题。这些流程应反映上
述每个通用阶段，因为上述每个领域对整体的安全开发流程都至关重要。另外还需要讨论这一安全流程
在长期时间内的性质，包括威胁模型的更新频率，安全响应小组的职能，以及客户如何获得有关安全更
新的通知等。
服务的交付
如果要将关键业务流程迁移到云计算模型下，则还需要对内部安全流程进行更新，以允许多个云提供商
可以在需要时参与到这一流程中。这其中包括的流程有安全监控、审计、法定责任、事件响应，以及业
务连续性等。这一协作必须被包含到客户和云提供商最初的云交
提供商的服务交付能力以及客 付工作中，并需要照顾到所有参与方的需求。对于某些应用或服
户的安全管理和审计需求必须 务，服务的安全需求非常简单直观，但对其他服务（例如涉及到
能够匹配。 高价值资产的服务），则需要考虑并建立更加严格的需求，包括
物理安全需求、额外的日志，以及更深入的管理员背景核查等。
任何云服务协议都应包含有关性能问题管理等问题的详细规划，按照需要照顾到网络和映像方面的法定
责任，并包含在服务的交付遇到中断后，负责进行修复的特定责任联系人和流程。最终，该协议应当定
义云服务应以怎样的价格提供何种程度的安全监控和审计功能。
端点完整性
© 2010 Microsoft Corporation。保留所有权利。
- 5. 4
云安全的讨论通常会专注于服务本身，以及提供商的安全品质和实践。可如果不能对整个服务链从开始
到结束的全过程进行评估，就可能会在服务的设计和交付中产
对于基于云的服务，一定要确保 生瑕疵。云服务的开始和结束可能发生在组织内部，或使用相
在安全性的考虑中包含端点方 关服务的个人所使用的个人计算机或设备上。在很多情况下，
面的考虑。 如果组织的安全防护受到威胁，问题通常会发生在特定工作站
上，而不会发生在后台服务器上。为了增强云计算端到端的信
赖程度，所有活动都应考虑到，这样才能保护用户防范包括在线身份盗窃、网站跨站点脚本攻击、钓鱼
攻击，以及恶意软件下载等各种威胁。
今天的大部分企业都实施了具备抑制功能的内部风险管理程序，以保护端点并管理信息安全性，并且整
个基础架构已经得到了充分理解，在整个环境的任何级别下都是透明的。然而在云计算环境中，则应审
查安全标准和方法，因为云服务可能依赖多个服务提供商，但可能无法对所有提供商获得相同级别的透
明度。
因此一定要考虑不同服务是如何合作的，是如何被整个组织所使用，以及都存在哪些不同类型的端点系
统。如果端点安全也交由提供商负责，那么就产生了一些非常重要的问题，例如：如何强制实施安全和
遵从性需求？如何保护数据不被误用？用户是否依然可以使用加密或权限管理机制保护数据防范丢失
或失窃？服务是否可被限制为仅供特定已授权端点或机器使用？
信息保护
在决定服务是否可由服务提供商进行管理时，服务的运作所涉及数据的敏感程度起到了至关重要的因素，
对于这种情况，还要决定需使用怎样的访问控制机制以确保整个事物可满足遵从性方面的需求。 实施健
全的数据分类机制即可确定事物所涉及的数据集，并确定在特定
实施数据分类机制有助于决定 情况下应用给数据集的控制机制，借此即可帮助组织作出决策。
哪些数据在什么样的情况下，已 无论数据的存储和传输方式如何，组织都需要确定可接受的数据
经可以放入云端，并对其进行怎
处理和信息管理级别。这一基本原则还适用于目前的内部环境。
样的控制。
除此之外，对于云服务的交付，还需要了解需要承受的其他挑战，
包括数据主权、信息的访问，以及数据分隔和处理。
多年来，已经针对数据的保护制定了相关的规章制度。这些制度通常都针对特定的司法制度，用于对数
据的权威性划定限制或范围。随着云计算的到来，数据可能会保管在最初确定的范围之外，或位于多种
不同的范围或位置中。在客户的司法范围或位置之外承载数据可能导致有关信息管理和访问方面的问题，
即谁，或哪些实体对数据拥有“主权”。目前一些较新的云服务正在尝试通过允许客户指定数据的物理
存储位置，解决这些挑战。
当信息的管理和控制从一方转交给另一方，组织可能会失去保护、获取，或移动信息的能力。因此一定
要理解谁控制了访问信息所需的身份和身份验证系统，备份数据都保存在哪里，是否支持对数据进行加
密，加密解决方案有哪些相关成本（例如功能的缺失），以及如果对服务提供商的选择存在分歧，如何
获取对数据的访问和管理。例如，是否可以确保如果服务被取消，服务提供商无法保留任何数据。
最后，如果数据被存储在“公用云”中，承载数据的基础架构可能是与其他组织所共用的。此时依然可
以借助强数据保护实践确保数据按照正确的方式进行分隔和处理。因此在批准在云端处理数据之前，组
织一定要明确谁可以访问自己的数据，并考虑相关风险是否是可接受的。另外还需要明确云服务提供商
的架构，以确信如何保护共享的虚拟机防范来自相同物理硬件上，被恶意用户使用的其他虚拟机进行的
各种形式的潜在攻击。
© 2010 Microsoft Corporation。保留所有权利。
- 6. 5
结论
为了充分利用云计算机遇，应解决各种特定的安全问题：流程、技能、技术，以及控制。拥抱云环境的
组织应考虑下列实践点：
在采纳云服务之前，针对身份、数据，以及设备，实施功能完善的遵从性程序。
在评估风险和针对是否采用云计算做决策时，数据分类是一个关键需求。低风险数据可以放心投入
云中，而高影响数据则要求更强大的安全保护和隐私控制。
部署模式（私有、社区，以及公用）的选择需以数据分类、安全和隐私需求，以及业务需求为基础。
就算全面采纳云计算，组织依然需要强有力的内部团队，以与云提供商合作，管理安全和遵从性需
求。
透明度、遵从性控制，以及审计能力对于任何云服务提供商的评估工作都是重点因素。
组织必须为云中承载的应用的开发实施安全开发生命周期方法，并需要用类似的流程评估云提供商
的遵从性。
作为访问管理系统的基础，应使用更强的凭据取代用户名和密码。
所考虑的问题应为信息生命周期提供所需的控制，无论数据来源如何，都应对信息的访问进行限制，
限制已授权的个人，并限制可用的时间框。
数据的访问控制需要跨越组织边界运作，或需要跨越不同部门、外部供应商、政府机关，以及消费
者。因此必须提供能够跨越这些边界的联合访问，哪怕客户并不直接需要管理自己的身份和身份
验证。
相关材料
云计算联盟：云计算关键领域的安全指南：
http://www.cloudsecurityalliance.org/csaguide.pdf
ENISA：云计算信息担保框架：
http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-information-assurance-fr
amework/
保护 Microsoft 的云基础架构：
http://www.globalfoundationservices.com/security/documents/SecuringtheMSCloudMay09.pdf
客户端和云应用程序的安全考虑：
http://go.microsoft.com/?linkid=9704049
来自 Microsoft 在线服务的业务生产力联机套件安全问题：
http://go.microsoft.com/?linkid=9671260
© 2010 Microsoft Corporation。保留所有权利。
