Windows Azure 安全最佳实践 – 第 7 部分:提示、工具和编码最佳实践

在撰写这一系列文章的过程中,我总结出了很多最佳实践。在这篇文章中,我介绍了在保护您的 Windows Azure 应用程序时,需要考虑的更多事项。 下面是一些工具和编码提示与最佳实践: 在操作系统上运行 获取最新的安全补丁 尽量以部分信任模式运行 错误处理 如何实施重试逻辑 记录 Windows Azure 中的错误 Azure 存储的访问权限 Blob 的访问权限 存储连接字符串 门卫模式 旋转存储密钥 用于确保数据安全的加密服务 在操作系统上运行 获取最新的安全补丁 当使用 Visual Studio 创建新的应用程序时,默认行为是按如下方式在 ServiceConfiguration.cscfg 文件中设置来宾操作系统版本: osFamily=”1″osVersion=”*” 这很好,因为您将自动获得更新,这也是 PaaS 的主要优点之一。但这并非最佳做法,因为您使用的操作系统不是最新版本。为了使用最新的操作系统版本 (Windows Server 2012 R2),应按如下方式进行设置: osFamily=”4″ osVersion=”*” 遗憾的是,许多客户决定固定使用某个特定的操作系统版本,希望通过避免来宾操作系统更新来增加正常运行时间。这种做法仅适用于企业客户:他们系统地测试staging 部署中的每次更新,然后计划对在生产部署中运行的关键业务应用程序进行 VIP 交换。对于其他不会测试每个来宾操作系统更新的客户来说,不配置自动更新会将 Windows Azure 应用程序置于危险的处境。 — 来源:开发Windows Azure 应用程序的故障排除最佳实践 尽量以部分信任模式运行 Cloud Service默认情况下,部署到 Windows…


Windows Azure 安全最佳实践 – 第 6 部分:Azure 服务如何扩展应用程序安全性

多种  Windows Azure 服务可以帮助您将应用程序安全性扩展到云。    有三种服务可提供多个提供程序之间的身份标识映射、内部部署数据中心间的连接和相互发送消息的应用程序功能(无论应用程序位于何处)。 使用 Windows Azure Active Directory,您可以通过位于云中的应用程序的代理身份验证在应用程序上创建单点登录应用程序。使用访问控制服务功能,您可以将来自多个提供程序的标识映射到应用程序可以识别的claims。 通过 Service Bus,您可以使用安全消息传递和中继功能启用松散耦合的分布式应用程序。 Windows Azure Active Directory Windows Azure Active Directory 是一种云服务,可对 Windows Azure 和 Microsoft Office 365 上的应用程序提供身份认证和访问功能。Windows Azure Active Directory 是一种多租户云服务,Microsoft Office 365 依赖于其身份验证基础结构。 Windows Azure Active Directory 利用被公认具备企业级质量的 Active Directory 的功能,因此您可以轻松将应用程序迁移到云中。您可以使用访问控制服务 (ACS)(Windows Azure Active Directory 的一项功能)启用单点登录、安全增强型应用程序以及与现有 Active Directory 部署的简单互操作性。 访问控制服务 访问控制服务 (ACS)…


Windows Azure 安全最佳实践 – 第 5 部分:基于Claim 的标识,单点登录

