Securing Sensitive Documents in SharePoint

Introduction

If you are considering building a portal where users can access sensitive documents such as paystubs, financial statements, or medical records, a proper security model must be put in place. Whether building a portal for employees, customers, business partners, or job applications, a robust security model is a necessity given the potentially catastrophic impact of sensitive data leaking out. In the past, lax security or security breaches have resulted in disgruntled employees, loss of confidence in IT, or legal action.

Microsoft Office SharePoint Server 2007 (MOSS) or Windows SharePoint Services 3.0 (WSS) are popular options for implementing a portal. SharePoint’s strength lies in the diversity of the functionality provided in a single solution. That is, by natively integrating Enterprise Content Management, Enterprise Search, Collaboration, Workflow, and Business Intelligence, SharePoint opens the door to creative solutions while leaving worries about basic integration and feature details behind.

Although SharePoint has many new security features that allow site owners to implement very granular security settings for documents in their document libraries, these features easily can result in an administrative nightmare if not governed appropriately. Within SharePoint, administrators can maintain users or groups, assign permissions, and define permission levels, just as they do in Microsoft Active Directory (AD) or some other Lightweight Directory Access Protocol (LDAP) directory service. Adding SharePoint to a corporation’s list of supported platforms easily may lead to user sprawl where uninhibited site growth can cause skyrocketing administrative needs, so a properly defined governance plan is recommended to keep this from getting out of control. Even though SharePoint Governance is important and a fascinating topic, the focus here is on security and maintainability.

The solution for security and maintenance proposed here leverages AD’s strengths in managing identities, groups, and relationships together with SharePoint’s strengths in managing documents within libraries. But, this solution may be optimal only where SharePoint’s current security options, as described below, do not suffice.

Existing Solutions for Securing Documents in SharePoint

SharePoint has a number of built-in options for securing documents that may provide value to you, depending on your needs. These options include audience targeting and item level security. You could even consider writing custom code.

Audience Targeting

MOSS 2007 has a feature that allows you to enable audience targeting (although this is not available in WSS 3.0). Turning on this feature means any items in a list or library can be set to appear only for a particular audience. An audience can be defined as a SharePoint group, distribution list, security group, or a global audience. The advantage of this feature lies in showing a group of users only relevant information, as opposed to overwhelming them with less relevant information. For example, a company may have a list of all new employees, perhaps including some trivia and background information. Audience targeting permits administrators to show a list of only those employees that joined a particular business unit, and only the primary identification information. The disadvantage of audience targeting is that users are not prevented from seeing the entire list, by selecting a different view or URL hacking, unless item-level security is applied.

Item-Level Security

This feature enables users to set specific security on each item in a list or library. This means that, as items are added to the library, the user can indicate who can view the item. When setting the security for a single item, SharePoint allows the user to give access to an individual or group within AD and/or SharePoint. Item-level security is useful when uploading specific documents that only certain users should be able to see and completely prevent others from accessing them. For example, an internal portal for a company could display employee benefits only to that specific employee. Item-level security could allow only those users to see those documents without making the same documents available to the entire company.

The disadvantage of item-level security is the headache it poses for administrators in cases where it is unclear who the intended viewer is. For users of the older SharePoint Portal Server 2003, item-level security is not ideal given that users could see all items in a list, and only discover upon clicking whether they were authorized to view the item. SharePoint 2007 has now updated this feature with security trimming: Users see only the items listed that they are authorized to view, and all other items are filtered, or “trimmed” out.

Custom Code

If SharePoint doesn’t provide the feature you are looking for natively, chances are you have the option to extend SharePoint to include it. A document library could be created and a custom content query could be written so that documents are pulled only where the user ID matches a piece of metadata associated with the document. This is useful for filtering data just as audience targeting, but does not provide ultimate security. If a rogue user is familiar with the document naming conventions, they can skirt around your custom code and go after the documents directly unless item-level security is applied. Therefore, custom code is not recommended as a stand-alone solution for security.

Proposed Solution

After evaluating the options above and understanding their limitations, the proposed solution to address the problem of allowing users to privately view documents while attending to the enterprise security and administration concerns includes:

1. Building an automated process to import documents into SharePoint
2. Creating individual AD security groups for each user
3. Designing a SharePoint Document Library with separate folders for each employee

Start by looking at the import process and then learn about the Active Directory considerations and the Document Library.

Automated Import

