Merge pull request #216338 from v-amallick/Oct-20-2022-QualityStrategy

Quality strategy - Freshness

Author: v-dirichards

articles/backup/backup-encryption.md

@@ -2,25 +2,27 @@
 title: Encryption in Azure Backup
 description: Learn how encryption features in Azure Backup help you protect your backup data and meet the security needs of your business.
 ms.topic: conceptual
-ms.date: 05/25/2021
-ms.custom: references_regions 
+ms.date: 10/28/2022
+ms.custom: references_regions, engagement-fy23 
+author: v-amallick
+ms.service: backup
+ms.author: v-amallick
 ---
 
 # Encryption in Azure Backup
 
-All your backed-up data is automatically encrypted when stored in the cloud using Azure Storage encryption, which helps you meet your security and compliance commitments. This data at rest is encrypted using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant. In addition to encryption at rest, all your backup data in transit is transferred over HTTPS. It always remains on the Azure backbone network.
+Azure Backup automatically encrypts all your backed-up data while storing in the cloud using Azure Storage encryption, which helps you meet your security and compliance commitments. This data at rest is encrypted using 256-bit AES encryption (one of the strongest block ciphers available that is FIPS 140-2 compliant). Additionally, all your backup data in transit is transferred over HTTPS. It always remains on the Azure backbone network.
 
-## Levels of encryption in Azure Backup
+This article describes the levels of encryption in Azure Backup that helps to protect your backed-up data.
+
+## Encryption levels
 
 Azure Backup includes encryption on two levels:
 
