Why We Need Client-Side Encryption, not Client-Side Key Encryption

Question

While I appreciate the elegance of Azure's automatic Storage encyption, I think there's still a strong need for Client-Side Encryption (not Client-Side Key Encryption). For example, if there's a breach of an Azure account, the intruder would have access to blob data. Server-Side Encryption would not protect the data. Per the General Data Protection Regulation (GDPR) Article 34, Section 3(a): a data breach would not include personal data that is encrypted in a way the intruder cannot decrypt. Encrypting with the public side of an asymetric key pair, where a consumer external to the Azure account has the private key, would still be secure, and, therefore exempt from breach reporting requirements.

The more general use-case of a consumer providing a public key that they want used for whatever reason also necessitates Client-Side Encryption.

So I'm confused why the discussions of Azure encryption seem to discourage CSE, and when it is discussed, it's almost always as Client-Side Key Encryption.

Is there something I'm not understanding, or does Client-Side Encryption deserve more support?

Answer 1

Hello Moyer, Todd,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

Problem

I understand that you are concerned about the security of data stored in Azure, particularly in the context of a breach of the Azure account. Also, you're seeking to understand why Client-Side Encryption (CSE) is not more widely advocated compared to Client-Side Key Encryption (CSKE) and how CSE could better address security and regulatory requirements.

Solution

To answer your question, you will need to understand the difference between Client-Side Encryption (CSE) and Client-Side Key Encryption (CSKE).

Client-Side Encryption (CSE):

Process: Data is encrypted on the client side before it is sent to the cloud. The client holds the encryption keys and performs the encryption/decryption operations.

Control: The client has complete control over the encryption keys and the encrypted data. The cloud service never has access to the unencrypted data or the keys.

Client-Side Key Encryption (CSKE):

Process: Data is sent to the cloud, and the client manages the encryption keys used by the cloud service to encrypt/decrypt the data.

Control: The cloud service is involved in the encryption/decryption process, but the client retains control over the keys.

Why We Need Client-Side Encryption (CSE)

Enhanced Security:

With CSE, data is encrypted before it leaves the client’s environment. This means that even if the cloud service is compromised, the attacker only has access to encrypted data, which is useless without the decryption keys.

Since the encryption keys are never shared with the cloud service, there is no risk of them being exposed through cloud service vulnerabilities.

Regulatory Compliance:

Under regulations like GDPR, data breaches involving encrypted data where the keys are not compromised may not require reporting. CSE ensures that the data is encrypted in a way that meets these regulatory requirements.

For industries with strict data protection requirements (e.g., healthcare, finance), CSE provides a way to handle sensitive data securely and meet compliance standards.

Data Ownership and Control:

The client maintains full control over the encryption keys. This autonomy helps organizations enforce their own security policies and procedures.

Clients can ensure that their data sovereignty requirements are met since they control where and how the encryption keys are stored and managed.

Why Not Client-Side Key Encryption (CSKE) Alone

Reliance on Cloud Service:

Even though CSKE allows clients to manage the encryption keys, the cloud service still handles the encryption and decryption operations. If the cloud service is compromised, there’s a risk that the data could be decrypted by the attacker using the stolen keys.

CSKE requires trusting that the cloud service’s encryption processes are secure and that there are no vulnerabilities that could be exploited to access the data.

Key Exposure Risks:

With CSKE, there’s a shared responsibility between the client and the cloud service for data protection. Any lapses on the cloud service side could lead to key exposure.

While clients manage the keys, they must still rely on the cloud service to handle the actual encryption and decryption processes securely.

Practical Scenarios for Client-Side Encryption

So therefore, when thinking about practical Scenarios for Client-Side Encryption we need to look critically into these three main aspects:

1. Highly Sensitive Data: Organizations handling highly sensitive information (e.g., medical records, financial data) can use CSE to ensure that data remains protected at all times, even if the cloud infrastructure is compromised.
2. External Key Management: When clients need to comply with regulations requiring strict control over encryption keys and data access, CSE allows them to manage keys externally, ensuring no unauthorized access by cloud providers.
3. Data Sovereignty and Privacy: Organizations concerned about data sovereignty and privacy can use CSE to ensure that their data is protected in line with local laws and privacy regulations.

Azure's Position on CSE

Azure’s documentation and services tend to emphasize Server-Side Encryption due to its simplicity and ease of use for most scenarios. SSE allows Azure to provide a straightforward security model that works out-of-the-box for users, without requiring significant changes to their applications or processes.

However, Azure does support CSE through various SDKs and client libraries. For instance, Azure Storage SDKs for different programming languages provide support for encrypting data on the client side before uploading it to Azure Blob Storage.

References

Source: Azure Storage Client-Side Encryption. Accessed, 6/22/2024.

Source: Understanding GDPR requirements, particularly Article 34, Section 3(a), is essential for ensuring compliance. Accessed, 6/22/2024.

Source: Azure Key Vault Documentation. Accessed, 6/22/2024.

Source: Azure Security Best Practices. Accessed, 6/22/2024.

Accept Answer

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

** Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful ** so that others in the community facing similar issues can easily find the solution.

Best Regards,

Sina Salam