Salesforce Data Protection

 

When it comes to protecting confidential information in salesforce, there are different states where data needs a layer of protection. 

• Sometimes we need to protect the information on their mobile computers or laptops in case they are lost or data resides in a Salesforce org.

• Sometimes we want to keep their documentation protected on file servers so that it can even be protected from improper access by IT staff. 

• Sometimes we need to protect documentation when it travels attached to an email because they use managed email servers or in the cloud. Sometimes we need to protect the documentation when it is sent to third parties or even internally in order to minimize the possibility of it being copied, unprotected, or accessed by inappropriate users.

Data can change states quickly and frequently, or it may remain in a single state for the entire life cycle of a computer. We can consider three states for information or data:

1. Data at rest: Data at rest means data that is housed physically on computer data storage in any digital form (e.g. cloud storage, file hosting services, databases, data warehouses, spreadsheets, archives, tapes, off-site or cloud backups, mobile devices etc.). 

2. Data in transit: Data that travels through an email, web, collaborative work applications such as Slack or Microsoft Teams, instant messaging, or any type of private or public communication channel. It’s information that is traveling from one point to another.

3. Data in use: When it is opened by one or more applications for its treatment or and consumed or accessed by users.

How to protect data in salesforce? 

Data must be protected in each state & there are different ways to protect it in each state and it has some challenges in each state. Encryption, permission management & identity control are the different ways to protect the data. In the first place, we can restrict unauthorized access using Identity & Access control, then we can control what can be accessed and then using encryption, we can protect data at rest.

Protecting Data at Rest-

With the help of Shield encrypt, we can secure data at rest.

 

Challenges of Data at Rest Protection

 There are lot of challenges when it comes to protecting idle documentation:

• The data can be stored in different media and equipment: Important documentation is not only found in the file servers, or document managers, but there may also be copies on the users’ PCs, USB devices, etc.

• Scattered on mobile devices: Mobile phones and tablets are one more work tool that may contain important documentation at rest that must be protected. It must be taken into account that in many cases where sensitive data is managed, the mobile devices in which it is found are not corporate but personal and out of the control of IT departments.

• Inability to control cloud storage: Many storage providers offer encryption and protection of the data they manage at rest. However, the encryption keys are owned by the storage provider and not by the companies that hire them, so control of the documentation stored in these clouds is lost.

• Need to comply with different data protection regulations: Depending on the vertical in which our company operates, it may be subject to stringent data regulations regarding the protection and control over data. For example, patient data in the healthcare sector or customer data in the financial sector is protected by regulations such as EU-GDPR, HIPAA, PCI, etc. depending on the territory. These regulations impose protection policies on data at rest, regardless of whether it is stored in a database, on a file server or on mobile devices.

Protecting Data in Transit-

Data moving between cloud storage and a local file storage point or moving from one network to another is also considered in motion. Data in motion may be moving within a computer system, over a wireless connection or along a wired connection. In addition, files dragged from one folder to another, within an FTP site or emails are considered data in motion.

We are in the age of digital collaboration and there are now plenty of ways to share our data with others. In Salesforce, data can be shared with email, file transfer or communicating with other applications. When a 3rd party tries to hit salesforce, salesforce will not allow access to the Salesforce URL until its authenticated application, you can authenticate using namespace We can protect enforcing Identity and Access management. Using differ different ways like limited access using permission, oAuth 2.0 etc. 

Challenges of Data Protection in Transit

• There are an infinite number of means and channels of communication: These tools are normally in protecting a certain channel such as email, web downloads, etc. but it is complicated to reach any protocol and means of communication.

• Infinity of Cloud applications to protect: If we are talking about a CASB-type approach to secure the data that is downloaded from the cloud, it is very difficult to reach any application. Options are usually available for the most popular cloud applications such as O365, G-Suite, Salesforce, Box, etc.

• Impossibility to maintain control at the receiving end: In the case of email or MFT encryption, once the recipient has received the file and has it decrypted for him, control is lost. They offer point-to-point protection, but no further, with the exception of digital rights protection.

