SharePoint Security 101: What You Need to Know to Secure SharePoint

For most organizations, a healthy security stance is essential to protecting and preserving Microsoft SharePoint content. Depending on your industry, you might even be bound by regulations that require you to secure and audit access to some content.

Certainly, security is a broad topic that involves not only SharePoint farm administrators, but server, network, and database admins as well. Through delegation to site collection admins and site owners in the business units, security also involves day-to-day end users.

To effectively enforce business-driven information-management policies, collaboration with the business is also necessary.

In response to the vast number of interested security stakeholders, SharePoint 2010 offers a flexible security model that supports multiple authentication types and multiple levels of permission authorization.

But this flexibility has a downside: Without a clear, published strategy for how permission management should be performed in your organization, security chaos can make day-to-day usage quite painful.

With all these variables, it's no wonder that security can become a complex equation.

Rest assured that armed with a clear understanding of your security requirements, some technical guidance, and bit of common sense, you can build a security model that is both effective and sustainable.

In this three-part series, we aim to provide you with this technical guidance -- and we'll throw in some best practices for good measure.

In this article, I'll start off with the basics, provide you with several step-by-step procedures, and make sure that you have a good overall understanding of the SharePoint authorization model. The focus will be on the farm and work through web applications and site collections, down to individual sites, lists, libraries, and items. In Part 2, Kevin Laahs will focus on claims-based authentication; in Part 3, Todd Klindt will talk about hardening your SharePoint servers.

SharePoint's Logical Hierarchy

Before we get into setting permissions, let's review the basic terminology of a SharePoint environment. A SharePoint farm refers to all the servers (i.e., web front end, application servers, and database servers) that work together to provide a SharePoint service to users. Within the farm, a structured hierarchy organizes content, as Figure 1 shows. The purpose of this hierarchy is to organize and secure the vast amount of content within SharePoint.

 
Figure 1: SharePoint's logical hierarchy

Securing the Farm

Despite the enormous responsibility that it implicates, securing the farm is quite a simple process. Permissions are mostly cut and dried: You're either a farm admin, or you aren't. A farm admin has full control over the farm, including managing web applications, starting and stopping services, backing up or restoring the farm -- effectively, any task that can be found in Central Administration, SharePoint's web-based administration interface. A farm administrator can also grant anyone access to any and all content within SharePoint. Indeed, the farm admin role is a powerful one, and you should be cautious about who is granted this level of access.

Farm administrator access is granted by adding Active Directory (AD) users or security groups to the farm administrators group within Central Administration:

1. Within Central Administration, click Security and then select Manage The Farm Administrators Group.

2. Add or remove AD users or groups as needed.

Security note: To perform certain administrative tasks such as creating web applications, you also need to be a local Windows administrator on the web server (or servers) that run the Central Administration web application.

Granting PowerShell Access

Although Central Administration is commonly used for many day-to-day operations, Windows PowerShell is an incredibly powerful way to administer and automate SharePoint functions from a command-line interface. (To learn more about using PowerShell with SharePoint, see " Using Windows PowerShell to Manage SharePoint 2010 " and " SharePoint Administrators Can Learn to Love PowerShell .")

To grant permissions for others to run PowerShell commands, use the Add-SPShellAdmin cmdlet. This command grants necessary permissions on SharePoint servers, the configuration database, and (optionally) a SharePoint content database. If you run this command without specifying a database, then the user is granted access to the farm only, not to any content databases. To grant a user the ability to run all cmdlets within a content database (e.g., to use Get-SPWeb to return a site), use the -database switch to grant the user access to the content database.

Security note: To use the Add-SPShellAdmin cmdlet to grant PowerShell access, you must be a farm administrator, a local administrator on the server on which the command is run, and a security admin on the database server (or servers) to which you are granting permission.

Securing a Web Application

