Securing SharePoint sites consists of granting permissions to people who usually belong to groups and then assigning those permissions to securable objects. Simple, right? We review each of these key security elements, which are shown in Figure 1, in the discussion that follows.
Securable Objects
Securable objects consist of all of the solution
elements to which permissions can be applied. For example, you can apply
permissions uniquely to a site collection, a subsite or site within a
site collection, a list or library, a folder, or an individual item in a
list or library. By default, permissions are inherited in your site
hierarchy. For example, security permissions for the top-level
site are inherited by all subsites unless you explicitly “break” the
inheritance. Permissions for the site are inherited in each object (list
or library) on the site, and permissions for documents or list items
are inherited from the library as shown in Figure 2.
As a general best practice, you always want to apply
security at the “highest” level possible in your solution because it’s
easier to manage and maintain security in fewer places. The menu option
used in SharePoint to apply unique permissions is Manage Permissions.
It’s easiest to understand how security permissions have been applied if
permissions are the same for all elements of the site. This is clearly
not always possible or practical, but it should be a guiding principle
for your security model. Another reason for minimizing security
exceptions in SharePoint is that the interface does not easily show you
where permissions have been “broken.”
Because there is no visual trigger that highlights a
specific item (or list or site) that is secured differently than its
peers, it can be difficult to quickly identify or change where
item-level security has been applied. For example, if you are the site
or list “owner” (with Full Control permissions), the only way to tell if
a document has unique permissions is to examine permissions in the
context of the document. If you need to update security permissions for
individually secured items, you will need to update each item
independently. If you are the “help desk” person trying to help an end
user navigate to a list or library, you will need to remember that your
permissions may be
different than the end user’s permissions inside the same list or
library, so you may see more or fewer documents than the person you are
trying to assist. If you find that you have a security model that
contains many item-level exceptions, you may want to consider
documenting the exception in the item metadata or using a third-party
solution for SharePoint security analysis and management.
Because
security permissions are shared in all documents in a document library,
if you have permissions to edit one document in a library, you have
permissions to edit all documents in that library unless security has
been “broken” (managed) for an individual document in the library. By
editing we mean the ability to alter or delete those documents. If you
store documents in folders, security in the folder is inherited into
each document in the folder. This is one reason that you may want to use
folders in a document library—to apply shared editing permissions to
separate groups of documents and minimize the use of item-level
permissions. This is one example of how security has an impact on your
user experience and content topology. Introducing folders to manage
collective security may solve authorization issues but may introduce an
inconsistency in how content is managed (for example, other libraries
may group documents by metadata). Consider this when balancing security
management and usability.
Security Trimming
Any object that you secure in SharePoint is secure in
both a “browse” and “search” scenario. If a document, list, or site has
unique permissions, users who do not have access to the object will not
see it in lists or search results. This is called security trimming.
If an unauthorized user attempts to access this content directly via a
URL link, that user will be denied access and prompted for alternate
credentials. Security trimming also impacts search results. If two
different users execute the same exact search, they may see different
results based on their permissions. Security does not affect the
relevancy of results; only the number of items that are returned.
Security Exceptions
While not technically part of SharePoint, Information
Rights Management (IRM) offers another way to secure items stored in
SharePoint. Microsoft IRM allows users to create a persistent set of
access controls that live with the content itself rather than the
location where the item is stored. IRM services can be used, for
example, to protect an individual item from being downloaded or printed.
When enabled, IRM security takes precedence in a list or library. For
example, if an authorized user opens a rights-managed document from a
document library where the IRM protection does not allow documents to be
e-mailed, the user would not be able to send that document to another
user, even if that person also has access to the SharePoint library.
Instead, the person would have to go to the library and download the document directly. For more information about IRM and SharePoint 2010, refer to http://msdn.microsoft.com/en-us/library/ms458245(office.14).aspx.
There are several objects in SharePoint that cannot
be secured. These include views, Audiences, Web Parts, and list
Columns. Be sure to consider the following implications about which
objects can be secured and how security is inherited:
Because you cannot secure an individual view
of a document library, you cannot use unique views to “get around” the
fact that you cannot secure an individual Column in a list. For example,
you may want to have a Column in a list that shows financial numbers
that you don’t want all users to see. You cannot secure the financial
Columns using Manage Permissions or secure a view
that doesn’t display the financial Columns. In this scenario, you
should consider using an alternate means of sharing the sensitive data.
For example, one approach might be to use Excel to store the information
and secure the Column in Excel. You can then use Excel services to
display the information in a SharePoint Web Part. Another approach would be to show the
protected data in a separate list, using an event handler to keep the
two lists synchronized.
You cannot secure a Web Part, but you can use an Audience to target
a Web Part so that it only shows up to users who “belong” to that
Audience. (Note that the content displayed in a Web Part is always
secure, but security cannot be applied to the Web Part itself.)
Targeting a Web Part using an Audience does not secure the content
displayed in the Web Part—you must secure the object displayed in the
Web Part by managing permissions on the content. This is an important
distinction. Audiences are used to “personalize” presentation and
effectively manage screen real estate with relevant content. Use
Audience targeting to feature information, not to protect it.
People and Groups
In the context of SharePoint, “people” are individual
users who need access to a SharePoint site and can be defined
individually or as a member of a group. A group is a named collection of
people (users) in SharePoint.
While individual people can be granted permissions
inside of SharePoint, it is generally more desirable to first add that
person to a group and then grant permissions to the group. That way, new
users can be added in one place, the SharePoint
or Active Directory Group, and they will automatically get all the
permissions associated with that group. This methodology is also helpful
in two other ways: 1) it is easier to replicate security (for example,
our new resource should have the same access as Mary) and 2) it reduces
the amount of legacy security that accumulates over time (Tom has left
the company but his name is still associated with a collection of sites
across our environment).
In SharePoint, there are two types of groups that you will work with:
A Domain Group is created outside SharePoint in Active Directory.
A Domain Group (also called an Active Directory or AD Group) is defined
for the entire enterprise and can be used in any site collection in
SharePoint or to manage access for other applications used by your
organization. Domain Groups are generally created by a security
administrator in your IT group, but some organizations allow business
teams to request the creation of a new Domain Group that they can manage
themselves. Domain Groups are most often created to represent
persistent roles or geographic groups of people inside your
organization. If you can, you should take advantage of existing,
automatically maintained Domain Groups to assign permissions for your
site. For example, if there is already a Domain Group for Managers and
you have content or sites that are for Managers only, you should use
this existing group in your site. When new managers are added or if
someone is no longer a manager, you will not need to worry about (or be
responsible for) adding or deleting them from the group. If your
organization allows you to create Domain Groups that are not
automatically populated, you may have to manage “comings and goings,”
but you will still only need to do so in one place. It is not always
possible or practical to have an Active Directory group for individual
sites in SharePoint. This is especially true if you are creating highly
granular, low membership groups. You should not clutter AD with
SharePoint-specific groups. You should also avoid creating AD groups
that cannot be repurposed (that is, used in multiple security
applications in and out of SharePoint). In these instances, you are
better served leveraging SharePoint security groups.
A SharePoint Group can be defined by a Site Collection Administrator or a user with Manage Permissions privileges and can be
used to secure objects within a single site collection only. Groups
created in SharePoint for one site collection can only be used within
that individual site collection and must be separately created and
maintained if needed in another site collection. All SharePoint Groups
are created at the site collection level and are available to any
subsite or other securable object in the site collection.
SharePoint Groups can include Active Directory Groups
and/or individual users. However, SharePoint Groups cannot include
other SharePoint Groups. There are two types of SharePoint Groups:
Default Groups and Custom Groups. The primary advantage of SharePoint
Groups is in situations when you chose to deviate from the inherited
security of a parent site and assign unique permissions to a site. In
this case, SharePoint will create the appropriate groups for Owners,
Members, and Visitors, and the administrator can manage security by
assigning membership for these groups.
Figure 3 summarizes the different types of security groups in SharePoint and describes the characteristics of each group.
Default SharePoint Groups
SharePoint provides several default SharePoint Groups for team sites as shown in Table 1.
Each of these SharePoint Groups is associated with a default permission
level.
Table 1. SharePoint Groups and Default Permission Levels for Team Sites
| Group Name | Default Permission Level |
|---|
| Owners | Assigned Full Control permission level for [Site Name].
Generally, there will be a small number of users in this group. |
| Designers | Assigned Design
permission level for [Site Name]. You might use this group to give
users permissions to design the structure of the site without giving
them permission to assign security or create subsites. In practice, we
don’t find this default group used very often. |
| Members | Assigned Contribute
permission level for [Site Name]. More users will be in this group. For
team sites, it’s likely that all eam members will also be included in
the site’s Members group. |
| Visitors | Assigned Read permission level for [Site Name]. Generally, the largest number of users will be in this group. |
| Viewers | Assigned View permission level for [Site Name]. |
Additional default security groups are created if you
use templates other than the Team Site template in SharePoint or if you
activate publishing features for a site. Table 2
shows the additional default SharePoint Groups provided in sites
created with the Publishing template or when publishing features are
enabled. You may enable publishing features for your site but decide
that you do not need any of these security groups. If that is the case,
you can leave these groups with no members. In most cases, we discourage
the deletion of any default security groups as requirements may change
and these groups may be brought to bear further in a site’s evolution.
Table 2. SharePoint Groups and Default Permission Levels for Publishing Sites
| Group Name | Default Permission Level |
|---|
| Restricted Readers | Assigned Restricted Read
permission level for [Site Name]. This group is rarely used and is most
often leveraged when users should have a very limited visibility into
presentation page content only. |
| Style Resource Readers | Assigned
permissions that allow the member to have read access to the Master
Page Gallery and Restricted Read to the Style Library. This group is
used for design team members who may want to see associated styling
elements. |
| Quick Deploy Users | Assigned
permissions that allow the user to contribute to the Quick Deploy Items
library plus Limited Access to the rest of the site. |
| Approvers | Assigned Approve
permission level for [Site Name]. This group is used for content
publishing purposes. Members have the authority to see, validate,
publish, or reject/ propose content changes prior to public consumption. |
| Hierarchy Managers | Assigned Manage Hierarchy permission level for [Site Name]. |
In addition, SharePoint includes several special users and groups for administering SharePoint sites:
Site Collection Administrators
have an “all-access pass” to every element of content and all site
permissions. In addition, they are recorded as the contact for the site
collection and can audit site content, enable site collection features,
and monitor site and search usage. You cannot hide content from a Site
Collection Administrator, so
if you have content that needs to be visible only to members of the
executive committee, you will need to designate a member of the
executive committee as the Site Collection Administrator. You need to
designate individual people, not a group, as Site Collection
Administrators, with the ideal number being more than one, but no more
than a handful of users. It is recommended that Site Collection
Administrators (or any administrator) be named users and not service
accounts. Using service accounts eliminates auditing capabilities as you
can’t track changes to specific resources.
Farm Administrators
control which users can manage settings for the server farm. By
default, Farm Administrators do not have access to site content, though
they can take ownership of a site if they want to view content. This
group is used only in Central Administration; you won’t see this group
in any individual site collection.
Administrators
have the same privileges as Farm Administrators, but they can also
install new products and applications, deploy Web Parts to the entire
farm, create new Web applications, and start services (such as a search
crawl). This group does not have access to site content by default and
is not visible in an individual site collection.
Custom SharePoint Groups
The
out-of-the-box security groups in SharePoint are essentially a
combination of “role” and “permissions.” Also, the SharePoint model is
inclusive and not exclusive. That is, you cannot define activities that
users or groups are not allowed to perform. For example, the Members
group has the Contribute permission level by default, so people often
associate the Members group with Contribute permissions, even though
this doesn’t have to be the case. There may be situations where you have
different groups of people who need different access permissions to
various objects in your solution, and it may not be possible or
practical to create an Active Directory group for them. While you can
add multiple Active Directory Groups to a SharePoint Group, you cannot
“nest” SharePoint Groups. If the same group of people need different
permissions in different sites (for example, Contribute in one and Read
in another) and you can’t use an Active Directory Group, you will want
to create a custom SharePoint Group. You may also want to create a
custom group because the terms Visitors, Members, and Owners just don’t
make sense in your organization. As a best practice, when you create a
custom SharePoint Group, choose a name for the group to reflect the
people in the group and their collective “role” in the organization, not
their security permissions. This is hard to explain without an example. As a
general practice, you always want to give a person or group the least
amount of permissions to effectively achieve the required business
functionality ... and no more. This certainly creates additional
administrative overhead, but it is a core tenet of ensuring the
stability and security of a SharePoint environment.
Permissions
Individual permissions (such as view items, open
items, edit items, and delete items) are grouped together into
permission “levels,” such as Contribute, which allow users to perform
specific actions. You can also create custom permission levels, but when
you do this you may make managing a site more difficult, and you will
also make it more difficult to audit your site’s security. That doesn’t
mean that you shouldn’t create custom permission levels, but it does
mean that you should carefully document all the permissions levels that
you create for your site. In addition, you should validate any custom
security groups as being essential. One we have seen often is a custom
security group that offers content contribution but does not have
deletion rights. (Note that the
Recycle Bin may minimize the need for this type of customization.)
Individual permissions are assigned to one or more permission levels,
which are in turn assigned to individual users (if you absolutely have
to) and/or SharePoint Groups (the preferred approach).
The out-of-the-box or default permission levels for team sites include
Full Control
provides administrator access to the site. This permission level
contains all permissions. This permission level cannot be customized or
deleted. As a general rule, you will only allow a user to have Full
Control privileges when they have demonstrated an understanding of how
SharePoint works, SharePoint best practices, and, most importantly, your
organization’s governance model. This user can give anyone else
permissions, including Full Control.
Design allows the user to create lists and document libraries, edit pages, and apply themes, borders, and style sheets in the site.
Contribute allows the user to add, edit, and delete items in existing lists and document libraries.
Read
allows read-only access to the site. Users and groups with this
permission level can view items and pages, open items, and download
documents.
Limited Access
is a special permission level that is automatically assigned to users
who have access to some areas of the site but not all areas. For
example, a user with Contribute access to a document library on a
subsite will appear in the permissions list of the home page as having
limited access permissions. This does not allow him to view anything on
the home page unless he belongs to a group that has home page access.
Limited Access is automatically assigned by SharePoint when a user or
group is provided unique access to a specific securable object. This
permission level cannot be customized or deleted.
The out-of-the-box or default permission levels for publishing sites include
Manage Hierarchy
allows users to create sites and edit pages, list items, and documents.
This permission level does not include permissions to approve items,
apply themes and borders or style sheets, or create groups. However,
this permission level is otherwise very similar to Full Control.
Approve
allows users to edit and approve pages, list items, and documents. You
will most likely use this permission only in publishing sites.
View
allows users to view pages, list items, and documents. Document types
with server-side file handlers can be viewed in the browser but not
downloaded.
Restricted Read
is designed to give users access to a specific list, document library,
item, or document without giving them access to the entire site.
Previous document versions and user rights information are not available
to people and groups with this permission level.
It is possible to create “custom” permission levels
based on business needs. Custom permission levels, like securable
objects that require unique security, will add complexity to the
maintenance of your security model. Some individual permissions have
dependencies, but in general, SharePoint will not allow you to delete an
individual permission from a permission level if other individual
permissions depend on it. With 32 individual permissions, you can see
that creating custom permission levels can get very complicated. If you
do create custom permission levels, be sure to carefully document and
describe what you have done and why you have created the custom levels.
Examples of possible “custom” permission levels that we have seen in
practice include
Editor (or Restricted Contributor).
For users who can upload and edit documents but cannot delete
documents. This custom permission level can help ensure that users
cannot accidentally delete a document but still have the capability to
upload and edit them. To create a custom Editor permission level, start
by creating a copy of the Contribute permission level and then remove
(uncheck) the Delete Items and Delete Versions permissions. Users
without delete permissions will not be able to edit the document Name
(file name) after uploading the document. If the Name needs to be
changed, a user with Contribute, Design, or Full Control permissions
will have to make any necessary changes to the Document Name. Users with
custom Editor permissions (add, change, but not delete) can edit other
metadata properties.
Manage Permissions. For users who need to manage permissions for the site or library but not necessarily have Full Control access.
By default, a user must have Full Control permissions to manage
security for a site. However, you may want to delegate the
responsibility for managing security to a user who should not have Full
Control access to the site. In this case, create a custom permission
level that starts with the Contribute set but adds
the Manage Permissions user permission. This custom permission level
will allow users to upload, edit, and delete documents and manage user
access without having full control. You’ll want to be careful about
creating this type of access because in addition to allowing a group
with this custom permission set to add and remove users from Groups,
they can also create new groups and change permissions on existing
objects. As with Full Control, only highly trusted and trained users
should have the ability to manage permissions on your site.
Use the following best practices for creating and managing permission levels:
If a custom permission level is needed for a SharePoint site collection, always start with an existing permission level and then either add to or delete from that set of permissions to create the custom permission level.
Try
to create short, meaningful names for each custom permission level and
be sure to add a description that summarizes what type of access is
associated with the permission level. In some cases, it is helpful to
prepend your organization’s name to customizations to have them stand
out as unique and personalized.
As a general rule, do not change the “default” permission levels.
Remember the saying “You touch it, you own it.” SharePoint does not
offer any indicator that shows alterations to native security levels. If
a similar permission level is needed and you are tempted to modify one
of the default permission levels, follow this process instead:
Start with a copy of that permission level and make a custom permission level.
After copying the default permission level, make additions or deletions to individual permissions.
