SharePoint 2010 : Identifying Isolation Approaches to SharePoint Security

2/28/2011 9:38:35 AM
Microsoft SharePoint Server 2010 was built to be a robust, capable, and scalable environment. Along with SharePoint’s capabilities comes the responsibility to secure its vital components, protecting them from attacks and data loss. Fortunately, SharePoint allows for a wide range of security functionality, features, and tools to properly secure a SharePoint farm. Knowledge of these capabilities is a must for a SharePoint administrator.

This article focuses on the aspects of information security that an organization can implement to protect information stored in a SharePoint environment. This includes server-level security from a network operating system and web services perspective, Active Directory integration, firewall and access to intranet and extranet information, file-level security for information stored and indexed on non-SharePoint-managed data stores, file-level security for information stored within a SharePoint-managed data store, user-level security for access to SharePoint data, and administrative controls to monitor and manage user and access security.

In addition, tools and services useful for securing SharePoint such as the Microsoft Baseline Security Analyzer, IPsec, Public Key Infrastructure (PKI), and others are covered to provide for enhanced security.

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 because each host can theoretically host millions of sites, 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 Web Applications

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 and 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.

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 Farms

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.

  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 5) - Starting the OCS Services on the Server & Validating Server Functionality
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 4) - Configuring the Server & Configuring Certificates for OCS
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 3) - Configuring Prerequisites & Deploying an OCS 2007 Server
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 2) - Prepping the Domain & Delegating Setup and Administrative Privileges
  •  Exchange Server 2010 : Installing OCS 2007 R2 (part 1) - Extending the Active Directory (AD) Schema & Preparing the AD Forest
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment - Understanding Microsoft’s Unified Communications Strategy
  •  Protecting SharePoint 2010 from Viruses Using Forefront Protection 2010 for SharePoint
  •  Protecting SharePoint with Advanced Antivirus and Edge Security Solutions : Securing SharePoint Sites Using Forefront UAG
  •  Developing Applications for the Cloud on the Microsoft Windows Azure Platform : Accessing the Surveys Application - Geo-Location
  •  Developing Applications for the Cloud on the Microsoft Windows Azure Platform : DNS Names, Certificates, and SSL in the Surveys Application
    Video tutorials
    - How To Install Windows 8

    - How To Install Windows Server 2012

    - How To Install Windows Server 2012 On VirtualBox

    - How To Disable Windows 8 Metro UI

    - How To Install Windows Store Apps From Windows 8 Classic Desktop

    - How To Disable Windows Update in Windows 8

    - How To Disable Windows 8 Metro UI

    - How To Add Widgets To Windows 8 Lock Screen

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
    programming4us programming4us