Merge pull request #283267 from WilliamDAssafMSFT/docs-editor/workspaces-encryption-1722181044

Docs editor/workspaces encryption 1722181044

Author: Jill Grant

articles/synapse-analytics/security/media/workspaces-encryption/workspace-activation.png

@@ -2,21 +2,19 @@
 title: Azure Synapse Analytics encryption
 description: Understand encryption of data at rest in Synapse Analytics workspaces, configuration of encryption, key management, and Transparent Data Encryption (TDE).
 author: meenalsri
-ms.service: azure-synapse-analytics
-ms.topic: conceptual
-ms.subservice: security
-ms.date: 03/24/2022
 ms.author: mesrivas
 ms.reviewer: whhender, wiassaf
-
-
+ms.date: 07/31/2024
+ms.service: azure-synapse-analytics
+ms.subservice: security
+ms.topic: conceptual
 ---
 # Encryption for Azure Synapse Analytics workspaces
 
 This article will describe:
-* Encryption of data at rest in Synapse Analytics workspaces.
-* Configuration of Synapse workspaces to enable encryption with a customer managed key.
-* Managing keys used to encrypt data in workspaces.
+- Encryption of data at rest in Synapse Analytics workspaces.
+- Configuration of Synapse workspaces to enable encryption with a customer managed key.
+- Managing keys used to encrypt data in workspaces.
 
 ## Encryption of data at rest
 
@@ -25,7 +23,7 @@ A complete Encryption-at-Rest solution ensures the data is never persisted in un
 The first layer of encryption for Azure services is enabled with platform-managed keys. By default, Azure Disks, and data in Azure Storage accounts are automatically encrypted at rest. Learn more about how encryption is used in Microsoft Azure in the [Azure Encryption Overview](../../security/fundamentals/encryption-overview.md).
 
 > [!NOTE]
-> Some items considered customer content, such as table names, object names, and index names, may be transmitted in log files for support and troubleshooting by Microsoft.
+> Some items considered customer content, such as table names, object names, and index names, might be transmitted in log files for support and troubleshooting by Microsoft.
 
 ## Azure Synapse encryption
 
@@ -35,12 +33,12 @@ This section will help you better understand how customer-managed key encryption
 > Synapse workspaces do not support the use of EC, EC-HSM, and oct-HSM keys for encryption. 
 
 The data in the following Synapse components is encrypted with the customer-managed key configured at the workspace level:
-* SQL pools
- * Dedicated SQL pools
- * Serverless SQL pools
-* Data Explorer pools
-* Apache Spark pools
-* Azure Data Factory integration runtimes, pipelines, datasets.
+- SQL pools
+   - Dedicated SQL pools
+   - Serverless SQL pools
+- Data Explorer pools
+- Apache Spark pools
+- Azure Data Factory integration runtimes, pipelines, datasets.
 
 ## Workspace encryption configuration
 
@@ -49,46 +47,54 @@ Workspaces can be configured to enable double encryption with a customer-managed
 > [!IMPORTANT]
 > The configuration setting for double encryption cannot be changed after the workspace is created.
 
