SharePoint 2010 is easily one of Microsoft’s most complex products, and the task of securing SharePoint can be...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
overwhelming. Even so, there are some relatively simple steps you can perform that will go a long way toward improving the overall security of your SharePoint deployment and ensuring the sensitive data it contains is protected.
Step 1: Limit permissions
One of the most common SharePoint security problems is users receiving excessive permissions. The principle of least privileges should be used any time a user is being granted access to SharePoint. Unfortunately, users are often given excessive permissions, either because it is easier for an administrator to assign blanket permissions over granular permissions, or because the administrator does not truly understand the SharePoint permissions model.
To give you a more concrete example, imagine a specific user needs to be able to manage a large group of sites, sub-sites, lists, and libraries. In that type of situation, the easy thing to do would be to make the user a site collection administrator. Unless the user requires the ability to manage every site within the entire site collection however, then making the user a site collection administrator grants the user excessive permissions. Unfortunately, there are no shortcuts to making sure SharePoint permissions are assigned in an appropriate manner. If you already have a SharePoint deployment in place, then a comprehensive audit is required in order to verify nobody has excessive permissions.
Although it is extremely important to assign users the least permissions within SharePoint, it’s also important to remember that using a solid permissions model within SharePoint alone is not enough. SharePoint is an application that has other dependencies. In order for SharePoint to be secure, its dependencies must also be configured securely. Specifically, this means granting users the least permissions at the Active Directory level and assigning users permissions to SQL Server only if absolutely necessary.
Step 2: Harden SharePoint servers
One of the most important steps an administrator can take toward securing SharePoint is server hardening. Server hardening is the process of reducing your server’s attack surface. To start, isolate the various SharePoint server roles from one another. SharePoint Server 2010 consists of three primary server roles: The Web server role, the application server role, and the database server role. Although SharePoint will allow you to install all of these roles to a single server, it is better from a security standpoint to use dedicated servers for each role.
In the not too distant past, the idea of SharePoint Server role isolation was considered to be cost-prohibitive for smaller organizations because of hardware and software licensing costs. Today, server virtualization makes it possible to isolate the various roles from one another without having to spend a fortune on server hardware. Licensing costs are also reduced in a virtual environment since the Enterprise and Datacenter editions of Windows Server are licensed for use on multiple virtual machines.
Although role isolation is a good first step, it isn’t enough by itself. In order to truly harden your SharePoint servers you must reduce the server’s attack surface to the point that only the services that are absolutely necessary are running.
The first rule of attack surface reduction is that each server (physical or virtual) should be dedicated to one sole purpose. In other words, if a server is acting as a SharePoint application server, then you shouldn’t also try to use the server as a file server, domain controller, etc. The server should run SharePoint and SharePoint only.
Of course, there are exceptions to this philosophy. In most cases, there are certain support apps that need to run on production SharePoint servers, such as antivirus and backup agents. Running these types of applications on your SharePoint Server is perfectly acceptable and in the case of antivirus software, critically important.
Once you have made sure your SharePoint servers are not running any unnecessary software, it is a good idea to disable or remove any unnecessary server roles, features, or system services. Fortunately, Microsoft provides a list of the services required for each of the SharePoint roles.
Another way to harden your servers is to configure SQL Server to listen on non-standard ports. By default, SQL Server listens on TCP port 1433 and UDP port 1434. The fact that these ports are well-known and used consistently makes them a prime target for attack. As such, Microsoft recommends blocking UDP port 1434 and TCP port 1433. After doing so, you can configure SQL Server to listen on a different port. Of course, you will also have to make SharePoint aware of the alternate port assignment as well; organizations can refer to Microsoft’s instructions for this.
Step 3: Use dedicated service accounts
One of the biggest security blunders administrators make with regard to SharePoint is the misuse of service accounts. During the initial setup, the administrator is prompted to supply service accounts for SharePoint to use; the specifics vary depending upon how SharePoint is being installed.
From a security perspective, it’s critical to use a dedicated service account for each function. When you supply a set of service account credentials for SharePoint to use, SharePoint will assign special permissions to the account that enable it to be used for the task at hand. Normally, SharePoint will only provision the account with the bare minimal permissions required for performing the task at hand.
The problem occurs when you use the same service account for multiple purposes. Doing so causes the service account to begin to accumulate permissions that exceed those required to perform any one single task. Service accounts that have been provisioned with excessive permissions could potentially be exploited.
At a minimum, Microsoft recommends administrators who are setting up a SharePoint farm use three service accounts. Those accounts are:
- SQL Server Service Account -- This can be either a local system or a domain account, but for multi-server SharePoint deployments, domain accounts tend to work best. The service account is used for the MSSQLSERVER and the SQLSERVERAGENT services. If you are deploying a named instance of SQL server, then the service account will be used for services that correspond to that named instance.
- Setup User Account -- The Setup User Account is used with SharePoint’s Setup Wizard and the SharePoint Products Configuration Wizard. This must be a domain account and it must have administrative permissions on the server on which setup is run. Furthermore, the account must be added to the SECURITYADMIN and DBCREATOR roles that are found within SQL Server.
- Server Farm Account -- This account is used to manage and configure the SharePoint farm. It is also used to run the Microsoft SharePoint Foundation Workflow Timer Service and to act as the application pool identity for the SharePoint Central Administration website. The account must be a domain account. The account you specify is automatically added to SQL Server and given the DBCreator, SecurityAdmin, and DB_Owner roles within SQL Server.
It’s important to remember that comprehensive SharePoint security consists of far more than these three steps. Other steps to consider include having a patch management solution in place, running the Best Practices Analyzer on a regular basis, and placing your SharePoint servers behind an application firewall.
About the author:
Brien M. Posey is an eight time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox. Send comments on this article to firstname.lastname@example.org