Encrypting Your Data in the Cloud: Rubrik CloudOut with Amazon S3

In a previous post, I discussed the role of data encryption as a critical component of any company’s security posture and the potential pitfalls of not using encryption properly. This is magnified when you are talking about storing data outside of customer data centers in public cloud storage repositories such as Amazon S3, Azure Blob Storage, and Google Cloud Storage.

Security is one of the key pillars of Rubrik’s Cloud Data Management platform, and we design security into every aspect of the platform. This includes end-to-end encryption, both in transit and at rest, which extends to our integration with public cloud providers.

The majority of Rubrik customers take advantage of our CloudOut capability to store their backup data in one of the big three public cloud providers, often as a replacement for tape. This approach is typically more cost effective, more reliable, and offers better response times in the event that data restoration is required.

To secure data uploaded via CloudOut, Rubrik enables encryption in transit using TLS and encryption at rest using various methodologies. No matter the cloud provider, Rubrik applies the same three key principles to how we encrypt customer data:

Use the strongest encryption cipher available and widely deployed: We use AES-256 for the Data Encryption Key (DEK) and either AES-256 or RSA-2048 for the Key Encryption Key (KEK), depending on the option chosen.

Encrypt data client-side: While TLS provides encryption in transit and is used by Rubrik for all data transmissions, encrypting data at rest on the client-side as well offers some additional benefits:

• Customers get double encryption with the data encrypted before being uploaded and while in transit.
• Customers can follow a policy that dictates the cloud provider should never have access to data in unencrypted form. While it is unlikely that a provider would attempt to read customer data, encrypting data server-side does mean that there will be a time period, after transmission and prior to the data being written, when the the data is in cleartext. By encrypting data prior to upload, Rubrik ensures that the cloud provider never has access to unencrypted data.

Allow users to manage and store their own encryption keys: Many security professionals recommend a separation of responsibilities so that only the customer has possession of the KEK or at least manages the KEK even if it is stored by the cloud provider.

Over a series of  blog posts, we’ll dive into how Rubrik encrypts data at rest before it’s uploaded to each of the big three public cloud providers. This post will focus primarily on AWS.  If you need a primer or a refresher on data encryption, check out my encryption 101 and key management blog posts. For a comparison of object storage encryption for the three main public cloud providers, I recommend reading my cloud encryption blog post.

Amazon Web Services

Let’s take a look at Amazon Web Services (AWS) and how Rubrik uses Amazon S3 as an archiving target for protected data. S3 supports two method of client-side encryption, both of which can be used with Rubrik:

• Key Management Service (KMS)-managed Customer Master Key (CMK)
• Client-side key

Both methods utilize a S3 encryption client provided by AWS, which Rubrik uses for envelope encryption of backup data prior to it being uploaded to S3. The primary difference between the two methods are how the Key Encryption Key (KEK) or Customer Master Key (CMK), as it is known in the AWS world, is stored and managed.

KMS-Managed Customer Master Key
To use the Amazon KMS-Managed Customer Master Key (CMK), the user has to create the CMK using the AWS IAM Console or via the API. A Master Key ID is assigned to each CMK, which is a logical representation of the actual backing key.

• Rubrik and the S3 encryption client can reference the Key ID without the actual backing key being exposed in the clear or exported from KMS.
• The backing key can be rotated without needing to change the Key ID.

The Master Key ID is inputted during the archive creating process in the Rubrik dashboard:

Once the archive is created, the encryption workflow is as follows:

1. The Rubrik archive manager passes the data to be encrypted to the S3 encryption client.
2. The encryption client requests a data key from KMS using the specified CMK ID.
3. KMS uses the associated CMK to generate a new unique one-time data key.
4. KMS passes the plaintext and the ciphertext versions of the data key to the encryption client.
5. The encryption client encrypts the backup data using the plaintext data key and then deletes the key from memory.
6. The encryption client returns the encrypted message, which includes the encrypted data key alongside the encrypted data, to the Rubrik archive manager.
7. The encrypted message/data is uploaded to S3 by the archive manager.

The decryption workflow is as follows:

1. The Rubrik archive manager pulls the encrypted backup data from S3.
2. The Rubrik archive manager invokes the S3 encryption client.
3. The encryption client retrieves the encrypted data key from the encrypted message/data  and sends the encrypted data key to KMS.
4. KMS uses the associated CMK to decrypt the encrypted data key.
5. KMS passes the plaintext data key to the encryption client.
6. The encryption client decrypts the data using the plaintext data key and then deletes the key from memory.
7. The encryption client returns the decrypted data to Rubrik.

Client-Side Key
In this option, Rubrik uses asymmetric encryption with the RSA-2048 cipher to encrypt the data key. The Rubrik documentation recommends using OpenSSL to generate the private key, although you can use any trusted key generator that supports RSA-2048 cipher with a sufficiently random seed for the key.

The private key is inputted during the archive setup process.

This private key is stored and protected within the Rubrik software platform, where it is used to generate the associated public key. The public key functions as the KEK to encrypt all data keys used for this archive.

Once the archive is created, the encryption workflow is as follows:

1. The Rubrik archive manager passes the data to be encrypted to the S3 encryption client along with the generated public key .
2. The encryption client generates a unique one-time only symmetric data key and encrypts the data using that key.
3. The encryption client encrypts the plaintext data key using the provided public key and then deletes the plaintext key from memory.
4. The encryption client returns the encrypted message, which includes the encrypted data and the data key.
5. The encrypted message/data is uploaded to S3 by the archive manager.

The decryption workflow is as follows:

1. The Rubrik archive manager pulls the encrypted backup data from S3.
2. The Rubrik archive manager passes the encrypted message and the stored private key to the S3 encryption client.
3. The encryption client retrieves the encrypted data key from the encryption message and uses the private key to decrypt the ciphertext data key.
4. The encryption client decrypts the data using the plaintext data key and then deletes the key from memory.
5. The encryption client returns the decrypted data to Rubrik.

While a copy of the private key is stored within the Rubrik software platform, it’s critically important for the customer to store their copy of the private key securely. The customer’s copy is required in the event that a new Rubrik instance has to be deployed and connected to that same S3 archive. For that reason, I recommend customers use a robust key management solution to store and manage their private keys and not rely on ad hoc solutions such as a text file saved on a laptop.

Rubrik’s approach to archiving data to the public cloud ensures that our customer have end-to-end encryption of their data. When combined with a multi-layered security posture, this approach provides customers protection against both insider and outsider threats.

To learn more, watch the video below from Cloud Field Day 3 on native AWS protection and Rubrik.