SharePoint 2010 : Planning Your Security Model - Defining and Documenting SharePoint Security

This section describes a process you can use to work through the steps required to properly secure your site (or site collection). We recommend that you complete and document your security model before actually creating groups or assigning permission levels in a site collection. The following are the steps described in this process:

Step 1.	List and describe where unique security is required.
Step 2.	List and describe who needs access.
Step 3.	List and describe the permission levels.
Step 4.	Define and create the SharePoint Security Groups you need.
Step 5.	Apply security permissions.

Step 1: List and Describe Where Unique Security Is Required

A well thought out security model is crucial for the successful assignment of security in any SharePoint site collection. To simplify the ongoing management of security of each site collection, it is important to determine which parts of a site collection have common security requirements and which parts have unique requirements. This should happen in a review of security with your business sponsor. You need to carefully consider the implications of “over-securing” content. If every site is locked down for Read access, it will be hard to achieve your knowledge management objectives. Also remember that SharePoint security is inclusive—you need to fully understand the requirements associated with protecting highly secured content and know what should never happen (for example, security breaches).

As you think about creating the permission structure for each site collection, you need to carefully balance the ease of maintaining and administering the security model with the need to control specific permissions for individual securable objects. As a general rule, try to manage security at the site level. If there are particular items that contain sensitive information that must be even more secure than the site as a whole, you can apply security to individual securable objects. But remember, applying detailed security permissions at the object level can be a very time-consuming task. SharePoint 2010 includes the capability to identify how permissions have been assigned in your site collection , but “unpacking” permissions is a group by group, site by site, object by object process, so the more complex your model, the more complex it will be to examine and maintain security. You will not be able to tell just by looking at a document library or site whether unique security has been applied (without the use of third-party administration tools)—you will have to examine the settings for the object or group to see how it has been secured. This is why it is easier to maintain security at the site level: You have only one place to look when you need to understand how security has been applied.

Consider each part of a site when determining the security assignments for the top level site, the subsite, and document libraries and lists. Document the overall site security model and note the parts that require unique security levels. One way to initially document the security that will need to be applied is to start with the site architecture diagram and add a visual indicator to define where unique security is needed. There are several tools you can use to create a site architecture diagram, including PowerPoint or Word if the diagram is not very complex. Figure 1 shows a simple site architecture diagram that includes an indicator (the words UNIQUE or INHERIT) to show where unique security permissions will be applied.

Figure 1. Site architecture diagram with security indicator

Notice that the Discussion Board on the home page is in bold. This is a visual cue that the Discussion Board will have different security than the rest of the home page—all employees have Read access to most of the content on the home page, but they can contribute to the Discussion Board. The same would be required for surveys. You could also create a “node” in your diagram for each object in the site and use dotted lines or different colors to indicate where unique security is required. Planning security is an iterative process, and you may find that you need a more text-based approach to evolve your model. The remaining examples show a series of tables you can use to design and document your security model. Table 1 shows an example of the first level of your security model for an intranet—where you describe each securable object and document whether it needs unique or inherited permissions. Starting with a table like the one shown in Table 8-3, facilitate a conversation with the business sponsor about the types of permissions that are needed for the site. In general, a similar approach can be used to prepare the security model for an extranet (that is, externally accessible site for content presentation or collaboration with partners or customers), but more care would be required to define shared and exclusive partner/client areas.

Table 1. Sample Security Table

Securable Object	Description	Unique or Inherited Permissions
Home	Top level site in the hierarchy	Unique
	Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the page
Home/Discussion Board	Discussion board on the home page that anyone can contribute to	Unique
Home/Subsite for Team A	Subsite for just the Finance Team	Unique
Home/Subsite for Team B	Subsite for the Marketing Team where only a few people will edit	Unique
Home/Subsite B/Document Library 2	Private library where Marketing Department will work on documents before everyone else in the company can see them	Unique
Home/Subsite for Team C	Subsite for Human Resources where all users can Read but only members of HR can edit	Unique

Note that this example assumes a home page where a small number of individuals can contribute content but a large number can read content. The home page is a site where the primary purpose is communications. On the home page, there is a discussion board that every user can contribute to even though they only have Read permissions for the rest of the content on the home page. We use this example in the description of the security planning process in the remaining steps in this section. As we go through the steps, we expand the columns in the table. At the end of the steps, we will have documented our security model for this site collection.

When planning security keep in mind the following:

• Security of each object is inherited from its parent unless inheritance is explicitly broken. For example, by default, every object (for example, list or library) on a site has the same security as the site itself. If a user has Contribute access to the site, they have Contribute access to every object on the site. Similarly, if a user has Contribute access to a document library, she has Contribute access to every document in the library unless unique permissions have been applied to a document.

