Cross-Tenant Customer-Managed Keys (CMK)

Important:

The Customer-Managed Keys (CMK) feature is available for eligible OneTrust accounts hosted on a dedicated environment and is subject to additional licensing, terms, and conditions. The CMK feature replaces the Bring Your Own Key (BYOK) feature. Please contact your account representative to learn more about eligibility requirements.

OneTrust supports Cross-Tenant Customer-Managed Keys (CMK) for OneTrust accounts hosted on dedicated environments. CMK empowers users with direct control over their encryption keys, meeting some compliance requirements by giving customer control in the ability to unencrypt their data or not, while maintaining the flexibility and benefits of cloud services. Utilizing Cross-Tenant CMK functionality offers the following benefits:

Enhanced Compliance

Regulatory frameworks and various privacy laws mandate robust data protection mechanisms. Cross-Tenant CMK ensures that customers have the ability to control if the data can be unencrypted by OneTrust in rendering the application for the customers’ users.

Control and Ownership

With Cross-Tenant CMK, customers retain control over their encryption keys. The keys are stored within their own Azure Key Vault, managed using their own Azure Active Directory (Azure AD) tenant. This ownership empowers privacy officers to enforce compliance policies effectively.

With your encryption key, OneTrust will encrypt data at rest in our SQL servers, storage accounts, Cosmos DB accounts, and data lake instances of OneTrust. This means that all instances of data storage within OneTrust will use your encryption key to store data at rest.

Attention:

Removal of this key will make your data illegible and functionality of OneTrust will cease to work. Losing this key also means that you will lose all data in OneTrust.

Configuring Cross-Tenant CMK

The following steps and diagrams demonstrate how to configure Cross-Tenant CMK and how CMK-managed resources within OneTrust’s Azure Tenant (SQL servers, storage accounts, Cosmos DB accounts, and data lake instances) access the customer-managed encryption key within the Customer’s Azure Tenant for encryption at rest.

Step 1: OneTrust Tenant Actions



On OneTrust's Azure Tenant, OneTrust will:

  1. Create a multi-tenant Azure AD application

    Azure AD organizes users and apps into groups called tenants. Within OneTrust’s Azure Tenant, OneTrust will create an application and configure it as a multi-tenant application during app registration to make the app available to users both in OneTrust’s Azure Tenant and in the Customer’s Azure tenant once the app is installed.

  2. Create a resource group

    OneTrust will create a resource group as a container to hold the SQL servers, storage accounts, Cosmos DB accounts, and data lake instances of OneTrust.

  3. Create a User-Assigned Managed Identity

    Within the resource group, OneTrust will also create a User-Assigned Managed Identity that will be used by the resources in the resource group to access the key in the Customer’s Azure Tenant.

  4. Configure the User-Assigned Managed Identity as a Federated Identity Credential on the application

    OneTrust then configures the User-Assigned Managed Identity as a Federated Identity Credential, which authenticates and authorizes the User-Assigned Managed Identity as a verified credential and grants it access to Azure resources.

  5. Share the AppId with Customer

    OneTrust will then share the AppId for the multi-tenant Azure AD application with the Customer in order for the Customer to proceed with the configuration steps within their own Azure tenant.

Step 2: Customer Tenant Actions



On the Customer Tenant, Customer will:

  1. Install the multi-tenant Azure AD application

    Once configuration is complete in OneTrust’s Azure Tenant, the customer will install the same multi-tenant application in their own Azure tenant using the AppId provided by OneTrust.

  2. Create Azure RBAC Role Assignments for the current user

    Customer will configure the logged in user with the Key Vault Crypto Officer role so that the user continues to have access to the Azure Key Vault via Azure Roles-Based Access Control (RBAC) after its creation.

  3. Create a new Azure Key Vault

    Customer will create a new Azure Key Vault in their Azure Tenant where the encryption key will be stored.

  4. Create an encryption key

    Customer will create the encryption key in their new Azure Key Vault that will be assigned for all CMK-managed resources (SQL servers, storage accounts, Cosmos DB accounts, and data lake instances).

  5. Grant the multi-tenant Azure AD application access to the key vault

    To grant OneTrust’s multi-tenant Azure AD application access to the Customer’s Azure Key Vault, Customer will create an Access Policy with the Get, Wrap Key, and Unwrap Key permissions. This will allow CMK-managed resources to access the encryption key.

  6. Share the Key Identifier URL with OneTrust

    Customer will share the Key Identifier URL for the encryption key with OneTrust in order for OneTrust to set this as the key for all CMK-managed resources in the resource group within OneTrust’s Azure Tenant.

Step 3: OneTrust Tenant Actions



On OneTrust's Azure Tenant, OneTrust will:

  1. Assign encryption key to CMK-managed resources

    OneTrust will add the Key Identifier URL provided by the Customer to all CMK-managed resources in OneTrust’s Azure Tenant. With the encryption key, OneTrust will encrypt data at rest in the SQL servers, storage accounts, Cosmos DB accounts, and data lake instances of OneTrust.

Managing the Encryption Key Life Cycle

With Cross-Tenant CMK, OneTrust customers are responsible for controlling and managing the encryption key life cycle, which includes the creation, upload, rotation, and deletion of encryption keys. The following Microsoft resources can be referenced when managing an encryption key.

To rotate an encryption key

Per Microsoft, "Key rotation is an online operation and should only take a few seconds to complete, because this only decrypts and re-encrypts the database's data encryption key, not the entire database." For more information on this process, see Microsoft's Rotate the Transparent data encryption (TDE) protector article.

To delete an encryption key

Per Microsoft's recommendations, "If a key is ever suspected to be compromised, such that a service or user had unauthorized access to the key, it's best to delete the key." For more information on this process, see Microsoft's Remove a Transparent Data Encryption (TDE) protector using PowerShell article.