LiveRamp Vault Service

Vault Service Overview

LiveRamp strives to provide best in class data security and privacy without limiting the capabilities of our clients’ data. The LiveRamp Vault Application has been developed to allow clients to access the benefits of LiveRamp products (such as Safe Haven) without having to move their consumer data outside of their control.

The application enables clients to generate IdentityLink (IDL) packets from within an instance of a client-owned cloud infrastructure so that the client’s consumer data is never exposed to an external network, while still enabling full use of the LiveRamp platform for collaboration, activation, and measurement activities. The IdentityLink packets produced by the application cannot be decoded back to the original consumer identifiers.

Traditional LiveRamp Client Interface
Figure 12. Traditional LiveRamp Client Interface


LiveRamp Vault Service Interface
Figure 13. LiveRamp Vault Service Interface


This is an exciting addition to LiveRamp’s product suite that enables LiveRamp to better fit the needs of customers with stringent privacy controls. While it isn’t necessarily better for every client, it’s a solution that opens new ways for LiveRamp to work with clients. Please speak with your LiveRamp rep to see if the Vault Service is suitable to your needs.

Workflow

See the diagram below for an overview of the Vault Service workflow.

Vault_Service-Vault_Service_workflow_diagram.png

Uploading Data

The Vault Service process starts when you upload a file containing your customer records to an S3 input bucket that you own and control. Each row of the file should contain the identifiers you want to have translated into IDLs and packaged into an IDL packet.

Note: Support for additional identifiers is coming soon. Please make sure that for the time being the only identifiers included in input files are email addresses and CIDs. Speak with your LiveRamp rep if there are identifiers other than email address that you are interested in sending.

Supported Fields

  • Up to three plaintext emails per record.

  • An optional CID (custom ID).

  • Attribute data in the form of a string, numeral, enum, etc...

Example File Structure

An example header row is shown below. Note: You don't have to include values for every identifier for each row. ATTRIBUTE_1… N will be replaced with your CRM attributes.

CID|EMAIL1|EMAIL2|EMAIL3|ATTRIBUTE_1|ATTRIBUTE_2|ATTRIBUTE_N

The application supports three file formats: CSV, PSV, TSV.

The above input will produce a file with the following output:

CID|IDLPACKET|ATTRIBUTE_1|ATTRIBUTE_2|ATTRIBUTE_N

IdentityLink Packets

IdentityLinks (IDLs) are LiveRamp’s proprietary, pseudonymous identifiers for representing individuals. IDL creation involves hashing, salting, and private key encryption in order to prevent consumer data from being re-identified. IDLs form the basis for using the LiveRamp product. Once your data has been converted to IdentityLinks you are able to use the LiveRamp platform for collaboration, activation, and measurement activities.

LiveRamp’s Vault Application produces IdentityLink packets in your environment. Packets are produced by bundling individual IdentityLinks for a given client record and then adding an additional layer of encryption that involves a randomly-generated code. The randomly-generated code provides an added layer of protection, ensuring that the same client record (with the same IDL) will produce a packet which looks different every time the application runs.

The packets produced by the application are sent to LiveRamp, where they are unpacked and the included IdentityLinks are loaded into the client’s LiveRamp account.

The diagram below shows how the Vault Application creates IdentityLink packets.

Vault_Service-IDL_packet_creation_diagram.png

No matter which method you use to implement the Vault Service, the security protocols listed below apply. See the additional sections for information on the specific process for each implementation method.

  • The Vault App is distributed as a Docker image. Clients obtain the docker image from LiveRamp’s AWS ECR repository.

  • The application will need read-only access to an S3 input bucket, and write access to an S3 output bucket. The S3 input bucket is owned by you `(the client) and the S3 output bucket is owned by the LiveRamp platform.

  • LiveRamp manages the keys and secrets. The application has read-only access to these resources.

  • The application uses AWS PrivateLink for accessing resources managed by core LiveRamp platform (keys, secrets, output bucket, and docker registry), which means that traffic is never exposed to the public internet.

  • For troubleshooting purposes, the copy of Vault App logs will be stored in an S3 bucket owned by LiveRamp.

  • Except for the AWS PrivateLink network endpoint, the Vault App doesn’t require access to any other network resources.

There are two methods that can be used to implement the Vault Service:

  • Private Cloud, where LiveRamp manages the infrastructure needed to run the vault application from within a cloud project controlled by your company. This provides the best of both worlds: the ease of a managed service, within the privacy of your own cloud project. This is our recommended method for clients who might not have the engineering resources required to use the Self-Managed Cloud implementation.

    Private Cloud Roles and Responsibilities
    Figure 14. Private Cloud Roles and Responsibilities


  • Self-Managed Cloud, where LiveRamp provides a simple Docker image for your engineering team. Your team would be responsible for setting up an environment to run the Docker container. This method is only recommended for clients that have the engineering resources to provide ongoing support and maintenance.

    Self-Managed Cloud Roles and Responsibilities
    Figure 15. Self-Managed Cloud Roles and Responsibilities


Private Cloud Implementation

Under the Private Cloud method, the Vault App is built and distributed as a Docker container image. The application utilises two S3 buckets (input and output S3 buckets) in addition to AWS PrivateLink for securely accessing keys and secrets from LiveRamp managed AWS Key Management Service and AWS SecretsManager resources. AWS PrivateLink is used for pulling Docker images and storing data and copy of logs to S3 buckets (S3 output bucket and S3 monitoring bucket).

The processing is initiated by uploading a file, either from AWS Console or AWS CLI, to the input S3 bucket. The upload creates an event that will start the Vault App as an on-demand compute engine (AWS ECS Fargate task) pre-configured for running our application as a Docker container. The application will process the uploaded file and write the resulting file in the output S3 bucket, where it will be sent to downstream applications (i.e. SafeHaven).

After processing a file, the Vault App stops and doesn’t consume resources (no costs when not processing). Uploading multiple files will create multiple Fargate tasks - one for each file, and processing will be done in parallel.

Private Cloud Workflow Diagram
Figure 16. Private Cloud Workflow Diagram


Private Cloud Roles and Responsibilities

Because the application lives in a client-controlled cloud environment which LiveRamp doesn’t have access to, we work closely with your IT team to install and update the application and runtime environment. LiveRamp publishes regular updates, and a built in update-pull mechanism will keep the Vault App up to date. The Vault App updates will be controlled by LiveRamp without need for accessing your cloud environment. The runtime environment (infrastructure) changes, if needed, will require LiveRamp to either work closely with your IT team or get temporary access to your cloud environment.

In the case of troubleshooting, LiveRamp tech support is on hand to assist. LiveRamp can provide support via consultory services, or for hands-on service you can grant us temporary access to the application execution environment.

Self-Managed Cloud Implementation

The Vault App is built and distributed as a Docker container image. The application has dependencies on two S3 buckets (input and output S3 buckets) and uses AWS PrivateLink for accessing keys and secrets from LiveRamp managed AWS KMS and AWS SecretsManager resources. AWS PrivateLink is used for pulling Docker images and storing data and copy of logs to S3 buckets (S3 output bucket and S3 monitoring bucket).

There are many ways to implement this, but below are two suggested setups for Vault App:

Option 1. - AWS ECS Fargate task setup

Under the ECS Fargate task setup option, you initiate the process by uploading a file, either from AWS Console or AWS CLI, to the input S3 bucket. The upload creates an event that will start the Vault App as an AWS ECS Fargate task. The application processes the uploaded file and writes the resulting file in the output S3 bucket.

After processing a file, the Vault App stops and doesn’t consume resources (no costs when processing is not taking place). Uploading multiple files creates multiple Fargate tasks - one for each file - and processing is done in parallel.

Option 2. - AWS EC2 setup

This setup requires an AWS EC2 Linux instance with installed Docker, and requires running the Vault App as a Docker container. The application runs and periodically checks the input S3 bucket for newly uploaded files. When a file is uploaded, either from AWS Console or AWS CLI, the application starts processing the file.

If multiple files are uploaded they will be processed one by one (no parallel processing in this method). The resulting file is written to the output S3 bucket. The application would require access to permanent storage to track already processed files. In this setup, there are monthly costs for running an EC2 instance.

Self-Managed Cloud (AWS EC2 Setup) Workflow Diagram
Figure 17. Self-Managed Cloud (AWS EC2 Setup) Workflow Diagram


Self-Managed Cloud Maintenance

Because the application lives in your cloud environment, we would work closely with your IT team and support them during the installation and updates of the application and runtime environment. LiveRamp will publish regular application updates, and a built-in mechanism will force updates. You will have to regularly update the Vault App. The runtime environment (infrastructure) changes, if needed, will require LiveRamp working closely with your IT team.

In the case of troubleshooting, LiveRamp tech support is on hand to assist. LiveRamp can provide support via consultory services.