• Permissions from the parent can be reapplied if previously broken. However, any special permission levels that were previously created at the object level will be removed when permissions from the parent are reapplied.

Given these characteristics, think about the following regarding security as the site is designed:

• Try to design the site to allow assignment of permissions at the site level.

• If security at the object level is required, consider security for an entire object (an entire list or library, for example) before securing individual items. This may mean creating a second document library (or a folder within a library) if you need unique permissions for a particular group of documents.

• Always consider navigation. If you assign unique security to a nested subsite, you must ensure that the user has a navigation path to it. That is, if a user has access to a subsite but does not have any access to the parent site he/she will have no way to get to this site. This is why it is good practice to examine your security model from the top down (that is, home page to lowest level subsite) then in the reverse (lowest level site back to home page).

Step 2: List and Describe Who Needs Access

The next step is to carefully consider who needs access to a site collection or part of a site collection. The easiest way to document this is to add columns to the table created in Step 1 to identify who needs what type of access to each securable object in the site collection. This is shown in Table 2.

Table 2. Sample Security Table with Access Defined

Securable Object (level in the site hierarchy)	Description	Unique or Inherited Permissions?	People or Roles that Need Access	What Do These Users Need to Do?
Home	Top level site in the hierarchy Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the page	Unique	Entire Company Members of the Marketing Team Fred and Sally	Read Contribute content Design or manage the entire site collection
Home/Discussion Board	Discussion board on the home page that anyone can contribute to	Unique	Entire Company	Contribute content
Home/Subsite for Team A	Subsite for just the Finance Team	Unique	Members of the Finance team	Contribute content
			John (Site Owner for this site)	Design or manage this site
Home/Subsite for Team B	Subsite for the Marketing Team where only a few people will edit	Unique	Members of the Marketing Team Bob, Jane, Seth Sarah (Site Owner for this site)	Read Contribute content Design or manage this site
Home/Subsite B/Document Library 2	Private library where Marketing Department will work on documents before everyone else in the company can see them	Unique	Members of the Marketing Team	Contribute content
Home/Subsite C	Subsite for Human Resources where all users can read but only members of HR can edit	Unique	Entire Company Members of the HR Team	Read Contribute content

This step may require several revisions as the plan is reviewed with key stakeholders for the site and as the site design evolves. It should account for expected functional growth and anticipated security changes.

Step 3: List and Describe the Permission Levels

Next, evaluate the out-of-the-box permission levels to ensure that that they meet your needs. As described earlier, permission levels are the collection of individual permissions that describe what users can and cannot do with the securable objects on a site. You can use a table structure like that shown in Table 3 to describe the permission levels needed for your site. In our scenario, we do not need any custom permission levels, but you can use the example in Table 3 as a reference.

Table 3. Permission Levels for this Site

What Are the Permission Levels for This Site?	Describe Each Permission Level
Full Control	Administrator rights—all permissions.
Design	Create lists and document libraries, edit pages and apply themes, borders, and style sheets in the site.
Contribute	Add, edit, and delete items in existing lists and document libraries.
Read	Read-only access to the site—view items and pages, open items, and documents.
Manage Permissions	CUSTOM: Create and change permission levels on the site and assign permission to users and groups.
Editor	CUSTOM: View, add, and edit items or documents in lists, document libraries, and discussion comments; cannot delete items.

Step 4: Define and Create the SharePoint Security Groups You Need

Create a custom SharePoint Group when there is a group of users in a site collection that need different permission levels in different areas of the site where it will be confusing to call the group Members in one part of the site and Visitors in another or where it is not possible or practical to create a Domain Group for these users. When you create a custom SharePoint Group, it is best to choose a group name with a business-oriented name—such as Marketing Team—rather than a permission-oriented name like Member or Visitor. Create your custom SharePoint Groups at the top level of the site with no permissions. Then, add specific permission levels to the custom group at the specific securable objects where unique access is needed within the site collection.

For simple sites and most team sites, you can begin by using the default SharePoint Groups (which are [Site Name] Owners, [Site Name] Members, and [Site Name] Visitors) and assign permissions at the site level. In our example, by examining the security requirements, we decide that we want to create a custom SharePoint Group called Marketing because we want to create a clearly named group of people that we can maintain as a group but assign different permission levels to this group depending on the securable object within the site. Whether or not you use custom or default security groups, you will generally follow a model similar to the inverted triangle shown in Figure 2. In general, you should assign users only the permissions they need to do their jobs.