基于Claim的身份标识是处理网站与 Web 服务的身份认证和访问一种简单而强大的方式,无论您是在本地工作还是面向云工作。 您可以通过减少自定义实施和使用基于Claim的单一简化标识模型,创建更安全的应用程序。 Windows Identity Foundation (WIF) 是一组 .NET Framework 类。它是用于在您的应用程序中实施基于Claim的标识的框架。 从架构上说,使用基于Claim的标识可以将应用程序从身份验证业务中脱离出来。单点登录变得更容易实现,您的应用程序不再负责以下操作: 对用户进行身份验证。 存储用户帐户和密码。 调用企业目录以查找用户标识详细信息。 与其他平台或公司的身份标识系统集成。 相反,您的应用程序使用颁发机构发到您的应用程序的包含Claim的安全Token。SecurityToken Service(STS) 是根据可互操作协议构建、签署和颁发安全token的服务。您的应用程序是relying party。 Claim。Claim是您的应用程序需要了解的用户信息。例如,用户的姓名或电子邮件地址,或者是否在销售组织中。您的应用程序将接受以下来源的Claim: 安全token。在 Web 服务中,这些Claim包含在 SOAP envelop的安全头中。在基于浏览器的 Web 应用程序中,Claim从用户的浏览器通过 HTTP POST 到达,而且可能稍后会缓存在 cookie 中(如果需要会话)。 颁发机构。颁发机构是知道如何颁发安全token的 Web 应用程序或 Web 服务。在基于Claim的身份标识的方案中,颁发机构负责发布相应的Claim(如姓名和电子邮件或此人是否在销售组织中)。 Security Token Service(STS)。 STS 同时受客户端和 Web 服务信赖,可提供可互操作的安全token。 Relying Party。即您的应用程序或 Web 服务。它通常被描述为Claim aware应用程序或基于Claim的应用程序。 SAML Token。大多数现有的 STS 都会颁发…


