What follows are guidelines and recommendations for dealing with and managing security in
SharePoint.
You can control access to site and site content by assigning permissions to users or groups for a specific site or site content at the following levels within a site collection:
 Site

Library or list

Folder
 Document or item
You should understand the following concepts before designing your any permission plan.
 Permissions: Permissions grant a user the ability to perform specific actions. For example, the
View Items permission allows a user to view items in a list or folder, but not to add or remove items. Permissions can be granted to individual users at site or site content levels.
For information about available permissions, see User permissions and permission levels
(SharePoint Server 2010) .

Fine-Grained Permissions: Fine-grained permissions are unique permissions on securable objects that are at a lower level in a site hierarchy, such as permissions on a list or library, folder, or item or document. Fine-grained permissions allow for greater granularity and customization of user permissions in a site collection.

Permission Level: Permission levels are collections of permissions that allow users to perform a set of related tasks. For example, the Read permission level includes the View Items, Open
Items, View Pages, and View Versions permissions (among others), all of which are needed to view pages, documents, and items in a SharePoint site. Permissions can be included in more than one permission level.
Permission levels are defined at the site collection level and can be customized by any user or

group whose permission level includes the Manage Permissions permission. For more information about customizing permission levels, see Configure custom permissions (SharePoint
Server 2010) .
The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For information about default permission levels and the permissions included in each level, see User permissions and permission levels (SharePoint Server 2010) .
The individual permissions that collectively make up permission levels also have known and identified dependencies with one another. SharePoint enforces these dependencies when you modify permission levels using the SharePoint user interface.

SharePoint Group: A SharePoint group is a group of users that are defined at site collection level for easy management of permissions. Each SharePoint group is assigned a default permission level. For example, the default SharePoint groups are Owners, Visitors, and Members, with Full

Control, Read, and Contribute as their default permission levels respectively. Anyone with Full
Control permission can create custom groups.
 User: A user can be a person with a user account from any authentication provider supported by the Web application. We recommend that you assign permissions to groups rather than users, although you can directly grant individual users permissions to a site or specific content.
Because it is inefficient to maintain individual user accounts, you should assign permissions on a per-user basis only as an exception.

Securable Object: A securable object is a site, list, library, folder, document, or item for which permissions levels can be assigned to users or groups. By default, all lists and libraries within a site inherit permissions from the site. You can use list-level, folder-level, and item-level permissions to further control which users can view or interact with site content. You must first break the permission inheritance before you change or assign permissions for that securable object. You can resume inheriting permissions from the parent list or site at any time.
You can assign a user or group permissions for a specific securable object. Individual users or groups can have different permissions for different securable objects. The following diagram illustrates the relationships among permissions, users and groups, and securable objects.

Group Best Practices
It is very important to use groups whenever possible versus assigning permissions by a single user.
 Because people move in and out of teams and change responsibilities frequently, tracking those changes and updating the permissions for uniquely secured objects would be time-consuming and error-prone when using individual users. So use groups instead.
 Groups can also provide additional context to why the group member(s) have been given the
 permission level they have. If it is role based then the group name can indicate this, but the individuals name cannot indicate this context.
Rely on group membership instead of individual user membership in the scopes. For example, if a single group can be used in place of 1,000 users, the scope will be 999 membership entries smaller for the scope and any of its parent scopes which will be updated with Limited Access rights for that single group instead of all 1,000 individual users with Limited Access rights. This

additionally helps increase the speed of Limited Access rights push and ACL recalculation at the parent scope objects.
SharePoint Limits

There is a practical limit of 2000 users/groups given access that you should keep in mind.

There is a limit of 5k users/ad groups per SharePoint group.
There are many ways to make management of security easier. One of the most significant is fully understanding and planning for permission and security inheritance.
Permissions on securable objects within a site are inherited from the parent object by default. You can break inheritance and use fine-grained permissions — unique permissions on the list or library, folder, or item or document level — to gain more control of the actions users can take on your site.
Stopping inheriting permissions copies the groups, users, and permission levels from the parent object to the child object, and then breaks the inheritance. When permission inheritance is broken, all permissions are explicit and any changes to parent object do not affect the child object. If you restore inherited permissions, the child object will inherit its users, groups, and permission levels from the parent again, and you will lose any users, groups, or permission levels that were unique to the child object.
For ease of management, use permission inheritance wherever possible.
Author Note: If you choose to break inheritance and use fine-grained permissions, you should use groups to avoid having to track individual users. Because people move in and out of teams and change responsibilities frequently, tracking those changes and updating the permissions for uniquely secured objects would be time-consuming and error-prone.

