Migrate MySQL on-premises to Azure Database for MySQL: Security

APPLIES TO: Azure Database for MySQL - Single Server Azure Database for MySQL - Flexible Server

Prerequisites

Business continuity and disaster recovery

Overview

Moving to a cloud-based service doesn't mean the entire internet has access to it always. Azure provides best in class security that ensures data workloads are continually protected from bad actors and rouge programs.

Authentication

Azure Database for MySQL supports the basic authentication mechanisms for MySQL user connectivity, but also supports integration with Microsoft Entra ID. This security integration works by issuing tokens that act like passwords during the MySQL login process. Configuring Active Directory integration is incredibly simple to do and supports not only users, but Microsoft Entra groups as well.

Audit logging

MySQL has a robust built-in audit log feature. By default, this audit log feature is disabled in Azure Database for MySQL. Server level logging can be enabled by changing the audit\_log\_enabled server parameter. Once enabled, logs can be accessed through Azure Monitor and Log Analytics by turning on diagnostic logging.

To query for user connection-related events, run the following KQL query:

AzureDiagnostics
| where ResourceProvider =="MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlAuditLogs' and event\_class\_s == "connection\_log"
| project TimeGenerated, LogicalServerName\_s, event\_class\_s, event\_subclass\_s
, event\_time\_t, user\_s , ip\_s , sql\_text\_s
| order by TimeGenerated asc

Encryption

Data in the MySQL instance is encrypted at rest by default. Any automated backups are also encrypted to prevent potential leakage of data to unauthorized parties. This encryption is typically performed with a key that is created when the instance is created. In addition to this default encryption key, administrators have the option to bring your own key (BYOK).

When using a customer-managed key strategy, it's vital to understand responsibilities around key lifecycle management. Customer keys are stored in an Azure Key Vault and then accessed via policies. it's vital to follow all recommendations for key management, the loss of the encryption key equates to the loss of data access.

Data can be encrypted during transit using SSL/TLS. As previously discussed, it might be necessary to modify your applications to support this change and also configure the appropriate TLS validation settings.

Firewall

Once users are set up and the data is encrypted at rest, the migration team should review the network data flows. Azure Database for MySQL provides several mechanisms to secure the networking layers by limiting access to only authorized users, applications, and devices.

The first line of defense for protecting the MySQL instance is to implement firewall rules. IP addresses can be limited to only valid locations when accessing the instance via internal or external IPs. If the MySQL instance is destined to only serve internal applications, then restrict public access.

When moving an application to Azure along with the MySQL workload, it's likely there are been multiple virtual networks setup in a hub and spoke pattern that requires Virtual Network Peering to be configured.

Private link

To limit access to the Azure Database for MySQL to internal Azure resources, enable Private Link. Private Link ensures that the MySQL instance is assigned a private IP rather than a public IP address.

Review a set of potential security baseline tasks that can be implemented across all Azure resources. Not all of the items described on the reference link apply to the specific data workloads or Azure resources.

Security checklist

• Use Microsoft Entra authentication where possible.

• Enable Advanced Thread Protection.

• Enable all auditing features.

• Consider a Bring-Your-Own-Key (BYOK) strategy.

• Implement firewall rules.

• Utilize private endpoints for workloads that don't travel over the Internet.

Next step