Windows Server AppFabric 的安全模型

  • 项目

必须保护 Windows Server AppFabric 管理的 .NET Framework 应用程序，以便允许用户仅访问他们具有授权的服务和数据。为此，您必须标识用户，验证他们所声称的身份，并确定他们是否有权查看信息或执行请求的任务。客户端与服务器之间的消息交换必须在安全通道上进行，以确保传输私人信息。支持 AppFabric 的 Microsoft 技术提供了一些集成服务，公司可以使用这些集成服务安全连接和使用您的应用程序。AppFabric 管理员无需维护多组用户数据库，而且他们可以从一个图形工具轻松管理数百 Interanet 服务器的所有服务。通过支持 AppFabric 的 Microsoft 安全技术和产品的集成，可以为用户分配对运行其应用程序所需的所有资源的访问权限。

AppFabric 安全的关键部分

AppFabric 安全模型的主要目标是为大部分的 AppFabric 用户提供简单、有效的机制。由于它与现有 Windows、.NET Framework、IIS 和 SQL Server 安全模型集成，用户可以利用现有安全知识和技能集使用此 AppFabric 安全模型。特别是，此安全模型使用 Windows、.NET Framework、IIS 和 SQL Server 安全概念在其管理的 WCF 和 WF 应用程序上强制实施不同级别的安全。由于 AppFabric 仅向已然非常强大的集成 Microsoft 安全添加了极少的增强功能，因此了解 Microsoft 安全概念的管理员对它非常熟悉。这会降低 AppFabric 客户的长期总拥有成本。如果您已经熟悉了这些产品和技术，则您可以按照安全和保护部分中的指南轻松保护您的应用程序。

AppFabric 使用如下现有安全概念：

  • Windows 安全。 AppFabric 利用 Windows 组和文件系统安全。应用程序的所有组件一致使用 Windows 的强大安全体系结构，并将身份验证与对 AppFabric 资源的受控访问权限相关联。有关详细信息，请参阅 Windows 安全。

  • .NET Framework 安全。 AppFabric 为其 WCF 和 WF 服务使用 Windows Communication Foundation 安全。WCF 是一个基于 SOAP 消息的分布式编程平台，对客户端与服务之间的消息进行加密对保护数据非常重要。WCF 为根据现有安全基础结构和公认的 SOAP 消息安全标准，交换安全消息提供了一个多用途、可互操作的平台。如果您已使用现有技术（如 HTTPS、Windows 集成安全或验证用户身份的用户名和密码）构建了安全的分布式应用程序，则会熟悉 WCF 使用的概念。有关详细信息，请参阅 IIS 和 .NET Framework 安全性。

  • IIS 安全。 AppFabric 利用 IIS 安全功能的子集，因为其服务都位于 Windows Process Activation Service (WAS) 中，并且其管理工具显示在 IIS Manager 中。IIS 与 Windows 操作系统紧密集成以为应用程序和数据提供最高级别的安全性。IIS 集成到 Windows NT 安全模型和操作系统服务（如文件系统和目录）中。AppFabric 在 AppFabric 工作流服务需要访问运行时的暂留数据库时利用应用程序池标识的概念。IIS 使用与所有其他 Windows 服务相同的 Windows NT Server 访问控制列表 (ACL)。因为 IIS 使用 Windows NT Server 用户数据库，因此 AppFabric 管理员不需要在每个 Web 服务器上创建单独的用户帐户，并且 Intranet 用户只需要登录到其网络一次。有关详细信息，请参阅 IIS 和 .NET Framework 安全性。

  • SQL Server 安全。 AppFabric 创建 SQL Server 数据库角色以控制对其暂留和监控数据库的访问权限。AppFabric 为其 SQL Server 数据库的访问权限使用 Windows 集成身份验证。集成的安全使用在调用线程上建立的当前 Windows 标识访问 SQL Server 数据库。然后，您可以将 Windows 标识映射到 AppFabric SQL Server 数据库和权限。有关详细信息，请参阅 SQL Server 安全。

AppFabric 概念安全角色

