This post explains the options Teradata supports for using encryption keys in VantageCloud Enterprise.

Since VantageCloud Enterprise is Teradata’s data and analytics solution for the cloud, optimised for performance, and cloud agnostic, we present the encryption key features together for all CSPs (Cloud Service Providers). However, due to the differences among the services related to the encryption keys that every CSP offers and some backlog to implement the encryption features among all the CSPs, sometimes the deployment is not the same for all CSPs. We will show the differences in the encryption key features Teradata supports on those occasions.

Encryption Keys

A cryptographic or encryption key is a string of characters used within an algorithm specific for this purpose to alter data to appear random. Like a physical key, it locks (encrypts) data so that only someone with the correct key can unlock (decrypt) it.

There are different methods for utilising the keys:

• In symmetric encryption, we use the same key for encryption and decryption.
• In asymmetric encryption, we have separate keys for encrypting and decrypting. They are the public (for encryption) and private (for decryption) keys.

Encrypting data at rest is a frequent practice to protect it from rogue actors and accidental exfiltrations. I.e., we turn plain text into gibberish so users can’t read the information at first sight. They need an encryption key to transform it again.

Teradata offers symmetric encryption for VantageCloud Enterprise.

Some Concepts about Encryption Keys

The table below summarises some relevant concepts to understand the encryption options Teradata supports for VantageCloud Enterprise in the different CSPs.

Encryption Keys Types for Teradata Enterprise

The following table shows the encryption key types Teradata supports for the different CSPs when finishing this post. It also includes the relevant CSP service used to manage the keys.

For your information, the CSP-Managed Keys are always active to encrypt the data in all platforms. In the case of GCP and Azure, the Cloud Service Providers enable the Google-Managed Keys and the Platform-Managed Keys, respectively, by default in all their services. In AWS, Teradata always enables the AWS-Managed Keys in all the VantageCloud Enterprise accounts.

Thus, after applying the CSP-Managed Key, you can choose if you want to add an additional level of security with the Customer-Managed Keys.

HSM Key

The HSM-backed key offering differs across the three CSPs (AWS, Azure and Google Cloud).

In AWS, the CloudHSM service doesn’t work with the AWS API and may not be integrated with AWS services such as EBS, S3, etc. You must use custom code or third-party tools to manage and use your keys with CloudHSM.

However, Azure has the Azure Key Vault Premium (almost equivalent to Azure Managed HSM). This service allows you to create keys that are both software-protected and HSM-protected. This is nearly identical to what Google Cloud KMS provides (i.e., the ability to develop software-protected or HSM-protected keys).

As we can see in the table above, Teradata currently supports HSM-backed keys only in Google Cloud.

Encryption Key Features in Teradata Enterprise

When you opt to encrypt your data at rest, Teradata encrypts the disks of all services within the Enterprise account, such as the database (SQLE), Viewpoint, Data Mover, etc. It also encrypts the DSA Backups and Snapshots you store in Object Storage (AWS S3, Azure Blob Storage or Cloud Storage).

Additionally, you have the option to rotate the encryption keys.

Bear in mind that you must keep the encryption keys in an account you own. This account must be in the same region as the Teradata Enterprise account.

Below are details about the key encryption features Teradata offers for VantageCloud Enterprise.

However, depending on the CSP, some features and characteristics differ for every Teradata Enterprise implementation. The table below summarises the parts that vary for the encryption key implementation based on your chosen CSP.

Furthermore, Teradata supports key rotation for VantageCloud Enterprise. However, if you use Enterprise on GCP, Teradata must restart the database whenever you decide to rotate the keys.

Encryption Keys for Cross-Region and Cross-Site Restores

If you use Customer-Managed Keys, Teradata supports them for Cross-Region and Cross-Site Restores with Snapshots in AWS and Azure. Additionally, if you use Cross-Site Restores with DSA Backups, Teradata supports them in AWS, Azure and GCP. However, if you need to use Cross-Region Restores with DSA Backups, then Teradata only supports Customer-Managed Keys in Azure and GCP. You have further details in the tables below.

As an additional security consideration for the Cross-Site and Cross-Region Restores, Teradata stores the DSA Backups and Snapshots in Object Storage. I.e., AWS S3, Azure Blob Storage or Cloud Storage buckets, depending on the platform. Teradata secures the API calls to those buckets so they run within the CSP backbone when the bucket is in the same region as the VaaS account and in Azure during the deployment of your Enterprise instance. Only the API calls in Google Cloud are protected when the bucket is in another region. The table below summarises how Teradata configures the NOS API calls. For further information, check the NOS section of the network configuration posts for AWS, Azure and GCP.

Quotas and Limitations

If you choose a Teradata Enterprise deployment on AWS and Azure with encryption keys, you don’t need to update any quota in your account.

However, if you choose Enterprise on GCP with PO SSD disks and want to use CMEK keys, you may need to increase the quota for CMEK API calls in large deployments. The diagram below shows further details on how much you may need to increase the quota. Discussing this increase with Teradata and Google Cloud would be best.

Losing Access to the Encryption Keys

Revoking access to your CMEK from Teradata will cause VantageCloud Enterprise to cease operating and may result in data integrity issues, corruption or complete data loss. As soon as the key is revoked, the Vantage system identifies this event and raises an urgent S1 incident ticket with the Teradata Support organisation. The disruption continues until a valid key is provided to VantageCloud Enterprise again.

Note that revoking CMEK should be used only as a last resort – revoking Teradata’s access to keys may lead to an inconsistent data state. – Once the Vantage system is back up, it’s your responsibility to validate the integrity of the data in the system. Teradata can’t perform this validation because they can’t access your data anytime.

If the data is inconsistent, you can raise a Change Request to Teradata to restore the database to a previous Recovery Point Objective (RPO) using the most recent recovery point/ backup.

When to Revoke Permissions on the Encryption Keys

If you find that your keys may be compromised, the benefit of locking down access outweighs the loss of accessible data. If you are in such a situation, you can just disable the encryption key instead of deleting it, as you may need to enable the key again later.

Since Vantage loses access to the encryption keys, it will automatically open an S1 incident, as explained previously.

Next Steps

This post introduces the encryption key features in Teradata VantageCloud Enterprise. If you are in the process of deciding if you should deploy an Enterprise database within your organisation, contact Teradata for further details on encryption (or anything else).

If you are already deploying an Enterprise system, Teradata will synchronise with you and share the appropriate information to share the keys, rotate them, etc.

I updated this post on 21 December 2023 to update the Customer-Managed Keys and Business Continuity table.

This article was updated on 26 December 2023 to provide further details about encryption keys and Cross-Site and Cross-Region Restores. I created the “Encryption Keys for Cross-Region and Cross-Site Restores” section.

I updated the tables “Encryption Key Types for Teradata Enterprise – Differences per CSP” and “Encryption Keys and BaaS with DSA Backups for Teradata Enterprise” on 7 February 2024.

I changed the tables where I explained the encryption key rotation and how Teradata secures the NOS reads on 17 June 2024.

On 20 November 2024, I corrected the diagram showing the relationship between the CSP-Managed and the Customer-Managed Keys.