As Microsoft SharePoint Products and Technologies
mature, more organizations are using SharePoint sites to upload
sensitive information that needs to be properly secured. This phenomenon
is predictable, since an increasing use of SharePoint for collaboration
and information hosting activities would naturally lead users to upload
information that needs to be secured. There is a perception among a
sizable number of security professionals and information technology
administrators that the SharePoint platform is not a secure platform.
Microsoft
SharePoint 2010, when properly configured, offers tight security and can
work well in rather demanding environments. But getting the product
properly configured requires teamwork, training, and an understanding of
how SharePoint security works. Depending on the level of security you
want to achieve, both in terms of breadth and granularity, you might
need to work with one or several layers of security available within the
SharePoint platform.
Introducing SharePoint Security
SharePoint security is
managed at every level of the hierarchy. Conceptually, you can think of a
SharePoint farm as consisting of a hierarchy of elements as shown in Figure 1.
The important concept to understand here is that there are security
settings at nearly every level and that these settings “pass through” or
apply to the down-level containers, too.
When you take a long step back
and look at how content is actually hosted in SharePoint, it is really
accomplished within a series of nested containers: Content items are
hosted in a list. Lists are hosted in sites. Sites are hosted in site
collections. Site collections are hosted within managed paths (even the
root site of a Web application is hosted in a hidden managed path called
root), and managed paths are hosted in Web applications.
Granted, some content is
hosted in publishing pages directly, so keep in mind that the previous
paragraph’s simple explanation is not making a sweeping statement
without any exceptions in SharePoint. But it is fair to say that the
majority of the content hosted in SharePoint in done so in lists.
Document libraries, under the hood, are really just complex lists, with a
customized view that exposes the documents instead of the list items to
which the documents are attached.
The reason it is important
to understand the structure—how SharePoint content storage is set up—is
because different parts of SharePoint security are applied at different
“layers.” Some security is applied at the Web application layer,
whereas other security is applied at the content item layer. Figure 2 offers an outline of how security is applied within SharePoint 2010.
Note:
Site quotes, audiences,
database status, and alternate access mappings are not security features
in SharePoint 2010. Site quotes and database status instead are focused
on setting capacity limits, alternate access mappings provide alternate
URLs to the existing content, and audiences are really a view-crafting
feature.
Security is commonly thought
of as being applied to content, and although this is certainly true
within SharePoint 2010, security is more than this. Security is about access—access
to content, but also access to the containers that host the content. So
it is reasonable to assume that by blocking access to a container at an
upper layer, such as a Web application, you can effectively block
access to an entire set of content without having to visit and configure
each list in which the content resides.
The interplay of security
settings at the different layers within SharePoint will force the
information technology (IT) team and SharePoint users to communicate
better about how security should be set. The product is designed to
allow the management of security settings applied directly to content by
nontechnical end users who are the owners of the content. IT personnel
don’t (at least not often) get involved in this process. However, there
are some settings that are configured only by the IT administrators (or
SharePoint farm administrations if you have a separate team managing
your SharePoint deployment) through Central Administration, because they
are only available in the Central Administration interface or through
Windows PowerShell.
You might think that the
appropriate manager of a particular SharePoint “layer” should be the
individual who would make changes to the security
settings for that layer. But since many of these security settings
affect other settings in other layers, it is critical to maintain
communication and coordination between those involved to ensure that
SharePoint is secured correctly.