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