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's standpoint. 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 to make security decisions, and I'm a strong believer in making the security of IT systems as transparent as possible. With Idera SharePoint encrypt, agents are 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 in SharePoint'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 big drawback is that it can't stop those in the IT department with privileged accounts from viewing sensitive SharePoint data. Idera SharePoint encrypt is designed to prevent privileged account holders from viewing encrypted data, which is especially useful for organizations that outsource all or part of their 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 encrypted documents 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 could be a serious limitation. Idera plans to add full search capability in a future version. Finally, it's worth noting that Idera SharePoint encrypt can decrypt 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 supports SharePoint 2007 SP2 and later, including SharePoint Foundation, installed on Windows Server 2003 (32- or 64-bit editions) or later. Itanium processors aren'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 the console 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 communicates with the management console. Any additional agents communicate with the master agent. Service accounts used to run encryption agents must be SharePoint farm administrators and local administrators on the server where the service is installed. In addition, they must have Database Owner permissions in the SharePoint 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 administrator accounts. You're also guided through making sure that the management console can communicate with the master encryption agent. If you want to install the agent 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 management policy in addition to the two policies created out-of-the-box (none and decrypt). Key management policies provide for automated encryption key changes and expiration. I decided to create a policy that uses Advanced Encryption Standard (AES) 256-bit encryption, requires the key to be changed 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 management policies. After the policy is applied, all items in the library are encrypted. Any items that are subsequently added or created through SharePoint's web interface 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 administrator can 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 be decrypted using the built-in decrypt policy. If a built-in policy or key management policy is removed from a SharePoint document library, the files encrypted 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. This is useful in situations in which administrators might need access to a document library to change the structure or manage views but need to be prevented from 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 policy information should also be backed up. Two administrators are required to enter their credentials before a MEK can be restored. All cryptographic functions are 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 the tempdb database, snapshots, or any mirrored database instances, which might be a consideration in high-security environments. TDE also has the advantage of being 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 forms of 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. If you can, it's definitely a solution worth considering.
|
Idera SharePoint encrypt
|