Windows Azure 安全最佳实践 – 第 4 部分:需要采取的其他措施

  那么,哪些安全威胁应由 WindowsAzure 环境缓解?哪些安全威胁必须由开发人员缓解? 开发 Windows Azure 应用程序的最佳安全做法一文说明了对于在 Windows Azure 中运行的应用程序而言,什么样的威胁应被视为主要威胁。它还专门说明了 Azure 能够缓解的威胁以及您需要调用 API 的内容和您需要自己处理的内容。(它未涉及合规性问题。) 您应该处理的内容 我将选择一些威胁和您应该执行的操作,并提供一些参考,以便您可以了解有关如何在代码中进行实现的更多信息。该列表在 Windows Azure 安全概述中提供。但是具体结果将取决于您。 这个列表并不全面。正如您从本系列文章的以前部分中了解的那样,您根据您自己的应用程序需求来调整您的安全做法。 篡改威胁 篡改/泄漏凭据或其他敏感应用程序数据。 针对 SSL 连接,使用 WindowsIdentity Foundation 和 HTTPS 相互身份验证。 请参见如何管理服务证书,了解有关将证书添加到存储、将证书与服务关联以及更新证书的信息。在这些情况下,我们假设 IT 管理人员和服务开发者是两个不同的人,但是他们也可能是同一个人。 请参见 Windows Identity Foundation,帮助开发者简化用户访问,方法是通过claim将用户访问从应用程序外部化,以及使用预先构建好的安全逻辑和集成 .NET 工具减少开发工作量。 否认威胁 审计日志收集、存储和分析。根据需要使用监控和诊断 API,将日志通过 HTTPS 传输到私有 Blob 存储/表存储。请参见: 在 Windows Azure 中控制日志记录和跟踪(来源于 MSDN 杂志)。 Azure Monitor(可获得用于实时监控…


Windows Azure 安全最佳实践 – 第 3 部分:确定安全框架

构建云应用程序时,安全始终是计划和执行 Windows Azure 的首要核心因素。 第 1 部分介绍了威胁形势并且建议您的应用程序使用深度防御。第 2 部分提出安全是一项共同责任,Windows Azure 为您的应用程序提供超出内部部署应用程序需求的强大安全功能。但另一方面,它也暴露了您应该考虑的其他漏洞。 此部分中将探索如何检查应用程序的体系结构。模式与实践团队提出通过安全框架来检查应用程序,以便您在开始编码之前即确定威胁和您的响应。 此部分还介绍了如何将Microsoft 安全开发生命周期 (SDL) 通过规定的方式应用于您的组织以解决应用程序生命周期中每个阶段的安全性问题。 安全框架 透过安全框架,您可以轻松了解应用程序的安全状况。 此概念在 Windows Azure 安全记要中有详细说明。该文档由模式与实践团队的首席项目经理 J.D. Meier 和 Paul Enfield 撰写。该文档还收集了客户、现场工程师、产品团队和业内专家的意见,提供了基于常见原则、模式和实践确保 Windows Azure 上的常见应用程序方案的安全性的解决方案。 那篇文档概述了您可能遇到的威胁、攻击、漏洞和应对措施。它还详述了一组方案,其中包含许多常见的应用程序类型。那篇文档提供了一个安全框架,指导设计和构建 Windows Azure 应用程序时的安全性考虑。 那篇文档开头介绍了一个常见的 ASP.NET 应用程序,并确定了一组操作且为它们分类: 审计和日志记录 身份验证 授权 通信 配置管理 加密 异常管理 敏感数据 会话管理 验证 此方法可帮助您解决安全框架所识别的关键安全热点,以确保解决方案的安全。 对于内部部署应用程序,您需要分别处理各个主要问题。下图显示了一种十分典型的内部部署应用程序体系结构,然后标出了相应的热点。 借助托管基础结构,我们可以少费神一些问题,因为这些问题由托管基础结构进行处理。例如,Windows Azure 应用程序没有权限创建用户帐户或者提升权限。 文档中建议您 使用基本图表示您的体系结构,然后将框架覆盖在基本图之上。应用框架之后,即可评估每一项的适用性并快速排除不需要关注的类别。…


Windows Azure 安全最佳实践 – 第 2 部分:Azure 提供哪些现成可用的安全机制

在WindowsAzure 安全最佳实践 – 第 1 部分:深度解析挑战防御对策中,我介绍了威胁形势以及在您的应用程序中采用深度防御的计划。     在本部分中,我将说明 Windows Azure 的安全是一项共同责任,Windows Azure 为您的应用程序提供超出内部部署应用程序需求的强大安全功能。但另一方面,它也暴露了您应该考虑的其他漏洞。最后,在应用程序开发过程中,您应该积极保护应用程序的安全。 本节将概括介绍 Windows Azure 提供的功能。有关详细信息,请参阅全球基础服务在线安全。全球基础服务团队提供值得信赖的可用在线服务,可为您和 Microsoft Windows Azure 带来竞争优势。 此系列文章旨在为您提供更多背景信息,让您能够编写出适用于公共云的理想应用程序。 Windows Azure 如何帮助保护主机? 您可能会说“别着急 Bruce。Windows Azure 如何帮助保护主机?” WindowsAzure 安全概述全面概括了 Windows Azure 提供的安全功能。该文章由Charlie Kaufman 和 Ramanathan Venkatapathy 撰写。它从客户和 Microsoft 运营的角度分析了可用的安全功能,介绍帮助提高Windows Azure 安全性的人员和流程,并简单讨论了合规性。我将总结这些功能,并建议您阅读并理解该概述以进一步深入了解。 Windows Azure 旨在将通常构成应用程序(服务器、操作系统、网络和数据库软件等)基础的大部分基础结构抽象化,让您可以专注于构建应用程序。 从表面看,您会看到基于云的计算和存储,以便您构建和管理应用程序及其相关配置。迁移到 Windows Azure 的每种方式可能都要求您具有您所控制的一定程度的授权。 我将在后面的文章中介绍您应针对身份验证机制执行的一些最佳实践。 Windows Azure 必须确保客户数据的机密性、完整性和可用性,就像任何其他应用程序托管平台一样。它还必须提供透明问责,让您和他们的代理能够跟踪您自己以及…


Windows Azure 安全最佳实践 – 第 1 部分:深度解析挑战防御对策

我每次与开发人员讨论将应用程序迁移到云时都围绕着两个主要问题。 首先是业务。将应用程序迁移到云可以带来怎样的规模经济? 其次是安全问题。“云的安全性如何,尤其是 Windows Azure?Windows Azure 可以提供哪些优势?为保证应用程序的安全,我需要采取哪些措施?” 此外还有个心照不宣的问题:“我如何让用户对云的使用体验就像使用内部部署应用程序一样顺畅?” 作为 ISV,我们希望向授权用户、客户和系统提供随时随地使用任何技术访问所需数据的功能,同时满足机密性、可用性和完整性方面的基本安全要求。 而且同样重要的是,我们希望让坏人远离这些数据。 本文是多篇有关软件设计挑战的文章中的第一篇,旨在说明如何才能让拥有访问权限的人顺利访问软件,同时阻止未经授权者访问。 此系列文章旨在为您提供更多背景信息,让您能够编写出适用于公共云的理想应用程序。 威胁 首先我将简要概括一下这些挑战。您的应用程序面临的威胁多种多样,与您能想到的内部部署应用程序面临的威胁相类似。但对于内部部署应用程序,有些关键威胁会得到缓解,因为它们在防火墙之后运行。 迁移到 Windows Azure 云时,有些威胁会提高,有些则会降低。同您部署自己的应用程序时相比, 缓解这些威胁变成了一个更深层次的合作。在您自己的服务器上部署应用程序时,您控制着对服务器的物理访问、操作系统、补丁以及用户的访问方式,等等。但随之而来的是加重了维护基础结构、确保执行备份、配置负载平衡器的责任。 但与 Microsoft 合作时,全球基础服务团队可以应对各种客户需求,并承担与您的应用程序安全相关的部分责任。 这一点类似于由您负责基础结构的基础结构即服务 (IaaS) 和与 Microsoft 共享基础结构的平台即服务 (PaaS) 之间的区别。 在这两种环境中,您需要考虑七个攻击矢量。 对应用程序进行管理的客户管理员。如何对应用程序进行部署、更新和数据访问?哪些人拥有访问权限以及如何对访问进行身份验证? 托管服务的管理中心。如何、何时、在哪里、用什么工具监视托管商管理员以及谁拥有托管服务的访问权限? 如何对服务器进行物理访问?它是否被放在办公桌下?是否具有武装防护措施?谁可以接触服务器以及谁拥有这些设备的物理访问权限? 用户可以访问哪些数据以及如何将数据提供给这些用户?用户有权查看哪些数据? 客户如何才能从应用程序内部攻击 Windows Azure?客户如何对系统进行越狱并损害系统? 客户使用 Azure 来攻击其他网站时,会发生什么? 即使将应用程序迁移到云,传统威胁仍然存在。例如,您仍然需要防范跨站点脚本攻击 (XSS) 和代码注入攻击。而提供商需要防范 DNS 攻击和网络拥堵问题。 有些威胁进一步扩大,比如您需要考虑的数据隐私。您需要知道数据的存储位置和数据隔离,尤其是在多租户环境中。您还需要处理访问权限。 云服务提供商的性质带来了新的威胁。例如: 新权限升级攻击(VM 到主机或 VM 到 VM) VM 边界的越狱…


Windows Azure 数据安全(清理和泄漏)

免责声明:本文档中所述过程为 2012 年 1 月时起的情况,如有变更,恕不另行通知。 希望将应用程序部署到 Windows Azure 的企业客户(实际上是所有客户)最为关心的就是其数据的安全性。释放磁盘空间并将其重新分配给其他客户时,要确保新的所有者无法读取释放空间后磁盘上原来的数据,在数据保护中这一点有时会被忽视。一个极端的例子是,废弃处理从数据中心移除的驱动器或在其他任务中再次利用。释放之前先使用零或其他模式覆盖释放的空间,是确保这一点最简单的方式。这种覆盖可能会大大影响性能,因此 Azure 与大多数系统一样,会使用更为复杂但更有效的机制。 在本文中,我们将发现 Windows Azure 和 SQL Azure 软件为达到以下目的而实施的做法:防止在删除 Windows Azure 虚拟机实例、Windows Azure 虚拟机驱动器、Windows Azure 驱动器、Windows Azure 存储、SQL Azure 数据或 SQL Azure 实例本身时造成数据泄露或将一个客户的数据暴露给其他客户。这些机制的细节有所不同,但概念均类似,即:不允许任何用户从之前未写入数据的磁盘位置读取数据。 本文中的详细信息由 Windows Azure 首席软件工程师、杰出的安全架构师 Charlie Kaufman 提供。您可以在此处和此处找到 Charlie 的一些著作。Charlie,谢谢你! 关于数据保护的概念 在实践中,磁盘是稀疏分配的。这意味着在创建虚拟磁盘时,不会分配全部的磁盘空间量。而是创建一个表,将虚拟磁盘上的地址映射到物理磁盘上的区域,并且该表最初为空白。客户第一次在虚拟磁盘上写入数据时,将会分配物理磁盘空间并在表中设置标志。我们可以通过下面的一系列图表来了解其概念: 图 1:分配给用户的数据块   在上面的图 1 中,基于两个用户各自的写入请求为他们各分配两个数据块。   图 2:用户释放数据块 在上面的图 2 中,一个用户“删除”数据以释放数据块。数据块标记为可用,其他方面不受影响。…


#AzureChat – 自动伸缩和虚拟机

我们很高兴地推出再一次的 #AzureChat,这是 @WindowsAzure 团队为您精心打造的一个在 Twitter 上进行的聊天活动! #AzureChat 专注于云计算的各个方面以及云开发的最佳实践。想要了解有关特定云服务的更多信息?希望获得相关提示和技巧、开发人员趋势以及最佳实践?#AzureChat 就是一个很好的地方,让您能够参与社区讨论,与其他开发人员分享您的看法,同时还能得到 Microsoft 专家的指导。 太平洋标准时间 12 月 5 日(星期四)上午 9:00,我们将邀请 Corey Sanders 和 Stephen Siciliano 举行一次在线问答讨论会,主要议题为自动伸缩和虚拟机。Corey 和 Stephen 分别从事于Virtual Machine 团队和Autoscale 团队。当您将这两者联系在一起, 您会得到一个可伸缩的和具有成本效益的系统, 可以利用它来部署您的工作负载。Stephen 和 Corey 将回答您任何在Windows Azure中有关伸缩和虚拟机的问题。 他们还将介绍一些最新的公告,包括用于自动伸缩的新SDK。我们建议您提前将问题提交到 @WindowsAzure。 #AzureChat 的工作形式: 您可以加入 Tweet“聊天室”,浏览并参与到对话中 您也可以使用 Hootsuite、Tweetdeck 或任何其他 Twitter 客户端。您只需使用话题标签 #AzureChat 设置一栏即可。 请在太平洋标准时间 12 月 5 日(星期四)上午 9:00 参加这次聊天活动。(如果您来晚了,可以在聊天过程中随时加入进来,此次活动时长为…

1

删除 Windows Azure 网站上的标准服务器头

编辑人员注释: 本文章由 Windows Azure 网站团队的项目经理 Erez Benari 撰写。 请求和响应中包含的 HTTP 头是Web 服务器和浏览器之间的 HTTP 通信过程的一部分。例如,以下是一个典型网站上某个 Web 请求的典型响应中记录的头: HTTP 头是客户端和服务器之间的通信过程中的一个关键部分。它们允许服务器发送与请求相关的信息,而不是内容本身的一部分。例如,Content-Length 头可告知浏览器要接收的内容的长度,而 Cache-Control 头告知浏览器该内容能否缓存响应。 我们提供了两个特别有趣的头,它们可告知客户端提供请求及其属性的 Web 服务器的类型。尽管所有 Web 服务器都会发出这种类型的头,但是许多用户希望服务器不发送此信息,因为他们希望在一定程度上保持匿名。客户要求我们在 Azure 网站上禁用这些头,因此我们在 Windows Azure 网站的最新发行版中实现了这一点。 如何禁用这些头? 通过 IIS 中的请求筛选模块可轻松删除这些头。要删除某个头,您需要站点上存储的 web.config 文件,其中包含以下内容: 上述操作将删除 Server 头。X-Powered-By 和 X-AspNet-Version 头是许多用户希望删除的另外两个头。要删除这两个头,web.config 需要包含以下部分。对于 X-Powered-By,以下内容位于 <system.webserver> 集内: 而对于 X-AspNet-Version,以下内容应位于 <system.web> 内: 因此,如果要删除所有内容,Web.config 将如下所示: 当然,如果站点中已经有一个现有的 web.config…