Product Review: Idera SharePoint encrypt
Idera SharePoint encrypt makes security easy for both administrators and users, but there are some caveats you need to be aware of.
September 21, 2012
When I heard that I was going to be reviewing Idera SharePoint encrypt, I was preparing for a complex solution from both an administrator's and user'sstandpoint. Whenever I've looked at encryption solutions in the past, especially when Microsoft Outlook and Microsoft Exchange Server were involved,there's always been some onus on users to specify what gets encrypted by performing a series of steps. Idera understands that users should never be left tomake security decisions, and I'm a strong believer in making the security of IT systems as transparent as possible. With Idera SharePoint encrypt, agentsare installed on SharePoint front-end web servers, and they do all the work. There's no desktop software to install, and there are no visible changes inSharePoint's web interface. Users can continue using SharePoint as they did before, so no training is required.
SharePoint uses Microsoft SQL Server to store data. Although it's possible to use transparent data encryption (TDE) in SQL Server 2008 and later, one bigdrawback is that it can't stop those in the IT department with privileged accounts from viewing sensitive SharePoint data. Idera SharePoint encrypt isdesigned to prevent privileged account holders from viewing encrypted data, which is especially useful for organizations that outsource all or part oftheir IT operations.
However, Idera's solution isn't able to encrypt all file types, so it's worth checking the product release notes. For example, it can't encrypt .jpeg or.png image files. In addition, it encrypts only data stored in document libraries, so list encryption isn't supported. By design, the contents of encrypteddocuments can't be searched, but documents can be searched by filename. Depending on the size of your SharePoint environment and how it's used, this couldbe a serious limitation. Idera plans to add full search capability in a future version. Finally, it's worth noting that Idera SharePoint encrypt candecrypt only files that are accessed through SharePoint's web interface. This means that if you're working with applications that use the SharePoint APIs,encrypted documents can be viewed only if they're opened through the SharePoint web interface.
Installation
Idera SharePoint encrypt consists of an agent (or service) that gets installed on a SharePoint front-end web server. The encryption service supportsSharePoint 2007 SP2 and later, including SharePoint Foundation, installed on Windows Server 2003 (32- or 64-bit editions) or later. Itanium processorsaren't currently supported. The management console can be installed on Windows 7 (64-bit), Windows Server 2008 R2 (64-bit), or Windows Server 2008 (64-bit)and requires Microsoft .NET Framework 4.0 or later. Again, Itanium processors aren't supported. TCP port 5194 must be open on all servers running theconsole and encryption agent.
If you have more than one front-end web server in your SharePoint farm, the first encryption agent you install becomes the master agent that communicateswith the management console. Any additional agents communicate with the master agent. Service accounts used to run encryption agents must be SharePointfarm administrators and local administrators on the server where the service is installed. In addition, they must have Database Owner permissions in theSharePoint database that will store your encrypted data.
Installing the console and master encryption agent is a simple process. You're guided through adding a license file and the first two console administratoraccounts. You're also guided through making sure that the management console can communicate with the master encryption agent. If you want to install theagent on more than one SharePoint front-end web server, you must provide the IP address of the master encryption agent.
Configuration
After installation, you need to configure your encryption system, which is a three-step process. The first step is to create at least one key managementpolicy in addition to the two policies created out-of-the-box (none and decrypt). Key management policies provide for automatedencryption key changes and expiration. I decided to create a policy that uses Advanced Encryption Standard (AES) 256-bit encryption, requires the key to bechanged every year, and requires keys to be kept for seven years. Federal Information Processing Standard (FIPS) 140-2 encryption is also supported.
The next step is to create at least one ACL. There are three kinds of ACLs:
None. Encrypts and decrypts files for all users with no additional access control other than that specified by native SharePoint security.
Block Admins. Encrypts and decrypts files for all users and provides a quick way to make sure IT administrators can't see the encrypted content.
Specify Users. Allows or denies access to encrypted content for specific local, Active Directory (AD), or SharePoint users.
For this test, I chose Block Admins.
The final step is to switch to the Portals tab, which Figure 1 shows, and choose the document library or libraries to apply your ACLs and key managementpolicies. After the policy is applied, all items in the library are encrypted. Any items that are subsequently added or created through SharePoint's webinterface are also encrypted.
Figure 1: The Portals Tab in Idera SharePoint encrypt
For every item encrypted, Idera logs the event and an encryption KeyGUID. If a document needs to be decrypted at some point in the future, an administratorcan open the document as a text file and see the KeyGUID to identify which encryption key is required to decrypt the document. Documents can also bedecrypted using the built-in decrypt policy. If a built-in policy or key management policy is removed from a SharePoint document library, the filesencrypted with that policy remain encrypted.
There's an option that allows administrators to view the file structure of a SharePoint shared document library but not the contents of its documents. Thisis useful in situations in which administrators might need access to a document library to change the structure or manage views but need to be preventedfrom viewing sensitive content.
Idera SharePoint encrypt uses a Master Encryption Key (MEK), which should be backed up daily. The XML files that contain all the configuration and policyinformation should also be backed up. Two administrators are required to enter their credentials before a MEK can be restored. All cryptographic functionsare carried out by the software itself, so a separate public key infrastructure (PKI) isn't required.
Just What's Needed But with Caveats
Idera SharePoint encrypt has many beneficial features, but it also has a few caveats:
The lack of support for decrypting documents through third-party programs that use the SharePoint APIs (e.g., an Outlook plug-in created to make accessing SharePoint documents easier for users) is a serious limitation if your organization is using or plans to use such programs.
Idera SharePoint encrypt isn't able to encrypt all file types and encrypts only files located in document libraries.
It's also important to note that, unlike SQL Server TDE, Idera's solution can't encrypt databases, associated log files, backups, data written to thetempdb database, snapshots, or any mirrored database instances, which might be a consideration in high-security environments. TDE also has the advantage ofbeing able to encrypt all SharePoint items.
However, many organizations are now using the new support for Remote BLOB Storage (RBS) in SharePoint 2010 to move data out of SQL Server to cheaper formsof storage. In this case, you need a third-party encryption solution, such as Idera SharePoint encrypt.
When exploring possible encryption solutions, you need to think carefully about whether you can live with the shortcomings of Idera SharePoint encrypt. Ifyou can, it's definitely a solution worth considering.
About the Author
You May Also Like