Edit

Share via

Security considerations for SQL Server on Azure Virtual Machines

  • Article

Applies to: SQL Server on Azure VM

This article includes overall security guidelines that help establish secure access to SQL Server instances in an Azure virtual machine (VM).

Azure complies with several industry regulations and standards that can enable you to build a compliant solution with SQL Server running in a virtual machine. For information about regulatory compliance with Azure, see Azure Trust Center.

First review the security best practices for SQL Server and Azure VMs and then review this article for the best practices that apply to SQL Server on Azure VMs specifically.

To learn more about SQL Server VM best practices, see the other articles in this series: Checklist, VM size, HADR configuration, and Collect baseline.

Checklist

Review the following checklist in this section for a brief overview of the security best practices that the rest of the article covers in greater detail.

SQL Server features and capabilities provide methods of securing data at the database level that can be combined with security features at the infrastructure level. Together, these features provide defense-in-depth at the infrastructure level for cloud-based and hybrid solutions. In addition, with Azure security measures, it's possible to encrypt your sensitive data, protect virtual machines from viruses and malware, secure network traffic, identify and detect threats, meet compliance requirements, and provides a single method for administration and reporting for any security need in the hybrid cloud.

  • Use Microsoft Defender for Cloud to evaluate and take action to improve the security posture of your data environment. Capabilities such as Azure Advanced Threat Protection (ATP) can be used across your hybrid workloads to improve security evaluation and give the ability to react to risks. Registering your SQL Server VM with the SQL IaaS Agent extension surfaces Microsoft Defender for Cloud assessments within the SQL virtual machine resource of the Azure portal.
  • Use Microsoft Defender for SQL to discover and mitigate potential database vulnerabilities, as well as detect anomalous activities that could indicate a threat to your SQL Server instance and database layer.
  • Vulnerability Assessment is a part of Microsoft Defender for SQL that can discover and help remediate potential risks to your SQL Server environment. It provides visibility into your security state, and includes actionable steps to resolve security issues.
  • Use Azure confidential VMs to reinforce protection of your data in-use, and data-at-rest against host operator access. Azure confidential VMs allow you to confidently store your sensitive data in the cloud and meet strict compliance requirements.
  • If you're on SQL Server 2022, consider using Microsoft Entra authentication to connect to your instance of SQL Server.
  • Azure Advisor analyzes your resource configuration and usage telemetry and then recommends solutions that can help you improve the cost effectiveness, performance, high availability, and security of your Azure resources. Use Azure Advisor at the virtual machine, resource group, or subscription level to help identify and apply best practices to optimize your Azure deployments.
  • Use Azure Disk Encryption when your compliance and security needs require you to encrypt the data end-to-end using your encryption keys, including encryption of the ephemeral (locally attached temporary) disk.
  • Managed Disks are encrypted at rest by default using Azure Storage Service Encryption, where the encryption keys are Microsoft-managed keys stored in Azure.
  • For a comparison of the managed disk encryption options, review the managed disk encryption comparison chart
  • Management ports should be closed on your virtual machines - Open remote management ports expose your VM to a high level of risk from internet-based attacks. These attacks attempt to brute force credentials to gain admin access to the machine.
  • Turn on Just-in-time (JIT) access for Azure virtual machines
  • Use Azure Bastion over Remote Desktop Protocol (RDP).
  • Lock down ports and only allow the necessary application traffic using Azure Firewall which is a managed Firewall as a Service (FaaS) that grants/ denies server access based on the originating IP address.
  • Use Network Security Groups (NSGs) to filter network traffic to, and from, Azure resources on Azure Virtual Networks
  • Use Application Security Groups to group servers together with similar port filtering requirements, with similar functions, such as web servers and database servers.
  • For web and application servers use Azure Distributed Denial of Service (DDoS) protection. DDoS attacks are designed to overwhelm and exhaust network resources, making apps slow or unresponsive. It's common for DDoS attacks to target user interfaces. Azure DDoS protection sanitizes unwanted network traffic, before it impacts service availability
  • Use VM extensions to help address anti-malware, desired state, threat detection, prevention, and remediation to address threats at the operating system, machine, and network levels:
  • Use Azure Policy 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.
  • Use Windows Server 2019 or Windows Server 2022 to be FIPS compliant with SQL Server on Azure VMs.

