Plan site permissions (SharePoint Server 2010)

Článek
11/30/2016

Applies to: SharePoint Foundation 2010, SharePoint Server 2010

This article helps you plan access control at the site collection, site, subsite, and site content (list or library, folder, item or document) levels. This article also describes the concepts about permission inheritance and fine-grained permissions.

This article does not address planning the security of your entire server or server farm. For more information about planning other aspects of security, such as authentication methods and authentication modes, see Plan authentication methods (SharePoint Server 2010).

In this article:

About site permissions
About permission inheritance
Plan for site permissions
Plan for permission inheritance
Worksheet

Introduction

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

Before developing your plan for site and content access, you should consider the following questions:

To what granularity do you want to control permissions for the site or site content? For example, you might want to control access at the site level, or you might need more restrictive security settings for a specific list, folder, or item.
How do you want to categorize and manage your users by using SharePoint groups? Groups do not have any permission until they are assigned a permission level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site content inherit those permission levels.

For more information about using groups to help manage permissions, see Choose security groups (SharePoint Server 2010).

About site permissions

You should understand the following concepts before designing your permissions 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).
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.

Specific permission levels

About permission 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. For more information about the best practices for using fine-grained permissions, see Best practices for using fine-grained permissions

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. When you remove a user’s permissions, that change will affect the child object. We propagate the delete regardless of the status of inheritance. 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.

Tip

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.

Plan for site permissions

When you create permissions, you must balance the ease of administration and performance against the need to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content.

Use the following guidelines to plan site permissions:

Follow the principle of least privilege: Users should have only the permission levels or individual permissions they need to perform their assigned tasks.
Use standard groups (such as Members, Visitors, and Owners) and control permissions at the site level.
- Make most users members of the Members or Visitors groups. By default, users in the Members group can contribute to the site by adding or removing items or documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which means that they can see pages and items, and open items and documents, but cannot add or remove pages, items, or documents.
- Limit the number of people in the Owners group. Only those users you trust to change the structure, settings, or appearance of the site should be in the Owners group.
Use permission levels rather than assign individual permissions.

Note

You can create additional SharePoint groups and permission levels if you need more control over the actions that your users can take. For example, if you do not want the Read permission level on a specific subsite to include the Create Alerts permission, break the inheritance and customize the Read permission level for that subsite.
Microsoft SharePoint Foundation 2010 and SharePoint Server 2010 use Check Permissions to determine a user or group’s permissions on all resources within a site collection. You can now find both the user's directly assigned permissions and the permissions assigned to any groups of which the user is a member by checking permissions for a specific site or site content.

Plan for permission inheritance

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	Group home page	Unique
SiteA/SubsiteA	Sensitive group	Unique
SiteA/SubsiteA/ListA	Sensitive data	Unique
SiteA/SubsiteA/LibraryA	Sensitive documents	Unique
SiteA/SubsiteB	Group shared project information	Inherited
SiteA/SubsiteB/ListB	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	Description	Unique or inherited permissions
SiteA	Group home page	Unique
SiteA/SubsiteA	Sensitive group	Unique
SiteA/SubsiteA/ListA	Non-sensitive data	Unique, but same permissions as SiteA
SiteA/SubsiteA/LibraryA	Non-sensitive documents, but with one or two sensitive documents	Inherited, with unique permissions at the document level
SiteA/SubsiteB	Group shared project information	Inherited
SiteA/SubsiteB/ListB	Non-sensitive data, but with one or two sensitive items	Inherited, with unique permissions at the item level
SiteA/SubsiteB/LibraryB	Non-sensitive documents, but with a special folder containing sensitive documents	Inherited, with unique permissions at the folder and document level

Worksheet

Use the following worksheet to fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance.

-
Site and content security worksheet (https://go.microsoft.com/fwlink/p/?LinkID=213970&clcid=0x409)

Sdílet prostřednictvím