This article answers common questions about protecting backups from ransomware with the Azure Backup service.
What are the best practices to configure and protect Azure Backups against security and ransomware threats?
Your backup data that’s securely stored in an Azure resource called Recovery Services Vault or Backup Vault is isolated. This vault is a management entity, any application or guest don’t have direct access to these backups, thus prevents malicious actors to perform destructive operations on the backup storage, such as deletions or tampering of backup data.
The following practices protect backups against security and ransomware threats:
Manage access to back up resources using Azure role-based access control (Azure RBAC).
- Azure Backup allows you to segregate duties within your team to grant only the amount of access necessary for your team members to do their jobs using Azure role-based access control (Azure RBAC) to manage Azure Backup.
- Use Privileged Identity Management to provide time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused permissions. Learn more.
Ensure soft delete is enabled to protect backups from accidental or malicious deletes
Soft delete is enabled by default on a newly created Recovery Services vault. It protects backup data from accidental or malicious deletes for 14 days at no additional cost, allowing the recovery of that backup item before it’s permanently lost. We recommend not to disable this feature. If backups are deleted and soft delete isn’t enabled, you or Microsoft can’t recover the deleted backup data. Use Multi-user authorization (MUA) as an additional layer of protection for these critical operations on your Recovery Services vault to validate operation before disabling this feature. For more information, see How to enable, manage, and when to disable soft delete for Azure Backup?
We also recommend using Multi-user authorization (MUA) to protection critical operations on your Recovery Services vault.
Ensure Multi-user authorization (MUA) is enabled to protect against rogue admin scenario.
MUA for Azure Backup uses a new resource called the Resource Guard to ensure critical operations, such as disabling soft delete, stopping and deleting backups, or reducing retention of backup policies, are performed only with applicable authorization. For more information, see:
Set-up alerts and notifications for critical backup operations.
Azure Backup provides multiple monitoring and notification capabilities for a wide range of scenarios. Ensure they're configured correctly for timely alerts and required actions. Learn more
We recommend you to use Azure Monitor for Alerts to receive alerts/notifications on critical operations.
Ensure network connectivity between backup services and workloads is secure.
- For Azure VM, data in transit remains on the Azure backbone network without needing to access your virtual network. Therefore, backup of Azure VMs placed inside secured networks doesn't require you to allow access to any IPs or FQDNs.
- For databases on Azure VM, secure the outbound access with the following network connectivity requirements for SQL Server, for SAP HANA database on Azure VM.
- For PaaS resources, such as PostgreSQL, communication happens within the Azure network. For workloads (such as Azure Files, Azure Disk, and Azure Blobs) where the backup data is stored in the operational tier, you need to allow Azure services on the trusted services list to access storage account in Network Settings for the corresponding storage account.
- For on-premises workloads that are protected using MARS or MABS, can use Microsoft peering for ExpressRoute or Virtual Private Network (VPN) to connect to Azure. Use private peering when using private endpoints for Backup. Network traffic between peered virtual networks remains private.
For more information, see:
Ensure backup data is encrypted.
By default, backup data at rest is encrypted using platform-managed keys (PMK). For vaulted backups, you can choose to use customer-managed keys (CMK) to own and manage the encryption keys yourself. Additionally, you can configure encryption on the storage infrastructure using infrastructure-level encryption, which along with CMK encryption provides double encryption of data at rest.
- MARS or MABS backup allows you to use your own passphrase to allow end-to-end encryption of data. However, ensure that the associated encryption passphrase is securely stored in an alternate location (other than the source machine), preferably in the Azure Key Vault. Keep track of all the passphrases, if you've multiple machines being backed-up with the MARS agents.
- You can also back up encrypted Azure VMs (encrypted using Azure Disk Encryption) and encrypted SQL Servers running in Azure VMs (encrypted using TDE) to ensure end-to-end encryption.
For more information, see:
Regularly monitor your backups
Use the monitoring solutions (for example, Backup Explorer) to identify machines in the organization that aren’t protected by Azure Backup, monitor your backup items, backup jobs, and policies. For more information, see:
Validate backups periodically by performing test restores.
Periodically perform data recovery test of your backups to verify the backup configurations and availability of the backup data meet your organization’s recovery needs, and expected RPO and RTO requirements. Define your backup recovery test strategy to include the scope of test recovery and frequency for performing a test recovery.
Enable Soft delete is enabled to protect backups from accidental or malicious deletes.
Soft delete is a useful feature that helps you deal with data loss. Soft delete retains backup data for 14 days, allowing the recovery of that backup item before it’s permanently lost. For more information, see How to enable, manage and disable soft delete for Azure Backup?
Ensure Multi-user authorization (MUA) is enabled for an additional layer of protection.
MUA for Azure Backup uses a new resource called Resource Guard to ensure critical operations, such as disabling soft delete, stopping and deleting backups, or reducing retention of backup policies, are performed only with applicable authorization.
For more information, see:
If backup was enabled on the source system and backups are healthy prior to the point of attack, then consider the following actions:
- Review the incident timeline to estimate the impact on production workloads.
- Identify the last clean recovery point created before the impact.
- Review the retention duration of the existing recovery points. If more time is required to restore from an attack, then consider extending the retention duration in the backup policy.
- Perform recovery to an isolated and secure network.
- Perform restores on smaller sets of data (for example, item-level recovery) to ensure healthy recovery points.
- Scan the restored data for signs of infection to ensure it’s not compromised.
- Once the data is ascertained to be clean, use it for production system.
- Once complete, ensure backups are configured and healthy on the recovered workloads.
- Identify gaps to check where the process didn’t work as expected. Find opportunities to improve process.
No, the infected recovery point (that is, backed-up data containing infected data) can’t spread to previous non-infected recovery points.
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, so that they aren’t deleted by the retention policy.