Accessors (read paths)

Introduction

Accessors are configurable APIs that allow a client to retrieve data from the user store. Accessors are intended to be use-case specific. For example, you might configure two separate accessors GetEmailForMarketing and GetEmailForAuthentication. They enforce data usage policies and minimize outbound data from the store for their given use case.

As an example of data minimization, you might configure an accessor called GetPhoneCountryCodeForAnalytics that returns the country code of a user's phone number when called, instead of the raw phone number. This reduces the sensitivity of the data outside your store, minimizing your surface area for an attack and simplifying compliance.

Accessors can be configured to access either live or soft-deleted data. Soft-deleted data is data that has been deleted but is temporarily retained for a narrow set of purposes, e.g. fraud investigations. See Data Lifecycle for more details.

What Accessors Do

How Accessors Work

1. Data, consents and purposes are stored inside the safety layer boundary (either in UserClouds User Store or an owned-and-operated database like RDS)
2. Data consumers request access by sending context, like purpose or identity, to a use-case specific accessor API
3. Several access policies are evaluated for each user record, using the data passed in context and data in the user object:
   1. Global baseline policy for accessors: Applied to ensure baseline security. Learn more here.
   2. Column-default access policies: Column default policies for all columns accessed by the accessor are applied, unless overridden. Learn more here.
   3. Accessor-specific access policy composition: Applied in addition to the above policies.
4. User data is further filtered according to whether the users have consented to the accessor's data processing purpose.
5. For records where access is granted, the accessor's data transformers transform each column of the outbound data, minimizing the data for the given use case. If no transformer is specified for a given column, the column's default transformer is used. Learn more here.

Structure of an Accessor

At creation time, each accessor is associated with a user record selector, a set of columns, a set of data transformers, a purpose and an access policy.

• The user record selector is a SQL-like clause that specifies which records the accessor should return data for, based on an array of values that are passed at execution time. The accessor's response will only include users that have consented to the accessor's purpose for all non-system columns used in the selector. Since UserClouds does not store consents for system columns, they can be referenced in the selector regardless of accessor purpose / user consents.
• The columns indicate which data fields the accessor will retrieve.
• Each column is associated with a transformer, which tokenizes, minimizes or otherwise obscures the outbound data from that column.
• The purpose is selected from your company's list of data processing purposes. This indicates what the accessor will be used for, e.g. marketing. The accessor will run a purpose check, filtering out user records and data for which the user has not consented to the specified purpose across all columns. The accessor's response will only include users that have consented to the accessor's purpose for all columns being retrieved, and all non-system columns used in the selector. Learn more here.
• The access policy determines the circumstances in which the data can be retrieved. Access policies run on each user record and filter out user records which fail the access policy.

Learn More

For more info on accessors, see:

• Creating an accessor
• Executing an accessor