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.

Since the beginning, security has been a key pillar of Rubrik’s Cloud Data Management platform. Our engineers have built security into every aspect of the platform, from end-to-end encryption to immutable backups. Naturally, this obsession with security extends to our integration with the cloud.


As customers adopt the cloud, many are leveraging our CloudOut capability for long-time archive in the public cloud, 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.


I recently spelled out how Rubrik secures data that is sent to the cloud by encrypting data both in transit and at rest using a variety of methodologies with AWS. This post gives a more in-depth look at Rubrik’s main principles for encrypting data in the cloud, including using the strongest encryption cipher available, encrypting data on the client side before being sent to the cloud, and providing customers with flexible key management.

Encrypting Data in Microsoft Azure

For the second post in our 3-part cloud encryption series, let’s take a look at how Rubrik uses Microsoft Azure Blob Storage as an archiving target for protected data. Azure supports customer-provided KEKs for encrypting Content Encryption Keys (CEK) on the client-side, as well as a storage client library that Rubrik utilizes for envelope encryption of backup data prior to it being uploaded to Blob Storage. As with our Amazon S3 integration, Rubrik uses asymmetric encryption with the RSA-2048 cipher to generate the KEK. The private key is inputted during the archive setup process.


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

  1. The storage client library generates a unique one-time only symmetric CEK
  2. The backup data is encrypted using the CEK
  3. The storage client invokes a key-wrapping algorithm requesting a KEK from Rubrik, and a public key is generated
  4. The CEK is encrypted using the public key as the KEK
  5. The encrypted CEK is stored, as metadata, alongside the ciphertext data while the plaintext version of the CEK is deleted from memory
  6. The encrypted message is uploaded to and stored in Azure Blob Storage


The decryption workflow is as follows:

  1. The Rubrik archive manager pulls the encrypted backup data from Azure Blob Storage
  2. The storage client library invokes a key-unwrapping algorithm requesting the stored private key associated with the archive
  3. The encrypted CEK is decrypted using the the private key
  4. The data is decrypted using the plaintext CEK, which is then deleted from memory


Along with the encryption method, customers should choose a robust key management solution to store and manage their private keys. After all, you could use the strongest encryption method in the world, but that doesn’t matter if your keys are lost or are compromised. It’s like having a state of the art anti-burglar system but leaving the house keys and alarm codes under the welcome mat.

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

Stay tuned for an upcoming post on how Rubrik encrypts data in Google Cloud! To learn more, read this intro to cloud encryption and why it matters.