For more information about security best practices, see SQL Server security best practices and Securing SQL Server.

Microsoft Defender for SQL on machines

Microsoft Defender for Cloud is a unified security management system that is designed to evaluate and provide opportunities to improve the security posture of your data environment. Microsoft Defender offers Microsoft Defender for SQL on machines protection for SQL Server on Azure VMs. Use Microsoft Defender for SQL to discover and mitigate potential database vulnerabilities, and detect anomalous activities that may indicate a threat to your SQL Server instance and database layer.

Microsoft Defender for SQL offers the following benefits:

Portal management

After you've registered your SQL Server VM with the SQL IaaS Agent extension, you can configure a number of security settings using the SQL virtual machines resource in the Azure portal, such as enabling Azure Key Vault integration, or SQL authentication.

Additionally, after you've enabled Microsoft Defender for SQL on machines you can view Defender for Cloud features directly within the SQL virtual machines resource in the Azure portal, such as vulnerability assessments and security alerts.

See manage SQL Server VM in the portal to learn more.

Confidential VMs

Azure confidential VMs provide a strong, hardware-enforced boundary that hardens the protection of the guest OS against host operator access. Choosing a confidential VM size for your SQL Server on Azure VM provides an extra layer of protection, enabling you to confidently store your sensitive data in the cloud and meet strict compliance requirements.

Azure confidential VMs leverage AMD processors with SEV-SNP technology that encrypt the memory of the VM using keys generated by the processor. This helps protect data while it's in use (the data that is processed inside the memory of the SQL Server process) from unauthorized access from the host OS. The OS disk of a confidential VM can also be encrypted with keys bound to the Trusted Platform Module (TPM) chip of the virtual machine, reinforcing protection for data-at-rest.

For detailed deployment steps, see the Quickstart: Deploy SQL Server to a confidential VM.

Recommendations for disk encryption are different for confidential VMs than for the other VM sizes. See disk encryption to learn more.

Microsoft Entra authentication

Starting with SQL Server 2022, you can connect to SQL Server using any of the following authentication methods with Microsoft Entra ID (formerly Azure Active Directory):

  • Password offers authentication with Microsoft Entra credentials
  • Universal with MFA adds multifactor authentication
  • Integrated uses federation providers like Active Directory Federation Services (ADFS) to enable single sign-on (SSO) experiences
  • Service Principal enables authentication from Azure applications
  • Managed Identity enables authentication from applications assigned Microsoft Entra identities

To get started, review Configure Microsoft Entra authentication for your SQL Server VM.

Azure Advisor

Azure Advisor is a personalized cloud consultant that helps you follow best practices to optimize your Azure deployments. Azure Advisor analyzes your resource configuration and usage telemetry and then recommends solutions that can help you improve the cost effectiveness, performance, high availability, and security of your Azure resources. Azure Advisor can evaluate at the virtual machine, resource group, or subscription level.

Azure Key Vault integration

There are multiple SQL Server encryption features, such as transparent data encryption (TDE), column level encryption (CLE), and backup encryption. These forms of encryption require you to manage and store the cryptographic keys you use for encryption. The Azure Key Vault service is designed to improve the security and management of these keys in a secure and highly available location. The SQL Server Connector allows SQL Server to use these keys from Azure Key Vault.

Consider the following:

  • Azure Key Vault stores application secrets in a centralized cloud location to securely control access permissions, and separate access logging.
  • When bringing your own keys to Azure it is recommended to store secrets and certificates in the Azure Key Vault.
  • Azure Disk Encryption uses Azure Key Vault to control and manage disk encryption keys and secrets.

Access control

When you create a SQL Server virtual machine with an Azure gallery image, the SQL Server Connectivity option gives you the choice of Local (inside VM), Private (within Virtual Network), or Public (Internet).

