SharePoint 2010 : Securing Information - Securing Sites

The following sections discuss several security configurations that are applied at the site level.

1. Indexing Site and List Content

Security concerns itself with access to a resource. In SharePoint 2010, security can involve not only preventing access to a resource by a given set of users and/or group; it can also be used to create barriers that make finding the content more difficult. You will find that the Index Site and List Content configurations can be helpful in ensuring that a site and/or list content does not appear in the search results for SharePoint 2010.

To prevent a site from being indexed, navigate to the Site Settings link in your site and click the Search and Offline Availability link to open the Search And Offline Availability page (Srchvis.aspx). As you can see in Figure 1, you select the No option for the Allow This Site To Appear In Search Results configuration to ensure that the entire site’s content is not indexed and will not appear in the search results.

Note:

Use this configuration option carefully, because if you choose not to index the content of a site, users won’t be able to use the local Search feature to find local content.

At the list level, you can turn off indexing of individual lists by clicking the List Settings link and then clicking the Advanced Settings link. Among the various configuration options available is the setting to Allow Items From This List (Or Document Library) To Appear In Search Results. You can select either the Yes or No option (Yes is selected by default).

At both the list and the site levels (refer back to Figure 1), you will see the option to allow or deny Offline Client Availability. If you select the No option, the content of the site (or list) cannot be taken offline from the server. Because data breaches can occur when people unwittingly lose laptops or mobile devices while traveling or when they are otherwise not careful with information security when away from the office, disabling the offline capabilities of sensitive information provides another way to secure information in SharePoint 2010.

2. Site Permissions and Permission Inheritance

Site permissions and how permissions work in SharePoint 2010 are somewhat confusing topics, so the following sections simplify permissions for you, clearly illustrating what your users will need to know to successfully administer security in their sites. There are several parts to this discussion; first there is an overview of permission followed by a discussion of permission dependencies. Then you will learn about permission inheritance, followed by security groups, and then there is a discussion of using Active Directory groups in SharePoint.

2.1. Permission Overview

First, it is important to note that SharePoint only performs authorization of accounts to access resources. SharePoint does not perform authentication, which involves the creation of an access token that follows a user everywhere he goes on the network. This access token includes user’s name, the groups to which he belongs, his SID, and all of the SIDs for the groups to which he belongs. SharePoint then uses this information, in concert with the SharePoint specific permissions, to authorize or deny the user’s request for a given resource.

Note that these permissions cannot be broken down into more granular permissions. For example, the Add And Customize Pages site level permission includes the ability to add, delete, or change HTML pages or Web Part Pages and edit the website using a compatible SharePoint website editor. But you can’t use this permission to assign someone the ability to add and change pages but not delete them. This permission can’t be broken into smaller, more granular permission sets.

Now, some people might respond to this statement by saying that at the Web application layer, you can explicitly deny portions of this permission by employing the explicit Deny permission, and they would be correct. For example, you could explicitly Deny the Delete permission for a user or group of users, and then even though they might have that permission at the site collection or site level, the permission at the Web application layer would override the local permission and they would be unable to delete documents or list items.

But even at the Web application layer, you can’t break down the permissions to their component parts. So the Add And Customize Pages site level permission cannot be broken down into Add, Delete, or Change permissions—it’s all or nothing.

In SharePoint, these base permissions are grouped into permission levels that are then assigned to users and/or groups directly. Table 2 outlines which permissions are assigned to the more common permission levels that you’ll discover in SharePoint.

2.2. Permission Dependencies

The assignment of some permissions requires the assignment of other permissions. In other words, there are some permission dependencies that need to be understood if users are to effectively manage permissions and security for their sites. What follows is an outline of the permission dependencies in SharePoint 2010.

The Open permission has no other dependencies. This permission is included in every permission level. If you give only this permission to a user account, that user (in theory) will be able to open a website, list, or library to access the items in that site or list. However, this permission only grants access to the containers. Without additional permissions on the items within the site or container, the user will be denied access to the site or container. The Open permission affects the behavior of documents that have server-side handlers, such as .xls files when Excel Web Renderer is installed. Server-side handlers for a file type can be registered by adding a line to the Serverfiles.sml file in the SharePoint install location on the Web front-end server.

The View Pages permission, which grants the ability to view pages in a website, is dependent only on the Open permission. The combination of these two permissions will still not grant a user access to a site, because the permission to access content within the page or a list still has not been granted.

