Plan site security (Office SharePoint Server)
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
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
Subsite scripting
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 (Office SharePoint Server).
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 (Office SharePoint Server).
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.
Note
Because it is inefficient to directly maintain user accounts, it is recommended that you use group permissions as much as possible. Particularly if you are using fine-grained permissions (see the following section), you should use groups to avoid having to track individual user accounts. People can move in and out of teams and change responsibilities frequently, and you do not want to have to track all of those changes and continually update the permissions for uniquely secured objects.
The following diagram illustrates how users and groups are assigned specific permission levels for a particular securable object.
.gif "Specific permission levels")
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.
Microsoft Office SharePoint Server may disable output caching if a site collection contains more than 10,000 unique Access Control lists (ACLs). Users may experience slower performance when they try to access the site content. For more information about caching, see Caching in Office SharePoint Server 2007.
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.
| 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 |
Comparatively, it is not so easy to manage a site that has permission inheritance as illustrated 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 |
Subsite scripting
If your environment requires the highest level of content and site isolation, it might be beneficial to design your Office SharePoint Server site structure in a way that minimizes the risks associated with using contiguous URL namespaces. The default Office SharePoint Server site URL namespace configuration could allow a possible subsite scripting issue, in which a malicious user can perform actions on a site that are beyond the permission level that the user has been granted. The issue exists because Office SharePoint Server sites are security boundaries, any number of which can be adjacent to each other under the same host name. Because Web browsers only consider host names (and not sites) to be security boundaries, content containing scripts that reside on one Office SharePoint Server site could, under certain circumstances, be run on other sites if they are under the same host name.
Office SharePoint Server authorizes access to content based on an authenticated user’s rights and group membership. Because of this, a script that runs on behalf of a user can effectively perform any action that the user is permitted to perform. The potential issue is described in the following example:
User A and user B each have their own Office SharePoint Server site collections: http://my/sites/UserA, and http://my/sites/UserB.
User A has contributor permissions on his own site, but he has no permissions on User B’s site. When User A browses to User B’s site, he gets an Access Denied error.
However, User A can upload a document to his site that contains a malicious script and give User B read access to it. If User B views the document User A created, the malicious script could run without warning using User B’s credentials. In the context of many available Web browsers, the script is not crossing a security boundary, and running the script is not considered a cross-domain event.
The issue exists because User B’s Office SharePoint Server site and User A’s Office SharePoint Server site are under the same host name. In this site structure, User B and User A must be able to trust each other to not attempt to perform a scripting attack. If groups of contributors cannot trust each other, their sites should be partitioned across separate host names. The scripting issue is of most concern in Office SharePoint Server collaboration scenarios, rather than Internet publishing or structured portal scenarios, because the malicious user must have contributor access to perform a subsite scripting attack.
As Office SharePoint Server use grows, especially intranet use in large organizations, and as multiple users within organizations become contributors to some part of a path-based deployment (for example, http://my or http://corp), the ability to trust all contributors to that host can be challenging. This is particularly true in scenarios where self-service site creation is used, and where subsites become deeply nested. You can design your Office SharePoint Server deployment to minimize these concerns. For information about designing information architecture, see Determine the information architecture of your site.
For information about designing Office SharePoint Server site collections, sites, and subsites, see Determine sites and subsites.
For additional security guidance, see Security Resource Center for SharePoint Products and Technologies (https://go.microsoft.com/fwlink/?LinkId=148056).
Using host-named site collections
Using host-named site collections enables you to increase site and content security by supporting the creation of multiple root-level site collections within a single Web application. For example, administrators for hosting organizations can use host-named site collections to create multiple domain-named sites. Windows SharePoint Services 3.0 supports the creation of multiple domains in a single Web application. This enables you to place multiple domains, such as http://UserB.collab.mycorp.com and http://UserB.collab.mycorp.com, in separate site collections within the same Web application. However, you need to consider the following issues when using this approach to manage the subsite scripting issue:
Using friendly host names, such as http://UserB.collab.mycorp.com, can cause DNS issues because you need to point all friendly host names to the correct Office SharePoint Server deployment. Fully qualified domain names can mitigate this issue by enabling the use of wild card DNS entries, such as *.collab.mycorp.com.
Office SharePoint Server includes support for the self-service creation and management of path-based site collections. Deploying host header named sites can create an operational burden for site provisioning. For more information on self-service site creation, see Configure self-service site creation.
For more information about host-named site collections, see Plan for host-named site collections (Office SharePoint Server).
Moving content to a separate host name
If you have existing content that you want to move to a separate host name, consider the following guidelines:
You can move small amounts of content, including document libraries and lists, using client features such as Send To, Other location, Open with Explorer View (for documents), or Export to Spreadsheet (for lists).
To move larger amounts content, including sites and site collections, consider backing up and restoring your content. For information on backing up and restoring your content, see Back up and restore site collections by using built-in tools (Office SharePoint Server 2007).
For larger amounts of data, consider creating a new site collection using a different host name.
Consider creating a managed path at the same level as the site of the original location to host the site collection. By defining a managed path, you can specify which paths in the URL namespace of a Web application are used for site collections. This is important because Office SharePoint Server content uses server-relative paths in many cases. While restoring content to a new location, Office SharePoint Server can repair the host name of a URL, but a level mismatch at this point can result in a failure of the restore operation. For more information about managed paths, see Define managed paths.
Worksheet
On the Site and content security worksheet (https://go.microsoft.com/fwlink/?LinkId=73135&clcid=0x409), fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.