Salesforce Security – An Encryption Guide For The Paranoid
If you are using Salesforce, you would be having a lot of data stored in Salesforce objects. Some of it would be sensitive data, and some of it would even be sensitive enough that you don’t want anyone to look at it, like revenue-related data. So the question is, is the data on your Salesforce implementation secure enough? How fastidious are you about your customer’s or company’s sensitive data and how to make sure that the data remains secure and be accessible to particular eyes necessarily?
This post is for those paranoid-at-heart people who are not satisfied with Salesforce’s high-level default data security standards and protocols.
Encrypting Data in Salesforce
Salesforce, in general, has very strict security protocols and standards so usually there is no need to additionally secure any data. But for some data, there is nothing paranoid about taking extra precaution. More and more companies nowadays are taking the security of their user and financial data very seriously and to satisfy them Salesforce and third party Salesforce developers have provided users a number of ways to encrypt their data.
Salesforce Custom Field Encryption (Both Classic and Platform)
For those using Salesforce Developer, Enterprise, Performance, Unlimited, and Database editions, there is a way that they can encrypt data values. This is applicable to custom fields only. All you have to do is to select the text (encrypted) field when created new custom field, and it will open a page something like this.
Select all appropriate options and save.
This option is mostly used when you have multiple Salesforce users entering or reviewing information and don’t want them to view the data after entering. It's also useful for storing passwords for visualforce based portals. You can tweak with the mask type to partially show values, like the last 4 digits of a credit card.
As you may notice this method is useful for encrypting data at rest.
Don't forget to check out: How To Pass Salesforce AppExchange Security Review
Using Apex Crypto Class
Now if you are slightly more paranoid and you think that custom field encryption is not enough, you can leverage the APEX class’s properties for encrypting data at rest and in-transit. Apex classes are the more granular level of encryption and require significant know-how about Salesforce, Apex programming, and Salesforce customization. Therefore we recommend you consult a Salesforce expert before using this method.
Apex Crypto classes, as the name suggests, provide Salesforce developers with a number of functions that allow them to create data digests, signatures, and message authentication codes. They are useful in encrypting and thus protecting the confidentiality of the data as well as provide a way to allow authentication of data by an external system, a very useful trick when you are transmitting data from one service to another through a solution of Salesforce and integrated third-party web services.
How does it work?
Apex Crypto classes depend mainly on four methods:
decrypt(algorithmName, privateKey, initializationVector, cipherText) decryptWithManagedIV(algorithmName, privateKey, IVAndCipherText) encrypt(algorithmName, privateKey, initializationVector, clearText) encryptWithManagedIV(algorithmName, privateKey, clearText)
The encrypt() method is used when you have your own initialization vector (IV) and want to use this IV to encrypt your data. This method is mainly used when your encrypted data may have to access by a third party system and you want this system to authenticate the data using the IV. The decrypt() methods, as you may have guessed it encrypt() method’s counterpart that is used to decrypt data. These methods can be used both in Salesforce or other third-party services that support AES level encryptions. Currently, Crypto classes only have symmetric key encryption only.
The private key values mentioned in the above methods are generated via another crypto class method named generateAesKey(size). The size here defines the length of your AES encryption protocol and thus is depended on your algorithm. Name that you again defined in encryption methods. As such the Crypto classes support 3 different AEStypes:
- AES128
- AES192
- AES256
and therefore the corresponding values for generateAesKey() function becomes 128, 192, and 256 respectively. The following lines of code will make these functions a lot more clear.
Blob presetIV = Blob.valueOf('Example of IV123');
Blob key = Crypto.generateAesKey(128);
// Generate the data to be encrypted.
Blob data = Blob.valueOf('Data to be encrypted');
Blob encrypted = Crypto.encrypt('AES128', key, presetIV, data);
Blob decrypted = Crypto.decrypt('AES128', key, presetIV, encrypted);
String decryptedString = decrypted.toString();
//check the authenticity of data( useful for integrations)
System.assertEquals('Data to be encrypted', decryptedString);
The encryptWithManagedIV() methods on the other hand are used to encrypt data using Salesforce generated initiation vector. It's counter par decryptWithManagedIV() method therefore also does not require any IV parameters. If you are going to use your data for Salesforce-based systems only then we recommend using this method.
Blob cryptoKey = Crypto.generateAesKey(256);
// Generate the data to be encrypted.
Blob data = Blob.valueOf('clear text waiting for encryption');
// Encrypt the data using <a class="vglnk" href="http://Salesforce.com" rel="nofollow"><span>Salesforce</span><span>.</span><span>com</span></a> generate the initialization vector
Blob encryptedData = Crypto.encryptWithManagedIV('AES256', cryptoKey, data);
// Decrypt the data - the first 16 bytes contain the initialization vector
Blob decryptedData = Crypto.decryptWithManagedIV('AES256', cryptoKey, encryptedData);
// Decode the decrypted data for subsequent use
String decryptedDataString = decryptedData.toString();
//check the authenticity of data( useful for integrations)
System.assertEquals('clear text waiting for encryption', decryptedString);
Third-Party Encryption Services
The third method to encrypt your data is using third party encryption services. Google ‘Salesforce Encryption Services’ and you will find a hundred of such third-party solutions. These services are, in almost every case, paid and requires a subscription licensed based fees. These services are mainly deployed as an added layer between data entry points and Salesforce and can be used to both encrypt and authenticate data. Theoretically, they should create some latency in data addition and retrieval, but in most practical cases the latency is negligible, provided the service is flawless of course.
Check out another amazing blog by Algoworks here: How To Integrate Salesforce And SharePoint Online Through Files Connect?
This method is mainly used by those who do not want to spend time and effort in getting a custom encryption solution. On the other hand, these solutions allow administrators to encrypt data at the DataCenter level and then send it to Salesforce. i.e. data in your Salesforce itself is encrypted and whenever a user requests data it is retrieved through Salesforce, then routed through DataCenter and decryption program, and then displayed to the user. In addition, this also means that you don’t have to worry about keys in Salesforce as they are handled by a third-party solution.
However encrypted data in Salesforce means that it would be impossible to integrate Salesforce with any other third-party solution without involving encryption solution’s adapter in between. Therefore if the encryption solution does not have any integration adapter to your choice of service, you may have to look into something custom.
Responses