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.com 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 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. Its also useful for storing passwords for visualforce based portals. You can tweak with the mask type to partially show values, like last 4 digits of a credit card.
As you may notice this method is useful for encrypting data at rest.
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 more granular level of encryption and requires significant know-how about Salesforce, Apex programming, and Salesforce customization. Therefore we recommend you to 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 external system, a very useful trick when you are transmitting data from one service to another through an solution of Salesforce and integrated third-party web services.
How does it work?
Apex Crypto classes depends 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 accessed 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 above methods is 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. Its 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 Salesforce.com 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);
Checkout these posts to know more about Crypto Classes
https://developer.salesforce.com/page/Apex_Crypto_Class
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_restful_crypto.htm
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_restful_crypto.htm
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 hundred 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.
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 had these solution allow administrators to encrypt data at DataCenter level and then send it to Salesforce. i.e. data in your Salesforce itself is encrypted and whenever a user requests a data it is retrieved through Salesforce, then routed through DataCenter and decryption program, and then displayed to user. In addition this also means that you don’t have to worry about keys in Salesforce as they are handled by the 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.
Pratyush Kumar
