Links

How it Works

Architectural Components

Below is an overview of the different components that make up the NIghtfall Salesforce DLP solution and how they interact.
Nightfall App
The Nightfall App is a connected app published on AppExchange which enables authentication between a customer’s Salesforce account and Nightfall services.
Apex Triggers
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.
Realtime DLP Streaming Webhook
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
Workflow Service
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.
The activity limits of the workflow service allows Nightfall to control API usages of both Salesforce instances and Nightfall backend services.

Data Flows

Setup and Policy Creation

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.

Real Time Updates From Salesforce Data Flow

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.
This Apex code will set auth headers with the shared API key and call Nightfall’s Queuing Service which ensures the execution of policies, even in the event the Nightfall Salesforce DLP service is unavailable.
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.

Handling Attachments

In cases where an attachment is involved, there will be the additional step in the flow of transferring the attached file for asynchronous scanning.

Manual Remediation Data Flow

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.

Security

Below is an overview of the solution as provided for the purpose of a security review with Salesforce.
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).
Nightfall DLP solutions enable integration between Salesforce and Nightfall’s backend services. For this purpose we have a connected app and Apex triggers in the Nightfall DLP package. These Apex triggers make a callout to nightfall’s public webhook which further enables scanning of Salesforce content.
As part of the package, we have Apex triggers on 7 objects:
  • Account
  • Task
  • Case
  • EmailMessage
  • FeedComment
  • FeedContent
  • ContentVersion
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.
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.