Security Considerations for Server and Site Configurations
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
When you host content on a Web service, you must make decisions about how best to protect the content from unauthorized users, and to what degree the content needs to be protected. The decisions you make influence the way you configure your servers and sites. There are pros and cons to each configuration, and your organization's requirements for security will always be different than another organization's requirements.
Microsoft , like most other Web services, supports multiple configurations, each of which has different tradeoffs in functionality, performance, ease of deployment, and security. This topic discusses eight specific ways of deploying content with , and lists each method's pros and cons from a security standpoint. Choose the configuration that best meets the needs of your data and your organization.
1. Physical Isolation: Separate Networks
The most secure way of deploying content is to isolate the content from all untrusted users. You can do this by removing all network connections from the server running or by creating a separate physical network dedicated to the content.
This option has obvious drawbacks in functionality and ease of deployment. Users will not be able to use their existing network credentials to authenticate on the server running and creating multiple physically isolated networks is a costly deployment option.
2. Physical Isolation: Separate Server Computers
The next most secure way to deploy content is to put each site on its own server computer. This helps mitigate a security exploit on one site that grants the attacker control of the server computer from being used to attack other sites based on .
Again, this option has serious drawbacks for ease and cost of deployment. Each new site requires a new server computer. This is a waste of server resources if the sites cannot keep the server computers busy all the time, and it is an administrative drain to manage multiple server computers.
3. Process Isolation: Separate Application Pools
The next most secure way to deploy is to put each site in its own application pool on the same server computer. Application pools in Internet Information Services (IIS) provide a way for multiple sites to run on the same server computer but still have their own worker processes. This mitigates an exploit on one site which allows the attacker to inject code onto the server from attacking other sites. Each site has its own worker process and identity which prevents two processes from interacting.
While this configuration is easier to deploy than separate server computers, deploying sites using separate application pools still has significant performance and deployment issues. Because each application pool has its own process, you cant deploy more than 10 to 20 sites on a server by using different application pools. The memory overhead of each application pool is about 30 to 50 MB. Beyond ten to twenty sites, the server will run out of memory to hold all the site processes.
4. Logical Isolation: Separate Virtual Servers
The next most secure way to deploy is to put each site into its own virtual server with a unique domain name but using the same application pool. This method gives each site its own domain name, which helps prevent cross-site scripting attacks.
However this method still suffers from the scalability limitations of multiple virtual servers. Each ASP.NET page generates a separate DLL for each virtual server, even if the source file of the ASP.NET pages is the same. The separate DLLs consume memory and will prevent more than 100 sites from running on the same server.
5. Logical Isolation: Separate Host Headers
also supports hosting multiple domain-named sites in a single virtual server. This is called host header mode because uses the host header or domain name to resolve the different sites. This scales much better than separate virtual servers and still helps prevent cross-site scripting attacks between two sites. can host up to two million sites per server computer in host header mode.
The downside of this configuration is in the additional deployment costs. In this configuration, each site requires a separate DNS entry in the domain controller.
6. SharePoint Site Isolation: Separate Site Collections
also supports hosting multiple site collections using the same virtual server and the same domain name. Site collections can be scaled out across multiple database servers for additional storage capacity and throughput. The upside of this configuration is scalability and ease of deployment. can host up to 2 million sites in a single domain. Creating a site collection does not require any DNS entry and can be easily automated and delegated to end-users. includes Self-Service Site Creation so users can even create their own sites.
However, while enforces security on the site, the sites are still vulnerable to cross-site scripting attacks from other sites within the domain.
7. SharePoint Site Isolation: Separate Sites
also supports multiple subsites and workspace sites within a single site collection. can host up to 250,000 subsites within a given site if the subsites are organized into folders of no more than 1000 subsites each.
The upside of this configuration is seamless navigation around the site collection. There is no built-in navigation from one site collection to another, but there is navigation from one subsite to another within a site collection.
The downside is reduced scalability - because all sites must be stored in the same content database, it is difficult to increase either storage capacity or throughput. Also, as with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites within the domain.
8. SharePoint Site Isolation: Separate Lists
Finally, supports list- and library-level security. You can deploy content in a single site using separate lists and document libraries for different content. The upside of this configuration is seamless navigation around the site and global visibility of all objects. Users will be able to see that a library exists, even if they have no permission to read documents inside the library.
However, this is the least secure way to deploy content. The content is vulnerable to cross-security scripting attacks. Users in parent sites can also delete or deny access to content in subsites.
For more information about list-level security, see the Help system.
Other Security Issues
In addition to the eight deployment configurations list above, there are two other security issues worth mentioning that apply to all configurations: secure sockets layer and anonymous access.
Secure Sockets Layer (SSL)
All of the deployment configurations above are vulnerable to network sniffing attacks unless the communication between the client and server is encrypted. supports the standard IIS SSL functionality to encrypt content between client and server. There is a substantial performance penalty for using SSL, but it the only way to protect data from hackers who can monitor the network. When using basic authentication, SSL is highly recommended because basic authentication sends user names and passwords over the network and SSL protects that data.
supports anonymous access, but it is disabled by default. Any server that allows anonymous access is more vulnerable than a server that requires authentication. Anonymous sites can be attacked by anyone. Servers that require authentication can only be attacked by users who have some permission on the network.
For more information about architecture, including server farms, virtual servers, application pools, site collections, and sites, see the following topics:
For information about SSL and anonymous access in , see the following topics:
For more information about installing , see the following topics: