Azure security baseline for Azure Database Migration Service

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Database Migration Service. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Database Migration Service.

When a feature has relevant Azure Policy Definitions they are listed in this baseline, to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.


Controls not applicable to Azure Database Migration Service, and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Database Migration Service completely maps to the Azure Security Benchmark, see the full Azure Database Migration Service security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

NS-1: Implement security for internal traffic

Guidance: When you deploy Azure Database Migration Service resources you must create or use an existing virtual network. Ensure that all Azure virtual networks follow an enterprise segmentation principle that aligns to the business risks. Any system that could incur higher risk for the organization should be isolated within its own virtual network and sufficiently secured with either a network security group (NSG) and/or Azure Firewall.

Azure Database Migration Service uses TLS 1.2 by default. If needed for backward compatibility for the data source being migrated, support for TLS 1.0 or TLS 1.1 can be enabled in the service configuration blade of your Azure Database Migration Service.

Use Microsoft Sentinel to discover the use of legacy insecure protocols such as SSL/TLSv1, SMBv1, LM/NTLMv1, wDigest, Unsigned LDAP Binds, and weak ciphers in Kerberos.

How to create a network security group with security rules:​ /azure/virtual-network/tutorial-filter-network-traffic​​

How to deploy and configure Azure Firewall:​ /azure/firewall/tutorial-firewall-deploy-portal

Responsibility: Customer

NS-2: Connect private networks together

Guidance: If your migration use case involves cross network traffic, you have option to use Azure ExpressRoute or Azure virtual private network (VPN) to create private connections between Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections do not go over the public internet, and they offer more reliability, faster speeds, and lower latencies than typical internet connections. For point-to-site VPN and site-to-site VPN, you can connect on-premises devices or networks to a virtual network using any combination of these VPN options and Azure ExpressRoute. To connect two or more virtual networks in Azure together, use virtual network peering. Network traffic between peered virtual networks is private and is kept on the Azure backbone network.

Responsibility: Customer

NS-3: Establish private network access to Azure services

Guidance: Where applicable, use Azure Private Link to enable private access to source and destination services such as Azure SQL Server, or other required services during migration. In situations where Azure Private Link is not yet available, use Azure Virtual Network service endpoints. Both Azure Private Link and service endpoints provide secure access to services via an optimized route over the Azure backbone network without crossing the internet.

In addition, make sure the prerequisites are fulfilled before provisioning Azure Database Migration Service on your virtual network, including the communication ports that need to be allowed.

Responsibility: Customer

Identity Management

For more information, see the Azure Security Benchmark: Identity Management.

IM-1: Standardize Azure Active Directory as the central identity and authentication system

Guidance: Azure Database Migration Service uses Azure Active Directory (Azure AD) as the default identity and access management service. You should standardize Azure AD to govern your organization’s identity and access management in:

Microsoft Cloud resources, such as the Azure portal, Azure Storage, Azure Virtual Machine (Linux and Windows), Azure Key Vault, PaaS, and SaaS applications.

Your organization's resources, such as applications on Azure or your corporate network resources.

Securing Azure AD should be a high priority in your organization’s cloud security practice. Azure AD provides an identity secure score to help you assess identity security posture relative to Microsoft’s best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.

Note: Azure AD supports external identities that allow users without a Microsoft account to sign in to their applications and resources with their external identity.

Responsibility: Customer

IM-2: Manage application identities securely and automatically

Guidance: Azure Database Migration service requires users to create an Application ID (service princip) and authentication key in Azure Active Directory (Azure AD) for migrations to Azure SQL Database Managed Instance in 'Online' mode. This Application ID requires either the Contributor role at the subscription level (which is not recommended due to the excessive access permissions Contributor role would be granted) or creation of custom roles with specific permissions that Azure Database Migrations Service requires.

It is recommended to remove this Application ID once the migrations are complete.

Responsibility: Customer

IM-3: Use Azure AD single sign-on (SSO) for application access

Guidance: Azure Database Migration Service is integrated with Azure Active Directory for identity and access management to Azure resources, cloud applications, and on-premises applications. This includes enterprise identities such as employees, as well as external identities such as partners, vendors, and suppliers. This enables single sign-on (SSO) to manage and secure access to your organization’s data and resources on-premises and in the cloud. Connect all your users, applications, and devices to the Azure AD for seamless, secure access and greater visibility and control.

Responsibility: Customer

IM-7: Eliminate unintended credential exposure

Guidance: Azure Database Migration Service allows customers to deploy/run code or configurations or persisted data potentially with identities/secretes, it is recommended to implement Credential Scanner to identify credentials within code or configurations or persisted data. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

If GitHub is used, you can use native secret scanning feature to identify credentials or other form of secrets within the code.

Responsibility: Customer

Privileged Access

For more information, see the Azure Security Benchmark: Privileged Access.

PA-3: Review and reconcile user access regularly

