Using Isolation to Secure Applications
The Network Service built-in user account is the default worker process identity for application pools in IIS 6.0. You can have more than one application pool running with this process identity. However, if you use the Network Service account to configure ACLs on application pool resources, every application pool will then have access to every other application pool's resources.
Configuring an Application Pool Identity to Isolate Applications
To isolate applications effectively, each application pool should have its own account identity. That account identity must be added to the IIS_WPG local group so the account can launch the worker process associated with the application pool. However, you should not use the IIS_WPG group itself to configure ACLs on content files and directories. In addition, if you configure any accounts to be used either for anonymous access or for site authors or owners, you should not add them to the IIS_WPG group. Doing so would give those accounts access to directories that are shared among application pools, such as the compression cache and the ASP template cache. For more information about configuring an application pool identity, see Configuring Application Pool Identity in IIS 6.0.
To configure applications with a high level of isolation, create a unique user account for anonymous access, and then make this account the anonymous user account for your Web site. For step-by-step instructions, see Alterando a conta usada para autenticação anônima. A unique anonymous user identity combined with a designated account for the application pool identity provides two of the essential elements needed for constructing an effective security boundary for the application. In addition, having a unique anonymous user identity allows you to configure authorization so that applications launched by the anonymous user can access only the required resources.
Configuring Authorization to Isolate Applications
Authorization uses the authenticated identity of the user, including the anonymous user, to limit access to resources. In this context, an application pool identity can be considered a user. You can use the application pool identity to configure ACLs to file system resources, the IIS metabase, and registry keys.
Use an ACL to permit or deny specific users access to an application's directories and files. When you configure ACLs on content, use groups to contain application pool identities and assign ACLs to those groups. Your groups can represent various user functions or actions, such as authoring or anonymous access, or specific permissions such as Browse or Read. Then, assign NTFS permissions to file system resources to allow permissions where the application pool identity requires access, for example, logging directories or script caches.
Use the Metabase Explorer tool in the IIS 6.0 Resource Kit Tools or the Meta-Data Edit Tool to view and set ACLs on metabase keys. Default ACLs on application pools give the IIS_WPG, Network Service, and Local System accounts the ability to query metabase properties for all application pools. You can increase isolation by:
Removing metabase entries for IIS_WPG.
Assigning the application pool identity Read permission.
Assigning any Web site author or administrators Read permission.
Giving the Administrators group and any other system administrators Full Control.
To configure ACLs on registry keys, you can use templates from the Windows Server 2003 Security Guide to restrict permissions on the registry. In addition, you can specifically restrict access to portions of the registry that contains information about Component Object Model (COM) objects used by your applications.
For more information about isolating applications, see Configuring Application Isolation using Windows Server 2003 and IIS 6.0.