It is much easier to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It becomes more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and others with inherited permissions. As much as possible, arrange sites and subsites, and lists and libraries so they can share most permissions. Separate sensitive data into their own lists, libraries, or subsites.
For example, it's much easier to manage a site that has permission inheritance as described in the following table.
Securable object Description Unique or inherited permissions
SiteA
SiteA/SubsiteA
SiteA/SubsiteA/ListA
Group home page
Sensitive group
Sensitive data
SiteA/SubsiteA/LibraryA Sensitive documents
Unique
Unique
Unique
Unique
SiteA/SubsiteB
SiteA/SubsiteB/ListB
Group shared project information Inherited
Non-sensitive data Inherited
SiteA/SubsiteB/LibraryB Non-sensitive documents Inherited
However, it is not as easy to manage a site that has permission inheritance as shown in the following table.
Securable object
SiteA
SiteA/SubsiteA
SiteA/SubsiteA/ListA
Description
Group home page
Sensitive group
Non-sensitive data
SiteA/SubsiteA/LibraryA Non-sensitive documents, but with one or two sensitive documents
SiteA/SubsiteB
SiteA/SubsiteB/ListB
Group shared project information
Non-sensitive data, but with one or two sensitive items
SiteA/SubsiteB/LibraryB Non-sensitive documents, but with a special folder containing sensitive documents
Unique or inherited permissions
Unique
Unique
Unique, but same permissions as SiteA
Inherited, with unique permissions at the document level
Inherited
Inherited, with unique permissions at the item level
Inherited, with unique permissions at the folder and document level
SharePoint Limits:

More than 1000 security scopes (unique/broken inheritance) will lead to performance degradation. This can be mitigated by using multiple ‘containers’ such as sites and site
 collections.
50k scopes per list/document library is a limit. In other words more than 50k unique permissions per list is a hard limit that SharePoint 2010 has built in.

It is important to understand when and why you should use an active directory group or a SharePoint group.
Managing users of SharePoint sites is easier if you assign permission levels to groups rather than to individual users. SharePoint group is a set of individual users and can also include Active Directory groups. In Active Directory Domain Services (ADDS), the following groups are commonly used to organize users:
 Distribution group: A group that is used only for e-mail distribution and that is not securityenabled. Distribution groups cannot be listed in discretionary access control lists (DACLs), which are used to define permissions on resources and objects.
 Security group: A group that can be listed in DACLs. A security group can also be used as an email entity.
You can use security groups to control permissions for your site by adding security groups to SharePoint groups and granting permissions to the SharePoint groups. You cannot add distribution groups to
SharePoint groups, but you can expand a distribution group and add the individual members to a
SharePoint group. If you use this method, you must manually keep the SharePoint group synchronized with the distribution group. If you use security groups, you do not need to manage the individual users in the SharePoint application. Because you included the security group instead of the individual members of the group, ADDS (Active Directory Domain Services) manages the users for you.
Authors Note: For ease of security management, do not assign permission levels directly to Active
Directory groups, and do not add security groups that contain nested security groups, contacts, or distribution lists whenever possible.
Decide Whether To Add Security Groups
Adding security groups to SharePoint groups provides centralized management of groups and security.
The security group is the only place where you manage individual users. Once you add the security group to a SharePoint group, you do not have to manage security group members in that SharePoint group. If a user is removed from the security group, the user will be automatically removed from the
SharePoint group.
However, using security groups in SharePoint sites does not provide full visibility of what is happening.
For example, when a security group is added to a SharePoint group for a specific site, the site will not appear in the users’ My Sites. The User Information List will not show individual users until they have contributed to the site. In addition, security groups with deep nested structure might break SharePoint sites.
Considering the previous advantages and disadvantages, here are the industry recommendations:

 For intranet sites that are broadly accessed by your users, use security groups because you do not care about the individual users who accessed the intranet site home page.

For collaboration sites that are accessed by a small group of users, add users directly to
SharePoint groups. In this case, there is more of a need to know who is a member so the group members know each other’s e-mail addresses and how to contact each other.
Determine Which Security Groups To Use For Granting Access To Sites
Each organization sets up its security groups differently. For easier permission management, security groups should be:
 Large and stable enough that you are not continually adding additional security groups to your
SharePoint sites.