For the system I am working with, the number of sensitive documents that are loaded into SharePoint on a bi-weekly basis is too much to handle manually. This burden arose where, in addition to loading a large volume of documents, each document has to be tagged with item-level security.

A three-step import process (see Figure 1) can be implemented with a console application scheduled on the SharePoint Server: securing FTP documents, moving documents while applying security, and removing documents:

1. Securely import documents: The documents need to be uploaded into the SharePoint environment in a secure way. S-FTP is one approach that can be used. A batch process can be leveraged to move the documents from the S-FTP site to a secured folder on the SharePoint Server.
2. Move documents while applying security: This is the key step in the process. I’ve included a few lines of code for the AD-specific items. For each document that is contained in the temporary secure folder, the following sub-process must be followed:
• Determine which user this document belongs to.
• Determine whether an AD Security Group exists for this user.

using System.DirectoryServices.Protocols;
.
SearchRequest req =
   new SearchRequest(name, ldapFilter, scope,
                     attributeList);
SearchResponse resp = 
   (SearchResponse) _ldapConnection.SendRequest(req);

• If an AD Security Group does not exist, create it.

using System.DirectoryServices.Protocols;
.
AddRequest req = new AddRequest(distinguisedName,
                                objectClass);
AddResponse resp =
   (AddResponse)_ldapConnection.SendRequest(req);

• Determine whether a folder exists for this user in the Document Library.
• If a folder does not exist, create it and secure the folder to the user’s AD Security Group.

// Create the folder
.
// Just like in configuration, break the security
// inheritance.
folderItem.BreakRoleInheritance(true);

// Now, clear all the current Limited Access security!
List<SPRoleAssignment> rolesToDel =
   new List<SPRoleAssignment>();
foreach (SPRoleAssignment ra in
         folderItem.RoleAssignments)
{
   if (ra.RoleDefinitionBindings.Count == 1 &&
       ra.RoleDefinitionBindings[0].Type ==
          SPRoleType.Guest)
   {
      rolesToDel.Add(ra);
   }
}

foreach (SPRoleAssignment ra in rolesToDel)
{
   folderItem.RoleAssignments.Remove(ra.Member);
}

// Now, add the correct new security group for this
// individual
SPRoleDefinition roleDef =
   MySPWeb.RoleDefinitions.GetByType(SPRoleType.Reader);

try { roleDef = MySPWeb.RoleDefinitions[permLevel]; }
catch { }

SPRoleAssignment assign =
   new SPRoleAssignment(fullGroupName, null, groupName,
      null);
assign.RoleDefinitionBindings.Add(roleDef);
folderItem.RoleAssignments.Add(assign);

• Store the document in the folder in the Document Library.
3. Remove documents: Once the process completes and the documents are in the document library, a cleanup process can remove the documents from the temporary folder on the SharePoint server.

Figure 1: Process for Securing Documents

Active Directory Considerations

For this solution, AD is set up as the authentication provider in SharePoint. When in a situation where each individual must access only their own documents and no one else’s, a recommended solution is to create individual AD security groups. Although this initially may sound like an administrative headache, the tedium can be resolved by having the import process create the necessary groups for the users who had documents being imported. The import process must be set up in such a way that it has the appropriate permissions to do so. Once the group is created, the user requests access to their documents, and the administrator makes the user a member of their individual security group in AD. This is far simpler than having to assign item-level security each time a document is added to SharePoint.

If only a single security group is created, and documents are displayed to users through custom code, hackers can figure out a way around the code to retrieve the documents directly from the document library.

Document Library Considerations

Separate folders must be created for each security group that has a document. This allows you to secure the folder to the security group in AD and add additional documents to the same folder. Securing the folder eliminates the need for applying item-level security to each document. The folder structure also simplifies the user’s access to the documents. Security trimming automatically handles pulling only those documents for the logged-in user. If implemented properly, users are not even aware that folders are being used. A custom front end can be used to enable style customizations and to further abstract the back end structure.

Conclusion

Although the importance of proper security and privacy are not to be underestimated, it is advantageous to do this in a cost effective way. The technique outlined in this article allows you to secure documents to individuals without incurring unnecessary costs in terms of support and maintenance.

About the Author

Daan De Brouckere is a Senior Solution Architect at Crowe Chizek and Company LLC with extensive experience architecting distributed systems leveraging either Microsoft or Java-based technologies for a wide range of clients. You can reach Daan at ddebrouckere@crowechizek.com.