A web application is a user's entry point into SharePoint. Specifically, a web application consists of one or more Microsoft Internet Information Server (IIS) websites that control how users are authenticated (or not authenticated, if you allow anonymous access). Organizations commonly have multiple web applications to isolate certain types of content or sets of users, such as a Record Center or extranet, respectively. When granting permissions to a web application, the sole purpose is to control who has access to the content within the site collections that are associated with the web application. In other words, you cannot grant permissions to administer a web application; only farm admins can do that, and they have administrative control over all web applications.

To adjust permissions to content within a web application, change the user policy for the web application. You can make this change in Central Administration:

1. Within Central Administration, click Application Management.

2. Select Manage Web Applications.

3. Highlight the web application and click the User Policy button in the Ribbon.

4. Add or deny permissions, as needed.

Security Note: Because permissions can also be set for individual site collections (which I cover in the next section), permissions aren't usually granted this way. This method is very powerful and is used for special purposes. For example, you might decide to use it to grant read-only access to auditors, to ensure that they have access to all site collections in the web application. Furthermore, this web application policy is the only method for denying someone access to SharePoint. This setting takes precedence over any other permission that is granted. Also, none of the permissions that you grant here are visible at a lower level. For example, a site collection administrator can't see who has been granted permissions through the web application policy. Again, this method of setting permissions is powerful but potentially confusing and dangerous -- so use it with caution!

Allowing Anonymous Access

Anonymous access allows non-authenticated (i.e., guest) users to access a SharePoint web application. Anonymous access is commonly used for Internet-facing sites but can also be used for intranets. Anonymous access can be enabled whether you use claims or classic authentication. Here's how you enable anonymous access:

1. Within Central Administration, click Application Management.

2. Select Manage Web Applications.

3. Highlight the web application and click the Authentication Providers button in the Ribbon.

4. Select the zone. (A zone allows you to expose a web application with a unique URL. You can have as many as five zones per web application. All zones have access to the content databases and site collections that are associated with that web application.)

5. Select the Enable Anonymous Access check box and click Save.

Security note: By default, anonymous users have no access to site collections until that permission is granted. Therefore, after anonymous access has been enabled, you must set which permissions anonymous users have. (I cover this topic in the Grant Anonymous Access section of this article.)

Securing a Site Collection

Although you can grant permissions to multiple site collections through the web application policy, save this method for special circumstances. Users are authenticated at the web application level and authorization is typically performed at the site collection level. In other words, for regular, day-to-day permission management, you should assign permissions via site collections.

By default, permissions are inherited or cascade down to all websites, lists, libraries, folders, and items in the site collection hierarchy. Thus, permissions that are granted to the top-level site also apply to a document buried deep within a site collection. As you'll learn, this inheritance can be stopped.

The highest level of access within a site collection belongs to the site collection administrator. This user has implicit access to all SharePoint content (e.g., sites, lists, libraries, items) within the site collection, whether or not permission is specifically granted. Through Central Administration, a farm admin can specify up to two site collection administrators for each site collection. Within each site collection, however, a site collection administrator can add additional admins as needed.

You grant regular users (i.e., non-administrators) access through the site collection. In fact, each site collection is administered separately, making these collections very convenient administrative units that can be delegated out. Because administration occurs from within the site collection (and not Central Administration), administrative tasks are often assigned to trained business users, empowering them to be somewhat self-supporting. Of course, depending on your site collection architecture, this administrative boundary can become a challenge. For example, if you need to grant access to multiple site collections, that access must be granted one collection at a time for each user or group of users.

Security Note: If a user tries to access a site to which they don't have permissions, of course they get an access denied error. But you can have the user request access from this error page. To learn more, see " How to Manage SharePoint Site Access Requests."

Understanding SharePoint Groups

