Salesforce Shield is made up of three components.
1.Platform Encryption (Natively encrypt sensitive data)
2.Event Monitoring (Detailed data & Monitoring)
3.Field Audit Trail (Prevents Data loss)
Platform Encryption :
1.Encrypt sensitive data when it's stored at rest in the salesforce cloud.
it means encrypts data metadata layer at place where it is stored.
In database it stored in an encrypted manner.
2.Support customer-controlled encryption key lifecycles.
Manage the lifecycle of data encryption keys.
Note :
Data stored in many standard and custom fields and in files and attachments can be encrypted using an advanced Hardware Security Module-based (HSM)
key derivation system, so it is protected even when other lines of defense have been compromised.
Tenant Secret Key :
Generated and rotated by customers. A New Tenant Secret can only be generated once every 24 hours in a production
organization and every 4 hours in sandbox environment. The option is disabled, if the Tenant Secret is generated in last 24 hours
in production and 4 hours in sandbox environment.
Master Secret Key :
Generated and rotated by Salesforce.
Master secrets used in the key derivation function are rotated with each major Salesforce release.
How Platform Encryption works ?
The salesforce user submits a save request the first thing that gets invoked is the encryption service.
The encryption service checks if there is any encryption policy applied to that particular operation.
If yes it takes in the cache if there is a encryption key available for encryption.
If not it sends a request to the key derivation server which generates a key of the tenant secret which
is generated in the particular org.
The Master secret which is generated at the start of every release by salesforce itself.
so it generates a encryption key and it sends it sends back to the encryption service.
Now as soon as the encryption service receives the encryption key it generates a random initialization vector
which is used to encrypt the data.The data which is encrypted and the initialization vector against that particular
operation gets stored in the salesforce.
Probabilistic Encryption :
By default, Salesforce encrypts data using a probabilistic encryption scheme.
Probabilistic encryption is the use of randomness in an encryption algorithm so that when encrypting the same text several times,
it will, in general, yield different cipher texts.
Probabilistic encryption is so secure that it can often cause issues when logic is executed in the database or when encrypted values are compared to a string or to each other. When these types of configuration
changes are made within a Salesforce org, filtering isn’t possible because the data has been turned into random, patternless strings.
For example, you might run a SOQL query in custom Apex code against the Contact object, where LastName = ‘Jones’.
If the LastName field is encrypted with probabilistic encryption, you can’t run the query because each instance of the value
‘Jones’ represents a different text string.
It is recommended to use probabilistic encryption whenever data in a field will not need to be filtered on.
Deterministic (Filter-Preserving) Encryption
Deterministic encryption addresses the issue with probabilistic encryption by securing the Salesforce org while retaining the
benefits of filtering data.
To be able to use filters when data is encrypted, we have to allow some patterns in our data.
Deterministic encryption uses a static initialization vector (IV) so that encrypted data can be matched to a
particular field value. The system can’t read a piece of data that’s encrypted, but it does know how to retrieve
the cipher text that stands for that piece of data because of the static IV. The IV is unique for a given field in a given org
and can only be decrypted with your org-specific encryption key. The Salesforce Shield Platform Encryption at rest approach
is to expose just enough determinism to enable users to filter on encrypted data while limiting it enough to ensure that a
given plain text value does not universally result in the same cipher text value across all fields, objects, or orgs.
In this way, deterministic encryption only decreases encryption strength as minimally necessary to allow for filtering.
Deterministic encryption allows for the user to specify if case sensitivity on record values needs to be accounted for 2 Types
of Deterministic Encryption:
Case-Sensitive – Allows for the ability to filter data on a case-sensitive basis. ‘ACME’ and ‘Acme’ will be
considered 2 unique values and the encryption scheme would use different cipher text strings to identify these 2 records.
Case-Insensitive – Allows for the ability to filter data but does not factor the case of the value. ‘ACME’
and ‘Acme’ would be considered the same value and the encryption scheme would use the same cipher text value
for both (assuming the record is in the same field / object / org)
Note :
What’s Data Encryption?
Data encryption is the process of taking information in readable form and translating it to a non-readable form.
It converts data into a secret code and is the most effective way to achieve data security. To read an encrypted file,
you must have access to a secret key or password that enables you to decrypt it.
Unencrypted data is called plain text; encrypted data is referred to as cipher text.
When data is encrypted, each bit of data is turned into a fully random cipher text string.
Encryption will not generally impact users who are authorized to view the data.
Deterministic(Static IV)
ex :
value cipher Text
BOB 1234az96
BOB 1234az96
Probabilistic(Random IV)
ex :
value cipher Text
BOB 1234az96
BOB 6924wh12
Event Monitoring :
1.Monitor data loss
2.Increase adoption
3.Optimize performance
Event monitoring lets you to easily see what data users are accessing, from what IP address, and the actions done to that data.
e.g. API calls, user logins, users who are running reports, exporting reports, downloading files, and etc.
Event Monitoring data can be accessed via the API.
Use the SOAP API and REST API resources to retrieve event log files that contain information useful
for assessing organizational usage trends and user behavior.
You can track up to 28 different event types. Log data is read only. You can’t insert, update, or delete log data.
You can access those data via API and pull the data into any visualization tools. For example Salesforce Analytics.
Field Audit Trail :
1.with up to 60 fields per object selected for tracking changes.
2.Tracked changes may be displayed in a related History list.
3.Stored in a related object for upto 18 months.
Note : Any historical data that is captured before platform encryption
was enabled is still in readable state.it is not encrypted.
Any data that was created or updated prior to enabling platform encryption
that is still in readable mode. If you want to get it encrypted we need to reach salesforce.
User with "Manage Encryption Keys" Permission can generate,export,import and destroy organization-specific keys.
Monitor the key management activities of these users regularly with the setup audit trail.
Protected fields are only visible to the users who have the “View Encrypted Data” permission. Encrypted data can only be accessed with appropriate Tenant Secret.
Considerations :
1.Custom Fields - You can't use encrypted custom fields in criteria-based sharing rules,filtering or sorting contexts.
2.SOQL/SOSL - Encrypted fields that use encryption scheme can't be used with aggregate functions & few SOQL and SOSL clauses.
3.Portals - If a portal is enabled in your organization,you can't encrypt standard fields.
If legacy portals are active, shield platform encryption can't be enabled.
4.Field Audit Trail - Data in a previously archived Field Audit Trail isn't encrypted when you turn on Platform Encryption.
5.Apps like Commerce cloud, Quip, Marketing Cloud, Salesforce CPQ etc. don't support data encrypted with Shield Platform encryption.
Platform Encryption :
=====================
1.Advanced Settings :
For encryption policy tasks, also require that admins have the Manage Encryption Keys permission.
Deterministic Encryption
Use deterministic encryption when you want to filter on encrypted data.
Apply this scheme to specific fields from the Encryption Policy page.
Allow BYOK to Opt Out of Key Derivation
Lets you disable Salesforce’s key derivation process, and use your uploaded key material as the final data encryption key.
Encrypt Custom Fields in Managed Packages
Lets you encrypt custom fields in installed managed packages.
Encrypt Field History and Feed Tracking Values
Includes field history and feed tracking changes in data encrypted during the synchronization process.
2.Encryption Policy
Shield Platform Encryption also supports custom fields in installed managed packages.
Apply encryption to custom fields from the management settings for each object.
For best results, encrypt the least number of fields possible. When you add encryption to a field, all new data in that field is encrypted.
3.Encryption statistics :
we get to know that the data which already exists is encrypted (or) not.
which records in my org are encrypted and how many are still in readable state.
we can gather statistics once in every 24 hours.
4.Key Management
Salesforce allows us to generate a tenant secret or else we can go ahead and import our own key which is generated by some other external systems.
Note :
As soon as generate a new key, the first key becomes archived.
All 50 keys available in org, of which only one can be active either could be archived or destroyed state.
No comments:
Post a Comment