Windows Azure 安全最佳实践 - 第 7 部分：提示、工具和编码最佳实践
在撰写这一系列文章的过程当中，我总结出了不少最佳实践。在这篇文章中，我介绍了在保护您的WindowsAzure应用程序时须要考虑的更多事项。php
下面是一些工具和编码提示与最佳实践：html
· 在操做系统上运行前端
o 获取最新的安全补丁算法
o 尽可能以部分信任模式运行windows
· 错误处理后端
o 如何实施重试逻辑设计模式
o 记录 Windows Azure中的错误数组
· Azure存储的访问权限缓存
o Blob的访问权限安全
o 存储链接字符串
o 门卫模式
o 旋转存储密钥
o 用于确保数据安全的加密服务
在操做系统上运行
获取最新的安全补丁
当使用 Visual Studio建立新的应用程序时，默认行为是按以下方式在 ServiceConfiguration.cscfg文件中设置来宾操做系统版本：
osFamily="1"osVersion="*"
这很好，由于您将自动得到更新，这也是 PaaS的主要优势之一。但这并不是最佳作法，由于您使用的操做系统不是最新版本。为了使用最新的操做系统版本 (Windows Server 2012 R2)，应按以下方式进行设置：
osFamily="4" osVersion="*"
遗憾的是，许多客户决定固定使用某个特定的操做系统版本，但愿经过避免来宾操做系统更新来增长正常运行时间。这种作法仅适用于企业客户：他们系统地测试staging部署中的每次更新，而后计划对在生产部署中运行的关键业务应用程序进行 VIP交换。对于其余不会测试每一个来宾操做系统更新的客户来讲，不配置自动更新会将 Windows Azure 应用程序置于危险的处境。
-- 来源：开发Windows Azure 应用程序的故障排除最佳实践
尽可能以部分信任模式运行
Cloud Service默认状况下，部署到 Windows Azure的角色将以彻底信任模式运行。若是要调用非 .NET代码或使用须要彻底信任的 .NET库，或任何须要管理员权限的代码或库，则须要彻底信任。将您的代码限制为以部分信任模式运行意味着，任何有权访问您代码的人可执行的操做更加有限。
使用部分信任能够在您的 Web应用程序受到威胁时，限制攻击者的破坏范围内。例如，默认状况下，恶意的攻击者没法修改磁盘上的任何 ASP.NET页面，也没法更改任何系统二进制文件。
因为用户账户不是虚拟机上的管理员，使用部分信任会增长更多的限制，多于 Windows 自动施加的限制。此信任级别经过 .NET的代码访问安全性(CAS)支持强制执行。
部分信任与 .NET中的“中等信任”级别相似。仅授予对某些资源和操做的访问权限。一般，您的代码仅能经过 TCP链接到外部 IP 地址，而且仅能访问其“本地存储”中的文件和文件夹（而非系统上的任何位置）。您的代码使用的任何库必须以部分信任模式运行，或特别标记为“容许部分信任的调用方”属性。
您能够在服务定义文件中明确配置角色的信任级别。服务定义架构提供了WebRole元素和WorkerRole元素的enableNativeCodeExecution属性。要以部分信任模式运行您的角色，必须在WebRole或WorkerRole元素上添加enableNativeCodeExecution属性，并将其设置为false。
可是，部分信任限制了应用程序的功能。因为一些微不足道的缘由，一些有用的库（如用于访问注册表或访问众所周知的文件位置的库）没法在此类环境中运行。即便 Microsoft本身的一些框架也不会在此环境中运行，由于它们没有设置“partially trustedcaller”属性。
有关以部分信任模式运行的限制，请参阅Windows Azure部分信任策略参考。
处理错误
Windows Azure 可以自我修复，您的应用程序能够吗？
重试逻辑
瞬态故障错误是因为一些临时状况（如网络链接或服务不可用等问题）致使的。一般，若是您很快重试致使瞬态错误的操做，将会发现错误已消失。
不一样的服务可能会有不一样的瞬态故障，而且不一样的应用程序所需的故障处理策略也不一样。
虽然它看上去彷佛与安全无关，但将重试逻辑嵌入应用程序是一个最佳作法。
Azure 存储
使用随附 SDK的 Windows Azure Storage Client Library已经具有所需的重试行为。您能够经过设置RetryPolicy属性在任何存储客户端上设置重试行为。
SQL、Service Bus、缓存和 Azure存储
可是 SQL Azure不会提供现成的默认重试机制，由于它使用的是 SQL Server客户端库。Service Bus也不会提供重试机制。
所以，Microsoft模式与实践团队和Windows Azure客户咨询团队开发了瞬态故障处理应用程序块。该块提供处理特定 SQL Azure、存储、Service Bus和缓存状况的多种方式。
瞬态故障处理应用程序块中包含有关当您使用应用程序中的如下 Windows Azure服务时可能出现的瞬态故障的信息：
·SQL Azure
·Windows Azure ServiceBus
·Windows Azure存储
·Windows Azure缓存服务
目前，该块包括加强的配置支持、对包装异步调用的加强支持，实现了块的重试策略与 Windows Azure存储重试机制的集成，适用于企业库依赖注入容器。
捕捉错误
很遗憾，任何系统都不可避免地会出现故障，Windows Azure也确定会出现故障。即便使用重试逻辑，您偶尔也会遇到故障。您能够将自定义的错误处理添加到 ASP.NET Web应用程序。自定义错误处理能够简化调试并提升客户满意度。
Eli Robillard 是 Microsoft MVP 计划的一员，他的文章ASP.NET的丰富自定义处理介绍了如何建立错误处理机制，该机制对用户很是友好而且仍提供了开发人员须要的详细技术信息。
若是显示错误页面，它应该在不牺牲美感的前提下为开发人员和最终用户提供服务。理想的错误页面会保持站点的外观和感受，具有为内部开发人员（经过 IP地址识别）提供详细错误信息的能力，同时确保不向最终用户提供任何详细信息。相反，它让用户轻松返回本身寻找的站点，而不会形成混乱。网站管理员应该可以经过电子邮件或在服务器日志中检查遇到的错误，（可选）而且可以接收来自遇到故障的用户的反馈。
记录 Windows Azure中的错误
ELMAH（错误记录模块和处理程序）自己很是有用，只需进行简单修改便可提供很是有效的方式，用来处理整个 ASP.NET Web应用程序的错误记录。个人同事Wade Wegner在他的文章在 WindowsAzure 中将 ELMAH与表存储结合使用中介绍了他建议的步骤。
当 ELMAH开始运行 Web 应用程序并正确配置后，您便可得到如下功能，而无需更改任一代码行：
· 记录几乎全部未处理的异常。
· 可远程查看已记录异常完整记录的网页。
· 有一个网页能够用来远程查看任何记录的异常的完整详细信息，包括色彩斑斓的 stack trace。
· 在不少状况下，您能够检查 ASP.NET为给定异常生成的原始黄屏死机，即便在关闭customErrors模式的状况下也是如此。
· 在出现每一个错误时会发出电子邮件通知。
· 记录中最后 15个错误的 RSS 订阅。
要了解有关 ELMAH的更多信息，请参阅 MSDN文章使用 HTTP模块和处理程序建立可插入的ASP.NET组件，由Scott Mitchell和Atif Aziz共同撰写。另请参阅ELMAH项目页面。
远程访问错误
有许多可用于远程管理 Windows Azure存储账户的方案。例如，在开发和测试期间，您可能要可以检查表、队列和 Blob的内容，以验证您的应用程序是否如预期同样运行。您可能还须要将测试数据直接插入到存储中。
在生产环境中，您可能须要在故障排除期间检查应用程序存储的内容，或查看您保留的诊断数据。您可能还但愿下载诊断数据进行离线分析，并可以删除存储的日志文件以下降存储成本。
经过Web搜索能够发现愈来愈多可充当这些角色的第三方工具。请参阅Windows Azure存储管理工具获取一些有用的工具。
存储的访问权限
密钥
一个紧急注意事项是，任何应用程序都不该将 Windows Azure提供的任何密钥用做加密数据的密钥。例如 Windows Azure为存储服务提供的密钥。这些密钥已配置为容许出于安全性目的，或者当因为任何缘由受到威胁时轻松旋转。换言之，它们未来可能不存在，而且可能分发范围太普遍。
旋转密钥
当您建立存储账户时，您的账户已分配两个 256位账户密钥。其中一个密钥必须做为 HTTP(S)请求的一部分在头中指定。提供两个密钥，是为了进行密钥旋转，以保持数据的良好安全性。一般，您的应用程序会使用其中一个密钥来访问数据。而后在一段时间后（取决于您），您将应用程序切换为使用另一个密钥。若是您知道您的所有应用程序都已经使用另外一个密钥，您能够生成一个新秘钥,这将自动做废第一个密钥。以这种方式使用两个密钥，您的应用程序就能够访问数据，而不会产生任何停机时间。
请参阅如何查看、复制和从新生成Windows Azure存储账户的访问密钥，了解如何查看和复制 Windows Azure存储账户的访问密钥并执行主要和辅助访问密钥的滚动从新生成。
限制对 Blob的访问
默认状况下，仅存储账户的全部者可访问存储容器和其中的任何 Blob。若是要给匿名用户提供容器及其 Blob的读取权限，您能够设置容器权限以容许公共访问。匿名用户可在可供公众访问的容器中读取 Blob，而无需对请求进行身份验证。请参阅限制对容器和Blob的访问。
共享访问签名是授予容器和 Blob的访问权限的 URL。共享访问签名授予 URL已授予权限指定的 Blob服务资源的访问权限。当在某些具备 HTTP请求的状况下使用共享访问签名时须要当心，由于 HTTP请求会在互联网上以明文形式公开完整的 URL。
经过指定共享访问签名，您能够向用户授予权限，容许其在指定时间段内访问特定 Blob或某个指定容器中任何 Blob的 URL。您还能够指定可在经过共享访问签名访问的 Blob上执行的操做。支持的操做包括：
· 读取和写入 Blob内容、块列表、属性和元数据
· 删除 Blob
· Leasing Blob
· 建立 Blob快照
· 列出容器中的 Blob
块 Blob和页面 Blob 都支持共享访问签名。
若是共享访问签名的某些权限不许备向公众开放，那么它的访问策略应使用所需的最小权限进行构建。此外，共享访问签名应经过 HTTPS通讯安全地分配给指定用户，应与容器级别的访问策略相关联以进行吊销，而且应为签名指定尽量短的有效期。
请参阅建立共享访问签名和使用共享访问签名(REST API)。
存储链接字符串
若是您有某个托管服务使用 Windows Azure Storage Client Library访问 Windows Azure存储账户，建议您将链接字符串存储在服务配置文件中。经过将链接字符串存储在服务配置文件中，已部署服务能够响应配置更改，而无需从新部署应用程序。
在如下状况下，这样作会颇有利：
· 测试 –在将应用程序部署到staging环境时使用测试账户，而且当您将应用程序移到生产环境时必须将其切换为 Live账户。
· 安全性 –若是因为正在使用的密钥受到威胁致使您必须旋转存储账户的密钥。
有关配置链接字符串的更多信息，请参阅配置链接字符串。
有关使用链接字符串的更多信息，请参阅读取存储客户端库的配置设置和处理已更改的设置。
门卫设计模式
门卫是一种设计模式，其中存储的访问权限需进行协商，以便经过限制特权角色在专用内部渠道上的通讯交互并仅与其余 Web role/workerrole进行交互，以尽可能减少特权角色的攻击面。
该模式在 Microsoft下载中的文章开发WindowsAzure 应用程序的最佳安全作法中进行了说明。
这些角色应部署在单独的 VM上。
即便 Web role被成功攻击，也不会泄漏特权密钥材料。使用两个角色的如下示例是对该模式的最好诠释：
·门卫 –为来自 Internet的请求提供服务的 Web role。因为这些请求多是恶意的，门卫不被信任用于任何其余职责，除非验证了其收到的输入。门卫在托管代码中实施并以 Windows Azure部分信任模式运行。此角色的服务配置设置不包含用于 Windows Azure存储的任何共享密钥信息。
·KeyMaster –特权后端 worker role，仅接收来自门卫的输入，并经过安全渠道进行接收（即，可经过 HTTPS确保安全性的内部端点或队列存储）。KeyMaster经过门卫处理其订阅的存储请求，并假设请求已进行某种程度的净化。顾名思义，KeyMaster是使用服务配置中的 Windows Azure存储账户信息进行配置的，可从 Blob或表存储中检索数据。而后数据能够反馈回请求客户端。此设计不须要彻底信任或本机代码，但它可提供在须要时以较高权限级别运行 KeyMaster的灵活性。
多密钥
若是没法将部分信任门卫放置在彻底信任角色以前，则可以使用多密钥设计模式保护受信任的存储数据。例如，当 PHP Web role做为前端 Web role并将部分信任门卫放置在 PHP Web role前面时，可能会使性能下降得没法接受。
与门卫/KeyMaster模式相比，多密钥设计模式具备如下优势：
· 将存储账户的职责分离出来。若是 Web role A泄露了，仅会丢失不受信任的存储账户及关联密钥。
· 无需指定任何内部服务端点。相反，会使用多个存储账户。
· 面向外部的不受信任的 Web role无需 Windows Azure部分信任。因为 PHP不支持部分信任，PHP托管不可进行门卫配置。
请参阅 Microsoft下载中的开发 WindowsAzure 应用程序的最佳安全作法。
加密服务
您可使用加密来确保应用程序层数据的安全。加密服务提供程序 (CSP)是系统程序接口中显示的加密标准、算法和函数的实施。
Jonathan Wiggs 在 MSDN 杂志中发表了一篇文章Windows Azure 中的加密服务和数据安全，这篇文章生动地说明了如何在应用程序中提供这类服务。他解释说：“一致的建议是永远不要建立您本身的加密算法或使用专有加密算法。.NET CSP 中提供的算法已通过证实和测试并具备多年的公众支持。”
您能够选择下面的多种选项。Microsoft提供了：
Microsoft Base Cryptographic Provider。一组可导出到其余国家或地区的普遍的基本加密功能。
Microsoft Strong Cryptographic Provider。Microsoft Base Cryptographic Provider 的扩展，在 Windows 2000及更高版本中提供。
Microsoft Enhanced Cryptographic Provider。Microsoft Base Cryptographic Provider 经过更长的密钥和其余算法得出的结果。
Microsoft AES Cryptographic Provider。Microsoft Enhanced Cryptographic Provider 支持 AES加密算法。
Microsoft DSS Cryptographic Provider。经过安全哈希算法 (SHA)和数字签名标准 (DSS) 算法提供哈希、数据签名和签名验证功能。
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider。DSS Cryptographic Provider 的超集，同时支持使用安全哈希算法 (SHA)和数字签名标准 (DSS)算法进行 Diffie-Hellman密钥交换、哈希、数据签名和签名验证。
Microsoft Enhanced DSS and Diffie-Hellman CryptographicProvider。支持 Diffie-Hellman 密钥交换（40位的 DES 衍生品）、SHA哈希、DSS数据签名和 DSS 签名验证。
Microsoft DSS and Diffie-Hellman/Schannel CryptographicProvider。支持哈希、使用 DSS 进行数据签名、生成 Diffie-Hellman (D-H)密钥、交换 D-H 密钥以及导出 D-H 密钥。此 CSP 支持 SSL3和 TLS1 协议的密钥派生。
Microsoft RSA/Schannel Cryptographic Provider。支持哈希、数据签名和签名验证。算法标识符 CALG_SSL3_SHAMD5 用于 SSL 3.0和 TLS 1.0 客户端身份验证。此 CSP 支持 SSL2、PCT1、SSL3和 TLS1 协议的密钥派生。
Microsoft RSA Signature Cryptographic Provider。提供数据签名和签名验证。
密钥存储
经过加密数据提供的数据安全性仅与使用的密钥的安全性相同，而且此问题要比人们起初预想的难度要高得多。您不该该使用 Azure存储密钥，而可使用上一节中的提供程序建立您本身的密钥。
在 Windows Azure存储服务内部存储您本身的密钥库是保存一些机密信息的不错选择，由于您能够相信这些数据在多租户环境中的安全性并经过您本身的存储密钥确保其安全性。这与将存储密钥用做加密密钥有所不一样。相反，您可使用存储服务密钥随意访问密钥库,就像任何其余存储文件同样。
密钥管理
首先，要始终假设您用来解密、加密和保护数据的流程为任何攻击者所熟知。请牢记这一点，确保按期循环您的密钥以保证其安全性。仅将密钥提供给须要的用户，避免将密钥暴露得过于普遍而不受您控制。
清理
当您使用密钥时应进行清理，建议将此类数据存储在缓冲区，如字节数组。这样一来，清理完信息后，您就能够用零或任何其余数据（确保该数据已不在该内存中）覆盖缓冲区。
您仍然能够从 Jonathan的文章Windows Azure 中的加密服务和数据安全中研究和学习如何组合全部的组件。
总结
安全性绝非开发流程的最后一步。偏偏相反，它应该始终是开发流程的一部分，您应该根据您本身的应用程序的需求制定安全性决策。
您所使用的方法应确保您的应用程序开发周期中的每一个环节都考虑到安全性。检查您的体系结构和代码中可能容许其余用户访问您的数据的地方。
Windows Azure 使安全性成为成为一项共同责任。经过平台即服务，您能够更加专一于您的应用程序和您本身的安全性需求。
在这一系列博客文章中，我介绍了在 Windows Azure中如何确保应用程序的安全。这一系列文章分为七个部分，介绍了威胁、如何响应、在应用程序生命周期中可采起哪些流程，并规定了根据应用程序的需求实施最佳实践的方式。
我还介绍了一些集成用户标识的方法，以及 Azure提供的一些使用户可以以新方式访问云应用程序的服务。
如下是本系列中的文章的连接：
· Windows Azure 安全最佳实践 - 第 1 部分：深度解析挑战防护对策 。
· Windows Azure 安全最佳实践 - 第 2 部分：Azure 提供哪些现成可用的安全机制。
· Windows Azure 安全最佳实践 - 第 3 部分：肯定安全框架。
· Windows Azure 安全最佳实践 - 第 4 部分：须要采起的其余措施。
· Windows Azure 安全最佳实践 - 第 5 部分：基于Claims的标识，单点登陆。
· Windows Azure 安全最佳实践 - 第 6 部分：Azure 服务如何扩展应用程序安全性。
· Windows Azure 安全最佳实践 - 第 7 部分：提示、工具和编码最佳实践。
本文翻译自：