Enhancing Data Security and Digital Trust in the Cloud using Azure Services.
Introduction
Think of Client-Side Encryption (CSE) as a strategy that has proven to be most effective in augmenting data security and modern precursor to traditional approaches. In addition to providing a stronger security posture, this strategy is also in compliance with major data regulations like GDPR, FERPA and PCI-DSS. In this article, we’ll explore how CSE can provide superior protection for your data, particularly if an authentication and authorization account is compromised. We’ll also address common questions about Microsoft's stance on CSE and explain why CSE might not be as widely discussed as Client-Side Key Encryption (CSKE). By understanding these concepts, you can better meet security and regulatory requirements and ensure that your data remains protected.
Use Case
As shown below in the Figure 1: An example of Use Case Architecture. Protecting and managing financial and health sensitive data for clients is subject to stringent regulatory requirements such as GDPR and PCI-DSS and also the followings:
- E-commerce: Protecting customer data such as credit card information, personal details, and purchase history is crucial to maintaining trust and complying with regulations like GDPR and PCI-DSS.
- Technology and Software Development: Intellectual property, source code, and proprietary algorithms are valuable assets that need protection from unauthorized access and industrial espionage.
- Education: Institutions handle a significant amount of sensitive data, including student records, research data, and personal information of faculty and staff. Compliance with regulations like FERPA (Family Educational Rights and Privacy Act) is essential to protect the privacy of student information.
Practical Use Case scenario for CSE
- Organizations handling highly sensitive information (e.g., sensitive personal information) can use CSE to ensure that data remains protected at all times, even if the cloud infrastructure is compromised.
- Where and when clients need to comply with regulations that requiring strict control over the encryption keys and data access, CSE allows them to manage keys externally, ensuring no unauthorized access by cloud providers.
- Organizations concerned about data governance, sovereignty and privacy can use CSE to ensure that their data is protected in line with local laws and privacy regulations.
Understanding the concept
As it shown in the Figure 2: The Concept, the processes involved in client-side encryption (CSE) are the followings:
- The client device or application utilizes the authentications and authorization components, authenticates with Azure Key Vault to securely retrieve the encryption key.
- The client application uses the retrieved encryption key to encrypt the data, ensuring it is securely transformed into an encrypted format.
- The client uploads the encrypted data to Azure Storage, where it is stored securely in its encrypted form.
- When needed, the client retrieves the encrypted data from Azure Storage.
- The client retrieves the encryption key again from Azure Key Vault.
- It then decrypts the data, making it usable.
In a nutshell:
- The company uses strong encryption algorithms AES-256 to encrypt data on the client side before uploading it to Azure Blob Storage.
- Encryption keys are stored securely using a hardware security module (HSM), ensuring that keys are never exposed to the cloud service provider.
- Encrypted data is uploaded to Azure, and only authorized client-side applications can decrypt and access the data using the securely managed keys.
- NOTE: This does not jeopardize service-side encryption features for ease of use in protecting your data and if you are using client-side encryption, migrate your applications to version 2 for improved security.
Understanding Client-Side Encryption (CSE) and Client-Side Key Encryption (CSKE).
Client-Side Encryption (CSE) provides a significant security advantage by allowing organizations to maintain complete control over their data and encryption keys. This method not only enhances data security but also supports compliance with regulatory requirements, offering peace of mind in the ever-evolving landscape of cloud computing. CSE encrypts data before it is sent to any service like Azure and this means that the data is encrypted on the client’s side, and Azure never sees the encryption keys. Even if someone gains access to your Azure account, they cannot read your data without the keys. In contrast, Client-Side Key Encryption (CSKE) focuses on securing the encryption keys themselves. The client manages and controls these keys, ensuring they are not accessible to the cloud service. This adds an extra layer of protection by keeping the keys out of the service provider’s reach. Both approaches enhance security but address different aspects of data protection.
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.
- 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.
Azure's Position on CSE
Most of Azure’s documentation and services tend to emphasize Server-Side Encryption (SSE) 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.
Step-by-Step Solution for Implementing Client-Side Encryption (CSE) for Python, .NET Core Blazor App using C#, and Java Apps.
Requirements (Refers to Figure 1: An example of Use Case Architecture)
Cloud provider (Microsoft Azure)
- Choose the Right Azure Storage
- Select the Encryption Mode
- Ensure Right Dependencies
- Azure Key Vault Integration
- Azure Blob Storage (In this context)
Your organization responsibility to implement CSE
- Determine the level of security needed for your data.
- Identify any regulations (like GDPR) that mandate specific encryption practices.
- Choose a strong encryption algorithm (AES-256) latest version and a reliable encryption library in your programming language of choice. For example, Python’s cryptography library, Java’s javax.crypto or C# security.cryptography.algorithms package.
- Azure subscription, storage account, and .NET SDK.
To implement Client-Side Encryption (CSE) in your application using Azure Key Vault and Azure Blob Storage.
Azure Key Vault
You will set up Azure Key Vault to store and manage encryption keys securely.
- You will need to create a Key Vault as this will help to create RSA, EC, or AES keys in Managed HSM, then use them for encryption-at-rest in Azure Storage, Azure SQL, and more. So, in the Azure portal, create a new Key Vault resource as shown below.
You will Navigate to Administrators by click on it, then Click Add principal, then select your apps as seen on the screen below:
This will Set the permissions for the Key Vault, ensuring that your application can access the keys. So, review to create and Click on Create button as shown below:
It might take a couple of minutes for your Azure Key Vault creation to deploy successfully.
- Create or Import Encryption Keys:
Next is to create a new key or import an existing key in the Key Vault. This key will be used for encrypting and decrypting data. But prior to this you must have updated your network settings. So, let’s use Azure CLI:
- To Create a New Key using bash in Azure CLI
- To Import an Existing Key (If you have a key in a PEM or PFX file, you can import it) using bash in Azure CLI.
Replace <YourKeyVaultName>, <YourKeyName>, and <YourPemFilePath> with your Key Vault name, the key name, and the path to your key file.
- Assign Access Policies to allow your app to perform operations like `wrapKey` and `unwrapKey` with the key using bash in Azure CLI:
Replace <YourKeyVaultName> with your Key Vault name and <YourAppServicePrincipalId> with the service principal ID of your Blazor app.
Azure Blob Storage
You will configure Azure Blob Storage to store the encrypted data. You will be using Azure Storage client libraries for Blob Storage or Queue Storage if that’s your choice with the same steps.
- In the Azure portal, create a new Blob Storage account (Quickstart blobs) or using Azure CLI as shown below:
Replace <YourStorageAccountName>, <YourResourceGroup>, and <YourLocation> with your desired storage account name, resource group, and Azure region.
- Configure access control for your Blob Storage account, ensuring your app can read and write data using a service principal, for example you can assign a role like Storage Blob Data Contributor:
Replace <YourAppServicePrincipalId>, <YourSubscriptionId>, <YourResourceGroup>, and <YourStorageAccountName> with your service principal ID, subscription ID, resource group, and storage account name.
- Use SAS tokens or managed identities to secure access to the Blob Storage account. To generate a SAS token for the storage account using Azure CLI:
If your app is using a managed identity, the role assignment from previous step, it will automatically secure the storage account access, and no additional steps are required.
Replace <YourStorageAccountName> and <YYYY-MM-DD> with your storage account name and desired expiry date.
Implementing Client-Side Encryption for Python App
Encryption and Uploading in Python:
- Install the required libraries in bash command
- Encryption and Uploading in Python, for example:
Downloading and Decrypting in Python:
Decrypt and Download Data for example:
Implementing Client-Side Encryption for .NET Core Blazor App using C#
Encryption and uploading in C#:
- Irrespective of IDE you are using, Install the required NuGet packages:
- Encryption and Uploading code example**:
Downloading and Decrypting Example in C#:
Decrypt and Download Data:
Replace <your_storage_account> and your_base64_secret_key with your actual storage account URL and Base64 encoded secret key, respectively.
Implementing Client-Side Encryption for Java application
Encryption and Uploading in Java:
- You will first need to add the required dependencies to your pom.xml:
- Encryption and uploading similar code sample:
Downloading and Decrypting in Java
Decrypt and Download Data:
Likewise, you will replace <your_storage_account> and your_base64_secret_key with your actual storage account URL and Base64 encoded secret key, respectively and ensure you are using the latest Azure SDK.
Managing Encryption Keys
- Store encryption keys securely, preferably in a hardware security module (HSM) or a key management service (KMS) and make sure you regularly rotate encryption keys to enhance security.
Verifying and Testing
- Ensure that encryption and decryption processes are secure and cannot be bypassed.
- Verify that your implementation meets all regulatory requirements.
Outcome
- Even if the cloud storage is compromised, the encrypted data remains secure as the keys are not accessible to the attacker.
- The company meets regulatory requirements by ensuring data is encrypted in a way that aligns with GDPR, PCI-DSS, and FERPA digital trust standards.
- Full control over encryption keys and data access policies enhances the company’s ability to protect its clients' sensitive financial information.
Conclusion
We have seen so far, how Client-Side Encryption (CSE) provides an enhanced level of security by ensuring that data is encrypted before it leaves the client’s environment, and how we can implement this with three different programing languages for Azure App using Azure Key Vault, Azure Blob and create Azure Storage Account. This method aligns well with regulatory requirements such as GDPR, PCI-DSS, and FERPA, offering greater control over sensitive information and protecting it from breaches and unauthorized access. By implementing CSE, can better meet security and regulatory requirements, ensuring the highest level of data protection. It helps provides enhanced protection against data breaches. While it involves more complexity than Client-Side Key Encryption (CSKE), it offers significant security benefits that are crucial for handling sensitive data. CSE enhances security by allowing you to manage encryption keys independently. It's a valuable practice for safeguarding sensitive information in cloud solutions!
CAUTION:
- The code might need to upgrade depend on the time you are performing these tasks.
- If you are using Azure file share as a Persistent Volume Claim (PVC) in Azure Kubernetes Service (AKS) with POD workload identity to retrieve secret you will use the Secrets Store CSI Driver to natively retrieve secret contents from Azure Key Vault. This driver securely provides secrets to the requesting pods: https://learn.microsoft.com/en-us/azure/aks/developer-best-practices-pod-security
References
For more information on Azure's support for Client-Side Encryption and to access further resources on Azure's official documentation and security best practices.
- Why We Need Client-Side Encryption, not Client-Side Key Encryption. https://learn.microsoft.com/en-us/answers/questions/1723580/why-we-need-client-side-encryption-not-client-side.
- Client-side encryption - Wikipedia. https://en.wikipedia.org/wiki/Client-side_encryption.
- Client-side encryption FAQ - Google Workspace Admin Help: https://support.google.com/a/answer/14328489?hl=en-Link
- What Is Client Side Encryption - LogMeOnce Resources. https://logmeonce.com/resources/what-is-client-side-encryption/
- Client-side encryption for blobs - Azure Storage. https://learn.microsoft.com/en-us/azure/storage/blobs/client-side-encryption.
- How Microsoft 365 encryption helps safeguard data and maintain. https://techcommunity.microsoft.com/t5/microsoft-365-blog/how-microsoft-365-encryption-helps-safeguard-data-and-maintain/ba-p/2461066.
- Azure encryption overview. https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview.
- Data encryption models in Microsoft Azure. https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-models.
- Client-side encryption for blobs - Azure Storage | Microsoft Learn https://learn.microsoft.com/en-us/azure/storage/blobs/client-side-encryption?tabs=dotnet
- CSI Driver to natively retrieve secret contents from Azure Key Vault. https://learn.microsoft.com/en-us/azure/aks/developer-best-practices-pod-security
Published on:
Learn moreRelated posts
Microsoft Purview compliance portal: Information Protection – MIP auto-labeling for Azure SQL & Storage
Microsoft's Purview compliance portal has added a new feature that enables users to extend sensitivity labels to specific or all subscriptions...
Optimizing Azure Container App Deployments: Best Practices for Pipelines & Security
In this post, we take Azure Container App deployments to the next level with best practices for optimizing pipelines and securing sensitive d...
Seamless Updates, Zero Downtime: Master Continuous Deployment in Azure Container Apps
In this fifth part of our Azure Container Apps series, we dive into the world of Continuous Deployment. Learn how to automate your deployment ...
This Month in Azure Static Web Apps | 09/2024
We are back with another edition of the Azure Static Web Apps Community! :party_popper: September was yet another month ...
IPv6 Adoption: Enhancing Azure WAF on Front Door
The transition to IPv6 is a significant step for enterprise corporations, reflecting the evolution of internet technology and the need for a l...
Introducing the Data-Bound Reference Layer in Azure Maps Visual for Power BI
Imagine managing a nationwide sales team and needing to understand how your sales align with factors like population density, competitor locat...