Plan site security (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2008-12-09

In this article:

• About site security elements

• About assigning permissions

• About fine-grained permissions and permission inheritance

• Choose which levels of site security to use

• Plan for permission inheritance

• Worksheet

This article addresses planning for access control and authorization at the site collection, site, and subsite levels, and does not address planning for the security of your server or server farm. For more information about planning for other aspects of security, such as authentication methods and encryption, see Plan site and content security (Windows SharePoint Services).

Site security is controlled by assigning permissions to users and groups for a specific securable object (such as site, list, or item). When you plan for site security, you need to decide:

• To what degree you want to control permissions for individual securable objects. For example, do you want to control access for the entire site, or do you need specific security settings for a particular list, folder, or item?

• How you want to categorize and manage your users (by using groups). This article covers the essentials of site security and assists you as you determine the securable objects at which to apply specific permissions. For more information about categorizing users into groups, see Choose which security groups to use (Windows SharePoint Services).

  Note

  The way that groups and permissions interact has changed significantly from the previous version. In the previous version, site-level groups were used to contain both users and permissions — that is, when you added a user to a site group, you automatically determined the permissions that the user was granted for a site. In this version, the concepts of groups of users and permissions have been separated: SharePoint groups at the site collection level contain the users, permission levels contain the permissions, and groups have no permissions until they are assigned a permission level for a specific securable object (such as a site, list or library, folder, item, or document).

About site security elements

Regardless of what type of site you are creating, the security for your site includes the following five elements:

• Individual user permissions   Individual permissions that grant the ability to perform specific actions. For example, the View Items permission grants the user the ability to view items in a list. Farm administrators can control which permissions are available for the server farm by using the User Permissions for Web Application page in Central Administration. (To get to this page, on the Application Management page, under Application Security, click User permissions for Web application.) For information about available permissions, see User permissions and permission levels.

• Permission level   A pre-defined set of permissions that grants users permission to perform related actions. The default permission levels are: Limited Access, Read, Contribute, Design, and Full Control. 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 read documents, items, and pages of a SharePoint site. Permissions can be included in multiple permission levels. Permission levels can be customized by anyone assigned to a permission level that includes the Manage Permissions permission. For information about default permission levels and which permissions are included in them, see User permissions and permission levels.

• User   A person with a user account that can be authenticated through the authentication method used for the server. You can add individual users and directly assign a permission level to each user; users do not have to be part of a group. We recommend that you assign permissions to groups rather than users. Because it is inefficient to directly maintain user accounts, you should only assign permissions on a per-user basis as an exception. For more information about user account types, see User permissions and permission levels.

• Group   A group of users. Can be a Windows security group (such as Department_A) that you add to the site, or a SharePoint group such as Site Owners, Site Members, or Site Visitors. Each SharePoint group is assigned a default permission level, but the permission level for any group can be changed as needed. Anyone assigned a permission level that includes the Create Groups permission (included in the Full Control permission level by default) can create custom SharePoint groups.

• Securable object   Users or groups are assigned a permission level for a specific securable object: site, list, library, folder, document, or item. By default, permissions for a list, library, folder, document, or item are inherited from the parent site or parent list or library. However, anyone assigned a permission level for a particular securable object that includes the Manage Permissions permission can change the permissions for that securable object. By default, permissions are initially controlled at the site level, with all lists and libraries inheriting the site permissions. Use list-level, folder-level, and item-level permissions to further control which users can view or interact with the site content. You can return to inheriting permissions from a parent list, the site as a whole, or a parent site, at any time.

About assigning permissions

You can assign a user or group a permission level for a specific securable object (site, list, or item). Individual users or groups can have different permission levels for different securable objects.

The following diagram illustrates how users and groups are assigned specific permission levels for a particular securable object.

About fine-grained permissions and permission inheritance

You can use fine-grained permissions (permissions on the list or library, folder, or item or document level) to more precisely control what actions users can take on your site. The following securable objects are available for permission assignments:

• Site   Controls access to the site as a whole.

• List or library   Controls access to a specific list or library.

• Folder   Controls access to a folder's properties (such as the name of the folder).

• Item or document   Controls access to a specific list item or document.

Permission inheritance and fine-grained permissions

By default, permissions within a site are inherited from the site. However, you can break this inheritance for any securable object at a lower level in the hierarchy by editing the permissions (creating a unique permission assignment) on that securable object. For example, you can edit the permissions for a document library, which breaks the inheritance from the site. However, the inheritance is broken for only the particular securable object for which you assigned permissions; the rest of the site's permissions are unchanged. You can return to inheriting permissions from the parent list or site at any time.

Permission inheritance and subsites

Web sites are themselves a securable object to which permissions can be assigned. You can configure subsites to inherit permissions from a parent site or create unique permissions for a particular site. Inheriting permissions is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, that set of permissions is shared. This means that owners of subsites that inherit permissions from the parent site can edit the permissions of the parent. If you want to change permissions for the subsite alone, you must stop inheriting permissions and then make the change.

Subsites can inherit permissions from a parent site. You can stop inheriting permissions for a subsite by creating unique permissions. This copies the groups, users, and permission levels from the parent site to the subsite, and then breaks the inheritance. If you change from unique permissions to inherited, then users, groups, and permission levels start being inherited, and you lose any users, groups or permission levels that you uniquely defined in the subsite. Permission levels can also be inherited (and they are, by default), such that the Read permission level is the same, no matter what object it is applied to. You can break that inheritance by editing the permission level. For example, you might not want the Read permission level on a particular subsite to include the Create Alerts permission).

Choose which levels of site security to use

When you create your permission structure, it is important to find the balance between ease of administration, performance, and the need to control specific permissions for 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. As with any server or Web site, it is also important to follow the principle of least privilege when it comes to authorizing access to the site: Users should have only the permission levels they need to use. Begin by using the standard groups (such as Members, Visitors, and Owners) and controlling permissions at the site level for the easiest administration experience. Make most users members of the Visitors or Members groups. Limit the number of people in the Owners group to only those users whom you want to allow to change the structure of the site or change site settings and appearance. By default, users in the Members group can contribute to the site, adding or removing items or documents, but cannot change the structure of the site or change site settings or appearance. You can create additional SharePoint groups and permission levels if you need more control over the actions that your users can take.

If there are particular lists, libraries, folders, items, or documents that contain sensitive data and must be even more secure, you can grant permissions to a specific group or individual user. Be aware, however, that there is no way to view all of the permissions specific to lists, libraries, folders, items, or documents within a site. This means that it is difficult to quickly ascertain who has permissions on which securable objects and also difficult to reset any fine-grained permissions in bulk.

Plan for permission inheritance

It is easiest to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It gets more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and some 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 illustrated in the following table.

Comparatively, it is not so easy to manage a site that has permission inheritance as illustrated in the following table.

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/?LinkId=73136&clcid=0x409)