Guidance: Azure Database Migration service requires users to create an Application ID (service principal) and authentication key in Azure Active Directory (Azure AD) for migrations to Azure SQL Database Managed Instance in 'Online' mode. It is recommended to remove this Application ID once the migrations are complete.

Responsibility: Customer

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrators, developers, and critical service operators. Use highly secured user workstations and/or Azure Bastion for administrative tasks. Use Azure Active Directory, Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration including strong authentication, software and hardware baselines, restricted logical and network access.

Responsibility: Customer

PA-7: Follow just enough administration (least privilege principal)

Guidance: Azure Database Migration Service is integrated with Azure role-based access control (RBAC) to manage its resources. Azure RBAC allows you to manage Azure resource access through role assignments. You can assign these roles to users, groups service principals and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell or the Azure portal. The privileges you assign to resources through the Azure RBAC should be always limited to what is required by the roles. This complements the just in time (JIT) approach of Azure AD Privileged Identity Management (PIM) and should be reviewed periodically.

Use built-in roles to allocate permission and only create custom role when required.

Responsibility: Customer

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

DP-4: Encrypt sensitive information in transit

Guidance: Azure Database Migration Service encrypts the data in transit from the sources configured by the customer to the database migration service instance by default using TLS 1.2 or later. You can choose to disable this if the source server does not support TLS 1.2 connection, although it is highly recommended not to do so. Transfer of data from database migration service instance to the target instance is always encrypted.

Outside of the Azure Database Migration Service, you can use access controls, data in transit should be protected against ‘out of band’ attacks (e.g. traffic capture) using encryption to ensure that attackers cannot easily read or modify the data. Ensure for HTTP traffic, that any clients connecting to your Azure resources can negotiate TLS v1.2 or greater. For remote management, use SSH (for Linux) or RDP/TLS (for Windows) instead of unencrypted protocol. Obsoleted SSL/TLS/SSH versions, protocols, and weak ciphers should be disabled.

At the underlying infrastructure, Azure provides data in transit encryption by default for data traffic between Azure data centers.

Responsibility: Shared

Asset Management

For more information, see the Azure Security Benchmark: Asset Management.

AM-1: Ensure security team has visibility into risks for assets

Guidance: Ensure security teams are granted Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks using Microsoft Defender for Cloud.

Depending on how security team responsibilities are structured, monitoring for security risks could be the responsibility of a central security team or a local team. That said, security insights and risks must always be aggregated centrally within an organization.

Security Reader permissions can be applied broadly to an entire tenant (Root Management Group) or scoped to management groups or specific subscriptions.

Note: Additional permissions might be required to get visibility into workloads and services.

Responsibility: Customer

AM-2: Ensure security team has access to asset inventory and metadata

Guidance: Apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Azure Database Migration Service does not allow running an application or installation of software on its resources.

Responsibility: Customer

AM-3: Use only approved Azure services

Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.

Responsibility: Customer

Logging and Threat Detection

For more information, see the Azure Security Benchmark: Logging and Threat Detection.

LT-2: Enable threat detection for Azure identity and access management

Guidance: Azure AD provides the following user logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Microsoft Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:

  • Sign-ins – The sign-ins report provides information about the usage of managed applications and user sign-in activities.

  • Audit logs - Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.

  • Risky sign-ins - A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.

  • Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.

Microsoft Defender for Cloud can also alert on certain suspicious activities such as excessive number of failed authentication attempts, deprecated accounts in the subscription. In addition to the basic security hygiene monitoring, Microsoft Defender for Cloud’s Threat Protection module can also collect more in-depth security alerts from individual Azure compute resources (virtual machines, containers, app service), data resources (SQL DB and storage), and Azure service layers. This capability gives you visibility on account anomalies inside the individual resources.

Responsibility: Customer

LT-3: Enable logging for Azure network activities

Guidance: Enable and collect network security group (NSG) resource logs, NSG flow logs, Azure Firewall logs, and Web Application Firewall (WAF) logs for security analysis to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.

Note: Azure Database Migration Service does not produce or process DNS query logs which would need to be enabled.

Responsibility: Customer

LT-5: Centralize security log management and analysis

Guidance: Centralize logging storage and analysis to enable correlation. For each log source, ensure you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.

Ensure you are integrating Azure activity logs into your central logging. Ingest logs via Azure Monitor to aggregate security data generated by endpoint devices, network resources, and other security systems. In Azure Monitor, use Log Analytics workspaces to query and perform analytics, and use Azure Storage accounts for long term and archival storage.

In addition, enable and onboard data to Microsoft Sentinel or a third-party SIEM.

Many organizations choose to use Microsoft Sentinel for “hot” data that is used frequently and Azure Storage for “cold” data that is used less frequently.

Responsibility: Customer

Posture and Vulnerability Management

For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.

PV-8: Conduct regular attack simulation

Guidance: As required, conduct penetration testing or red team activities on your Azure resources and ensure remediation of all critical security findings. Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests are not in violation of Microsoft policies. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Customer

Next steps