Securing Hosting and Persistence
The persistence store is a key part of the Microsoft AppFabric 1.1 for Windows Server architecture. This store supports the durability of Windows Workflow Foundation (WF) instances as they travel through various states of execution. You can manipulate persisted workflow service instances by using administrative tooling in AppFabric. You must provide permissions to the persistence store to AppFabric users who run the administrative tools, as well as to applications at run time, to read and write from this data store. You must also control access to the persistence store at both the management and application scope levels.
An important security consideration is where the hosting of an application occurs. Application isolation protects data from being viewed or accessed by other applications. Additionally, controlling the identity of the application for downstream access of resources is a key part of the AppFabric security model. This identity affects the security principal that the application uses when it attempts to access the persistence store.
Both hosting and persistence fall within both application and management scopes, and must be secured differently within each area. Specific permissions are dictated by virtue of inclusion in various security groups. Application security scope affects the permissions that an application has at run time, and maps to the Application Server Users conceptual role. Management security scope affects the tools and related operations that an administrator and system services can execute. These permissions map to the Application Server Administrators and Application Server Operators conceptual roles.
Securing Persistence Data
When an instance of a service is persisted, its system state is saved in the persistence store. Applications often collect and transmit personally identifiable information or other confidential data. When that data is included in the application state when a service is persisted, it is saved in the persistence store. Multiple servers, sites, and applications may share a single persistence store. By design, persistence data is aggregated across servers and sites that share a store, to make it easier to manage the activity state of potentially thousands of instances of a service in a large environment. This allows an instance of a service to be persisted while running on one AppFabric server, and then resumed on another server if required by load-balancing criteria.
After data is stored in the persistence store, it is visible to all members of the AS_Administrators database role, and all members of the SQL Server sysadmin and dbo roles. Because persistence data is vulnerable to inadvertent or targeted exposure, you must take care to diminish the risk by managing permissions correctly.
You can secure the data in the persistence store in the following ways:
Use different persistence stores. You can create and configure an alternative persistence store on the same or a different server by using AppFabric cmdlets to create the store and using the AppFabric Persistence Database Configuration page to configure it. You can then configure certain applications to use only that store. This gives the specified applications a private persistence data store that no other applications can access.
Separate the persistence and monitoring store into two separate stores. By default the table and entities for both the persistence and monitoring stores are created in the DefaultApplicationServerExtensions store during installation. You can dedicate one store to only persistence and the other to only monitoring. This isolates applications and users in both management and application scopes from having access to one dual store and thus having access to all the tables for both persistence and monitoring.
Use Windows groups and SQL Server roles. Access to a SQL Server persistence store is implemented through SQL Server database roles. During the initialization of an instance store, the administrator can insert Windows Groups into the Instance Store Users, Instance Store Readers, and Instance Store Administrators SQL roles. For more information about securing data in persistence stores by using Windows groups and SQL Server roles, see Security Configuration for Persistence Stores.
Manipulate persistence features. You can use the extensions added to IIS Manager by AppFabric to enable and disable persistence features for a specific workflow service, for all workflow services in an application, for all applications in a Web site, or for all Web sites on a server. You can define a persistence policy at a higher level and have all the lower levels in the IIS and WAS hierarchy inherit the policy settings.
Use different application pool identities. By using different identities for IIS application pools, you can restrict or expand SQL Server permissions for the entire persistence store, or for individual entities within it. This is a fine-grained security technique that you perform at the IIS and SQL Server levels, and is not directly supported by the AppFabric tooling.
Securing Hosting
You use process isolation to separate the high-privileged AppFabric management scope services, such as the Event Collection service and the Workflow Management service, from low-privileged application scope application worker processes. The AppFabric services run within the management scope and have complete access to their respective monitoring and persistence stores. All application worker processes and users run in the application scope, typically in the context of an application pool identity.
At the application scope, further hosting isolation gives a more granular view of security. An application contains one or more .NET Framework services that all run in the same process. To secure these .NET Framework services from each other, they can execute in the context of different AppDomains. A .NET Framework process contains one or more .NET Framework AppDomains, each of which is an isolated environment where applications execute. Within an IIS application pool there can be one or more applications concurrently running if they are configured to share an application pool. Thus, AppDomains are a lightweight way to enforce isolation of execution without having to create the overhead of another process with all its resources.
If you need a more isolated hosting solution, configure each application to run in its own application pool with its own identity. This is a way to give applications different identities when they access the persistence store. IIS puts all of these identities into the IIS_IUSRS Windows security group at run time. Running in a separate process space is almost identical to running in a separate application domain from a security standpoint, in that no other application can access a given application’s code or data. Realize that with additional processes comes the overhead of additional operating system resources and context switching on the processor because each process has its own part of the CPU.
2012-09-12