• Difficulty determining what should be protected and what should not: PIt is difficult for a DLP or CASB system to determine what should be blocked or not. Certain rules can be set, but they can result in false positives that block the output of data when necessary.

• Sometimes, a “protect all” approach (with exceptions) is the best policy, for example, in the case of email encryption because if someone compromises an email box we are sure they will access encrypted data, but this is not always possible depending on the type of organization.

Protecting Data in Use

 

As mentioned above, we are talking about data in use when it is accessed by an application for treatment. Normally, behind the application there is a user who wants to access the data to view it, change it, etc. In this state, the data is more vulnerable, in the sense that in order to see it, the user must have been able to access the content decrypted (in the case that it was encrypted).

Challenges of Protecting Data in Use

• Most of the tools that control access to data do so before allowing access, but once validated, as we said above, it is more complex to control what can be done with the data.

• Even if we are limiting permissions on the documentation, if it is being shown to the user in the application, in a viewer, he can always take a picture, for example, although we can mitigate this action through dynamic watermarks on the open document.

• Collaboration platforms that limit rights such as prohibiting downloading or only letting the document be seen, can be efficient when we only need to access the document, but have limitations if we need to modify the document for example with an agile tool on the desktop. In addition, we must not forget that the cloud platform itself has the document decrypted at the time of access and stored in their systems so it is technically possible to access the content of it. This can be a problem when we are talking about confidential data or subject to strict data protection regulations.

Data Masking

• Data masking or data obfuscation is the process of hiding original data with modified content. The main reason for applying masking to a data field is to protect data that is classified as personally identifiable information, sensitive personal data, or commercially sensitive data.

• Data masking is the process of replacing sensitive information with fully functional, dummy data when data is copied from a production environment to a non-production environment.

Why Secure Sandbox Data?

In recent years, expansive new privacy regulations such as the European Union (EU) General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) require companies to make technical and organizational changes to their security practices to ensure compliance. These regulations affect nearly every Salesforce customer. 

In addition, industry-specific regulations such as the Payment Card Industry Data Security Standards (PCI DSS) and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) include strict privacy data protection.

 

Noncompliance and data breaches can result in total loss of customer trust and severe financial and legal consequences, with fines of $5,000–$100,000 per month until a company achieves compliance. GDPR infractions can lead to even larger fines of up to 4% of annual global revenues, or $20 million, whichever is greater.

The Challenge of Securing Sandbox Data

Sandbox environments can contain personal information (PI) and personally identifiable information (PII). PI and PII data include the names of customers, employees, phone numbers, email addresses, physical addresses, Social Security numbers, credit card, and banking details, compensation information, general secrets, and more. Because sandboxes are typically used for development and testing, a larger group of developers, employees, and contractors that can’t typically access production environments might need to be given access to sandboxes. Managing sandbox data privacy often is an afterthought and if implemented can be time-consuming and difficult.

Without special tooling for sandbox data, Salesforce administrators and developers spend considerable time and resources securing full and partial sandbox data. They do so to ensure that the sensitive data in production is carefully controlled as data is replicated from production to sandbox environments.

There are multiple tools available for data masking, you can use 3rd party tools which do the data masking like Datapilier of Flosum etc. 

You can also use the Data Masking manage package to mask the data.

Data Mask Manage package-

Salesforce Data Mask is a powerful resource for Salesforce admins and developers that masks sensitive data in sandboxes.

How Does Data Mask Work?

Data Mask is a managed package that you install and configure in an Unlimited, Performance, or Enterprise production org. You then run the masking process from any sandbox created from the production org. The masking process lets you mask some or all sensitive data and ensures that the data is not replicated in a readable or recognizable way into another environment. Data Mask uses nondeterministic obfuscation to prevent reverse engineering or statistical inference attacks from de-obfuscating the newly rendered data.

Once your sandbox data is masked, you can’t unmask it. This process does not affect your production data, so if you change your mind, you can always refresh the data from production and create a new sandbox org. After you configure Data Mask, you can mask data sets as often as needed.