Like many other systems, SharePoint uses the notion of groups to simplify the assignment of permissions to multiple users. Note that SharePoint groups are specific to a site collection. Thus, you cannot use one SharePoint group to span multiple site collections. Again, this can be a blessing (when you want administrative separation) or a curse (when you don't). Also, SharePoint groups can't be nested, meaning that you can't place one SharePoint group within another. Some of these limitations don't apply to AD security groups, however. For example, you can assign one AD group permissions to multiple site collections. To better understand your options, here are the different ways permissions within a site collection can be granted:

You assign permissions to users or groups by granting permission levels. Each site collection has its own built-in set of permission levels; you might be familiar with some of them (e.g., Full Control, Design, Contribute, Read). You can also create custom permission levels for more granular control over the granted access. Here are the steps to grant permissions within a site collection:

1. Within the site collection, go to the Site Actions menu and select Site Permissions.

2. On the Ribbon, click the Grant Permissions button.

3. In the dialog box, select individual users, SharePoint groups, or AD security groups.

4. Specify whether you want to add these users to a SharePoint group or to grant permissions directly. (Note: If you selected one or more SharePoint groups in step 3, you can only grant permissions directly.)

5. Optionally, send these users a welcome email.

When creating a new SharePoint group, you can also assign permissions to the group. Doing so makes permission assignment easy because you need only add users into the group. You can create new SharePoint groups from the same Site Permission screen on which you grant permissions.

Security note: When creating a new site collection, three default SharePoint groups are created automatically: owners (who have Full Control access), members (who have Contribute access), and visitors (who have Read-Only access).

Permission Inheritance

By default, permissions that are set for the top-level site within a site collection apply to all content in the site collection hierarchy (as Figure 1 shows). This concept is called permission inheritance and it helps to simplify permission management.

You can no doubt think of cases in which you need to establish unique permissions for a certain level. For example, you might want to protect a subsite and ensure that only managers have access. Within SharePoint, you can stop this permission inheritance on four different objects within the site collection: sites, lists/libraries, folders, and items. When you stop inheriting permissions, you can establish a unique ACL for that object, which then cascades to lower levels. This gives you a great deal of flexibility to mold a specific set of permissions around your content. However, be careful: The more you stop inheritance, the more complex permission management becomes over time. Another troublesome side effect of stopping inheritance too often is that it can drastically affect SharePoint's performance. As a general rule, stopping inheritance should be the exception, and you are encouraged to structure your sites, libraries, and folders accordingly. Figure 2 depicts an example of permission inheritance.

Figure 2: Permission inheritance in action 

The basic steps to stop inheritance and assign permissions are the same, regardless of the object type. For a site, use the Site Permissions link in the Site Actions menu. For a list or library, use the list's or library's settings page. For a folder or item, use the object's context menu, sometimes called the edit control block. If inheritance is stopped on an object, you can revert back to inherit, but any custom permissions that you applied will be lost.

Security note: Despite your best efforts, permission management can still spiral out of control. Another way to alleviate this is to have a good governance plan that gives administrative end users clear guidance about how to use groups and when or if to stop inheritance. Another option is to use third-party software such as AvePoint's DocAve Administrator, which can help manage permissions across the whole farm in one operation. Tools like this also help enforce a security policy as defined in a governance plan.

Granting Anonymous Access

If the web application is configured to allow anonymous access, you can adjust which permissions an anonymous user receives:

1. Access the permissions page for the object, as described in the previous section.

2. If necessary, click the Stop Inheriting Permissions button in the Ribbon. (You can't adjust anonymous access on an object that inherits permissions from its parent.)

3. In the Ribbon, click the Anonymous Access button.

4. Choose the permissions to grant to anonymous users. The available permissions will vary depending on the type of object.

5. Click OK to save.

Wrapping Up

Hopefully, this security overview wasn't too painful and served as a useful refresher for those who have a SharePoint background. By now, you should understand SharePoint's authorization capabilities and some of its limitations. You've learned how to define farm and PowerShell administrators, adjust a web application's user policy, and configure each of the four permissionable objects (i.e., site, list/library, folder, and item) within a site collection. I've also given you some quick steps to enable anonymous access and set anonymous permissions. In the next article of this series, Kevin Laahs will focus on authentication, specifically the claims-based authentication support in SharePoint 2010. Until then, be safe and secure.