-:::image type="content" source="./media/workspaces-encryption/workspaces-encryption.png" alt-text="This diagram shows the option that must be selected to enable a workspace for double encryption with a customer-managed key." lightbox="./media/workspaces-encryption/workspaces-encryption.png":::
+:::image type="content" source="media/workspaces-encryption/workspaces-encryption.png" alt-text="This diagram shows the option that must be selected to enable a workspace for double encryption with a customer-managed key." lightbox="media/workspaces-encryption/workspaces-encryption.png":::
 
 ### Key access and workspace activation
 
 The Azure Synapse encryption model with customer-managed keys involves the workspace accessing the keys in Azure Key Vault to encrypt and decrypt as needed. The keys are made accessible to the workspace either through an access policy or [Azure Key Vault RBAC](../../key-vault/general/rbac-guide.md). When granting permissions via an Azure Key Vault access policy, choose the ["Application-only"](../../key-vault/general/security-features.md#key-vault-authentication-options) option during policy creation (select the workspaces managed identity and do not add it as an authorized application).
 
  The workspace managed identity must be granted the permissions it needs on the key vault before the workspace can be activated. This phased approach to workspace activation ensures that data in the workspace is encrypted with the customer-managed key. Encryption can be enabled or disabled for individual dedicated SQL Pools. Each dedicated pool is not enabled for encryption by default.
 
-#### Using a User-assigned Managed identity
+<a id="using-a-user-assigned-managed-identity"></a>
+
+#### Use a User-assigned Managed identity
 Workspaces can be configured to use a [User-assigned Managed identity](../../active-directory/managed-identities-azure-resources/overview.md) to access your customer-managed key stored in Azure Key Vault. Configure a User-assigned Managed identity to avoid phased activation of your Azure Synapse workspace when using double encryption with customer-managed keys. The Managed Identity Contributor built-in role is required to assign a user-assigned managed identity to an Azure Synapse workspace.
 
 > [!NOTE]
 > A User-assigned Managed Identity cannot be configured to access customer-managed key when Azure Key Vault is behind a firewall.
 
-:::image type="content" source="./media/workspaces-encryption/workspaces-encryption-uami.png" alt-text="This diagram shows the option that must be selected to enable a workspace to use user-assigned managed-identity for double encryption with a customer-managed key." lightbox="./media/workspaces-encryption/workspaces-encryption-uami.png":::
-
+:::image type="content" source="media/workspaces-encryption/workspaces-encryption-uami.png" alt-text="This diagram shows the option that must be selected to enable a workspace to use user-assigned managed-identity for double encryption with a customer-managed key." lightbox="media/workspaces-encryption/workspaces-encryption-uami.png":::
 
 #### Permissions
 
 To encrypt or decrypt data at rest, the managed identity must have the following permissions. Similarly, if you are using a Resource Manager template to create a new key, the 'keyOps' parameter of the template must have the following permissions:
 
-* WrapKey (to insert a key into Key Vault when creating a new key).
-* UnwrapKey (to get the key for decryption).
-* Get (to read the public part of a key)
+- WrapKey (to insert a key into Key Vault when creating a new key).
+- UnwrapKey (to get the key for decryption).
+- Get (to read the public part of a key)
 
 #### Workspace activation
 
 If you do not configure a user-assigned managed identity to access customer managed keys during workspace  creation, your workspace will remain in a "Pending" state until activation succeeds. The workspace must be activated before you can fully use all functionality. For example, you can only create a new dedicated SQL pool once activation succeeds. Grant the workspace managed identity access to the key vault and select the activation link in the workspace Azure portal banner. Once the activation completes successfully, your workspace is ready to use with the assurance that all data in it's protected with your customer-managed key. As previously noted, the key vault must have purge protection enabled for activation to succeed.
 
-:::image type="content" source="./media/workspaces-encryption/workspace-activation.png" alt-text="This diagram shows the banner with the activation link for the workspace." lightbox="./media/workspaces-encryption/workspace-activation.png":::
+:::image type="content" source="media/workspaces-encryption/workspace-activation.png" alt-text="This diagram shows the banner with the activation link for the workspace." lightbox="media/workspaces-encryption/workspace-activation.png":::
 
 
-### Manage the workspace customer-managed key 
+### Manage the workspace customer-managed key
 
 You can change the customer-managed key used to encrypt data from the **Encryption** page in the Azure portal. Here too, you can choose a new key using a key identifier or select from Key Vaults that you have access to in the same region as the workspace. If you choose a key in a different key vault from the ones previously used, grant the workspace-managed identity "Get", "Wrap", and "Unwrap" permissions on the new key vault. The workspace will validate its access to the new key vault and all data in the workspace will be re-encrypted with the new key.
 
-:::image type="content" source="./media/workspaces-encryption/workspace-encryption-management.png" alt-text="This diagram shows the workspace Encryption section in the Azure portal." lightbox="./media/workspaces-encryption/workspace-encryption-management.png":::
+:::image type="content" source="media/workspaces-encryption/workspace-encryption-management.png" alt-text="This diagram shows the workspace Encryption section in the Azure portal." lightbox="media/workspaces-encryption/workspace-encryption-management.png":::
+
+> [!IMPORTANT]
+>
+> When changing the encryption key of a workspace, retain the old key until you replace it in the workspace with a new key. This allows decryption of data with the old key before it gets re-encrypted with the new key.
+> The state of the SQL pool (Online/Offline) does not affect the workspace customer managed key (CMK) rotation process. 
+>- SQL pools that are offline during the CMK rotation will remain encrypted with the old key or key version. If the old key or key version is disabled or expired, the pools will not resume as decryption is not possible. Upon resuming these pools, the old key or key version must 1) be enabled and 2) have an expiration date set in the future to allow decryption and subsequent re-encryption with the new key or key version. 
+>
+>- To ensure a smooth CMK rotation, if some SQL pools are offline during the process, the old key or key version should remain enabled and have its expiration date set in the future. This is crucial until the offline pools are successfully resumed and re-encrypted with the new key or key version.
+>- It is highly recommended not to *delete* old keys or key versions, as they might still be needed to decrypt backups. Instead, after all SQL pools have been re-encrypted with the new key or key version, *disable* the old key or key version. This ensures the old key or key version remains available for decrypting older backups if necessary.
 
->[!IMPORTANT]
->When changing the encryption key of a workspace, retain the key until you replace it in the workspace with a new key. This is  to allow decryption of data with the old key before it gets re-encrypted with the new key.
 
 Azure Key Vaults policies for automatic, periodic rotation of keys, or actions on the keys can result in the creation of new key versions. You can choose to re-encrypt all the data in the workspace with the latest version of the active key. To-re-encrypt, change the key in the Azure portal to a temporary key and then switch back to the key you wish to use for encryption. As an example, to update data encryption using the latest version of active key Key1, change the workspace customer-managed key to temporary key, Key2. Wait for encryption with Key2 to finish. Then switch the workspace customer-managed key back to Key1-data in the workspace will be re-encrypted with the latest version of Key1.
 
@@ -117,7 +123,7 @@ Use the following cmdlets for Azure Synapse workspace.
 
 
 
-## Next steps
+## Related content
 
 - [Use built-in Azure Policies to implement encryption protection for Synapse workspaces](../policy-reference.md)
 - [Create an Azure key vault and a key by using Resource Manager template](../../key-vault/keys/quick-create-template.md)