Question:
How is Druva data encrypted for different workloads, such as inSync M365 and Phoenix?
Answer:
Druva ensures the security of customer data by implementing robust encryption methods. Here’s a detailed breakdown of how data is encrypted:
Encryption Overview
Data at Rest:
Druva uses AES 256-bit encryption to protect data stored on the cloud (at rest). Each customer has a unique encryption key, which ensures that Druva has no access to customer data.Data in Transit:
TLS encryption is used to secure data as it moves between the customer’s environment and the Druva cloud, preventing unauthorized access.Separation of Data and Metadata:
Druva stores data and metadata separately, adding an additional layer of security. This method, coupled with block-level deduplication, obscures the structure of the data, making it difficult for malicious actors to reconstruct it.
Encryption for All Workloads
The encryption process used for inSync M365 and Phoenix workloads is identical. The consistent application of AES 256-bit encryption ensures comprehensive security across all supported workloads.
Encryption Model
Druva Cloud uses a digital envelope encryption method for managing encryption keys. This is the standard model for cloud encryption, offering the highest level of data security.
Key Management
Data Encryption Key (DEK):
The DEK encrypts customer data stored in Amazon S3.
It is a randomly generated AES-256 key, unique to each customer.
The DEK is only available in session memory during authenticated I/O operations.
The DEK is generated when a customer instance is created and stored as an encrypted token in AWS RDS.
Key Encryption Key (KEK) / Key Wrapping Key (KWK):
The KEK encrypts the DEK for secure storage.
It is generated using a Password-Based Key Derivation Function (PBKDF) with a SHA-256 hash, providing an additional layer of protection.
DEK Creation Process
Instance Creation:
A unique AES 256-bit DEK is generated.
An 11-character admin password (P1) and random salt (S1) are generated.
Concatenation:
S1, DEK, and P1 are concatenated and then encrypted using AES 256-bit encryption with a PBKDF based on the SHA2 hash of P1.Storage:
The resulting token (AT1) is stored in an AES-256 encrypted AWS RDS database.
Security Measures
The DEK is never stored in plain text and is only available in working memory during authenticated sessions.
The DEK token is securely encrypted with KEK before being stored in Druva’s cloud.
For more in-depth information, please refer to below link: https://www.druva.com/resources/white-papers/whitepaper-druva-security-overview