Policy Driven Data Control

For many applications the sensitive data being encrypted has many different access levels. For example, some data should only be accessible by certain teams or departments within a company. Or form field data that contains personally identifiable information (PII) should be only be accessible by a different set of users than file attachments. Deciding who has access to what data is one of the first decisions to be made when implementing the Data Control Platform in your application.

One best practice for solving this is to think about which groups make the most sense for your application. Most applications will have multiple groups in order to limit over-sharing encrypted data with too many users. Because groups in the Data Control Platform are low cost, using smaller, focused groups can be a better way to manage data access than putting all users into a single large group.

However, implementing the connection between access level and which users/groups should have access can be tricky. This logic is likely to change often as new access levels are introduced and new teams or departments are created. The code to do this mapping can be error prone and brittle, and it can introduce bugs as data labels and groups change. And keeping this logic consistent between various SDK usages and languages can add even more overhead.

Data Control Platform Policies

In order to make this process easier, the Data Control Platform supports a feature called Policies that makes it easy to define a centralized list of data labels and rules that automatically determine which users and/or groups should be given access when encrypting data. A Policy is defined upfront, so that subsequent calls to the Data Control Platform SDKs need only provide the labels of the data being encrypted. When this call is made to the SDK, the labels are evaluated against the Policy rules, producing a list of users and groups to whom data will be encrypted.

This takes the decision making of who to encrypt data to out of the developers’ hands and makes it a centralized administrative configuration. When changes to the Policy are saved, they will be available across all SDK usage and don’t require code rollouts to apply.

Creating a Data Control Platform Policy

Policies are created on a per-segment basis. Every segment in your Data Control Platform project can have a unique policy that applies only to that segment. To get started creating a new Policy, log into the IronCore admin console, select the segment you want, and add a new Policy.

Policy Data Labels

Policies are based on data labels of the data being encrypted. Data can contain up to three facets of labels, Classification, Sensitivity, and Data Subject. Only the Classification and Sensitivity labels are required. Any number of labels can be defined for each facet and used within Policy rules, but an individual data item being encrypted can only contain a single label for each facet. In the Policy editor, add all of the labels you support for each facet you need.

Policy Rules

Once the labels for your data are defined, the next step is to add rules which map a Classification : Sensitivity : Data Subject tuple into a list of user and/or group IDs that should be used when encrypting data that matches those labels. A Policy can have any number of rules, but keep in mind that the order of the rules matters. The first rule in the list that matches will be used, so be sure that the order of your rules makes sense. It’s also best practice to have a catch all rule at the bottom of your list that uses the *Any* wildcard to match for any combination of facets that wasn’t covered by an earlier rule.

SDK Usage

Once you have a Policy defined, the next step is to use the Policy options when encrypting data in the Data Control Platform SDKs. When encrypting data with an SDK, provide the tuple of labels that apply to the data being encrypted.

Rust

    let message = "this is my secret which has some labels.";
    let data_labels = PolicyGrant::new(
        Some(Category::try_from("PII")?),
        Some(Sensitivity::try_from("PRIVATE")?),
        None,
        None,
    );
    let encrypted_result = sdk
        .document_encrypt(
            message.as_bytes(),
            &DocumentEncryptOpts::with_policy_grants(None, None, data_labels),
        )
        .await?;

JavaScript

const message = "this is my secret which has some labels.";
const labels = {
    category: "PII",
    sensitivity: "PRIVATE"
};
sdk.document.encrypt(IronWeb.codec.utf8.toBytes(message), {policy: labels});

This SDK call will succeed if the data labels provided matched a valid Policy rule and the document was successfully encrypted to the resulting users and/or groups. This call can fail for two reasons: first, if the labels provided didn’t match a Policy rule and second, if the users/groups that the rule matched to didn’t exist. This diagram shows the flow for what happens when using the Policy calls in the SDK.

Encrypting a document using a Policy doesn’t restrict the ability to encrypt the documents to direct users and groups as well. You can use any combination of direct user and group IDs as well as the ones that resulting from the Policy evaluation.

User and Group Placeholder Values

When providing the IDs of groups to encrypt to with a Policy, certain placeholder items can be used within the group ID to make it more dynamic and to support advanced use cases. Usually these placeholders are used if users in your system have their own personal groups, which can be used to support GDPR use cases.

%LOGGED_IN_USER%

The %LOGGED_IN_USER% placeholder in a group ID will be replaced at runtime with the ID of the user who is performing the encryption operation.

%USER%

The %USER% placeholder in a group ID will be replaced with the value supplied in the substitute_user option provided in the Policy object provided to the SDK. This use case allows for a server-side process to encrypt to a policy on behalf of a user.