SharePoint Security: The Fundamentals of Securing SharePoint Deployments
Brien Posey
Even an inexperienced administrator can deploy Microsoft Office SharePoint Server 2007 within a matter of hours. Chances are, though, that while the basic deployment would indeed be functional, it probably wouldn’t be configured for optimal security. SharePoint Server 2007 is one of those applications that’s easy to install, but tough to do so properly.
What makes security so challenging is that SharePoint 2007 is a monolithic product that tries to be all things to all people. SharePoint 2007 is a Web application, but you can also think of it as a collaboration tool, a document server or even a development framework. The abstract and highly customizable nature of SharePoint is what makes it tough to secure.
As you’ve probably already figured out, there’s no magical solution to securing SharePoint. Every SharePoint deployment is unique, so a one-size-fits-all solution just isn’t practical. However, there is a basic approach that will work for all deployments.
If you’ve ever created a SharePoint site, you know SharePoint was designed to be modular, with building blocks you can use to create SharePoint sites, site collections, lists, libraries, and so on. And when it comes to security, you can use this modular nature to your advantage.
The idea is to focus on securing the individual components of your SharePoint deployment. The modular nature of SharePoint means your deployment typically requires many individual SharePoint servers. Thus, if you want your deployment to be secure, you must configure these individual servers to be secure.
SQL Server
All the data contained in SharePoint lists and libraries is stored in an underlying SQL Server database, which also stores most of the SharePoint configuration settings. Clearly, properly securing your SQL Server is essential.
Smaller organizations often install SQL Server and SharePoint on the same server to reduce server hardware costs. But deploying SQL Server and SharePoint on a common machine is a bad idea from a both a security and a performance standpoint.
One of the most fundamental concepts in IT security is to minimize a server’s attack surface. If SQL and SharePoint reside on the same server, that server is going to have a rather large attack surface. So, my first recommendation is to run SQL Server on a dedicated machine. If a dedicated SQL Server is beyond your organization’s budget, consider using server virtualization to isolate SQL and SharePoint.
It’s also a good idea to disable any unused services and components. A basic SharePoint deployment uses SQL Server’s database engine, the SQL Server Agent, and the SQL Server browser components. More advanced installations may require Full Text Indexing, Analysis, or Reporting services.
How do you decide what to disable? Microsoft provides a tool called the SQL Server Surface Area Configuration Tool (shown in Figure 1) that can help with the process. This tool is designed to analyze your SQL Server implementation and disable anything that isn’t being used. You should run this utility after you get SharePoint up and running.
To access the tool, choose the SQL Server Surface Area Configuration option from the server’s Start | All Programs | Microsoft SQL Server 2005 | Configuration Tools menu.
.png "SQL Server surface area configuration tool")
Figure 1 The SQL Server Surface Area Configuration Tool can help you figure out which components and services you can disable.
You should also carefully consider the authentication method you select for SQL Server security. Though you could choose either mixed mode or Windows Authentication Mode, you should configure your SQL Server to use Windows authentication whenever possible. Windows mode is more secure than mixed mode because it uses the Kerberos security protocol during the authentication process. Moreover, Windows authentication uses domain user accounts, so any password policies you have established within your Active Directory remain in effect.
Service Accounts
One of the biggest security mistakes administrators make when deploying SharePoint 2007 is that they don’t properly configure the service accounts. If you have ever installed SharePoint 2007, you know there are several points during the deployment and configuration processes where you are asked to provide a service account.
Administrators all too often create a single service account and use it throughout the SharePoint installation process. Although the resulting SharePoint server is functional, this approach is risky from a security standpoint.
The problem is that whenever you provide SharePoint with a service account, the designated account is granted rights to perform the task at hand. SharePoint provides the account with just enough permissions to do its job, nothing more. But if you use the same service account multiple times throughout the deployment process, you end up with an account with excessive permissions because it receives additional rights each time you use it. Someone could then run code on a SharePoint server that exploits these excessive rights and gain control over the server.
There’s a lot of contradictory information about how to structure the accounts SharePoint uses. It has become difficult to even confirm the recommended best practices. Still, if you are performing a basic SharePoint deployment, using a minimum of five separate accounts is advisable.
It’s also advisable to create a special user account solely for the purpose of installing SharePoint and SQL Server. It is common practice for administrators to log in using either their own personal account or the domain administrator account when deploying SharePoint. Using an existing account can be a mistake from a security prospective, because that account will be granted additional rights to complete the setup process.
If you decide to use a dedicated account for installation, you must make the account a member of the local Administrator’s group on each of your SharePoint servers. You must also make the account a member of the SQL Server Logins group, which will let the account log into your SQL Server instance.
Finally, you’ll need to assign the account the SQL Server Database Creator and SQL Server Security Administrator roles on your SQL Server. These roles give the accounts permission to create and modify databases and manage the SQL Server’s security. These special permissions are the basis of the recommendation to use a dedicated user account.
Besides creating an account specifically for the SharePoint installation process, you’ll have to create a few other service accounts:
Database Access Account. This is the account SharePoint will use to communicate with the SQL Server database.
SharePoint Search Service Account. The SharePoint Search Service will use this account to write content index files to the index server, and to replicate the index information to any query servers that exist in the farm.
Content Access Account. This account is used to crawl content within a specific Shared Service Provider. In some cases, you may need to create multiple content access accounts so that multiple content sources can be crawled individually.
Application Pool Service Account. Worker processes within IIS use this account. Web applications within the pool must have a way of accessing SharePoint content databases, and the Application Pool Identity account facilitates this process.
SQL Server Service Account. SQL Server also requires a service account, and you should use a dedicated account for this purpose.
More advanced SharePoint deployments may require the use of additional service accounts. The Related Content section at the end of this article includes a link to a TechNet article that provides detailed information on some of the other service accounts you may need.
Naming Conventions
By now you can see that you’re going to have to create a lot of accounts before you even begin deploying SharePoint. One trick for ensuring a smooth deployment is to decide on a naming convention for your service accounts before you create them.
There are different approaches you can use in establishing a service account naming convention, but there are a few basic rules you should follow. It is advisable to make the names as descriptive as you can, and take the time to document the chosen names and their intended purposes. For example, you might call the SharePoint Search Account something like SPT_Search.
The reason for not spelling out SharePoint has to do with some legacy limitations. Windows allows usernames in excess of 100 characters, but at one time usernames were limited to sixteen characters. Occasionally unexpected problems crop up with longer usernames due to legacy hardware or software. While it’s rare, it has happened so it’s better to stick to shorter names.
Keep in mind that while I’ve recommended using descriptive service account names, and it certainly makes life easier for administrators, doing so doesn’t always provide optimal security. Service accounts make good targets for hackers because they have greater permissions than normal user accounts. They often also have static, unchanged passwords. That being the case, you may want to consider camouflaging your service accounts. If you do, be sure to document the service account names and functions.
Encrypting Traffic
When it comes to planning a SharePoint deployment, administrators spend a lot of time designing the server architecture. One element that is sometimes overlooked is Public Key Infrastructure (PKI).You need to have PKI in place before deploying SharePoint so you can properly encrypt SharePoint traffic. HTTP traffic between SharePoint servers and end users needs to be SSL-encrypted (using HTTPS).
Likewise, traffic between SharePoint servers should be encrypted using IPSec. Both types of encryption are dependent on certificates and on an underlying PKI infrastructure.
These security best practices are by no means comprehensive. They are, however, a good starting point you can use to ensure that your SharePoint installation is as secure as possible.
Brien Posey*, MVP, is a freelance technical author with thousands of articles and dozens of books to his credit. You can visit his Web site at** brienposey.com*.
Related Content
· Plan for administrative and service accounts (Office SharePoint Server)