Small enough that you can assign appropriate permissions.
For example, a security group called "all users in building A" is probably not small enough to assign permissions, unless all users in building A have the same job function, such as accounts receivable clerks.
This is rarely the case, so you should look for a smaller, more specific set of users, such as “Accounts
Receivable”.
SharePoint Groups vs Active Directory Groups
This table is meant to help summarize the advantages and disadvantages described earlier in this document.
• Not reliant on AD (if your AD is a mess)
• Distributed ownership and management options
• Managed by users
• Can be managed by the
SharePoint Object Model
• Members of these groups are visible to users in
SharePoint.
• Managed by domain administrators
• Available in many systems
• Centralized management and easier removal
• Only used in SharePoint
• Managed by (potentially) untrained users
• One more place to manage security (independent of AD)
• Cannot contain another
SharePoint group as a member.
• Difficult to determine permissions assigned to people
• Requires lots of planning
• Members of these groups are not visible in SharePoint.
• User can only be a member

of 1024 AD groups
(recursively).
Active Directory Group Recommendations
The following are general guidelines that will be followed when determining whether a SharePoint
Group or Active Directory Group should be created.

A great place to start looking for useful Active Directory Groups or potential SharePoint groups is your distribution lists.

If the group and its representative membership would be useful in other applications it should be created in Active Directory. There should be careful consideration for the longevity of the group when creating it within Active Directory. If it is extremely short term then this may indicate an exception should be made and it could be created in SharePoint instead.

In a general sense most Active Directories have the following collections of groups that can be used throughout SharePoint: o Department Specific – Example: Accounting
 Sub Department Specific – Example: Accounts Payable o Systems Specific – Example: SharePoint
 Specific System Usage – Example: SharePoint Administrators o Location Specific – Example: North America (this is dependent on organization size/reach)
 Sub Location – Example: United States

Sub Location – Example: Florida o Sub Location – Example: Miami o Position Level– Example: Executives, Directors, Managers, Entry Level, etc. o By Status– Example: Contract, Full Time, Part Time, etc.

For Cross Functional, Initiative, or Project related groups, most of the time, they should be created as SharePoint Groups. The general exception to this rule would be if the initiative was a long term one, or one with considerable strategic importance (where membership could be used in other systems, and where membership may have other important implications around group policies and things of that nature).
Author Note: There are many third party tools and vendor products that make maintenance, management and provisioning of permissions, users, groups, and security easier. It is highly recommended you evaluate these if you’re encountering significant costs from a management and resource standpoint dealing with security.

The organization will adhere to the best practice guidance provided in this authoritative whitepaper on the subject. http://www.microsoft.com/download/en/details.aspx?id=9030
Recommendations
We recommend that you use FGP (fine grained permissions) for only those business cases for which it is required. FGP can be expensive in terms of both operational oversight and performance.
If you must use fine-grained permissions, consider the following recommended practices:
Ensure that you do not have too many items at the same level of hierarchy in the document libraries, because the time necessary to process items in the views increases.
Avoiding Fine Grained Permissions
1.
Break permission inheritance as infrequently as possible.
2.
Use groups based on directory membership to assign permissions.
3.
Assign permissions at the highest possible level. As part of this strategy, consider the following techniques:

Use different document publish levels to control access. Before a document is published, the advanced permissions and versioning settings can be set for users who can only approve items in the document library.

For non-document libraries (lists), use the ReadSecurity and WriteSecurity permission levels.
When a list is created, the owners can set the Item-level permissions to either Read access

or Create and Edit access.
4.
Basically manage permissions by each SharePoint site uniquely (instead of at a fine grained level). So use the 3 built in groups or AD groups etc and set permissions at the web level.
5.
From another point of view, if you have a large list where you want to uniquely set permissions try having ‘more than one list’ in multiple webs to get around some of the performance impact involved (2k unique permissions per web as an example). It avoids a lot of the hierarchy performance hits outlined in that white paper.
6.
Using multiple site collections greatly reduces the issue. To keep it simple at a minimum an effective way would be doing it at the web level (or even list/library level before getting to the item level).
Managing Fine Grained Permissions With Security
Use event handlers to control edit permission. You can have an event handler that registers an event using the SPEventReceiverType.ItemUpdating and SPEventReceiverType.ItemUpdated methods, and then use code to control whether the update should be allowed. This is extremely powerful, because you can make security decision based on any metadata of a list or item, without affecting the view rendering performance.
Use AddToCurrentScopeOnly method to assign Limited Access membership within a SharePoint group.
The key element in this principle is to redesign the architecture so that scope membership does not cause ACL recalculation at the parent document library and Web.
This is mainly applicable if the cause of the excessive number of unique scopes was through an automated process such as an event handler or workflow that dynamically modified object permissions.
The recommendation in this case is to make a code change to whatever process was creating the unique security scopes.