As the sandbox data is masked, previously determined objects and fields undergo a transformation from sensitive, readable sandbox data to obfuscated data.

1. Install the Data Mask Managed Package

2. Configure Masking-You can configure the masking in one of two ways:

1. Configure it in production, then when a sandbox is created or refreshed, the configuration appears in the sandbox. Or,

2. Configure the masking in an existing sandbox.

3. Give the mask a name, API name, and description. Then, you can choose whether to mask case comments or delete all emails and Chatter feeds.

4. Select the Data to Mask and run 

Identity and Access Management

In the real world of salesforce, we might need to connect other applications seamlessly without compromising security, and Identity & Access Management deal with this complication.

In the below picture, salesforce is communicating with different cloud applications like a workday, mule, and other cloud-based applications. Along with this, it connected with Social clouds like Facebook, Linkedin, or Twitter, and premise systems that might be sitting behind the firewall, and mobile applications. 

In the above flow, There are two questions have been raised apart from Integration:

1. How do you determine the identity (Authentication) of the user to be logged in. For example, if someone logged in to salesforce and wanted to open Facebook, you facebook understand the identity of that user.

2. How do you determine the access (Authorization) of the user?

Identity & Access Management provides the answer to these two questions. Identity & Access Management ensures:

-the right people to get

-the right access

-the right resource 

-at the right time.

Authentication Vs Authorization 

Authentication	Authorization
Process of identifying a user based on a set of verifiable credentials such as username & password.	Determines if a user has permission to access resources on the server.
Process or action of proving or showing something to be true, genuine, or valid.	Verify the access of authenticated user and can grant or deny the access
Authentication means who a person is. These days, authentication is often used as shorthand for authorization and authentication.	Authorization means what a person can do.
Authentication can be done on the server itself or it can be sent to a 3rd party to authenticate.	Authorization cannot be done without authentication
Identify Management deals for authentication.	Access Management deals with authorization.
You control who can access your orgs and who can use apps running on the Salesforce Platform, on-premises, in other clouds, and on mobile devices.	You control what can be accessed in your orgs after authentication.

Benefits of Identity 

You control who can access your orgs and who can use apps running on the Salesforce Platform, on-premises, in other clouds, and on mobile devices with Identity which can help you in different ways:

• Convenience - Employees can log in to a workstation and connect to a Salesforce org without logging in again. In fact, they can have a single login that works for all their web and mobile apps. You can give them one-click access to third-party productivity tools and services, like Gmail or Microsoft Office 365. Users don’t have to remember lots of usernames and passwords.

• Control - Managers and supervisors can have more control over their employees. If you want fine-grained control over who uses what, you can require that a manager or supervisor approve employee requests to access an app or service. And when you need to revoke access to an app, you can do that, too.

• Security - The magic of Salesforce Identity is that more convenience plus greater control adds up to enhanced security. One identity source for user credentials across corporate networks and the web makes it easy for you and other Salesforce admins to monitor and manage usage. Reduce redundant accounts, and you reduce your vulnerability to malicious activity. And with multi-factor authentication, you can be twice as confident that your users are who they claim to be.

Features provided of Salesforce Identity

Identity helps to log in to the system in an easier way without compromising security. There are multiple features that support Salesforce Identity:

• Single sign-on

• Connected apps

• Social sign-on

• Multi-factor authentication

• My Domain

• Centralized user account management

• User provisioning

• Identity Connect

• App Launcher

Identity Standards & Protocols-

There are industry standards and protocols for identity and access management which helps users’ identities secure when they don’t have to sign in to external websites or apps. A standard is just a set of widely agreed-upon practices that industry members follow. A standard can include a protocol that specifies how systems exchange information.

Here are the three protocols that Salesforce and other identity vendors follow to implement identity solutions.

1. SAML

2. OAuth 2.0

3. OpenID Connect

SAML Protocol-

