Securing Data in Salesforce Marketing Cloud – Part Two of Three

Introduction

Thanks for joining us for the second installment of “Securing Data In Salesforce Marketing Cloud” (Part One is located here)! This informative article is part of a three-part series created by one of Devs United’s knowledgeable Technical Architects.

Part Two covers the advantages and considerations of the following security features in Marketing Cloud:

  • Tokenized Sending
  • Token API Security
  • Basic Authorization
  • OAuth

 

Tokenized Sending

Tokenized sending allows you to use contact data you deem too sensitive to store in your Marketing Cloud account database due to laws, regulations, or security policies in your messaging activity. This process allows you to take information from your own data systems and transmit it to the Marketing Cloud only at time of send via an API call. By way of example, this sensitive information can include the following attributes: 

  • Personally Identifiable Information (PII)
  • Protected Health Information (PHI)
  • Any other information you wish to retain on your own servers instead of the Marketing Cloud

 

Instead of storing sensitive information in your Marketing Cloud account database, your account will store a single token per send attribute. This token resembles a standard email address or phone number, but does not include any information about the contact.

Most of the work to implement tokenized sending falls to you and your internal systems. Review these prerequisites to implement this feature correctly. Current Marketing Cloud users will need to create a plan to convert clear send data into tokens and remove applicable sensitive attributes.

This process occurs in system memory, not in your account database. The Tokenized Sending process injects the fully rendered message into the Marketing Cloud MTA (mail transfer agent), which is the first of many MTAs to handle the message before it reaches the final destination. The Tokenized Sending environment does not include these additional MTAs, which can log messages passing through their servers.

You can also store non-sensitive contact information for use in segmentation and other activities. Tokenized sending permits personalized sending and lets these contacts interact with journeys, events, and activities. You can segment and filter contacts containing tokenized information.

Any tracking and deliverability information resides in your Marketing Cloud account database for use without referencing any sensitive information. This feature relies on other data types (such as a subscriber key or subscriber ID).

Email Send Example

 

Token API Security

 

Basic Authorization

Tokenized sending supports username and password authentication. Configure your endpoint to listen on port 443. Provide the credentials to your Marketing Cloud relationship manager when implementing your API framework.

 

OAuth

OAuth (Open Authorization) is an open protocol that provides secure API authorization from applications in a simple and standardized way.

The first step in any API-based integration is getting an OAuth access token to authenticate your calls.

Using the client ID and client secret from the installed package, call the REST Auth service to obtain an OAuth access token for authenticating your API calls. The Marketing Cloud provides a username and password to an OAuth endpoint and provides the resulting bearer token when accessing information from your data system. Implement this functionality with the assistance of your Marketing Cloud relationship manager.

Tokenized sending supports the client credentials grant specified in the OAuth2 specification. The Marketing Cloud provides a username and password to an OAuth endpoint and provides the resulting bearer token when accessing information from your data system.

 

Advantages:

  • Tokenized sending functions as part of any account type. It operates as an enterprise-wide configuration across parent and child business units.
  • You must develop the REST API calls for your data system to send the correct information at send time. These calls do not occur within the REST API framework provided by the Marketing Cloud.
  • Use the provided API specifications for getting and resolving tokens. You must develop your code around these specifications for this feature to work.
  • This feature requires that your REST API implementation must use HTTPS (SSL, port 443).
  • Your REST API implementation should handle up to 50 connections simultaneously and resolve batches of up to 500 tokens for each connection.
  • Each REST API connection should resolve tokens and return a response within 60 seconds.
  • Tokenized sending uses token-to-send attributes as a 1:1 relationship. You must create tokens, even when the subscriber is new or opting-in, and maintain the mapping of tokens to clear subscriber data.
  • All automatically processed STOP and unsubscribe requests from your subscribers require tokens. If your Get Token API (for SMS MOs) is unavailable or does not provide a token, you assume the responsibility to manually unsubscribe your subscriber.
  • This feature requires a subscriber key value for each contact in your account. Contact your relationship manager to ensure your Marketing Cloud account uses the subscriber key feature.
  • Tokenized sending supports this email functionality:
  • File-based imports
  • Auto-response and forwards from Reply Mail Management
  • Bounce tracking and categorization from Bounce Mail Management
  • One-click unsubscribe
  • Addition to the All Subscribers list (using the tokenized email message value)
  • Sends to Subscriber Lists
  • Sends to Data Extensions
  • Sends to Data Extensions using Data Filters
  • Triggered Sends (you must provide tokens, not email address)
  • Return Path Seed Lists
  • Tokenized sending supports this MobileConnect functionality:
  • File-based imports
  • Stops and unsubscribe (you must provide the Get Token API)
  • Send to All Contacts list
  • Send to Mobile List
  • Pass mobile numbers from mobile-originated messages to your system (you must provide the Get Token API)
  • Triggered Sends
  • No Token Queue for MO SMS Messages:
    • If your GET Token API does not provide a token to the Marketing Cloud after five tries, the system will log the message in a No Token Queue. This queue ensures you can still handle STOP messages and other important communications. You can also set up a custom data extract to retrieve the log.

 

Considerations:

  • This feature requires Marketing Cloud enablement to function. Contact your relationship manager to use tokenized sending.
  • You must log all request and response payloads to the Marketing Cloud.
  • You must monitor your production server and connectivity to the Marketing Cloud.
  • You must also test your REST API implementation before deployment using the provided testing harness.
  • You must also whitelist Marketing Cloud IP addresses to ensure proper communications between your data system and the Marketing Cloud. 
  • Tokenized sending will not function with these features:
  • MobilePush, GroupConnect, or Marketing Cloud Connector
  • MobileConnect QueueMO SMS API, and MessageContact SMS API
  • Other data privacy features, such as field-level data encryption or data obfuscation
  • Journey Builder activities when not storing decisioning criteria in a clear state or in the Marketing Cloud
  • Segmenting, filtering, or querying when not storing criteria in a clear state or in the Marketing Cloud
  • Execution of Service Level Agreements (SLAs) specifically for sending due to the inclusion of outside servers within the process
  • The Marketing Cloud will never create a new token from a clear email address or mobile number. You will always create a token for every use case.

 

Conclusion

Join us again for Part Three of “Securing Data in Salesforce Marketing Cloud,” where we will continue to discuss some of Marketing Cloud’s security features. A Downloadable PDF of the full article will be made available upon the final release of the series!

Click the link to go to the first part of this series! >> [Part One]

 

Reference links:

Marco Murabito