Security risk of backups from untrusted sources

Author: MashaMSFT

azure-sql/includes/virtual-machines-best-practices-security.md

@@ -31,4 +31,4 @@ SQL Server features and capabilities provide methods of securing data at the dat
 - Use [Azure Policy](/azure/governance/policy/overview) to create business rules that can be applied to your environment. Azure Policies evaluate Azure resources by comparing the properties of those resources against rules defined in JSON format.
 - Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Azure Blueprints are [different than Azure Policies](/azure/governance/blueprints/overview#how-its-different-from-azure-policy).
 - Use Windows Server 2019 or Windows Server 2022 to be [FIPS](../virtual-machines/windows/security-considerations-best-practices.md#fips-compliance) compliant with SQL Server on Azure VMs. 
-
+- Treat restoring backups as a high-risk operation and [never restore a backup from an untrusted source](../virtual-machines/windows/security-considerations-best-practices.md#security-risks-of-restoring-backups-from-untrusted-sources). 

azure-sql/managed-instance/recovery-using-backups.md

@@ -211,6 +211,32 @@ It's essential to acknowledge that geo-restore serves as an appropriate disaster
 
 For more information about business continuity choices, see [Overview of business continuity](../database/business-continuity-high-availability-disaster-recover-hadr-overview.md).
 
+## Security risks of restoring backups from untrusted sources
+
+This section outlines the security risks associated with restoring backups to Azure SQL Managed Instance from untrusted sources.
+
+### Why this matters 
+
+Restoring SQL backup files (`.bak`) introduces a potential risk if the backup originates from an untrusted source. The security risk is exacerbated further when SQL managed instances are shared by multiple applications, as it amplifies the area of threat. While backups that remain within a trusted boundary pose no security issue, restoring a malicious backup can compromise the security of the entire environment.
+
+A malicious `.bak` file can: 
+- Take over the SQL managed instance.
+- Escalate privileges and gain unauthorized access to underlying virtual machine (VMs) that hosts the SQL managed instance.
+
+This attack occurs before any validating scripts or security checks can execute, which makes it extremely dangerous. Restoring an untrusted backup is equivalent to running untrusted applications on a critical virtual machine, and introducing arbitrary code execution into your environment. 
+
+### Best practices
+
+Since Azure SQL Managed Instance is ring-fenced and isolated from other workloads, backup restore is supported, which is why extra care must be taken when restoring backups.
+
+Follow these backup security best practices to reduce the threat to Azure SQL Managed Instance:
+- Treat restoring backups as a high-risk operation.
+- Reduce the threat service area by using isolated instances.
+- Only allow trusted backups. Never restore backups from unknown or external sources.
+- Only allow backups that remained within a trusted boundary. Ensure backups originate from within the trusted boundary.
+- Do not bypass security controls for convenience.
+
+
 ## Limitations
 
 Consider the following limitations when working with backups and Azure SQL Managed Instance: 

azure-sql/virtual-machines/windows/backup-restore.md

@@ -137,6 +137,29 @@ The following table summarizes the capabilities of each backup and restore optio
 | Monitor backup jobs with SSMS or Transact-SQL scripts | Yes | Yes | Yes |
 | Restore databases with SSMS or Transact-SQL scripts | Yes | No | Yes |
 
+## Security risks of restoring backups from untrusted sources
+
+This section outlines the security risks associated with restoring backups to SQL Server on Azure VMs from untrusted sources.
+
+### Why this matters 
+
+Restoring SQL backup files (`.bak`) introduces a potential risk if the backup originates from an untrusted source. The security risk is exacerbated further when a SQL Server VM has multiple instances, as it amplifies the area of threat. While backups that remain within a trusted boundary pose no security issue, restoring a malicious backup can compromise the security of the entire environment.
+
+A malicious `.bak` file can: 
+- Take over the SQL Server on Azure VM.
+- Escalate privileges and gain unauthorized access to underlying virtual machine.
+
+This attack occurs before any validating scripts or security checks can execute, which makes it extremely dangerous. Restoring an untrusted backup is equivalent to running untrusted applications on a critical virtual machine, and introducing arbitrary code execution into your environment. 
+
+### Best practices
+
+Follow these backup security best practices to reduce the threat to SQL Server on Azure VMs: 
+- Treat restoring backups as a high-risk operation.
+- Reduce the threat service area by using isolated instances.
+- Only allow trusted backups: never restore backups from unknown or external sources.
+- Only allow backups that remained within a trusted boundary : ensure backups originate from within the trusted boundary.
+- Do not bypass security controls for convenience.
+
 ## Related content
 
 If you're planning your deployment of SQL Server on Azure VM, you can find provisioning guidance in the following guide: [How to provision a Windows SQL Server virtual machine in the Azure portal](create-sql-vm-portal.md).

azure-sql/virtual-machines/windows/security-considerations-best-practices.md

@@ -205,6 +205,29 @@ To be FIPS compliant with SQL Server on Azure VMs, you should be on Windows Serv
 
 SQL Server isn't currently FIPS compliant on Linux Azure VMs.
 
+## Security risks of restoring backups from untrusted sources
+
+This section outlines the security risks associated with restoring backups to SQL Server on Azure VMs from untrusted sources.
+
+### Why this matters 
+
+Restoring SQL backup files (`.bak`) introduces a potential risk if the backup originates from an untrusted source. The security risk is exacerbated further when a SQL Server VM has multiple instances, as it amplifies the area of threat. While backups that remain within a trusted boundary pose no security issue, restoring a malicious backup can compromise the security of the entire environment.
+
+A malicious `.bak` file can: 
+- Take over the SQL Server on Azure VM.
+- Escalate privileges and gain unauthorized access to underlying virtual machine.
+
+This attack occurs before any validating scripts or security checks can execute, which makes it extremely dangerous. Restoring an untrusted backup is equivalent to running untrusted applications on a critical virtual machine, and introducing arbitrary code execution into your environment. 
+
+### Best practices
+
+Follow these backup security best practices to reduce the threat to SQL Server on Azure VMs: 
+- Treat restoring backups as a high-risk operation.
+- Reduce the threat service area by using isolated instances.
+- Only allow trusted backups: never restore backups from unknown or external sources.
+- Only allow backups that remained within a trusted boundary : ensure backups originate from within the trusted boundary.
+- Do not bypass security controls for convenience.
+
 ## Related content
 
 Review the security best practices for [SQL Server](/sql/relational-databases/security/) and [Azure VMs](/azure/virtual-machines/security-recommendations), and then review this article for the best practices that apply to SQL Server on Azure VMs specifically.