本文转自：http://blogs.msdn.com/b/azchina/archive/2011/03/06/windows_5f00_azure_5f00_security_5f00_overview_5f00_white_5f00_papaer.aspx

摘要

 Windows Azure ，作为一个应用程序宿主平台必须提供私密性，完整性和用户数据的可用性。它也必须提供透明的可靠性来允许用户和他们的代理商通过自己和Microsoft追踪服务管理。 

本文档描述了大量在Windows Azure中实现的控制器，用户可以决定是否这些能力和控制器适合他们的唯一需求。该概述以从用户和微软业务观点对安全功能的技术测试开始 - 包括以Windows Live ID驱动并使用双向SSL认证进行扩展的身份和访问管理;分层环境和组件的隔离，虚拟机的状态维护和配置完整性，为尽量减少硬件故障的影响二提供的三重冗余存储。 在技术讨论的额外部分还提到了在用户的云环境中，通过Windows Azure的支持的可靠性如何监视，记录和报告。

紧接着技术的讨论，本文也提到了人员和流程来帮助使Windows Azure更安全。其中包括微软被全球公认的在Windows Azure的开发过程中的SDL原则，控制操作人员和管理机制，物理安全特性，例如用户选择地域，资料设备 访问，电力冗余。

本文以简短的对规范的讨论作为结束。规范在IT企业中始终有着持续影响力。 虽然对法律，法规和行业需求遵守的责任在Windows Azure的用户身上，微软对于提供基础安全设施的承诺，以及为适应用户特殊挑战而提供的不断扩大的工具选择范围对微软自身的成功是极其重要的。并且这些也是我们用户使用Windows Azure平台获得成功的关键所在。

目录

 1.引言

     1.读者和范围

1.   安全模型基础
   1. 用户视角：计算，存储，服务管理  
   2. Windows Azure的 视角: Fabric  
2.   云安全设计
   1.      私密性
      1. 身份和访问管理
      2. 隔离
      3. 加密
      4. 数据删除
   2.     完整性
      1.  可用性
   3.     可靠性
3.   开发周期安全
4.   服务操作
   1.       微软操作员
   2.       安全应答
   3.       网络管理  
      1.          Fabric Controllers的远程管理 
   4.      4.物理安全  
      1.          设备访问
      2.          电力冗余和故障转移
      3.          媒介清除
5.   合规
   1.       用户可选择的地理位置
   2.       合规控制
   3.       ISO 27001 认证
6.   进一步阅读参考文献
7.    术语表

1. 引言

Windows Azure是云端服务操作系统，包括了Windows Azure平台上的开发，服务寄宿和服务管理。Windows Azure通过微软数据中心提供开发人员按需计算和存储，让他们能够寄宿，拓展，管理互联网上的Web应用程序。通过使用Windows Azure，微软寄宿属于用户的数据和程序。也正因为这样，Windows Azure必须解决超出传统IT方案意义上的信息安全挑战。本文档介绍了Windows Azure的用户可以使用的控制器，以实现其所需的安全级别，并确定是否这些能力和控制器能够适应他们的独特需求。

 读者和范围

这本白皮书的目标读者包括：

• 对创建在Windows Azure 上的运行的应用程序感兴趣的开发者。
• 正在考虑用Windows Azure 支持新的或者现存服务的技术决策者。

这份白皮书中的的重点是作为在线服务平台组件

的Windows Azure 操作系统,并未涉及任何关于

Windows Azure 平台组件的详细说明，如Microsoft SQL Azure , AppFabric,或Microsoft Codename "Dallas"。 讨论集中在Windows Azure的安全特性和功能性上。

尽管本文提供了最低限度的一般性介绍信息，读者依然需要熟悉Windows Azure的基本概念（参考Microsoft提供的其他参考资料）。 在文档的最后，你能发现更多其他参考资料的链接来做进一步阅读。

文档的最后也包含了术语表，专业词汇在本文中用粗体加下划线标注。

安全模式基础

在专研更深的Windows Azure 安全特性技术之前，这一部分为它的安全模式提供了一个简单的概述，之后，这个概述假设了读者熟悉Windows Azure 基础概念，主要集中讨论安全相关的特性。

用户视野：计算，存储，和服务管理

Windows Azure 被设计成对典型基础运用下的大量基础设施的抽象（服务器，操作系统，Web数据库软件等）因此开发者可以集中精力创建应用程序，本节对一个典型用户访问Windows Azure时看到的东西进行了简要概述。