-- **Encryption of data in the Recovery Services vault**
-  - **Using platform-managed keys**: By default, all your data is encrypted using platform-managed keys. You don't need to take any explicit action from your end to enable this encryption. It applies to all workloads being backed up to your Recovery Services vault.
-  - **Using customer-managed keys**: When backing up your Azure Virtual Machines, you can choose to encrypt your data using encryption keys owned and managed by you. Azure Backup lets you use your RSA keys stored in the Azure Key Vault for encrypting your backups. The encryption key used for encrypting backups may be different from the one used for the source. The data is protected using an AES 256 based data encryption key (DEK), which is, in turn, protected using your keys. This gives you full control over the data and the keys. To allow encryption, it's required that you grant the Recovery Services vault access to the encryption key in the Azure Key Vault. You can disable the key or revoke access whenever needed. However, you must enable encryption using your keys before you attempt to protect any items to the vault. [Learn more here](encryption-at-rest-with-cmk.md).
-  - **Infrastructure-level encryption**: In addition to encrypting your data in the Recovery Services vault using customer-managed keys, you can also choose to have an additional layer of encryption configured on the storage infrastructure. This infrastructure encryption is managed by the platform. Together with encryption at rest using customer-managed keys, it allows two-layer encryption of your backup data. Infrastructure encryption can only be configured if you first choose to use your own keys for encryption at rest. Infrastructure encryption uses platform-managed keys for encrypting data.
-- **Encryption specific to the workload being backed up**  
-  - **Azure virtual machine backup**: Azure Backup supports backup of VMs with disks encrypted using [platform-managed keys](../virtual-machines/disk-encryption.md#platform-managed-keys), as well as [customer-managed keys](../virtual-machines/disk-encryption.md#customer-managed-keys) owned and managed by you. In addition, you can also back up your Azure Virtual machines that have their OS or data disks encrypted using [Azure Disk Encryption](backup-azure-vms-encryption.md#encryption-support-using-ade). ADE uses BitLocker for Windows VMs, and DM-Crypt for Linux VMs, to perform in-guest encryption.
-  - **TDE - enabled database backup is supported**. To restore a TDE-encrypted database to another SQL Server, you need to first [restore the certificate to the destination server](/sql/relational-databases/security/encryption/move-a-tde-protected-database-to-another-sql-server). The backup compression for TDE-enabled databases for SQL Server 2016 and newer versions is available, but at lower transfer size as explained [here](https://techcommunity.microsoft.com/t5/sql-server/backup-compression-for-tde-enabled-databases-important-fixes-in/ba-p/385593).
+| Encryption level | Description |
+| --- | --- |
+| **Encryption of data in the Recovery Services vault** | - **Using platform-managed keys**: By default, all your data is encrypted using platform-managed keys. You don't need to take any explicit action from your end to enable this encryption. It applies to all workloads being backed-up to your Recovery Services vault. <br><br>  - **Using customer-managed keys**: When backing up your Azure Virtual Machines, you can choose to encrypt your data using encryption keys owned and managed by you. Azure Backup lets you use your RSA keys stored in the Azure Key Vault for encrypting your backups. The encryption key used for encrypting backups may be different from the one used for the source. The data is protected using an AES 256 based data encryption key (DEK), which is, in turn, protected using your keys. This gives you full control over the data and the keys. To allow encryption, it's required that you grant the Recovery Services vault access to the encryption key in the Azure Key Vault. You can disable the key or revoke access whenever needed. However, you must enable encryption using your keys before you attempt to protect any items to the vault. [Learn more here](encryption-at-rest-with-cmk.md). <br><br> - **Infrastructure-level encryption**: In addition to encrypting your data in the Recovery Services vault using customer-managed keys, you can also choose to have an additional layer of encryption configured on the storage infrastructure. This infrastructure encryption is managed by the platform. Together with encryption at rest using customer-managed keys, it allows two-layer encryption of your backup data. Infrastructure encryption can only be configured if you first choose to use your own keys for encryption at rest. Infrastructure encryption uses platform-managed keys for encrypting data.  |
+| **Encryption specific to the workload being backed-up** | - **Azure virtual machine backup**: Azure Backup supports backup of VMs with disks encrypted using [platform-managed keys](../virtual-machines/disk-encryption.md#platform-managed-keys), as well as [customer-managed keys](../virtual-machines/disk-encryption.md#customer-managed-keys) owned and managed by you. In addition, you can also back up your Azure Virtual machines that have their OS or data disks encrypted using [Azure Disk Encryption](backup-azure-vms-encryption.md#encryption-support-using-ade). ADE uses BitLocker for Windows VMs, and DM-Crypt for Linux VMs, to perform in-guest encryption.  <br><br>  - **TDE - enabled database backup is supported**. To restore a TDE-encrypted database to another SQL Server, you need to first [restore the certificate to the destination server](/sql/relational-databases/security/encryption/move-a-tde-protected-database-to-another-sql-server). The backup compression for TDE-enabled databases for SQL Server 2016 and newer versions is available, but at lower transfer size as explained [here](https://techcommunity.microsoft.com/t5/sql-server/backup-compression-for-tde-enabled-databases-important-fixes-in/ba-p/385593). |
 
 ## Next steps
 

articles/backup/protect-backups-from-ransomware-faq.yml

@@ -69,7 +69,7 @@ sections:
 
             For more information, see:
 
-            - [Encryption of data in the Recovery Services vault using CMK, PMK, Infrastructure-level encryption](backup-encryption.md#levels-of-encryption-in-azure-backup).
+            - [Encryption of data in the Recovery Services vault using CMK, PMK, Infrastructure-level encryption](backup-encryption.md#encryption-levels).
             - [Azure Storage encryption for data at rest](../storage/common/storage-service-encryption.md).
             - [Transport Layer Security in Azure Backup](transport-layer-security.md).
 
@@ -81,7 +81,7 @@ sections:
             - [Monitor your backups with Backup Explorer](monitor-azure-backup-with-backup-explorer.md).
             - [Monitor backup workloads using Azure portal (using Recovery Services vault)](backup-azure-monitoring-built-in-monitor.md).
             - [Monitor backup health using Azure monitor metrics](backup-azure-monitoring-built-in-monitor.md).
-            - [Custom monitoring and alerting using azure monitor Log Analytics workspace](backup-azure-monitoring-use-azuremonitor.md).
+            - [Custom monitoring and alerting using Azure monitor Log Analytics workspace](backup-azure-monitoring-use-azuremonitor.md).
 
           - **Validate backups periodically by performing test restores**.
 
@@ -121,5 +121,5 @@ sections:
         answer: No, the infected recovery point (that is, backed-up data containing infected data) can’t spread to previous non-infected recovery points.
 
       - question: How can I extend the expiration of recovery points in case of impact?
-        answer: If you need more time to investigate and recover in case of an impact, you can extend expiration to ensure the recovery points aren't cleaned up (as per policy). [Learn more](backup-architecture.md#additional-reference), so that they aren’t deleted by the retention policy
+        answer: If you need more time to investigate and recover in case of an impact, you can extend expiration to ensure the recovery points aren't cleaned up (as per policy). [Learn more](backup-architecture.md#additional-reference), so that they aren’t deleted by the retention policy.