How it works
Nightfall DLP for Salesforce provides you with visibility into all data within your Salesforce instance.
Below is an overview of the different components that make up the Nightfall Salesforce DLP solution and how they interact.
The Nightfall App is a connected app published on AppExchange which enables authentication between a customer’s Salesforce account and Nightfall services.
The Nightfall Salesforce DLP solution makes use of Apex triggers to enforce Nightfall policies on data created and updated by end users in Salesforce.
Async triggers are created on the {object}ChangeDataEvent which are asynchronous and live outside of the transaction in Salesforce. Therefore failures of these won’t impact salesforce functionality. The primary purpose of this trigger is to send the event to the webhook in its original form.
As part of the integration, a public webhook is created so events from Salesforce triggers can be sent to Queueing Service for real time updates. The Queueing Service is a high availability service ensuring that all messages will reach the Nightfall DLP Service.
Nightfall Salesforce DLP Service
Nightfall has created a dedicated service for handling Salesforce DLP related functions as:
- Storing and managing client’s OAuth token from the Salesforce instance
- Receiving updates (with or without data in case of attachments) from streaming client
- Scheduling workflows to fetch complete/partial required data from salesforce
- Exposing APIs to create and update Nightfall policies with Salesforce related configuration
- Calling the Nightfall backend to:
- Create and update policies
- Transfer files to scan data
- Send notifications
- Store analytics data
A high availability workflow service is used to trigger historical scans and real time scans. These workflows will have several steps including fetching required data from Salesforce, sending files/data to file sage for scanning, calling the Nightfall notification service, and scheduling redaction actions.
- Fetching data from Salesforce
- Sending files/data to file sage for scanning
- Calling the Nightfall notification service
- Scheduling redaction actions.
The activity limits of the workflow service allows Nightfall to control API usages of both Salesforce instances and Nightfall backend services.
The following sequence diagrams describe the flow of data between Nightfall and Salesforce when the system is being set up. From nightfall user interfaces, users can either activate a new salesforce instance or any child organization.
During activation, Nightfall will direct users to authenticate with Salesforce through OAuth. Once authenticated, NIghtfall will store the generated access tokens. During this, Nightfall will also generate a unique api key for each Salesforce org and update this in the org’s custom protected settings.
Once a user requests the creation of a Policy, NIghtfall validates the object name and existence of the selected field. If the Policy is valid, then Salesforce DLP service will call the Nightfall Policy service to create the required Policy.
The following sequence diagram shows the sequence of events within the overall Nightfall Salesforce DLP solution that gets triggered when data is entered by end users into the system. Not only does this show the robustness of the overall architecture, but it also allows you to understand how and when Salesforce will communicate with these different systems.
When a user updates any fields in Salesforce, asynchronous Apex code will be triggered.
The Queueing Service will invoke the Nightfall Salesforce DLP service, which will validate the authentication header and then fetch the active policies defined in Nightfall.
Nightfall’s scanning workflow will be triggered using a Workflow Service. The content will be scanned, remediation action as per policies will be taken, such as sending a redacted version of field values to Salesforce (via the Workflow Service). Additionally notifications will be sent via Nightfall.
In cases where an attachment is involved, there will be the additional step in the flow of transferring the attached file for asynchronous scanning.
In cases where automatic remediation is not possible, users will instead handle alert notifications through the Nightfall User Interface to start a workflow to patch (i.e. update) the records in Salesforce that triggered the policy violation and create an audit trail within Nightfall.
Our solution is an API only app that uses a web application (app.nightfall.ui) and a web service (app.nightfall.ai/salescloud/webhook/v1).
As part of the package, we have Apex triggers on 7 objects:
These Apex triggers make a HTTP callout to a Nightfall hosted URL (app.nightfall.ai/salecloud/webhook). Based on these events, our backend service triggers workflows to scan the content for any PII. We also have one custom object (ApexLog) and a custom protected setting (WebhookSetting). The purpose of the ApexLog custom object is to capture error logs from our apex triggers. WebhookSetting stores API keys which are being used as a Basic authentication on the http callouts.
A custom object (ApexLog) and a custom protected setting (WebhookSetting) are also built in. The ApexLog custom object captures error logs using apex triggers. WebhookSetting stores API keys that are used for basic authentication on http callouts.
We ask our client’s to create a dedicated user account with system admin privileges for NIghtfall. During the setup processes, Customer’s will authorize Nightfall’s connected app via OAuth. On Successful OAuth, Nightfall backend receives the auth token and refresh tokens. These tokens are later encrypted with AES256 encryption and stored into the Nightfall database. Nightfall deletes existing tokens once a customer org gets de-provisioned.