图1：Windows Azure关键组件的简要概述。

如图1所示，Windows Azure 提供了两个主要的功能：基于云的计算和存储。在这上面，用户可以建立和管理应用程序和关联配置。用户通过订阅来管理应用程序和存储。典型订阅可以通过用信用卡在订阅网页上关联新的或者现存的身份凭证来创建。随后对订阅系统的访问可以通过一个Windows Live ID(https://login.live.com)来进行控制。Windows Live ID 是现存的运行时间最长的互联网身份验证服务之一，为Windows Azure提供了一个已被严格测试的门卫系统。

订阅可以包括零个或多个托管服务和零个活多个存储账户。一个  托管服务包含了一个或多个的部署。一个调度包含了一个或多个角色。一个角色包含了一个或多个实例。存储帐号包含二进制数据块，表格，和队列。Windows Azure 驱动是一个特殊的二进制数据块类型。  托管服务的访问控制和存储账户由订阅管理。对关联到订阅的Windows Live ID 进行身份验证的功能提供了对在该订阅下的所有托管服务和存储账户的完全控制权。

用户上传开发完成了的应用程序并通过Windows Azure Portal 网站，或编程通过服务管理API(SMAPI) 来管理他们的主机服务和存储帐号。用户通过浏览器进入Windows Azure Portal 或通过命令行工具（可编程或用Visual Studio）访问SMAPI，

SMAPI的身份验证是基于用户创建的共有/私有密钥对和通过Windows Azure Portal 注册的自签名证书的。这个证书会在后续的SMAPI访问中用到。SMAPI在Windows Azure Fabric中将请求进行排队，然后Windows Azure Fabric接管请求，初始化，管理所需要的应用。用户可以通过Portal或者使用相同认证机制的可编程SMAPI监视和管理他们的应用程序。

对Windows Azure 存储的访问时由存储账户密钥来管理的。该密钥关联到了每个存储账户上。存储账户密钥可以被Windows Azure Portal或者SMAPI所重置。

计算和存储能力进一步组成了Windows Azure的基础功能单元。图2 提供了更颗粒化的视图，暴露出了这些基础单元并说明了它们与之前描述的组件之间的联系。所有到目前为止讨论过的组件的描述归纳如下：

• 主机服务包含部署，角色和角色实例。
• 存储账户包含二进制数据块，表格，队列和驱动。

这些在术语表里定义都有定义，关于它们的详细说明在Windows Azure 的一般资料中就可以找到。在这里简单介绍来对本文余下部分的对Windows Azure 的安全功能更深入的讨论做准备。

主要的Windows Azure 主题，对象，和身份验证机制在表1中归纳如下：

表1Windows Azure 授权机制的总结：

图2：Windows Azure 组件和关系的颗粒化说明。

Windows Azure 的视角 ：Fabric

我们已经从一个上层的角度描述了可以被用户管理的Windows Azure组件，接下来我们将进一步探究在Windows Azure 基础计算和存储底下的Fabric。尽管我们已经说过用户可以通过定义的管理接口控制Fabric，Windows Azure主要目的依然是抽象虚拟基础设施的管理，使得它能为用户简单的呈现一致性的，可扩展性的资源集。简而言之，开发者不需要管理这些虚拟的基础设施，这些都是微软代做了。这一节将介绍由微软直接管理的Windows Azure Fabric中的一些基础组件。

基于被用户指定的角色实例的数目，Windows Azure 为每个角色实例提供了一个虚拟机（VM），然后在这些虚拟机上运行这些角色。这些虚拟机运行在为使用云技术特别设计的 管理程序上（Windows Azure 管理程序）。一个虚拟机是一个专门应用：它运行在一个托管了Fabric Agent（FA）的被叫做Root OS 的操作系统上。FAs管理guest agents (GA)，（托管在用户虚拟机上的guest OSes中）  。FAs也管理存储节点。Windows Azure 管理程序，Root OS/FA，和用户VMs/GAs组成了一个计算节点。

FAs被Fabric Controller （FC）管理，FC存在于计算和存储节点的外边（计算和存储集群通过独立的FCs管理）。如果有用户在系统运行时更新了他的应用程序的配置文件，FC会与 FA通信，FA然后联系GA，GA通知应用程序来报告配置的改变。在硬件故障的情况下，FC将自动找到可用硬件然后在新硬件上重启虚拟机。

2. 云安全设计

从根本上说/基本上，正如其它任何应用托管平台，Windows Azure 必须提供私密性、完整性和用户数据可用性。它也必须提供透明的可靠性来允许用户和他们的代理商通过自己和Microsoft追踪服务管理。在描述了基础组件和相互关系之后，这一节会说明Windows Azure是怎样提供这些信息安全的经典特征。

私密性

• 私密性确保用户的数据只能被授权实体访问。Windows Azure 通过以下机制提供私密性：
• 身份和访问控制 - 确保只有适当的被验证过的实体可以被允许访问。
• 隔离 - 通过保证适当的容器在逻辑上和物理上的分离来实现最小化数据交互
• 加密 - 在Windows Azure内部使用，来保护控制渠道并且可提供给需要严格数据保护机制的用户

更多的关于这些数据保护机制在Windows Azure中试如何实现的内容如下：

身份和访问管理

现有的最健壮的安全控制机制也不能防止那些获得未经授权的身份信息和密钥的攻击者。因此，身份信息和密钥管理在安全设计和Windows Azure的实现中都是关键的组件。

所有的主要身份和验证机制已经在之前介绍过了，它们归纳在表1中，这部分提供了更为深层的描述，包括APIs，应用程序优先级，密钥分配和对可信子系统（如Fabric 控制器）的身份验证。

SMAPI身份验证

SMAPI通过REST协议提供Web服务，它是通过Windows Azure 工具提供给用户开发者使用的。这个协议运行在SSL上 ，通过一个证书和用户创建的私钥来进行身份验证。这个证书不需要一个可信任的检查证书颁发者（CA）。只需要一个自签名证书并且将该证书的指纹通过Windows Azure Portal关联到订阅即可。只要用户拥有对密钥以及用来创建账户的Live ID的控制，这个方法提供了高度安全保证，确保只有用户授权的实体才能访问服务的特定部分。

最少特权用户软件

用最少的特权运行应用程序被广泛当作信息安全的最佳实践。为了与最少特权原理保持一致，用户没有被授予对虚拟机的管理员权限。默认情况下，用户软件在Windows Azure中使用低特权账户运行（将来版本中，用户可以根据需要选择不同特权模型）。这减少了潜在的影响，增加了任何除了获得漏洞外还需要提升特权才实施攻击的攻击复杂性。这也保护用户的服务不受自己终端用户的工击。

内部控制通信量的SSL双向认证

所有Windows Azure内部组件的通信被SSL保护。在大多数情况下，SSL证书是自签名的。例外是可能被Windows Azure网络外部访问的连接所使用的证书（包括存储服务）以及FC。

FC拥有微软CA颁发的证书，是拥有可信任根CA的。FC的公钥可以被微软开发工具使用。这样当开发人员递交了新的应用程序印象后，它们可以被FC公钥加密来保护任何里面的秘密资料。

证书和私有密钥管理

为了降低暴露证书和私钥给开发者和管理者的风险，它们是通过一个不同于使用它们的代码的独立机制安装的。证书和私钥是通过SMAPI或者Windows Azure Portal以PKCS12 (PFX)文件格式上传的。上传过程受到SSL的保护。这些PKCS12文件可以被密码保护，但是如果这样，密码必须在同一个消息中包含。SMAPI提供了密码保护机制（如果需要的话），使用了SMAPI的公钥加密了整个PKCS12数据块，在一个私密的FC上的数据存储点进行存储，并附带存储了简短的证书名和公钥来作为元数据。

在同一订阅中的角色所关联的配置数据指定了角色所需的证书。当一个角色在一台虚拟机上初始化时，FC得到了相应的证书，解密PKCS12数据块，重新使用FA的公共传输密钥对其加密，并且把它发送到节点上的FA处。节点上的FA把它发送到初始化角色的虚拟机上的GA处，然后GA解密它并且在操作系统的数据存储点上进行安装，并标记私钥可以被使用但是没有被导出。在安装后，所有临时证书拷贝和密钥被销毁。如果需要重新安装，证书必须被FC重新打包。

FC使用的硬件证书 

除了应用程序密钥，FC必须维护一组证书(密钥和/或密码）在向不同在它控制下的硬件设备验证自身时使用。传输，维持，使用这些证书的系统使得Windows Azure开发人员，管理者，服务备份员不必需要了解秘密信息。对FC的主身份公钥的加密在FC安装和重配置时使用，来传输访问网络硬件设备，远程电力转换器和其他系统所需的身份信息。FC在它的内部被复制的数据存储点(同样被FC的主身份证书加密）中维护这些秘密信息。

Windows Azure Storage的访问控制

前面已经讨论过，Windows Azure Storage拥有一个简单的访问控制模型。每个Windows Azure 订阅可以被创建一个或多个存储账户。每个存储账户有一个密钥用于在存储账户中控制访问所有数据。这支持这样的一个场景，存储关联应用程序并且这些应用程序完全控制他们的关联数据。通过在存储前端创建用户应用程序，给予应用程序存储密钥，让用户程序验证远程用户，甚至对单个的请求进行授权我们可以获得一个更为成熟的访问控制模型。

两种机制支持了一般性的访问控制场景。部分在数据存储的账户中的数据可以被标记为公开可读的,在这种情况下,读数据可以不需要共享密钥签名。这主要用于访问非敏感数据，例如网页图片。 

另一种机制被叫做共享访问签名（SAS）。一个进程，知道给定存储账户密钥（SAK），可以创建一个请求模板并且用SAK来签名。这个签完名后的URL可以给另一个进程，另一个进程之后可以用它来填充请求细节并向存储服务发送该请求。身份验证依然是基于一个用SAK创建的签名。但是该签名是由第三方发送给存储服务的。这样的代理机制可以对有效时间，许可集和存储账户中哪一部分可以被访问进行限制。

一个共享访问签名也被称为一个容器级别的访问策略，该策略代替了用一定数量参数（例如有效时间或者许可集）在URL中直接表示的方法。这些参数实际上由存储在Windows Azure存储服务中的访问策略指定。因为一个容器级别的访问策略可以在任何时候被修改或者撤销，它提供了更大的灵活性和对所授权限的控制力。

为了支持周期性的SAK的变化而不造成服务的中断，同一时间一个存储账户可以有两个关联到自身的密钥(任一密钥均有对数据的完全访问权）。改变密钥的顺序是先添加新的密钥到存储服务，然后改变所有访问该服务的应用程序使用的密钥。最后移除旧的密钥。改变被授权的存储密钥是通过SMAPI或者Windows Azure Portal来完成的。

隔离

除了对数据访问进行身份验证,简单地把不同的数据适当地进行隔离也是一种被广泛认同的保护方式。Windows Azure 提供了不同级别的隔离，如下讨论：

管理程序，Root OS 和Guest VMs的隔离

一个关键的边界是Root虚拟机与guest虚拟机的隔离，guest虚拟机与另一个guest虚拟机的隔离，这是通过管理程序和Root OS来管理的。管理程序/Root OS利用微软的数十年的操作系统安全的经验,以及最新微软Hyper-V经验,提供了一个健壮的guest VMs隔离。

 Fabric Controllers的隔离 

作为Windows Azure Fabric的核心部分，许多重要的控制器被应用以减少对Fabric控制器的可能危害，特别是防止哪些来自潜在的被在用户程序中所攻破的FAs的威胁。从FC到FA的通信是单向的 - FA实现了一个被SSL保护的服务，该服务被FC访问并只对请求作出反应。它不能发起与FC或者其他高特权内部节点的连接

FC以返回消息来自不受信任节点的标砖严格分析所有收到的返回消息。

此外，FCs和无法实现SSL的设备在独立的VLANs上，这限制了他们的身份验证接口暴露在被攻破的虚拟机的主机节点的可能性。

包过滤

管理程序和Root OS提供网络数据包过滤器保证不受信任的虚拟机不能产生伪造流量，不能接收非以它们为接受对象的数据，不能指挥数据流向以保障基础设施端点，此外，它们不能发送或接收不适当的广播数据。

存储节点只运行Windows Azure的提供的代码和配置，因此访问和控制的范围仅允许合法用户，应用程序及管理者。

用户访问VM（虚拟机）被包过滤限制在边缘有限的负载平衡器及Root OS。特别是远程调试，远程终端服务或远程访问虚拟机文件在默认情况下是不准许的；微软正计划允许用户能够明确选择这些协议。微软允许用户指定在上述情况下是否允许互联网及远程链接。

不同的应用程序之间的连接作用都被认为是互联网的连接。连接规则是累积的，例如，如果任务实例A和B属于不同的应用程序，A只有在A本身可以打开与互联网的连接且B可接受来自互联网的连接的情况下才可以打开与B的连接。

fabric控制器将目录上的角色转换为一个任务实例列表，并得到一个IP地址的列表清单。这个IP地址列表被FA用于数据包过滤器，只允许内部应用程序间的通信访问这些IP地址。角色被允许启动与互联网的连接。这使得他们能够通过网络连接并将信息通过他们的VIP送至任何网络可见任务中。

VLAN隔离

VLANs在隔离FCs和其他设备时被使用。 VLANs对网络进行隔离，这样VLANs之间的通信不可能不经过路由器，这防止了一个被攻破的节点伪造来自它自身VLAN外部的数据通信（除了对自身VLANs其他节点的通信外），并且它也不能窃听非来自或发到自身VLANs的通信。

每个群集中有三个VLANs：

•主VLAN - 连接不受信任的用户节点

•FC VLAN - ???括受信任的FCs和支持系统

•设备VLAN - 包括受信任网络和其他基础设施设备

从FC到主VLAN的通信是允许的，但通信不能从主VLAN到FC VLAN。从主VLAN到设备VLAN的链接也是被*的。这保证了即使一个运行用户代码的节点被攻破，也它不能攻击FC或设备VLAN的节点。）。

用户访问的隔离

管理用户环境访问的系统（即Windows Azure Portal，SMAPI，等等）是在一个由微软运作的Windows Azure应用程序中被隔离的。这在逻辑上将用户访问基础设施与用户应用程序和储存隔离。

加密

在存储和传输中的数据加密可令用户在Windows Azure使用中，确保数据的保密性和完整性。如前所述，关键的内部通信使用SSL加密进行保护。作为用户的选择之一，Windows Azure SDK扩展了核心.NET类库以允许开发人员在Windows Azure中整合.NET加密服务提供商（CSPs）。熟悉.NET CSPs的开发人员可以容易地实现加密，哈希以及密钥管理功能来存储和传输数据。举例来说，使用.NET CSPs，Windows Azure开发人员可以容易地访问：

•如ASE之类有多年现实世界测试使用经验的加密算法，从而避免 "roll your own crypto"的错误

•包括MD5和SHA - 2在内的一系列哈希功能来验证数据的正确性，创建和验证数字签名，以及创建非可辨认凭证来替代敏感数据。

•RNGCryptoServiceProvider类产生足以为强壮的密码系统所需的高级熵提供种子的随机数。

•简单易懂的密钥管理方法，使Windows Azure存储中自定义的加密密钥能够简单地被管理。

有关如何利用Windows Azure提供的加密功能，请参考本文件结尾处的参考资料。

数据删除

在适当情况下，私密性应当超出数据的生命周期。Windows Azure的存储子系统使用户数据在一次删除操作被调用后无法再被得到。所有的存储操作，包括删除操作被设计成即时一致的。一个成功执行的删除操作将删除所有相关数据项的引用使得它无法再通过存储API访问。所有被删除的数据项在之后被垃圾回收。正如一般的计算机物理设备一样，物理二进制数据当相应的存储数据块为了存储其他数据而被重用的时候会被覆盖掉。4.4.3节描述了物理媒介的清除。

完整性

希望把自己的数据计算和存储工作放到Windows Azure上的用户显然希望数据被保护起来不被未经授权地改变。微软的云操作系统以多种方式来提供这一保证。

对客户数据的完整性保护的首要机制是通过Fabric VM设计本身提供的。每个VM被连接到三个本地虚拟硬盘驱动(VHDs)：

•D：驱动器包含了多个版本的Guest OS中的一个，保证了最新的相关补丁，并能由用户自己选择。

•E：驱动器包含了一个被FC创建的映像，该映像是基于用户提供的程序包的。

•C：驱动器包含了配置信息，paging文件和其他存储。

D：和E：虚拟驱动器是只读的，因为它们的ACLs被设置为禁止来自用户进程的写操作。因为操作系统可能需要更新这些只读卷，它们用支持增量文件的VHD来实现。最初在一个应用程序内所有角色实例的VHDs完全相同地启动。D:驱动器的增量驱动器当Windows Azure要给含有操作系统的VHD打补丁时被移除掉。E:驱动器的增量驱动器当一个新应用程序映像被上传的时候被移除掉。这个设计严格保证了在下方的操作系统的用户应用程序的完整性。

另一个主要的完整性控制器当然是存储在读/写C:驱动中的配置文件。用户提供了一个单个的配置文件来指定在应用程序中所有角色的连接需求。FC为每个角色接管了该配置文件的子集，对每个角色都把它放在C:驱动器中。如果用户在角色实例正在运行时更新了配置文件，FC-通过FA-联系在虚拟机的Guest OS中运行的GA并通知它更新在C:驱动器中的配置文件。之后它通知用户应用程序来重读配置文件。C:驱动器的内容在此时未被移除，也就是说C:驱动器对于用户的应用程序来说是稳定的存储器。只有被授权的用户，通过Windows Azure Portal或者SMAPI来访问他们托管的服务才能够更改配置文件。因此，通过Windows Azure的固有设计，用户配置的完整性在应用程序的生命周期内得以保障。

至于Windows Azure存储，完整性是通过使用简单的访问控制模型（如前所述）来实现的。每个存储账户有两个存储账户密钥来控制所有对在存储账户中数据的访问，因此对存储密钥的访问提供了完全的对相应数据的控制。

最后，Fabric自身的完整性在从引导程序到操作中都被精心管理。正如之前说过的，在VM上运行的并托管Fabric内部节点的Root OS是一个非常富有经验的操作系统。在一些节点启动后，它启动FA并等待连接以及来自FC的命令。FC使用双向SSL验证连接到新启动的节点。FC向FAs的通信是通过单向推送的，这样攻击在命令链中的高层组件就很困难，因为底层组件不可能直接发送命令给高层组件。与上面提到的许多机制组合在一起，这些特征帮助用户让Fabric处在不受损的状态。

可用性

云计算平台的主要优势之一是基于通过虚拟化技术来实现的大规模冗余的强健的可用性。Windows Azure提供了大量的冗余级别来提东最大化的用户数据可用性。

数据在Windows Azure中被复制备份到Fabric中的三个不同的节点来最小化硬件故障带来的影响。

用户可以通过创建第二个存储账户来利用Windows Azure基础设施的地理分布特性达到热失效备援功能。这种情况下，用户可以创建自定义角色从而在微软设施内复制备份和同步数据。用户也可以写自定义角色来为离线私有备份而从存储中拿出数据。

在每个虚拟机上的GAs监视虚拟机的状态。如果GA响应失败，FC会重启虚拟机。将来，用户可以选择适应更为自定义化的持续/恢复策略的更为老道的检测流程。当硬件遇到问题时，FC会将角色实例移动到一个新的硬件节点并为这些服务角色实例重启网络配置来恢复服务的功能性。

如前所述，每个虚拟机有一个D：驱动器，包含了可供用户选择的Guest OS版本。用户可以手动从一个Guest OS移动到另一个，也可以选择让微软在有新的版本发布后帮助移动他们的应用程序。这个系统使得用户可以用最少的交互最大化定期维护的工作。

FCs为用户服务使用类似的高可用性原理和自动失效备援，从而让FC的管理功能始终可得。在Windows Azure平台或者用户服务软件更新时，FCs利用一个称为更新域的逻辑部分在给定时间中改变一个服务角色的实例中的一部分而让剩余的实例继续对请求进行服务。FCs也能够通过故障域知道潜在的硬件和网络点的故障。对任何拥有大于一个角色实例的服务来说，Windows Azure保证这些实例在多个更新和故障域中被部署（除非由用户特别指定）来保证在更新和独立网络硬件故障时服务的可用性。

可靠性

因为云计算平台实际上是外包计算环境，它们必须能够经常向用户和其指定的代理商证明其运行的安全性。 Windows Azure的实现了多层次的监测，记录和报告来让用户了解这一点。最主要的，监视代理（MA）从包括FC和Root OS在内的许多地方获取监视和诊断日志信息并写到日志文件中。它最终将这些信息的子集推送到一个预先配置好的Windows Azure存储账户中。此外，监视数据分析服务（MDS)是一个独立的服务，能够读取多种监视和诊断日志数据并总结信息，将其写到集成化日志中。

3.开发生命周期安全

微软采用广泛公认的技术和工具在Windows Azure的开发过程,自身服务的设计和实现方面提供安全保证。

Windows Azure完全集成了微软安全开发生命周期(SDL)的方针,这个方针在软件安全保证程序方面是世界公认的模型(关于更多的信息可以再进一步阅读参考资料中找到)。

特别地,微软会仔细审查哪些低信任度组件被高信任度组件分析的地方，例如：

• 当Windows Azure管理程序和Root OS进程处理来自用户控制的虚拟机的硬盘读写和网络读写请求时。

• 当Windows Azure  portal和SMAPI处理来自被用户控制的网络来源的请求时。

• 当FC分析通过SMAPI传输过来的额用户配置数据时。

除了仔细设计和实现外，这些组件使用托管程序（如C#)来开发以减少著名的内存处理漏洞的可能性，并在Fabric在进入生产模式前进行大规模的接口测试。微软在升级或者修改处理外部请求的代码前都会继续使用这些方式。

微软的SDL方针也广泛地被推荐给Windows Azure的用户，因为托管在Windows Azure上应用程序的安全很大程度上依赖于用户的开发过程。 作为本文的指南手册，开发Windows Azure应用程序的安全最佳实践，也能够在microsoft.com上找到（参考进一步阅读参考资料）。

即便微软和用户都按照SDL来做，在开发和部署到Windows Azure中间过程中依然会有极小的可能性遭受攻击。正如之前所述，用户是通过SMAPI来提供自己的应用程序的，SMAPI使用了证书身份验证和被HTTPS保护的信道以及其他控制器来传输代码。

服务的运营方式

操作Windows Azure的人员和流程大概是这个平台最重要的安全特性了。这一节描述了微软数据中心基础设施的特性。这些特性帮助提高和维护安全性，持续性和私密性。

微软操作人员

Windows Azure的开发人员和管理人员，按照我们的设计，被给予足够的权限来操作和提升服务以完成他们各自的职责。正如在本文中所述，微软实现了预防，检测和反应控制器，包括如下机制来帮助防止未经授权的开发者和/或管理活动：

• 对敏感数据的严格访问控制　

• 控制器组合以极大提升对恶意行为的非依赖性检测

• 多级监视，记录和报告

除此之外，微软还对相关操作人员进行背景认证，并根据背景认证级别对生产环境中的应用程序，系统和网络基础设施实行有限访问。

微软的操作人员只有在顾客要求下才能进入顾客的账户或者查看相关信息。这一切必须遵守相关程序并且只能在顾客需要的情况下完成。

安全响应

关于微软安全的漏洞可以通过向微软安全响应中心（http://www.microsoft.com/security/msrc/default.aspx)报告，或者通过邮件（secure@microsoft.com）。微软始终坚持对通过正规渠道反映的漏洞进行评估和回复。

网络管理

连接Windows Azure 用户的网络硬件是这一平台的关键部分。以下这一部分将介绍一些服务在这一层上提供的安全措施。

正如前面所提到的，Windows Azure 的内部网络被强大的过滤系统从其他网络系统中隔离开。在通常情况下能够为内部网络的高速度和低风险提供坚实的基础。

诸如交换器，路由器，负载均衡器等网络配置和管理工具只能由微软运营部进行操作，而且通常只有在重大变化的情况下才能进行操作（比如数据中心自己重置了）。这些由Windows Azuret提供的虚拟技术使得这些变化对于顾客来说几乎是看不见的。

此外，任何不能提供充分通信安全特性的硬件(比如SSL)都由一个独立的LAN管理，该LAN与其他暴露给互联网或者客户访问的节点是隔离的。

FC远程管理

Fabric控制器拥有一个可以接收来自SMAPI和Windows Azure 管理者的命令的应用程序接口。策略级别的决定是由SMAPI在应用程序级别上实施的，只会基于用户已经被验证的身份来生成关于用户自身资源的请求。作为低级别的，核心的供给和管理设施，FCs提供了细颗粒度的访问控制决策来适应他们的角色。

物理安全

一个系统不可能比它自身运行的物理平台更安全。Windows Azure在世界各地的微软设施中运行，并与其他微软在线服务分享空间和功用。每个设施被设计成24*7运行并且提供了多种方法来帮助免受停电，物理干扰，网络故障带来的影响。这些数据中心符合物理安全和可靠性的行业标准，并且他们是由微软操作人员管理，监视和维护的。进行一步关于Windows Azure物理安全的详细信息如下所述。

设施访问

微软使用行业标准访问机制，以保护Windows Azure的物理基础设施和数据中心设施。仅限于一小部分必须定期改变自己管理访问凭证的操作人员访问。数据中心的访问，以及审批数据中心的访问的机构，是被微软操作人员按照本地数据中心安全实践来控制的。

电力冗余和故障

每个数据中心设施至少含有两个电力的来源，包括一个泳衣保证离网操作的发电装置。环境控制器是自包含的并且当设备及其包含的系统重新在线时依然正常工作。

物理安全控制器被设计成在停电或其他环境事故中不会被关闭的。至于火灾或者可能威胁到生命安全的情形，这些设施被设计成允许被搬出以免遭威胁。

媒介清除

当系统生命结束时，微软操作人员会按照严格的数据处理步骤和硬件清除流程来处理。

5. 合规

随着全球标准包括ISO 27001、Safe Harbor和其他标准的扩散，使得商业和管理规范的重要性增长的很快。在很多的情况下，不遵从这些标准会对组织机构有明显的影响，包括灾难性的经济惩罚和声誉的损坏。任何一个之前讨论过的威胁都会对规范产生影响，但是也存在着其他一些威胁直接关系到未能按照广泛认同的实践来操作，提供规范的表现形式给独立的审计师，支持电子搜索，并且在其他方面促进用户的合理努力去核实校准是否符合规律法规和合同的需要。微软为用户提供了他们需要的信息去决定是否可能服从他们在Windows Azure下需要服从的法律和规范，并在可能的情况下提供示范该规范的工具。Windows Azure 中的一些帮助用户的方法讨论如下。

用户可选择的地理位置

Windows Azure 的一个内在的重要挑战是平衡服从规范需求和重要的在云服务后的经济驱动因子之一：分段用户数据和跨系统、地理和行政管理的多系统处理。Windows Azure用了一个很简单的方法 处理这个挑战：用户去选择他们的数据存储地。Windows Azure 中的数据被存储在微软的世界各地的数据中心，基于用户的地理位置的属性规定来决定用Windows Azure的 哪个入口。通过用户主动的选择数据存储的地理位置这样就提供了一个方便的方法去最小化服从规范的风险。

合规控制

在不同的控制器级别，本文从多维度说明了Windows Azure符合的已被认同的合规实践。下面是一些启用合规的关键安全特性：

表2：启用合规的特性

ISO 27001 证书

可信任的第三方证书已经提供了一个不用通过提供由独立审计员组成的小组（他们可能损害整个平台的完整性）过多的访问权限来保护用户数据的机制。Windows Azure

在 Microsoft Global Foundation Services (GFS)的基础设施上运作，部分GFS由ISO27001认证。ISO27001是世界范围内公认的首要国际性信息安全管理标准之一。Windows Azure正在获得更多行业认证评估的过程中。

除了国际认证标准 ISO27001，微软公司是Safe Harbor的签署者并许诺完成所有在Safe Harbor框架下自身的义务。

尽管符合法律，规范，行业需求的责任在Windows Azure用户身上，微软依然保证帮助用户通过上面所述的特性完成合规。

6.进一步阅读 参考文献

• 以下资源提供更多的关于Windows Azure 以及相关微软服务的信息，以及在本文中引用到的关键项：
• Windows Azure Home 常规信息和进一步关于Windows Azure资源的链接：http://www.microsoft.com/windowsazure/
• Windows Azure开发中心主要知识库，用于开发指导和参考：http://msdn.microsoft.com/en-us/windowsazure/default.asp
• 开发Windows Azure应用程序的安全最佳实践： http://download.microsoft.com/download/7/3/E/73E4EE93-559F-4D0F-A6FC-7FEC5F1542D1/SecurityBestPracticesWindowsAzureApps.docx
• Windows Azure中的加密服务和数据安全：http://msdn.microsoft.com/en-us/magazine/ee291586.aspx
• 微软的安全开发生命周期--SDL 是微软在Windows Azure开发期间的安全保障： www.microsoft.com/security/sdl/
• 微软的全球基础服务安全：http://www.globalfoundationservices.com/security/
• 微软GFS‘ ISO 27001证书-http://www.bsigroup.com/en/Assessment-and-certification-services/Client-directory/CertificateClient-Directory-Search-Results/?pg=1&licencenumber=IS+533913&searchkey=companyXeqXMicrosoft
• 微软安全响应中心--微软安全漏洞，包括Windows Azure问题，可以报告给http://www.microsoft.com/security/msrc/default.aspx 或通过邮件发送给secure@microsoft.com.。

免责声明

这个文件是根据目前状况提供的。本文的信息和观点表述包括URL和其他互联网站参考可能会没有提示而产生变动，您使用时可能有风险。其中的一些例子描述只是为了描述而提供，且都是虚构的。没有现实的联系或者推断。本文不提供你任何的微软产品过渡属性的法律权限，你可以复制使用本文作为内部参考目的。

7. 术语

本文翻译自：http://www.microsoft.com/windowsazure/whitepapers/papers/default.aspx

[转]Windows Azure安全概述