With the rise of ransomware attacks and other security threats, data encryption is mission-critical for any company’s security strategy. The risk of improperly encrypting data is especially amplified in the cloud era, when sensitive data is stored outside of customer data centers and in public cloud providers like Amazon Web Services, Microsoft Azure, and Google Cloud Platform. While these providers offer a number of tools to help customer encrypt data before it is stored, these tools can be complex and difficult to use.
Addressing the top enterprise pain points is what Rubrik was founded on, and security has been core to its platform since day one. This includes end-to-end encryption, both in transit and at rest, which we extend to our integration with public cloud providers. The Rubrik approach simplifies how data encryption is implemented and masks complexity from users.
Rubrik has a wide breadth of cloud capabilities, from simple archival to DR and test/dev. Many customers leverage our CloudOut capability for archival of their backup data in public cloud providers, often as a replacement for tape. This approach is typically more cost effective and more reliable, and offers better response times in the event that data restoration is required.
In a previous post, I walked through how Rubrik encrypts data sent to the cloud both in transit and at rest using various methodologies in AWS. I also explained how Rubrik encrypts data that is uploaded to Azure Blob Storage. In the final part of our cloud encryption series, I’m going to show you how Rubrik applies these same security principles to data that is sent to Google Cloud Storage.
Rubrik + Google Cloud Platform
Let’s take a look at Google Cloud Platform (GCP) and how Rubrik uses Google Cloud Storage as an archiving target for protected data. While Google Cloud allows client-side encrypted data to be uploaded and stored, it does not currently provide any client-side encryption clients or libraries. Therefore, Rubrik implemented its own encryption manager module within the software platform. The encryption manager makes use of envelope encryption with a Key Encryption Key (KEK) that is derived from a customer-provided password. Both the KEK and the Data Encryption Key (DEK) are symmetric keys using the AES-256 cipher.
The password is inputted during the archive setup process. The Rubrik encryption manager uses it as a seed to derive a symmetric key that is stored within the Rubrik software platform.
Once the archive is created, the encryption workflow is as follows:
- The Rubrik archive manager invokes the Rubrik encryption manager
- The encryption manager generates a unique one-time only symmetric DEK
- The backup data is encrypted using the DEK
- The DEK is encrypted using the stored KEK derived from the password for the archive
- The encrypted DEK is stored alongside the ciphertext data, while the plaintext version of the DEK is deleted from memory
- The encrypted message is uploaded to and stored in Google Cloud Storage
The decryption workflow is as follows:
- The Rubrik archive manager pulls the encrypted backup data from Google Cloud Storage
- The archive manager invokes the Rubrik encryption manager
- The encryption manager retrieves the stored KEK associated with the archive
- The encrypted DEK is decrypted using the the KEK
- The data is decrypted using the plaintext DEK, which is then deleted from memory
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, Rubrik provides customers protection against both insider and outsider threats — even in the cloud.
Want to explore data encryption further? Check out this blog post on the importance of data encryption and confidentiality.