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 RampID packets from within an instance of a client-owned cloud infrastructure so that the client’s consumer data are never exposed to an external network, while still enabling full use of the LiveRamp platform for collaboration, activation, and measurement activities. The RampID packets produced by the application cannot be decoded back to the original consumer identifiers.
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 for your needs.
How Vault Service Works
Workflow
See the diagram below for an overview of the Vault Service workflow.
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 RampIDs and packaged into a RampID packet.
Supported Fields
Identifier fields:
Maximum of three plaintext and/or three SHA256-hashed emails per record.
Maximum of two plaintext mobile phone numbers per record.
Maximum of one plaintext landline phone number per record.
Maximum of one firstname, last name, postcode.
CID (user/CRM ID) are optional.
Attribute fields:
Attribute fields are optional, not including any is a supported configuration.
Maximum of 500 attribute fields in a single file.
Attribute data can come in the form of a string, numeral, enum, etc..
Be sure to replace ATTRIBUTE_1 … N with the name of your CRM attributes.
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|SHA256EMAIL1|SHA256EMAIL2|SHA256EMAIL3|MOBILE1|MOBILE2|LANDLINE1|FIRSTNAME|LASTNAME|POSTCODE|ATTRIBUTE_1|...|ATTRIBUTE_N
The application supports three file formats: CSV, PSV, TSV.
The above input will produce a file with the following output:
CID|RAMPID_PACKET|ATTRIBUTE_1|...|ATTRIBUTE_N
RampID Packets
RampID s are LiveRamp’s proprietary, pseudonymous identifiers for representing individuals. RampID creation involves hashing, salting, and private key encryption in order to prevent consumer data from being re-identified. RampID s form the basis for using the LiveRamp product. Once your data has been converted to RampID s you are able to use the LiveRamp platform for collaboration, activation, and measurement activities.
LiveRamp’s Vault Application produces RampID packets in your environment. Packets are produced by bundling individual RampID s 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 RampID ) 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 RampID s are loaded into the client’s LiveRamp account.
The diagram below shows how the Vault Application creates RampID packets.
Vault Service Security
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.
Vault Service Implementation Methods
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.
Figure 12. Private Cloud Roles and ResponsibilitiesSelf-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.
Figure 13. Self-Managed Cloud Roles and Responsibilities
Private Cloud
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 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
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 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.