Because e-mail is a technology not designed with security in mind, protecting sensitive information in e-mail has always been a challenge. Most encryption solutions require users to work with their e-mail client in a slightly different way if mail needs to be encrypted or signed, especially if the intended recipient isn’t a company employee. Files can also be secured in transit, using technologies such as IPsec or SSL; or at rest on the disk, using NTFS, EFS and BitLocker. But once moved and stored in a different location, all the effort to secure the document is lost.
Active Directory Rights Management Services (AD RMS) encrypts e-mail messages and documents, additionally storing usage information with each file, determining who can view, copy, forward or print the document. Only the original owner can change or revoke these permissions.
When using Exchange 2010 and AD RMS together, Transport Protection Rules can be configured to automatically protect e-mail messages. Exchange is able to work with encrypted messages so that standard functionality — such as the ability to scan for malware and index message content — isn’t impaired.
Almost everyone knows someone (or is someone) who has forwarded e-mail to the wrong person by mistake, so when sensitive documents are distributed by e-mail, it’s important to ensure that only specific employees are able to work with the contents.
Most security breaches involve insiders accidentally or maliciously leaking information. Depending on the results of a risk assessment, sensitive communications — including financial reports, HR documents and anything that contains valuable intellectual property — should be secured for in-house consumption only.
To extend RMS functionality beyond the corporate firewall, you can create a dedicated AD RMS cluster in a separate AD forest with a container that holds accounts for your external partners. The RMS service must also be published on the Internet or in an extranet. A trust can then be established between the two internal RMS clusters, allowing users outside the company to work with encrypted documents. The disadvantage of this method is that credentials must be managed for external users, increasing administrative overhead and the likelihood of a security breach.
Alternatively, Windows Live IDs can be used for authenticating external users, but this is best suited to one-off scenarios where an external partner needs to view an RMS-protected document. Windows Live IDs cannot be added to Active Directory (AD) groups and have only basic assurance by means of a password, so they are not deemed suitable for use in situations where a high level of trust is required.
Business partners, with whom RMS-protected content is exchanged on a regular basis, can set up their own AD RMS servers and establish a trust between the two clusters. Another option is to use Active Directory Federation Services (ADFS) or Microsoft’s hosted Federation Gateway (Windows Server 2008 R2 SP1 or later with Exchange 2010 SP1), so that users in a partner’s AD forest can access internal AD RMS servers without needing a second set of credentials. Not all Microsoft applications, including Windows Mobile and SharePoint, will support RMS when ADFS, Federation Gateway or Windows Live IDs are used.
AD RMS requires Windows Server 2008 (or later), Active Directory, SQL Server (2005 or later), IIS with ASP.NET enabled and the Microsoft Message Queuing Service. The AD RMS role and SQL Server should be installed separately on dedicated servers. For more detailed information, see Pre-installation Information for Active Directory Rights Management Services. The RMS client component is built in with Vista and Windows 7. XP and Windows 2000 are supported, but the client must be downloaded and installed manually.
Users also need applications that are capable of creating and reading RMS-protected content. RMS is supported in Microsoft Office and Windows XPS viewer. Rights management is available in Office 2003 and later, but feature support varies between the different SKUs. For more detailed information, see AD RMS and Microsoft Office Deployment Considerations.
In a test environment, AD RMS is fairly easy to set up. If you just want to get a feel for the technology without installing the server components yourself, Office 2010 supports rights management using Windows Live IDs and Microsoft’s online licensing servers.
To protect a document in Word 2010, click Info on the File menu and select Protect Document > Restrict Permission by People > Restricted Access. If you’ve never used rights management before, you’ll be prompted to enroll a Windows Live ID or create a new one if you don’t already have an ID to use. Once set up for RMS, you will be asked to confirm the use of the ID for creating and opening rights-protected content in Word. Click OK to set restrictions on the document (Figure 1).
Figure 1 – Basic rights-management restrictions on a Word document
Click More Options in the Permission dialog to access more advanced rights management settings.
Figure 2 – Advanced rights management restrictions
When the document is saved and opened by a user who has been granted permissions, Word will need to contact an online licensing server. Users who haven’t explicitly been granted rights to the document will not be able to open it or otherwise view the content.
Microsoft has developed the Active Directory Rights Management Services Bulk Protection Tool, which allows security administrators to encrypt or decrypt files en masse, including Outlook PST files, if required. Using the tool in conjunction with the File Classification Infrastructure (FCI), administrators can automate encryption and setting usage policy on files, taking the weakest link in the security chain (the user) out of the loop. FCI classifies files and then calls the Bulk Protection Tool from a PowerShell script to apply an RMS template to the files. The tool can be downloaded for free. For more information on FCI, see Control Data Sprawl with File Classification in Windows Server 2008 R2.