Identifying Isolation Approaches to SharePoint Security

Various organizations have varying security needs. Some organizations, for example, require strong security and cannot tolerate even the slightest risk to their business. Other organizations have a much higher tolerance for security risks and often choose to make a system more functional at the expense of security. SharePoint scales its security well to the needs of these different organizations and provides a wide spectrum of security options that can be suited to the needs of many different organizations.

Arising from these ideas is the concept of security through isolation. SharePoint servers running on an isolated network segment, for example, are highly secure compared to those directly located on the Internet. The following section deals with approaches to isolate users via security boundaries in SharePoint. Each option further isolates users and increases the security offered. With the increased security comes decreased functionality, however. The functional needs of an organization must be weighed against the security needs.

Isolating SharePoint Data with Separate SharePoint Lists

The simplest, most straightforward approach to security through user isolation comes through the application of security on the list level in SharePoint. This model involves the entire pool of users having access to the site but then being disallowed or allowed access to SharePoint content through security set at the list level.

This model, although the most functional, also is weakest in security. Administrators in parent sites can seize access, and users are subject to potential cross-site script attacks in this design, which limits its security.

Isolating SharePoint Through Deployment of Separate Sites or Site Collections

Granting various groups of users access to SharePoint content by organizing them into sites is a more secure approach to SharePoint design. Users are limited in the types of access they receive to other sites, and searching can be limited to specific information. Administrative overhead is increased in this example, however, as separate groups of users and permissions need to be maintained. It is also more difficult to manage because all sites must use the same content database, reducing the scalability of the system.

Deploying users into separate Site Collections goes even further down the path of security and scalability. Separate Site Collections can be more easily scaled out than separate sites, as each host can theoretically host up to two million sites in a domain, if required. Both of these models are still vulnerable to cross-site scripting attacks, however. If a site is vulnerable to this type of activity, a more secure model may be needed.

Isolating SharePoint with Separate Host Headers and Virtual Servers

The problem of cross-site scripting attacks can be addressed through the creation of multiple host headers or virtual servers in SharePoint. Host headers allow for multiple domain names to correspond to different site collections in SharePoint. As a result, you can have a single SharePoint farm correspond to http://sharepoint.companyabc.com and http://sharepoint.cco.com and have them point to separate sets of data. This allows for an increased level of security between the sites, because users cannot see the data from the other site collections. This, of course, reduces the amount of collaboration that can take place between the sites and is limited in scope. Going one step further, each host header can be associated with an individual virtual server in SharePoint. By doing this, each site collection can be associated with a separate application pool. Each application pool is logically separate from the others and is theoretically not subject to failure if another one goes down or becomes corrupt. This also helps to further secure the SharePoint data, because users are on separate physical processes from each other.

Isolating SharePoint with Separate Physical Servers or Networks

The last, most secure, and also most expensive option for SharePoint security through isolation is by deploying each Site Collection on separate servers or in separate networks. By deploying on separate servers, a great deal of independence is achieved as attacks and snoops from one site are physically removed from the resources of another. This can prove to be expensive, however, because individual servers need to be purchased, configured, and maintained.

The ultimate security boundary for interconnected networks is to simply disconnect them from each other. It goes without saying that the most secure SharePoint farm is the one connected to an isolated network. There are some major disadvantages to this, however, because access from any other location becomes impossible.