If you add the View Lists permission, which is dependent on the Open and View Pages permissions being granted, then the combination of these three permissions will grant a user access to a site, its pages, and its lists and the content items in the list. However, the combination of these three permissions is much less than is given in the View Only permission level. For example, if you combine these three permissions into a permission level that allows users to quite literally view—and only view—information, then they will be forced to view this information from the browser (since the ability to use remote interfaces such as SOAP or WebDav is not granted), and they will not be able to create alerts nor will they be able to view versions on the content items. If you have any application pages, under this permission set being discussed here, the user would not be able to view those pages. When viewing documents in a library, the user will see the documents and will be able to view and open them, but as you can see in Figure 2, the user will be able to perform limited actions on the document using the Ribbon after the document is selected. Those actions include

• E-mail a link to the document

• Download a copy of the document

• Use the Send To features

• View the document’s properties

• Use the social tagging features

The View Application Pages permission is dependent only on the Open permissions, and it also requires a View Items permission before the user can access anything in a site or list. The View Application Pages is for form pages and most of the application pages. Specifically, it controls the application pages that inherit from the LayoutsPageBases class. This is the right that, for example, is removed from the Anonymous user when the lockdown feature in turned on, so that Anonymous users cannot open application pages. Other permission dependencies for SharePoint permissions are outlined in Table 3.

For the most part, the permission dependencies are sparse, meaning that selecting one permission doesn’t involve selection of a complex set of other permissions. This gives you and your site owners a great deal of flexibility in combining permissions into permission levels that are useful for a given situation. It also means that you can create permission levels that are more “lean” in what is granted to the user. You need not rely on the default permission levels if you want a more secure experience than what comes out of the box. Finally, security teams and compliance officers should be made aware of the robust and effective permissions that can be applied to accomplish a particular task in SharePoint and should have confidence that SharePoint is a secure system when configured properly.

Note:

There are two things that no software company—not Microsoft or Sun or Oracle or Novell or any other company—can guard against when it comes to security. No matter how well any software developers might write security features into their products, the reality is that they cannot—through technology alone—help you guard against an untrustworthy administrator and an unwise administrator. Those charged with securing information should be well trained, so that they can make good security decisions, and they should be trustworthy, so that you know they are not disseminating information to those who should not see it.

The default permission levels that are provided in SharePoint 2010 are there to enable people to be productive and to use the product’s features as designed by the product team. The default groups are not there to ensure you have a highly secure experience. Instead, the groups represent the product team’s assessment of general roles and responsibilities across a broad range of organizations, both in size and industry vertical. This is why, in many scenarios, you’ll want to use the default groups when possible, but you should not be afraid to create new permission levels and assign them as needed to ensure that SharePoint is at the level of security needed for your environment.

2.3. Permission Level Inheritance

The site collection is the security boundary in SharePoint. Permissions within a site collection are inherited from the root site and, by default, all lists and pages inherit the same permission sets. Permissions can be broken at the site or list level so that unique permissions can be set at either level.

Note that for some templates, when the site is created, if a user chooses to use Unique Permissions, the creator is presented with a page (Figure 3) to create new security groups and populate them with user and/or group accounts. The Setup Groups For This Site page (Permsetup.aspx) allows you to create three new groups. But by default, the visitors group is configured to use the parent sites’ Visitors group. The creator will need to select the Create A New Group option to completely sever inheritance from the parent site.

The permission level inheritance is tied to user and group inheritance in SharePoint 2010. This is a change from SharePoint Server 2007, in which you could inherit or break inheritance for users and group and/or permission levels. When permission inheritance is broken, or if permissions are being assigned explicitly, as is the case for a root site of a site collection, then you’ll see check boxes next to the security groups and users, but not next to the permission levels. Figure 4 illustrates explicit permissions for a workspace that is a subsite in a site collection. Note the check boxes next to the security groups and the reminder in the Ribbon that “This Web Site Has Unique Permissions.”

Because this site is not inheriting permissions and it is a subsite in a site collection, there is an icon to Inherit Permissions in the Security Ribbon. If you click this icon and then follow the instructions on the page that displays, you can change the permissions of this site from explicitly set to inherited. Figure 5 illustrates this change.

One of the more confusing aspects of inheritance is the inheritance of permission levels. On a subsite that has broken inheritance, you will see a Permissions Level icon in the Security Ribbon. When you select that icon, the Permissions Level page will display. Note that in Figure 6, you can see that you are inheriting permission levels, even though you have broken inheritance for the security groups. You might be tempted to look for a way to stop permission level inheritance, but you won’t be able to do it through the user interface. However, permission level inheritance can be broken through the Object Model using custom code.

To break permissions between a site and a list, navigate to the list settings, click Permissions For This List, and then click the Stop Inheriting Permissions icon in the Security Ribbon. You can also use this same location to inherit permissions by clicking the Inherit Permissions icon in the Ribbon. These two icons—Stop Inheriting Permissions and Inherit Permissions—are context sensitive and will appear based on whether or not your site or list is inheriting permissions. For the root site in a site collection, that icon position will display a Grant Permissions icon, which you can use to grant permissions to a user or group.

Any time permissions are explicitly applied, you will see an icon labeled Check Permissions. Clicking this icon will present what is known as the “people picker” input box into which you will enter a user or group name and then click Check Now. SharePoint will show you, for the local site, all of the permissions for that user as well as how that user’s permissions were obtained. Figure 7 illustrates the Check Permissions dialog box.

2.4. Groups

Groups are used to assign permission levels to multiple users or Active Directory groups in a single administrative action. SharePoint groups can be populated with other SharePoint groups, individual user accounts, and Active Directory groups. Different site templates (which are really nothing more than pre-built combinations of features) will have different default security groups. Table 4 lists the default groups that install with the more common site templates. Note that for most templates, you will find that only the site owners, site members, and site visitors groups will be created.

The activation of some features will install additional security groups if they don’t exist at the time the feature is activated. For example, a Team Site template, by default, has four groups (refer back to Table 16-5) instantiated when the site is created (assuming it is not inheriting permissions from a parent site). When the SharePoint Server Publishing Infrastructure feature is activated, these additional security groups are created. In fact, this feature essentially “installs” the following security groups (unless they already exist).

• Approvers

• Designers

• Hierarchy Managers

• Restricted Readers

• Style Resource Readers

What is interesting is that if you activate and then deactivate this feature, the security groups that were created through the feature activation process will persist past the deactivation process. SharePoint security is built in such a way that after a group is created, you must manually delete it to remove it from the site.

SharePoint groups can be populated with Active Directory users and security groups. You cannot populate SharePoint groups with other SharePoint groups or with Active Directory distribution groups. When a SharePoint group is populated with an Active Directory group, all of the nested Active Directory groups will also be granted permissions to SharePoint through the SharePoint group. The people picker in SharePoint does not enumerate nested groups for the site owner’s consideration when adding an Active Directory group to a SharePoint group. This can represent a security danger because, by default, end users who are managing sites normally do not have access to Active Directory or a way to enumerate group memberships or a nested group chain in Active Directory. Best practice in this case is to purchase a third-party product that will plug into SharePoint and provide the additional security administration tools that end users need to effectively manage security for their sites.

Note:

MORE INFO Two third-party products that will accomplish this task for you are DeliverPoint (Lightening Tools) and ControlPoint (Axeler). Be sure to include one of these tools in your budget when you plan your SharePoint deployment, because these tools are invaluable in security management at the site level.

Permission levels can be applied directly to Active Directory user or group accounts without first adding the users or groups to a SharePoint group. The base SharePoint permissions cannot be applied to either an Active Directory user or group or to a SharePoint group without first being grouped into a permission level. To assign a permission level directly to an Active Directory user or group, click the Site Actions menu and then click Site Permissions. Click the Grant Permissions icon in the Ribbon, select the Grant Users Permission Directly option (Figure 8), and then select the combination of permission levels you want to assign to this user and/or group.

To grant permissions to Active Directory users and/or groups within a SharePoint group, from the Site Permissions page, click the link of the group you want to populate and then use the people picker to find the users and/or groups you need to assign to the SharePoint group. When you have finished, those users and/or groups will have the SharePoint group’s permissions to the site or list.

2.5. Using Active Directory Groups for SharePoint Security

It is common in IT teams to assume that SharePoint will be secured through the use of Active Directory security groups. Some people think that this method gives the IT department more control over who is being granted permissions in SharePoint as well as that it is easier to use an Active Directory group to assign permissions once instead of having the site owner assign the same permissions (potentially) multiple times through individual account permission assignments.

Except for those sites that have wide audiences, such as the intranet or a divisional portal, however, it is a best practice to allow site owners to populate their SharePoint groups with user accounts and not group accounts.