When you want users to move seamlessly between Salesforce orgs and applications without logging in repeatedly, you set up single sign-on (SSO). SAML is an XML-based protocol, which means that the packages of information being exchanged are written in XML.

Here are a couple of examples of SAML in action.

• When you’re logged in to Salesforce and then click the App Launcher to get directly to your Gmail inbox, that’s SAML in action.

• When users who are already logged in to another app can access their Salesforce org without logging in again, that’s also SAML in action.

How does SAML work?

• A user tries to access a service. The service provider sends out a request to the identity provider basically asking, “Hey, is it okay if this user accesses my service?” The identity provider makes sure that users are who they say they are by checking its database and then returning a response—an assertion—saying, “Yes, this user is authorized, and here’s some information about the user.”

• The assertion is the information being sent. An assertion can carry detailed information about a user. It can also contain attributes about the user, like first and last names, contact information, maybe even the job title.

• SAML happens in the background. Your users don’t see any of it. They just click an icon or link and open another app without having to provide additional information or log in again. Sometimes their destination already knows something about them (those user attributes) when they get there.

OAuth 2.0 Protocol

OAuth 2.0 is an open protocol used to allow secure data sharing between applications. The user works in one app but sees the data from another. For example, you’re logged in to your Salesforce mobile app and see your data from your Salesforce org.

Behind the scenes, the apps perform a kind of handshake and then ask the user to authorize this data sharing. When developers want to integrate their app with Salesforce, they use OAuth APIs. Here are a couple of examples.

• A mobile app that pulls contacts from a Salesforce org uses OAuth.

• A Salesforce org gets contacts from another service also uses OAuth.

• Workbench uses oAuth 2.0 protocol for connecting with salesforce.

The following is an example of an app asking the user for permission to access information using OAuth 2.0.

OpenID Connect Protocol

• The OpenID Connect protocol adds an authentication layer on top of OAuth 2.0 to enable secure exchange of user information. Like SAML, OpenID Connect sends identity information from one service to another. Unlike SAML, OpenID Connect is built for today’s world of social networks. Have you ever installed a new app and come across a prompt like "Log in with your Google account"? That app is using the OpenID Connect protocol. When you sign in with Google, you’re not creating an account and another password. Only Google holds that information.

• The app developer used the OpenID Connect protocol to enable social sign-on.For instance, when Google verifies a user’s identity on behalf of another service, it’s authenticating the user. In this way, Google is an identity provider.

• Salesforce builds in support for several major social identity providers, including Google, Facebook, and LinkedIn. If a provider isn’t supported out of the box, you can still use it if it implements the OpenID Connect protocol—Amazon and PayPal, for example.

The advantage of the OpenID Connect protocol for users is that they can reduce the number of separate accounts, usernames, and passwords. On the flip side, developers can authenticate their users across websites and apps without having to own and manage password files. This process makes it that much harder for hackers to compromise user accounts.

Service Providers and Identity Providers

In the process of authenticating users, SAML exchanges identity information between the holder of the information called an identity provider (IdP), and the desired service, called a service provider. For Example- In the case where a user logs in to Salesforce and then accesses Gmail, Salesforce is the identity provider, and Google is the service provider. Salesforce can be both a service provider and an identity provider.

Salesforce as a Service Provider

Authenticated users can flow from an external identity provider into Salesforce. In this case, Salesforce is a service provider—users want to get access to this service, and their identity provider allows them to do so. This Salesforce configuration is common because often your company is already using an identity provider. The identity provider could be one of several on the market, like Microsoft’s Active Directory Federation Services (ADFS), Ping Identity’s PingFederate, open-source Shibboleth, or ForgeRock’s OpenAM.

Users log in from an identity provider and are then redirected to Salesforce (the service provider). In another module, you’ll set up SSO with Salesforce as a service provider and a third-party application as the external identity provider.

Salesforce as an Identity Provider

Authenticated users can also flow from Salesforce to other clouds and apps. In this case, Salesforce acts as an identity provider and provides SSO for users to connect to different service providers.