Diagram showing SQL Server connectivity.

For the best security, choose the most restrictive option for your scenario. For example, if you are running an application that accesses SQL Server on the same VM, then Local is the most secure choice. If you are running an Azure application that requires access to the SQL Server, then Private secures communication to SQL Server only within the specified Azure virtual network. If you require Public (internet) access to the SQL Server VM, then make sure to follow other best practices in this topic to reduce your attack surface area.

The selected options in the portal use inbound security rules on the VM's network security group (NSG) to allow or deny network traffic to your virtual machine. You can modify or create new inbound NSG rules to allow traffic to the SQL Server port (default 1433). You can also specify specific IP addresses that are allowed to communicate over this port.

Diagram showing network security group rules.

In addition to NSG rules to restrict network traffic, you can also use the Windows Firewall on the virtual machine.

If you are using endpoints with the classic deployment model, remove any endpoints on the virtual machine if you do not use them. For instructions on using ACLs with endpoints, see Manage the ACL on an endpoint. This is not necessary for VMs that use the Azure Resource Manager.

Consider enabling encrypted connections for the instance of the SQL Server Database Engine in your Azure virtual machine. Configure SQL Server instance with a signed certificate. For more information, see Enable Encrypted Connections to the Database Engine and Connection String Syntax.

Consider the following when securing the network connectivity or perimeter:

  • Azure Firewall - A stateful, managed, Firewall as a Service (FaaS) that grants/ denies server access based on originating IP address, to protect network resources.
  • Azure Distributed Denial of Service (DDoS) protection - DDoS attacks overwhelm and exhaust network resources, making apps slow or unresponsive. Azure DDoS protection sanitizes unwanted network traffic before it impacts service availability.
  • Network Security Groups (NSGs) - Filters network traffic to, and from, Azure resources on Azure Virtual Networks
  • Application Security Groups - Provides for the grouping of servers with similar port filtering requirements, and group together servers with similar functions, such as web servers.

Disk encryption

This section provides guidance for disk encryption, but the recommendations vary depending on if you're deploying a conventional SQL Server on Azure VM, or SQL Server to an Azure confidential VM.

Conventional VMs

Managed disks deployed to VMs that are not Azure confidential VMs use server-side encryption, and Azure Disk Encryption. Server-side encryption provides encryption-at-rest and safeguards your data to meet your organizational security and compliance commitments. Azure Disk Encryption uses either BitLocker or DM-Crypt technology, and integrates with Azure Key Vault to encrypt both the OS and data disks.

Consider the following:

  • Azure Disk Encryption - Encrypts virtual machine disks using Azure Disk Encryption both for Windows and Linux virtual machines.
    • When your compliance and security requirements require you to encrypt the data end-to-end using your encryption keys, including encryption of the ephemeral (locally attached temporary) disk, use Azure disk encryption.
    • Azure Disk Encryption (ADE) leverages the industry-standard BitLocker feature of Windows and the DM-Crypt feature of Linux to provide OS and data disk encryption.
  • Managed Disk Encryption
    • Managed Disks are encrypted at rest by default using Azure Storage Service Encryption where the encryption keys are Microsoft managed keys stored in Azure.
    • Data in Azure managed disks is encrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant.
  • For a comparison of the managed disk encryption options review the managed disk encryption comparison chart.

Azure confidential VMs

If you are using an Azure confidential VM, consider the following recommendations to maximize security benefits:

  • Configure confidential OS disk encryption, which binds the OS disk encryption keys to the Trusted Platform Module (TPM) chip of the virtual machine, and makes the protected disk content accessible only to the VM.
  • Encrypt your data disks (any disks containing database files, log files, or backup files) with BitLocker, and enable automatic unlocking - review manage-bde autounlock or EnableBitLockerAutoUnlock for more information. Automatic unlocking ensures the encryption keys are stored on the OS disk. In conjunction with confidential OS disk encryption, this protects the data-at-rest stored to the VM disks from unauthorized host access.

Trusted Launch