了解 AppFabric 安全模型有助于了解三种 AppFabric 安全角色的属性。这些角色是纯概念性的，在安全模型的任何位置都不能找到具有这些名称的实体。但是，这些概念性的角色显示在相应的映射物理 Windows 安全组和 SQL Server 数据库角色中。在您的安全解决方案中，将用户和权限分配给以下这些角色：

  • 应用程序服务器观察者。此管理角色为您提供对应用程序暂留和监控数据的完全可见性。应用程序服务器观察者可以：

    • 枚举应用程序和服务

    • 查看应用程序和服务配置

    • 查看监控数据

    • 检查暂留实例

  • 应用程序服务器管理员。此管理角色为您提供对应用程序配置、监控和暂留的完全监控。应用程序服务器管理员可以执行应用程序服务器观察者组可以完成的所有任务以及以下任务：

    • 挂起、恢复、终止、取消和删除暂留实例

    • 创建和删除事件源和事件收集器

    • 查看、清除和存档监控数据

  • 应用程序服务器用户。IIS 在运行时使用该运行时角色分配托管应用程序的所有应用程序池的标识。这为包含在应用程序中的服务提供了对暂留数据库和系统服务的共享权限。

作为一个 AppFabric 用户，需要了解的所有信息就是这些是在设计安全解决方案时使用的三个概念性 AppFabric 角色。按照本文档的说明将适当的用户和权限分配给相应的 Windows NT 组与帐户、IIS 应用程序池和 SQL Server 登录与数据库角色。有关使用 AppFabric 角色、其拥有的安全权限及如何映射到 Windows 安全组和 SQL Server 数据库角色的详细信息和重要安全指南，请参阅 Windows 安全、IIS 和 .NET Framework 安全性和 SQL Server 安全。

AppFabric 安全的作用域

AppFabric 使用 Windows 安全帐户和 SQL Server 登录与数据库角色确定用户或数据库具有的对系统资源（如暂留数据库、计时器数据、监控数据和配置文件）的访问权限。对这些资源的访问发生在应用程序和管理级别，它们是与 AppFabric 安全模型有关的逻辑作用域的两个区域。应用程序作用域包括运行作为 IIS 应用程序托管的 AppFabric 服务。从管理角度考虑，管理作用域与 AppFabric 的管理有关。为了进一步了解这三种 AppFabric 安全角色的用法，我们将在应用程序作用域和管理作用域上下文中研究其用法。

应用程序作用域

应用程序作用域定义 .NET Framework 服务的实际运行，这些服务在 AppFabric 进行配置，并驻留在 IIS 下的 WAS 进程空间。它与管理或工具无关；这些归入管理作用域下。应用程序作用域概念适用于概念性 AppFabric 应用程序服务器用户安全角色。此角色映射到 IIS_IUSRS Windows 组，该组是用于 IIS 服务帐户的 Windows 安全组。有关详细信息，请参阅 Windows 安全、IIS 和 .NET Framework 安全性，以及 SQL Server 安全。

每个应用程序都在一个应用程序池内运行。该池可以是默认的应用程序池，也可以创建和配置自己的应用程序池。（应用程序池的创建和配置属于以下“管理作用域”部分中讨论的管理功能。）可以使用应用程序池将应用程序和服务分组到同一个工作进程空间中，以便共享配置设置和其他操作系统实体。由于每个工作进程都是作为工作进程可执行文件的单独实例运行的，可以将服务于一个应用程序的工作进程 W3WP.EXE 与服务于其他应用程序池的工作进程分隔开。这样，在应用程序的宿主是其自己的应用程序池时，将允许应用程序隔离。应用程序隔离确保了在 Web 应用程序出现故障的情况下，不会影响在其他应用程序池内运行的应用程序。

应用程序隔离的另一个优点是自定义的安全隔离。这可以确保在访问下游资源（如 SQL Server）时，使用承载应用程序池（其中包含 AppFabric.NET Framework 服务）的工作进程的配置安全主体。默认应用程序池标识是 Network_Service 帐户。当您在 IIS 中配置应用程序池时，可以分配自己的自定义 Windows 帐户身份。在运行时，WAS 使用在 IIS 元数据库中指定的 Web 应用程序绑定，将来自应用程序池队列的任何传入消息转发到适当的 W3WP.EXE 工作进程。此为 AppFabric 允许激活为 WCF 终结点和服务使用非 HTTP 协议的方法。IIS 动态使用应用程序池的全部 Windows 帐户并将其添加到本地 BUILTIN\IIS_IUSRS Windows 安全组。这意味着在为应用程序创建自己的应用程序池，IIS 会自动将应用程序池的标识添加到 IIS_IUsers Windows 组。

通过使用具有不同安全标识的多个应用程序池，允许关于运行时访问 AppFabric 暂留和监控数据的应用程序隔离。默认情况下，这些数据库对其托管应用程序池使用的所有经验证的 AppFabric 标识共享。如果需要使用隔离提供更高级别的安全性，则可以将特定数据库资源的权限更细微地分配给特定 IIS 应用程序池使用的特定标识。还可以通过为特定应用程序创建自己的数据库，并确保特定身份的自己定义数据之间存在连接，在运行时控制安全性。或者可以基于每个应用程序将应用程序与监控数据库隔离，只允许其访问暂留数据库。

应用程序作用域还适用于 AppFabric 安装和使用的系统服务：

  • 事件收集服务。收集来源为 AppFabric 和托管应用程序的事件。

  • 工作流管理服务。处理工作流控制命令、使用过期计时器激活工作流实例，并重新启动已放弃的工作流服务。

这两个服务都作为 NTAuthority\LocalService 帐户运行。LocalService 帐户有权限发出跟踪事件，也有权限操作暂留实例（终止、挂起和恢复）。

提高安全控制通常会降低性能。虽然应用程序隔离增强了安全功能，但由于存在多个进程，还需要增加内存和进程资源的使用。为了节省资源，您可以使用 .NET Framework appDomain 模型（而非使用单独的进程）隔离应用程序。具有相同进程的两个或多个应用程序可以在不同的 appDomains 内安全共存，并且相互不会妨碍各自的虚拟内存和数据值。

管理作用域

管理作用域定义与应用程序管理相关的管理和工具。它与 AppFabric 中配置的 .NET Framework 服务的实际执行无关；这属于应用程序作用域。管理作用域概念适用于概念性的 AppFabric 应用程序服务器管理员和应用程序服务器观察者安全角色。

从管理和系统服务角度考虑，管理作用域与 AppFabric 的管理及支持技术有关。在应用程序执行之前，您可以执行管理操作，例如，配置并将 .NET Framework 应用程序部署到 AppFabric。当工作流状态为暂留，并且下一步骤需要通过 AppFabric 用户界面进行处理时，在执行期间您也可以执行管理操作。例如，可能需要恢复挂起的工作流。管理 .NET Framework 服务（在 AppFabric 中配置）的配置和执行的安全权限基于特定 Windows 安全组中的成员身份。从管理和控制的角度考虑（而不是从应用程序的角度考虑），管理作用域还适用于 事件收集服务 和 Workflow Management service。

概念性的应用程序服务器管理员和应用程序服务器观察者安全角色分别映射到本地 AS_Administrators 和 AS_Observers Windows NT 安全组。AS_Administrators 组包含 Workflow Management service 和 事件收集服务 的服务 ID (SID)。在此服务使用服务控制管理器注册之后，其 SID 将保持不变。这意味着无论服务运行时使用的标识是什么，事件收集服务 和 Workflow Management service 都将会是 AS_Administrators 的成员。此标识通常为 NTAuthority\LocalService。因此使用 SID（而非服务标识）可以确保使用 NTAuthority\LocalService 标识运行的任何其他进程或服务都不能是 AS_Administrators 的成员。有关 AppFabric 概念性的安全角色和如何使用的详细信息，请参阅 Windows 安全、IIS 和 .NET Framework 安全性，以及 SQL Server 安全。

AppFabric 在安装时保护管理作用域。当 Windows PowerShell cmdlet 在安装时创建监控和暂留数据库时，会根据相应的 AppFabric 概念性安全角色创建适当的 SQL Server 数据库角色。例如，在 AS_Observers 的 SQL Server 中创建的角色都是读者角色（MonitoringDbReader 角色用于监控，System.Activities.DurableInstancing.InstanceStoreObservers 角色用于暂留）。从管理角度考虑，为 AS_Administrators 登录帐户定义的 SQL Server 数据库角色包括链接到 AS_Observers 登录帐户及用于创建和修改数据库实体的其他角色的所有数据库角色。

默认情况下，在其安装过程中，AppFabric 安装程序运行部分 AppFabric cmdlet。AppFabric 为 AppFabric 的单一服务器安装创建所有必需的本地 Windows 安全组和帐户。如果您在多个服务器上使用 AppFabric，则将必须手动创建 Windows 域组，并将其分配给该服务器的适当 Windows 安全组，以远程管理 AppFabric 安装。作为一名管理员，您应该以应用程序服务器管理员和应用程序服务器观察者概念性安全角色的实际表现创建域组（即，DOMAIN\MyAppFabricAdmins 和 DOMAIN\MyAppFabricObservers）。然后，您可以将这些域帐户分配给域中所有 AppFabric 计算机上的 LOCAL\AS_Administrators 和 LOCAL\AS_Observers 组。

自定义 Windows PowerShell 脚本和 AppFabric Cmdlet 的安全模型

AppFabric 没有为自定义 Windows PowerShell 脚本或 AppFabric 发行版包含的许多 Windows PowerShell cmdlet 提供新的安全模型。对于安全模型的其他方面，AppFabric 在其支持技术中利用现有安全模型。在这种情况下，AppFabric 使用 Windows PowerShell 安全模型为自定义脚本和预先打包的 AppFabric cmdlet 强制实施安全性。

当 AppFabric Windows PowerShell 脚本运行时，将使用主机进程的标识执行此操作。这意味着运行 cmdlet 的用户的安全主体作为进程 ID 进行传递。不能使用模拟在用户运行主机进程的安全上下文下中运行 cmdlet。

虽然默认情况下能够以交互方式执行 Windows PowerShell 命令，但出于安全原因，最初会禁止运行 Windows PowerShell 脚本。您需要通过 Windows PowerShell 脚本执行组策略启用此功能才允许运行脚本。

AppFabric 附带的 Windows PowerShell 脚本已使用从证书颁发机构 (CA) 获取的证书进行了数字签名。通过使用来自 CA 的数字证书对实体进行签名，可保护程序包的完整性。通过使用单向哈希和公共加密算法，签名过程可确保将检测到作者签名后对程序包做的任何修改，并将随后阻止脚本的执行。您还可以使用数字签名验证签名实体确实是由声称创建它的一方创建。替代使用 CA 的一种简单且成本低廉的方法是使用本地 CA 和 Microsoft 证书服务器生成自签的证书。您可以使用私钥加密进一步保护证书。

security安全 注意
在信任的策略中使用本地 CA 签名 Windows PowerShell 脚本程序包的可能性极低。虽然本地签署的程序包在本地系统上受信任，但如果在外部系统上运行便不受信任。

联合身份管理和单一登录 (SSO)

联合身份验证系统也称为 Web 单一登录 (SSO) 系统。联合系统跨组织边界工作，连接使用不同技术、身份存储、安全方法和编程模型的进程。使用 Active Directory 联合服务 (ADFS)，处于一个公司的人员可以使用其现有的 Active Directory 帐户访问由不同公司托管的服务器。ADFS 还会在两家公司之间建立信任关系，为最终用户提供无缝的一次性登录 (SSO) 体验。通过此信任关系，组织可以安全共享用户的身份消息。

由 AppFabric 管理的基于 HTTP 的应用程序，在许多方面只是一个 IIS 应用程序。如果您需要将联合身份管理和 Web SSO 身份验证与您的应用程序集成，则您可以使用 ADFS，如同将其用于 IIS 应用程序一样。ADFS 将访问应用程序的登录帐户映射到域帐户，然后使用该域帐户对 IIS 进行身份验证。

由于 .NET Framework 4 使用 WCF 及其安全模型在其托管的服务及其客户端之间进行通信，仅支持基于 HTTP 的应用程序的传统 IIS 模型扩展到了 HTTP 之外。如果使用 HTTP 不进行传输身份验证，或使用非 HTTP 应用程序，则在服务内使用编程接口实现声明标识处理。声明感知应用程序将使用 ADFS 安全令牌中的声明做出授权决定，并提供其他应用程序个性化设置。对于 ADFS，您应了解声明标识处理如何与 IIS 应用程序协作才能将声明处理与您应用程序相集成。

本节内容

另请参阅

其他资源

WF Security Pack CTP

  2011-12-05