Encryption is the process of converting information or data into a code before it’s sent or stored. This is especially performed to secure your data and prevent unauthorized access such as:
- A DB Administrator trying to access the stored data
- A sniffer trying to read the data being sent over the Internet
In fact, encrypting data before it’s stored is different from sending/receiving encrypted data over the network (e.g. Internet) through a secure channel (e.g. HTTPS).
Generally speaking, encryption is needed to secure your data on the following two cases:
- When data is At-Rest (i.e. data that exist statically on physical media)
- When data is In-Transit or In-Motion (i.e. data that is being transferred between components, locations or programs, such as over the Internet)
For the first case, both Dynamics365 (Online) and SFDC enforce a secure data transfer over the Internet.
Now that you know that your data is always secured (i.e. encrypted) when sent over the Internet, do you still require Dynamics365 or SFDC to encrypt your data when they store it locally (i.e. within their data centers)?
Let’s first have an overview of each product’s approach for handling the so called At-rest Encryption!
For both Microsoft Dynamics 365 (online & on-premises), all new and upgraded organizations have data encryption activated. An encryption key is provided and can be easily changed by the administrator (The administrator should store this key in a safe location).
Microsoft Dynamics 365 uses standard Microsoft SQL Server cell level encryption for a set of default entity attributes that contain sensitive information (See details here), such as user names and email passwords. For more details about Encryption in Dynamics CRM you can watch this video or refer to this detailed post by my fellow CRM colleague Ben Hosking.
In SFDC, fields are not encrypted by default, unlike Dynamics 365 which, OOB, encrypts a bunch of default entity attributes. However, you have the ability to pick which field to encrypt, with some limitations!
SFDC have two solutions for encryption: Classic Encryption and the Shield Platform Encryption. Below you can find a table that summarizes the main differences between both solutions. You can find the full list of differences here.
Shield Platform Encryption
Included in base user license
Additional fee applies
|Native Solution (No Hardware or Software Required)||X||X|
|Encrypted Standard Fields||X|
|Encrypted Attachments, Files, and Content||X|
|Encrypted Custom Fields||
Dedicated custom field type, limited to 175 characters
|Encrypt Existing Fields for Supported Custom Field Types||X|
|Search (UI, Partial Search, Lookups, Certain SOSL Queries)||X|
|Available in Workflow Rules and Workflow Field Updates||X|
|Available in Approval Process Entry Criteria and Approval Step Criteria||X|
So, from a business perspective, the main limitations in the classic solution is the inability to encrypt OOB fields or existing custom fields. You also cannot perform search on encrypted fields. These are limitations that the Shield Platform Encryption solution address but with a price!
Oh well, this post is already getting too long!! I’ll stop here for now.
In my next post, and based on this preliminary analysis, I’ll provide a comparison of at-rest encryption approaches for both Dynamics CRM and SFDC. I’ll also discuss the alternatives to each approach’s limitations.