Security Planning

SharePoint security is an area that can become a larger issue as times goes on if a security plan is not developed up front and constantly governed. A breakdown in security can cause unwarranted access to configuration options within SharePoint or potential access to content that is meant for only certain individuals or groups. A security lapse can cause user resentment with the environment and user adoption can suffer. The best way to ensure this does not happen is to understand the SharePoint default groups available within SharePoint and the different permission levels, and determine whether a custom group or permission level is needed. The process and policy for creating new permission levels and SharePoint groups should be documented within a security plan available to all end users.

Default SharePoint Permission Levels

SharePoint permission levels are the building blocks on which the SharePoint groups are created. The permission level is assigned to a group and therefore assigned to all users within that group. It's important to understand each permission level and what the user has the ability to do if assigned that permission level. By default, the following permission levels are available, if the publishing template is not used:

• Limited Access: Allows users to view a particular list of the document library without giving them access to the entire site. Users aren't typically added to this group directly, but indirectly from permission changes to an individual item in the list or site.
• Read: Allows users to view items on a page.
• Contribute: Allows users the ability to add, edit, or delete items on site pages or in lists and document libraries.
• Design: Allows users to change the layout of site pages through the browser or Microsoft SharePoint Designer 2010.
• Full Control: Includes all permissions.

If the publishing template is used, the following permission levels are available:

• Restricted Read: Allows users to view pages and documents.
• Approve: Allows users to edit and approve pages, list items, and documents
• Manage Hierarchy: Allows users to create sites, edit pages, and list items and documents.

SharePoint 2010 includes 33 different permissions, which are utilized in five default permission levels. For example, it's important to understand that permission levels such as “Contribute” or “Full Control” are associated with even more fine-grained groups of permissions. The best way to review the permissions assigned to the permission level is to go to the Site Permissions, select a permission level, and act as if you are going to edit the permissions. This will display the fine-grained permissions of the permission level. (See Figure 8-7.)

Figure 8-7. Contribute list permissions

If different permissions are needed for a particular permission level we recommend that a new permission level be created with these unique permissions. This will help eliminate confusion for administrators who try to assign the correct permission levels to SharePoint groups. The most common reason for creation of a new permission level is to create a contribute-like permission level that removes the delete capability. This reason, among many others, will be further discussed later in this chapter.

Default SharePoint Groups

Before creating a security plan or a governance plan around SharePoint security, you must understand the default SharePoint groups. It's also critical to understand the permission level assigned to each group. The SharePoint groups can be different depending on which site template is selected. If a team site template is selected, the groups described in Table 8-2 are available.

If a publishing template is selected, the groups shown in Table 8-3 are available.

A good practice is to make most users members of the Visitors or Members group. This will eliminate unwanted changes made to the structure, site settings, or appearance of the site. However, it is important to remember that a user that is in the Members group has delete privileges. SharePoint does not provide a default group that uses a permission level that provides the ability to create but removes the ability to delete. This type of functionality would require a custom permission level and a custom group. The reason to create a custom permission level and custom group will be discussed in the next section.

Besides the SharePoint groups described in the Tables 8-2 and 8-3, there are also SharePoint farm administrators and site collection administrators. The SharePoint farm administrators group allows for administration of SharePoint at the farm level, the highest level. This group should be very limited in users. The site collection administrators group allows for administration of SharePoint at the site collection level. Administrator at the site collection level allows for configuration of security groups, site structure, and appearance. This group should also be very limited in users.

Determine Need for Custom Permission Levels or Groups

The default groups and permission levels provide a framework that is solely used by some organizations or used as a foundation and built upon by other organizations. As described above, if these default permission levels or groups do not fit well with your organization, custom permission levels and groups can be created. While sticking with the permissions levels and groups provided out of the box, this cannot always be avoided.

Custom Permission Levels

If custom permissions are needed for a permission level, we recommend that a new permission level with the new permissions be created instead of changing the default permission level. Some common scenarios when a custom permission level is needed are as follows:

• Default permission level includes all permissions except one that is needed by a group of users
• Default permission level includes a permission that is not needed by a group of users

Be sure to give the new permission level a descriptive name and verbose description so that administrators and users understand what this permission level provides. However, these permission levels should be used with caution and precise permissions should be reviewed to ensure they satisfy exact needs before being assigned to a SharePoint group.

Custom SharePoint Groups

The need for custom SharePoint groups is more common, straightforward, and has less overall impact to the security of your site than custom permission levels. Some common reasons you might have for creating new SharePoint groups include the following:

• You need more or fewer roles within the organization than are available in the default groups.
• Your organization has well-known names for roles that perform different tasks.
• You want to create a direct mapping from a Windows security group or distribution list and the SharePoint group.
• You prefer different group names than the default names provided.

Custom SharePoint groups should be well documented and available to all administrators for use throughout the site. Microsoft provides a worksheet to document all custom permission levels and groups at http://go.microsoft.com/fwlink/?LinkID=213969&clcid=0x409.

Monitor SharePoint Security

SharePoint security can become very unwieldy very quickly, so it is important to monitor new permission levels and SharePoint groups that are created. The process of creating such items should go through a governing board to ensure these new items make sense within the environment. Check for sites that break inheritance of parent sites, as these too can become difficult to effectively govern. SharePoint 2010 provides visible notification if the site permissions break inheritance from the parent site. Limit the breaking of inheritance as much as possible; this is where security issues arise and things get out of hand. A good practice is to perform regular security audits of permission levels, SharePoint groups, and how they are being used in conjunction with Active Directory groups and distribution lists. Auditing security using the built-in tools or available third-party tools will make site administrators think twice before assigning a permission level to a group. This process should be fully documented in a Security Plan.