Security and Compliance with AD RMS
Organizations today maintain enormous quantities of sensitive and confidential information in SharePoint, including all sorts of financial data and personally identifiable information, and protecting that information can be a challenge. With fines up to $15 million per offense, the cost of noncompliance with content storage and protection regulations, such as SOX, HIPAA, GLBA, and ISO 27000+, is high. It is therefore vital to review and use SharePoint compliance features appropriately, as well as to enforce usage policies outside of the SharePoint environment and provide compliance documentation.
The good news is that Windows SharePoint Services (WSS) 3.0 enables you to achieve compliance via an Information Rights Management (IRM) framework. Microsoft Office SharePoint Server (MOSS) 2007 goes even further by including Microsoft Office document protectors that take advantage of the IRM framework and its integration with Active Directory Rights Management Services (AD RMS).
However, it is easy to stumble over the IRM framework implementation details. Not even Microsoft gets it right all the time: The webcast titled "Best Practices for Managing and Securing SharePoint 2007
" claims that you can automate and force AD RMS encryption by moving files into a document library; that content protection in an AD RMS-enabled document library is the same as when using Microsoft Office Word; and that AD RMS policy follows a document wherever this document goes.
But the reality is more complicated. Misunderstanding the IRM framework can lead to ineffective security solutions and noncompliance at customer organizations, so it's important to get it straight.
In this column, I review the integration of SharePoint with AD RMS, with an emphasis on issues you must consider when designing and implementing SharePoint-based security and compliance solutions. First, I discuss the difference between AD RMS itself and SharePoint integration with AD RMS, and I show you first hand in a test environment that SharePoint integration with AD RMS requires a secure SharePoint environment to begin with.
Once this is clarified, I focus on certain usability issues you might want to address in your security and compliance solutions and documentation. I'm assuming you have already deployed AD RMS and MOSS. The deployment in production environments is covered very well in the "AD RMS Deployment with Microsoft Office SharePoint Server 2007 Step-by-Step Guide
." There is nothing to add, apart from some worksheets for this test environment.
In the next column, I'll cover the deployment of Microsoft Office 2007 and MOSS 2007 in an AD RMS pre-production hierarchy because this isn't covered in the WSS SDK or the AD RMS SDK. It's an interesting exercise and a great opportunity for a deep drilldown into the IRM framework architecture.
For now, however, let's focus on general security, compliance, and usability aspects that are not so well covered in the SharePoint documentation. The companion material for the April issue of TechNet Magazine includes worksheets, compiled tools, and source code. As always, the companion material is for illustration and test purposes only and is not to be used in a production environment.
Information Security versus Usage Policy
No introductory AD RMS presentation is ever complete without a demonstration of the technology's amazing document protection capabilities, including disabled copy and print options, document expiration, and so forth. It seldom occurs to people, however, that these aren't actual security features.
When you see a disabled print command, isn't it logical to conclude that the user cannot carry a printout to the competition? When you hear that a user can't forward a document and that unauthorized persons can't even open the document, doesn't it follow that the information in that document is protected from unauthorized disclosure?
No, unfortunately, it doesn't. You would have to outlaw all virtualization and remote desktop technology, third-party screen capture solutions, cell-phone cameras, and other such tools that enable the user to take an image of the document for purposes of printing, forwarding, and viewing beyond the document expiration date. ( Just take a glance ahead at Figure 2, which includes a screenshot of a protected document.) Perhaps you should also outlaw all Windows-based portable computers and Windows Mobile devices, which enable the user to open protected documents and show them to unauthorized viewers at any location.
Obviously, these document protection features don't help to enforce information security, though they can help to implement usage policy, such as to mitigate the risk that employees conduct business based on outdated information from expired documents. Digital Rights Management (DRM) may have been originally about preventing users from creating illegal copies so that the rightful owner can monetize intellectual property, but today this technology is clearly moving towards regulatory compliance enforcement.
Of course, AD RMS does go beyond merely enforcing usage policy by encrypting the content using Advanced Encryption Standard (AES) and Electronic Codebook ( ECB) ciphers. To encrypt the content, AD RMS generates a symmetric 128-bit AES content key, which is then encrypted using a public key obtained from the Server Licensor Certificate (SLC) of your AD RMS server.
You generate the SLC and the server's encryption keys when you install AD RMS in your Active Directory forest. AD RMS then embeds the encrypted content key together with the specified document protection settings in a publishing license (also called an issuance license), which AD RMS then signs using the owner's private key from his or her Client Licensor Certificate (CLC). The CLC—created as part of the user activation process when the user first creates an AD RMS-protected document—defines the user's right to publish content. The AD RMS-enabled application then attaches the publishing license to the encrypted content and then the content is protected. The arrangement of content pieces in the AD RMS-protected file depends on the application. Figure 1 illustrates the container format for the AD RMS Add-on for Internet Explorer, as documented in the AD RMS SDK.
Figure 1 The structure of an AD RMS-protected document in compound file binary format (CFBF)
Any user who wants to access the content must open the protected file, extract the signed publishing license, and upload this license together with the user's Rights Account Certificate ( RAC) to the AD RMS server in order to download a use license ( UL) for the document, also called an end-user license ( EUL). The RAC identifies the user by e-mail address or security identifier and it includes the user's encryption key, encrypted using the local computer's machine key as specified in the Security Process Certificate (SPC). The UL returned from the AD RMS server contains the content key, which the server encrypted using the user's public key obtained from the user's RAC. The user can now decrypt the content key with his or her private RAC key and then finally decrypt the protected file content.
As you can see, there are a lot of keys, licenses, and certificates involved in this process. The application can also add the UL to the protected file so that the user does not have to retrieve the UL again from the AD RMS server, but you can change this behavior in the AD RMS policy settings. You can specify that the user must obtain a new UL whenever he opens the document, or you can define a validity period for the UL so that the user must acquire a new UL when the current one expires. For all the details, check out the AD RMS SDK
. It's an excellent information source even if you are not a developer.
For SharePoint security architects and administrators, there are at least three important facts to take away from the AD RMS implementation details. First, AD RMS protection is end-to-end, meaning protection remains with the document wherever the document goes (note that I am talking about AD RMS here, not about SharePoint integration with AD RMS). So you can place an AD RMS protected file on a Windows BitLocker drive or on an unencrypted drive, you can place it on a file share with Everyone read access, you can upload it to a SharePoint document library, you can send it to an unauthorized recipient outside your organization, but the content remains protected end-to-end, from the document owner on one end to the consuming user on the other end.
Second, decrypting an AD RMS-protected document requires that the end user obtains a UL from your AD RMS server at least once. By logging all licensing activities on your AD RMS server, you can reliably track who opened the document and, perhaps even more importantly, who attempted to gain access unsuccessfully.
Logging is a new feature of AD RMS in Windows Server 2008 and it's really cool because you can create tools for security analysts based on .NET and SQL Server reporting technology to process this information automatically for forensic purposes. Of course, you can also see all the requests and certificate information directly in the AD RMS management console.
Finally, and this may seem obvious yet is nevertheless very important, AD RMS-based document protection relies on encryption. If you don't encrypt the document, you cannot enforce information security. If you create a tool that decrypts a protected document and stores it in unencrypted format, you break AD RMS end-to-end security.
Who is to tell that an unauthorized user didn't get an unencrypted copy? Microsoft mitigates against this by requiring developers to sign a Production License Agreement with Microsoft in order to obtain a production certificate. A production certificate signs an AD RMS application into the AD RMS production certificate hierarchy. It specifies among other things the modules that the system can load into the process space of the application to protect the unencrypted data in memory. It works. Microsoft says that AD RMS security has never been compromised.
SharePoint Integration with AD RMS
With these facts in mind, let's approach SharePoint integration with AD RMS. First and foremost, Microsoft states in all relevant product documentation pieces that AD RMS-enabled document libraries store content items unencrypted. So, there is no bulk encryption when you move items into an AD RMS-enabled document library. More importantly, because the items are unencrypted, there is no AD RMS protection and no security gain in the SharePoint environment.
SharePoint administrators and users might believe that AD RMS end-to-end security exists, but SharePoint integration with AD RMS fully depends on SharePoint security. According to "Information Rights Management in Windows SharePoint Services Overview
" in the WSS 3.0 SDK, Microsoft opted not to store the items in encrypted, rights-managed formats due to customer demand.
Take a look at Figure 2. It illustrates the IRM framework architecture in an unsecure SharePoint environment that permits unauthorized users direct access to the content databases. The key point is that integrated document protectors apply AD RMS protection dynamically when you download a document through SharePoint. This means that you perceive an unprotected content item as an AD RMS-protected document. When you upload changes, however, SharePoint removes the AD RMS protection again.
Figure 2 An AD RMS-protected document that is, in fact, a non-AD RMS-protected content item
It's important that you make sure that this decryption behavior is consistent with your security and compliance requirements. Just imagine a scenario where you host sensitive HR documents in an AD RMS-enabled document library and fail to inform the HR department that all SQL Server and SharePoint farm administrators as well as any SharePoint developers outside of the HR department have unrestricted access to the content items in unencrypted form. Don't neglect this issue in your solution design and in your compliance documentation. For example, you might have to deploy separate SQL Server instances and SharePoint farms that are maintained by HR-internal administrators only.
When designing security and compliance solutions, keep in mind that SharePoint integration with AD RMS does not eliminate the need to protect your SharePoint environment as described in the Office SharePoint Server Security guide
and the Windows SharePoint Services Security Account Requirements worksheet
. If you don't protect your security accounts and passwords, if you deploy unverified code from questionable sources, or even enable server-side scripts on your SharePoint servers, then an IRM framework and AD RMS integration won't save you when an unauthorized person gets access to the content items, as explained in the January column titled "SharePoint Security Accounts."
Check out the April companion material, which includes two Web Parts and a worksheet that demonstrates how a questionable Web Part can render all your security and compliance solutions ineffective. One Web Part downloads documents the proper way by using the SharePoint object model, and the other Web Part takes a shortcut by accessing the SharePoint content database directly within the security context of the application pool account.
As you can verify, the second Web Part provides the user with full access to all document libraries in the site collection regardless of SharePoint permissions and AD RMS settings. So, make sure your SharePoint developers don't break the rules and take shortcuts; don't program directly against content databases, and keep questionable components that do so away from your production servers.
AD RMS Policy Settings Override
Another important issue you must address in your compliance solutions and documentation is that content protection in an AD RMS-enabled document library is not the same as when working in Microsoft Office Word outside of document libraries. Check out Figure 3 and the worksheet titled "Specifying AD RMS Permissions in Microsoft Office Word inside and outside of Document Libraries" in the companion material.
Figure 3 Document library’s policy overrides owner’s policy.
The worksheet demonstrates that AD RMS-enabled document libraries do not retain AD RMS policy settings and user authorizations specified by the document owner. This is a result of the fact that SharePoint decrypts the document on upload, so the owner's policy definition does not follow the document into the SharePoint environment. The next time a user downloads the document, SharePoint applies the AD RMS policy settings defined for the document library and the user's permissions in SharePoint, as indicated in Figure 3.
Note that this issue primarily affects site administrators because SharePoint grants only users with Manage Permissions privileges the right to modify the AD RMS permissions of the document. Site members do not fall into this category. Nevertheless, it can be confusing for site administrators and it can lead to unintentional disclosure of confidential information to the wrong SharePoint users. When using AD RMS-enabled document libraries, make sure your site administrators and managers understand that the AD RMS document settings they change in their Office applications are not retained. For details how the IRM framework translates SharePoint permissions into AD RMS document permissions, see the topic "Information Rights Management in Windows SharePoint Services Overview
" in the WSS SDK.
AD RMS Protection versus AD RMS Protection
The policy override issue is hard to explain to site administrators and managers because the root cause is a miniscule difference between AD RMS-protected documents created outside of the SharePoint environment and those created within the SharePoint environment. The former retain their policies even when you upload them into an AD RMS-enabled document library, but the latter do not. AD RMS end-to-end security prevents SharePoint from decrypting documents created outside of the SharePoint environment.
Figure 4 Verifying that the application pool account has Full Control
For decryption to work on upload, the site's application pool account must have Full Control permissions as a document owner. SharePoint adds this application pool account to the document template that you download when you click the New button in an AD RMS-enabled document library. As a document owner, you can verify that the application pool account has Full Control. Just display the advanced AD RMS options by clicking on the More Options button in the Permission dialog box of the document in Word 2007, as illustrated in Figure 4.
Also, do not forget to mention in your compliance documentation that the list of users with permissions to the document does not reflect the list of users with permissions to the content item in SharePoint. SharePoint grants only the current user and the site's application pool account AD RMS document permissions on download.
The advantage is that the SharePoint user cannot share this document with anybody else outside of the SharePoint environment. The disadvantage is that document owners might incorrectly assume that AD RMS protection is more restrictive than it actually is. In the example of Figure 4, SPAdmin and ITUser have access to the document but the document permissions do not reveal this fact. Fortunately, only site administrators and managers can view document permissions. Site members don't and can't view the list of users with permissions to the document.
Document Protection Outside of the SharePoint Environment
It might take some time to get used to the way SharePoint maps site permissions to AD RMS document permission, but one aspect you might appreciate immediately is that you can't open a document downloaded from an AD RMS-enabled library under the identity of the application pool account. It's quite amazing.
In Figure 4, this is the WssDefaultSite account. The account has Full Control permissions and still it cannot open the document. So, an unauthorized person might guess the login name and password of the application pool account, but as long as you prevent direct connectivity to the content database and force all document access through SharePoint so that SharePoint can apply AD RMS protection, the content remains inaccessible, as illustrated in Figure 5.
Figure 5 The application pool account cannot open the AD RMS-protected document.
Check out the companion worksheet "Examining Content Item Security in an AD RMS Enabled Document Library." It explains how to use the GetDocument tool, which is also included in the companion material. GetDocument.exe uses FrontPage RPCs via Author.dll to download documents to the user's Desktop in a way that is similar to Microsoft Office Word. The tool demonstrates that SharePoint applies AD RMS protection no matter which way you download the document (and it makes it easier to specify different account information for each document download).
The application pool account can't open the document, even though the account has the Full Control permissions, because the application pool account doesn't have an e-mail address. If you use Microsoft Exchange Server, your user accounts most likely have valid e-mail addresses, and if you don't use Exchange Server, you must set the mail attribute of your users manually or by using tools such as Ldifde.exe; the application pool account doesn't need to be e-mail-enabled, however.
SharePoint uses the application pool account's security identifier when applying AD RMS protection on the server. AD RMS client applications, on the other hand, such as Word 2007, use the mail attribute to associate users with AD RMS permissions. If there is no mail attribute, then there is no match that would grant AD RMS permissions and the account cannot open the document.
Enforcing Read-Only Permissions
The inability to share documents outside of the SharePoint environment provides workflow designers with greater control over the collaboration process. Even more compelling, however, is the ability to enforce read-only document permissions outside of the SharePoint environment.
Out of the box, SharePoint prevents site visitors and other users with only View List Item permissions from uploading documents, but you can't prevent these users from modifying downloaded documents and distributing them by other means, such as e-mail messages. SharePoint integration with AD RMS closes this gap. Now, users with only View List Item permissions get AD RMS read permissions, but this doesn't include copy or edit permissions for the document content, as illustrated in Figure 6. What's meant to be read-only remains read-only within and outside of SharePoint!
Figure 6 The AD RMS-protected document remains read-only after download.
This seems to be one of the biggest benefits of SharePoint integration with AD RMS because it enables you to implement managed repositories for boilerplate documents. Talk about lowering business risks! Give the legal department Edit List Items permissions and the rest of the company View List Item permissions in SharePoint and you can rest assured that no bogus, manipulated, or outdated boilerplates fly around in your company. Just don't forget to allow document printing in the AD RMS-related library settings so that employees can print out the contract documents.
SharePoint integration with AD RMS is a useful feature that enables you to extend the reach of your security and regulatory compliance solutions far beyond the perimeter of your SharePoint environments. By using this technology, you can enforce usage policy and information security of documents after download. However, be sure to keep in mind that the IRM framework and AD RMS integration do not increase security within your SharePoint environment. It remains imperative to apply correct SharePoint access controls; protect security accounts; properly configure application pools, content databases, SQL Server instances, and SharePoint servers; and keep questionable components and unverified code away from your production servers.
The IRM framework is definitely worth evaluating. Without a doubt, you will notice rough edges and certain limitations of the current implementation, but the issues do not speak against the technology; instead, they highlight that this technology addresses a huge field of requirements and opportunities. Microsoft says that future AD RMS versions will provide more granularity and control, and this will certainly affect integration with SharePoint as well.
It would be great to have more control over permission mappings. It would be useful to have expiration dates relative to the download date. It would be nice to have the ability to configure document protectors for each individual document library separately. It would be helpful to combine document protectors with document parsers so that you can disable decryption of documents while retaining indexing and property promotion capabilities. The wish list is long, but the current implementation is definitely a step in the right direction and compelling for organizations that use SharePoint and must comply with regulations covering content storage and protection.
The only concern is that WSS 3.0 organizations cannot benefit from AD RMS integration out of the box because the Microsoft Office document protectors are included only in MOSS 2007. But don't despair! In the next column, I show you how to extend WSS 3.0 to achieve Office document protection based on the IRM framework and AD RMS, and it doesn't require developer skills. I will show you the nuts and bolts of this technology by deploying a pre-production environment, which is useful if you want to develop your own AD RMS-based Office and SharePoint solutions or simply compile solutions that other developers provide you free of charge in order to address security and compliance requirements beyond the standard capabilities built into WSS 3.0 and MOSS 2007. Stay tuned!
Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.