You have to carefully examine your SharePoint structure and spend some time planning to come up with the most effective security posture.
Adapted from “Pro SharePoint 2010 Governance” (Apress)
SharePoint security can become a larger issue as time goes on if you don’t develop and constantly govern an effective security process up front. A breakdown in security can cause unwarranted access to SharePoint configuration options or potential access to content that’s meant for only certain individuals or groups. Security lapses not only have financial or legal repercussions, but can also cause user resentment and reduced user adoption.
The best way to ensure this doesn’t happen is to understand the default groups available within SharePoint and the different permission levels. Then determine whether a custom group or new permission level is needed. You should document the process and policy for creating new permission levels and SharePoint groups within a security plan available to all end users.
SharePoint permission levels are the building blocks upon which you create SharePoint groups. 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 you don’t use the publishing template:
If you do use the publishing template, you’ll have the following permission levels available:
SharePoint 2010 includes 33 different permissions spread across five default permission levels. It’s important to understand, for example, 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’re going to edit the permissions. This will display the fine-grained permissions of the permission level.
If you need different permissions for a particular permission level, you should probably create a new permission level 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 to create a new permission level is to have a contribute-like permission level that removes the delete capability.
Before developing a security plan or a governance plan around SharePoint, 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.
You should 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’s important to remember that users in the Members group have delete privileges. SharePoint doesn’t provide a default group that uses a permission level with the ability to create, but not the ability to delete. This type of functionality would require a custom permission level and a custom group.
There are also SharePoint farm administrators and site collection administrators. The SharePoint farm administrators group allows for SharePoint administration at the farm level -- the highest level. This group should be extremely limited in users. The site collection administrators group allows for SharePoint administration at the site collection level. This level allows for configuring security groups, site structure and appearance. This group should also be limited in users.
Some organizations just use the default groups and permission levels. Others used them as a framework or foundation on which to build. If these default permission levels or groups don’t fit well with your organization, then by all means you should create custom permission levels and groups.
If you need custom permission levels, you should create a new permission level with the new permissions, instead of changing the default permission level. Some common scenarios that require a custom permission level include:
Be sure to give the new permission level a clear name and written description so you and your other administrators will understand what this permission level provides. Use these permission levels with caution. Review the precise permissions to ensure they satisfy your exact needs before assigning them to a SharePoint group.
The need for custom SharePoint groups is more common, and has less of an overall impact to the security of your site than custom permission levels. Some common reasons for creating new SharePoint groups include:
You should carefully document your custom SharePoint groups and make them available to all administrators for use throughout the site. Microsoft provides a worksheet to document all custom permission levels and groups.
Your SharePoint security status can become unwieldy extremely quickly, so it’s important to monitor new permission levels and SharePoint groups as they’re created. The process of creating these levels and groups items should go through the governance board to ensure they’re needed within your environment.
Check for sites that break the 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 your staff is using them in conjunction with Active Directory groups and distribution lists. Auditing security using the built-in tools or available third-party tools will make your site administrators think twice before assigning a permission level to a group. You should fully document these processes in your Security Plan.
Corey Erkes is a manager consultant for Sogeti USA in Omaha, Neb. Erkes has worked with a wide range of companies at different points in the lifecycles of their SharePoint implementations. He’s also one of the founding members of the Omaha SharePoint Users Group.
©2012 Apress Inc. All rights reserved. Printed with permission from Apress. Copyright 2012. “Pro SharePoint 2012 Governance” by Steve Wright and Corey Erkes. For more information on this title and other similar books, please visit apress.com.