Figure 2. Assign users only the permissions they need to do their jobs

Most of your users will belong to a group with Read permissions. Fewer users will belong to groups with Contribute permissions. Do not add every user as a member of the [Site Name] Owners SharePoint Group. Only a few users should have Full Control privileges. Because Full Control users can change other’s permissions, it is easy to lose control of the site if too many people have Full Control permissions. Do not confuse business ownership of a site with the default security group called [Site Name] Owners. In most cases, the business executive who is the “owner” or sponsor of the site is not going to have Full Control privileges for the site. Use the naming best practices described earlier to name the custom security groups you create for your site.

SharePoint allows you to quickly give everyone in your company access to a site collection by assigning Read privileges to “all authenticated users.” Before doing this, think about the impact. This gives everyone with credentials Read access. This may include contractors, consultants, and other temporary help. If this is not appropriate, you will need to adjust your security application. This would hold true for other areas of your intranet like a Human Resources site or an employee directory.

Step 5: Apply Security Permissions

Security is assigned from the perspective of the securable object. Therefore, in the last step of the process, permissions and objects that need security are combined with any existing Domain Groups and Default or Custom SharePoint Groups.

In this step, extend the security table to include the securable objects requiring unique security (from Step 1), the security group name (owners, members, visitors from this Step 4), the permission level (from Step 3), and the people who need access (from Step 2) in a table similar to Table 4. This complete security table example is shown in Table 4. Note that as a best practice, you should save your security plan and any other administrative documents for your site in a secure document library only visible to users with Full Control or Design privileges.

Table 4. Sample Complete Security Model

Securable Object	Description	Unique or Inherited Permission	Security Group	Permissions Level	Who Is in This Group?
Home	Top level site in the hierarchy Everyone in the company can see the home page, but only the people in the marketing department can edit most content on the page	Unique	Home Visitors Home Members Marketing Team	Read Contribute Contribute	AD Group for the entire company or AD group that contains employees only. No one—so this default group can be deleted. People who work in Marketing. Users are added and maintained by the Site Owner in SharePoint.
			Home Owners	Full Control	Fred (IT Resource). Sally (SharePoint Super User).
Home/Discussion Board	Discussion board on the home page that anyone can contribute to	Unique	Discussion Board Visitors	Read	Not explicitly used—Read access inherited from parent.
			Discussion Board Members	Contribute	AD Group for the entire company.
			Discussion Board Owners	Full Control	Not explicitly used—inherited from parent.
Home/Subsite for Team A	Subsite for just the Finance Team	Unique	Team A Site Visitors	Read	No Visitors for this site—need to remove permissions for the “parent” Visitors group when this site is created.
			Team A Site Members	Contribute	Individual members of the Finance team added to this “default” SharePoint Group for this subsite. There is no need to create a custom SharePoint Group for the Finance Team because they only have unique privileges on this one site.
			Team A Site Owners	Full Control	John (Team Leader or Project Manager).
			Home Site Owners	Full Control	Inherited from the parent level, includes Fred and Sally. It’s usually a good idea to share this group across all subsites and ask the subsite owner not to remove permissions for this group on an individual subsite.
Home/Subsite for Team B	Subsite for the Marketing Team where only a few people will edit most of the content	Unique	Marketing Team	Read	People who work in Marketing. Set up and managed at the top of the site collection. Note that the “parent” SharePoint Groups will be removed from access for this subsite because it is an exclusive, private site for the Marketing Team.
			Team B Site Members	Contribute	Bob, Jane, Seth (Implementers, Content Creators).
			Team Site B Owners	Full Control	Sarah (Site Owner for this site).
			Home Site Owners	Full Control	Inherited from the parent level, includes Fred and Sally.
Home/Subsite B/Document Library 2	Private library where Marketing Department will work on documents before everyone else in the company can see them	Unique	Marketing Team Team Site B Owners Home Site Owners	Contribute Full Control Full Control	People who work in Marketing. Sarah (Site Owner for this site)—inherited from subsite. Inherited from the parent level, includes Fred and Sally.
Home/Subsite C	Subsite for Human Resources where all users can Read but only members of HR can edit	Unique	Entire Company HR Team Home Site Owners	Read Contribute Full Control	AD Group for the entire company. Members of the HR Team. Inherited from the parent level, includes Fred and Sally.

In this example, two custom SharePoint Groups are created for Marketing and HR because these groups of people have different levels of access in different areas of the site collection. For all other securable objects, the default groups created by SharePoint are used. In addition, we explicitly removed permissions for any security group that was initially inherited from the parent (top level) site but should not have permissions for the uniquely secured object.