Proposed Pull Request Change

title description author ms.date ms.topic ms.author ms.service
Encryption options for Azure Elastic SAN Use platform-managed keys for the encryption of your Elastic SAN volumes or use customer-managed keys to manage encryption with your own keys. roygara 05/31/2024 concept-article rogarana azure-elastic-san-storage
📄 Document Links
GitHub View on GitHub Microsoft Learn View on Microsoft Learn
Raw New Markdown
Generating updated version of doc...
Rendered New Markdown
Generating updated version of doc...
+0 -0
+0 -0
--- title: Encryption options for Azure Elastic SAN description: Use platform-managed keys for the encryption of your Elastic SAN volumes or use customer-managed keys to manage encryption with your own keys. author: roygara ms.date: 05/31/2024 ms.topic: concept-article ms.author: rogarana ms.service: azure-elastic-san-storage # Customer intent: "As a cloud architect, I want to choose between platform-managed and customer-managed keys for encryption, so that I can meet my organization's specific security and compliance requirements for data stored in Azure Elastic SAN." --- # Learn about encryption for an Azure Elastic SAN Azure Elastic SAN uses server-side encryption (SSE) to automatically encrypt data stored in an Elastic SAN. SSE protects your data and helps you meet your organizational security and compliance requirements. Data in Azure Elastic SAN volumes is encrypted and decrypted transparently using 256-bit [AES encryption](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard), one of the strongest block ciphers available, and is FIPS 140-2 compliant. For more information about the cryptographic modules underlying Azure data encryption, see [Cryptography API: Next Generation](/windows/desktop/seccng/cng-portal). SSE is enabled by default and can't be disabled. SSE can't be disabled, doesn't impact the performance of your Elastic SAN, and has no extra cost associated with it. ## About encryption key management There are two kinds of encryption keys available: platform-managed keys and customer-managed keys. Data written to an Elastic SAN volume is encrypted with platform-managed (Microsoft-managed) keys by default. If you prefer, you can use [Customer-managed keys](#customer-managed-keys) instead, if you have specific organizational security and compliance requirements. When you configure a volume group, you can choose to use either platform-managed or customer-managed keys. All volumes in a volume group inherit the volume group's configuration. You can switch between customer-managed and platform-managed keys at any time. If you switch between these key types, the Elastic SAN service re-encrypts the data encryption key with the new KEK. The protection of the data encryption key changes, but the data in your Elastic SAN volumes always remains encrypted. There's no extra action required on your part to ensure that your data is protected. ## Customer-managed keys If you use customer-managed keys, you must use either an [Azure Key Vault](/azure/key-vault/general/overview) to store it. You can either create and import [your own RSA keys](/azure/key-vault/keys/hsm-protected-keys) and store them in your Azure Key Vault, or you can generate new RSA keys using Azure Key Vault. You can use the Azure Key Vault APIs or management interfaces to generate your keys. The Elastic SAN and the key vault can be in different regions and subscriptions, but they must be in the same Microsoft Entra ID tenant. The following diagram shows how Azure Elastic SAN uses Microsoft Entra ID and a key vault to make requests using the customer-managed key: :::image type="content" source="media/customer-managed-keys-overview/encryption-customer-managed-keys-diagram.png" alt-text="Diagram showing how customer-managed keys work in Azure Elastic SAN." lightbox="media/customer-managed-keys-overview/encryption-customer-managed-keys-diagram.png"::: The following list explains the numbered steps in the diagram: 1. An Azure Key Vault admin grants permissions to a managed identity to access the key vault that contains the encryption keys. The managed identity can be either a user-assigned identity that you create and manage, or a system-assigned identity that is associated with the volume group. 1. An Azure [Elastic SAN Volume Group Owner](../../role-based-access-control/built-in-roles.md#elastic-san-volume-group-owner) configures encryption with a customer-managed key for the volume group. 1. Azure Elastic SAN uses the managed identity granted permissions in step 1 to authenticate access to the key vault via Microsoft Entra ID. 1. Azure Elastic SAN wraps the data encryption key with the customer-managed key from the key vault. 1. For read/write operations, Azure Elastic SAN sends requests to Azure Key Vault to unwrap the account encryption key to perform encryption and decryption operations. ## Next steps - [Configure customer-managed keys for An Azure Elastic SAN using Azure Key Vault](elastic-san-configure-customer-managed-keys.md) - [Manage customer keys for Azure Elastic SAN data encryption](elastic-san-encryption-manage-customer-keys.md)
Success! Branch created successfully. Create Pull Request on GitHub
Error: