RMS is designed as a solution to allow digital enforcement of content usage policies. And like any other solution, one can follow some best practices to ensure that the service is running in a secure manner. Here are a few suggestions from the product team.

• Deploy RMS web services as https – not http.  Particularly for external services, deploying as https protects privacy of the RMS credentials that are sent back and forth in licensing requests, and importantly secures the authentication of certification requests.  Additional security for authentication can be enabled by requiring https with client authentication, not just the standard server authentication, and requiring smartcards.
• The default protection for RMS server private keys is a software-based protection.  For added protection, Hardware Security Modules can be used for key protection off the server.  Many varieties of HSM can be used, but two specific vendors who have done testing with RMS are Safenet (Luna HSM) and nCipher
• Avoid email address recycling. This ensures that users (who may otherwise get the recycled email address of an authorized user) do not get access to protected content that they shouldn’t have access to.
• Disable hibernation on desktops. You never know what is encrypted in memory and what is not. :-)
• Use Windows integrated authentication to access SQL as it is stated in the installation guide.
• ACL the pipelines appropriately. If you are not allowing Passport-authenticated users, you might want to have authentication of the licensing pipelines as well.
• Minimize the number of services on RMS Servers. This is a recommended practice for defense-in-depth strategy.
• The group of RMS administrators and the Superuser group should be an AD restricted group.
• RMS service account should be used, as opposed to any system account, to run RMS.  It should not be granted any additional special privileges.  Also, be sure to isolate the RMS server by not running other applications on it.  Sharing the RMS server with other applications may put RMS keys, and hence content, at risk
• Since Office applications currently use the content of the Active Directory email attribute, or alternate SMTP proxy addresses, associated with a user as that user’s unique identity, be sure to protect this field in AD.  Do not allow users in your AD to change this attribute, and inquire about the protection of this attribute before importing other organizations’ RMS servers into your list of trusted RMS domains.
• When making RMS services available to the internet, you can offer advanced protection by using an application layer firewall.  Rather than just opening port 443, ISA server (or potentially other application layer firewalls) can inspect the https traffic by terminating the https connection at the firewall and re-establishing a separate connection internally, once the traffic is inspected.  This is a best practice when internet-enabling any web based application.

Again, the above is not an exhaustive list, but can serve as a good starting point for understanding how to deploy RMS in a secure manner. If you have more specific questions, please leave us a comment here or join our newsgroup and we will do our best to answer them