Permissions and Security in SharePoint 2010

Microsoft SharePoint Server 2010 includes six permission levels by default. You can customize the permissions available in these permission levels (except for the Limited Access and Full Control permission levels), or you can create customized permission levels that contain only the specific permissions you need.

Although you cannot directly edit the Limited Access and Full Control permission levels, you can make individual permissions unavailable for the entire Web application, which removes those permissions from the Limited Access and Full Control permission levels.

The following tables from TechNet illustrate the various permissions for team and non-team sites:

Permission levels for team sites

Permission level	Description	Permissions included by default
Limited Access	Allows access to shared resources in the Web site so that the users can access an item within the site. Designed to be combined with fine-grained permissions to give users access to a specific list, document library, item, or document, without giving them access to the entire site. Cannot be customized or deleted.	Browse User Information Use Client Integration Features Open
Read	Allows read-only access to the Web site.	View Items Open Items View Versions Create Alerts View Application Pages Use Self-Service Site Creation View Pages Browse User Information Use Remote Interfaces Use Client Integration Features Open
Contribute	Create and edit items in the existing lists and document libraries.	Read permissions, plus: Manage Unsafe Content
Design	Create lists and document libraries and edit pages in the Web site.	Approve permissions, plus: Manage Lists Add and Customize Pages Apply Themes and Borders Apply Style Sheets
Full Control	Allows full control of the scope.	All permissions

If you use a site template other than the team site template, you will see a different list of default SharePoint groups. For example, the following table shows additional permission levels provided with the publishing template.

Permission levels for non-team sites

Permission level	Description	Permissions included by default
Restricted Read	View pages and documents. For publishing sites only.	View Items Open Items View Pages Open
View Only	View pages, list items, and documents. If the document has a server-side file handler available, they can only view the document by using that file handler.	Limited Access permissions, plus: View Items View Versions Create Alerts Create mobile alerts View Application Pages
Approve	Edit and approve pages, list items, and documents. For publishing sites only.	Contribute permissions, plus: Override Checkout Approve Items
Manage Hierarchy	Create sites; edit pages, list items, and documents. For Publishing sites only.	Design permissions minus the Approve Items permission), plus: Manage permissions View Usage Data Create Subsites Manage Web Site Manage Alerts

Unmanageable security is one of the primary factors which leads to "SharePoint Creep", as users create new sites when they are unsure of the current sites security level. The following guidance is intended to assist with creating a security model that is effective, scalable, and manageable.

1. Centrally create SharePoint security groups and add Active Directory (AD) groups to the SharePoint groups.
   

   By creating a SharePoint Security Group and then adding Active Directory (AD) groups to the SharePoint Group, you will essentially encapsulate any AD groups or individuals into one manageable container. This will help prevent "one off" security setting in which the administration time of trying to manage multiple groups or individuals is severely reduced as security is controlled at the container level. This is known as the "group within a group" approach for SharePoint security modeling. The groups should be created at the root of SharePoint Site Collection and then inherited down across sites. Break inheritance only when SharePoint groups should not have permissions to a site and need to be removed. If you break inheritance and create a new group, you have broken the centralization of your security model and lost a large portion of the capability to track which SharePoint groups have been created.

2. Avoid adding individuals. Use Active Directory groups instead.
   

   By adding groups from Active Directory to SharePoint, individuals still receive permissions and if they leave a group (ex. an employee changes from Marketing to Sales) they are automatically removed from the sites the group they belonged to had access to. If an individual is added, they will need to be removed at one a time from any SharePoint sites or objects they were given access to. Even if a group has only one individual, try to create a group so that security is set with a role based methodology (ex. there is only one person who undertakes quality control in the organization. They should be added to a Quality Control group with Active Directory, and then the AD Quality Control group should be added to the SharePoint Quality Control Group that has "Contribute" access to the Sales site).