When you deploy a generation 2 virtual machine, you have the option to enable trusted launch, which protects against advanced and persistent attack techniques.

With trusted launch, you can:

  • Securely deploy virtual machines with verified boot loaders, OS kernels, and drivers.
  • Securely protect keys, certificates, and secrets in the virtual machines.
  • Gain insights and confidence of the entire boot chain's integrity.
  • Ensure workloads are trusted and verifiable.

The following features are currently unsupported when you enable trusted launch for your SQL Server on Azure VMs:

  • Azure Site Recovery
  • Ultra disks
  • Managed images
  • Nested virtualization

Manage accounts

You don't want attackers to easily guess account names or passwords. Use the following tips to help:

  • Create a unique local administrator account that is not named Administrator.

  • Use complex strong passwords for all your accounts. For more information about how to create a strong password, see Create a strong password article.

  • By default, Azure selects Windows Authentication during SQL Server virtual machine setup. Therefore, the SA login is disabled and a password is assigned by setup. We recommend that the SA login should not be used or enabled. If you must have a SQL login, use one of the following strategies:

    • Create a SQL account with a unique name that has sysadmin membership. You can do this from the portal by enabling SQL Authentication during provisioning.

      Tip

      If you do not enable SQL Authentication during provisioning, you must manually change the authentication mode to SQL Server and Windows Authentication Mode. For more information, see Change Server Authentication Mode.

    • If you must use the SA login, enable the login after provisioning and assign a new strong password.

Note

Connecting to a SQL Server VM using Microsoft Entra Domain Services isn't supported - use an Active Directory domain account instead.

Auditing and reporting

Auditing with Log Analytics documents events and writes to an audit log in a secure Azure Blob Storage account. Log Analytics can be used to decipher the details of the audit logs. Auditing gives you the ability to save data to a separate storage account and create an audit trail of all events you select. You can also leverage Power BI against the audit log for quick analytics of and insights about your data, as well as to provide a view for regulatory compliance. To learn more about auditing at the VM and Azure levels, see Azure security logging and auditing.

Virtual Machine level access

Close management ports on your machine - Open remote management ports are exposing your VM to a high level of risk from internet-based attacks. These attacks attempt to brute force credentials to gain admin access to the machine.

Virtual Machine extensions

Azure Virtual Machine extensions are trusted Microsoft or 3rd party extensions that can help address specific needs and risks such as antivirus, malware, threat protection, and more.

  • Guest Configuration extension
    • To ensure secure configurations of in-guest settings of your machine, install the Guest Configuration extension.
    • In-guest settings include the configuration of the operating system, application configuration or presence, and environment settings.
    • Once installed, in-guest policies will be available such as 'Windows Exploit guard should be enabled'.
  • Network traffic data collection agent
    • Microsoft Defender for Cloud uses the Microsoft Dependency agent to collect network traffic data from your Azure virtual machines.
    • This agent enables advanced network protection features such as traffic visualization on the network map, network hardening recommendations, and specific network threats.
  • Evaluate extensions from Microsoft and 3rd parties to address anti-malware, desired state, threat detection, prevention, and remediation to address threats at the operating system, machine, and network levels.

FIPS compliance

FIPS is a US government standard that defines minimum security requirements for cryptographic modules in information technology products and systems. SQL Server is capable of being FIPS compliant in SQL Server 2016 and later or SQL Server 2014 with Extended Security Updates.

To be FIPS compliant with SQL Server on Azure VMs, you should be on Windows Server 2022, which has FIPS enabled by default. Windows Server 2019 can also be FIPS compliant if FIPS is manually enabled using the policy specified in Security Technical Implementation Guide (STIG) finding V-93511.

SQL Server is not currently FIPS compliant on Linux Azure VMs.

Related content

Review the security best practices for SQL Server and Azure VMs and then review this article for the best practices that apply to SQL Server on Azure VMs specifically.

For other topics related to running SQL Server in Azure VMs, see SQL Server on Azure Virtual Machines overview. If you have questions about SQL Server virtual machines, see the Frequently Asked Questions.

To learn more, see the other articles in this best practices series: