Azure security baseline for Azure Database for MySQL

This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Azure Database for MySQL. 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 for MySQL.

Note

Controls not applicable to Azure Database for MySQL, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Database for MySQL completely maps to the Azure Security Benchmark, see the full Azure Database for MySQL security baseline mapping file.

Network Security

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

1.1: Protect Azure resources within virtual networks

Guidance: Configure Private Link for Azure Database for MySQL with Private Endpoints. Private Link allows you to connect to various PaaS services in Azure via a private endpoint. Azure Private Link essentially brings Azure services inside your private Virtual Network (VNet). Traffic between your virtual network and MySQL instance travels the Microsoft backbone network.

Alternatively, you may use Virtual Network Service Endpoints to protect and limit network access to your Azure Database for MySQL implementations. Virtual network rules are one firewall security feature that controls whether your Azure Database for MySQL server accepts communications that are sent from particular subnets in virtual networks.

You may also secure your Azure Database for MySQL server with firewall rules. The server firewall prevents all access to your database server until you specify which computers have permission. To configure your firewall, you create firewall rules that specify ranges of acceptable IP addresses. You can create firewall rules at the server level.

Responsibility: Customer

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforMySQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Private endpoint should be enabled for MySQL servers Private endpoint connections enforce secure communication by enabling private connectivity to Azure Database for MySQL. Configure a private endpoint connection to enable access to traffic coming only from known networks and prevent access from all other IP addresses, including within Azure. AuditIfNotExists, Disabled 1.0.2

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: When your Azure Database for MySQL instance is secured to a private endpoint, you can deploy virtual machines in the same virtual network. You can use a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into a Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Azure Security Center monitoring: None

1.4: Deny communications with known-malicious IP addresses

Guidance: Use Advanced Threat Protection for Azure Database for MySQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

Enable DDoS Protection Standard on the Virtual Networks associated with your Azure Database for MySQL instances to guard against DDoS attacks. Use Azure Security Center Integrated Threat Intelligence to deny communications with known malicious or unused Internet IP addresses.

Responsibility: Customer

Azure Security Center monitoring: None

1.5: Record network packets

Guidance: When your Azure Database for MySQL instance is secured to a private endpoint, you can deploy virtual machines in the same virtual network. You can then configure a network security group (NSG) to reduce the risk of data exfiltration. Enable NSG flow logs and send logs into a Storage Account for traffic audit. You may also send NSG flow logs to a Log Analytics workspace and use Traffic Analytics to provide insights into traffic flow in your Azure cloud. Some advantages of Traffic Analytics are the ability to visualize network activity and identify hot spots, identify security threats, understand traffic flow patterns, and pinpoint network misconfigurations.

Responsibility: Customer

Azure Security Center monitoring: None

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Use Advanced Threat Protection for Azure Database for MySQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

Responsibility: Customer

Azure Security Center monitoring: None

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: For resources that need access to your Azure Database for MySQL instances, use Virtual Network Service Tags to define network access controls on Network Security Groups or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (e.g., SQL.WestUs) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

Note: Azure Database for MySQL uses the "Microsoft.Sql" Service Tags.

Responsibility: Customer

Azure Security Center monitoring: None

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network settings and network resources associated with your Azure Database for MySQL instances with Azure Policy. Use Azure Policy aliases in the "Microsoft.DBforMySQL" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Azure Database for MySQL instances. You may also make use of built-in policy definitions related to networking or your Azure Database for MySQL instances, such as:

  • DDoS Protection Standard should be enabled

  • Enforce SSL connection should be enabled for MySQL database servers

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

1.10: Document traffic configuration rules

Guidance: Use tags for resources related to network security and traffic flow for your Azure Database for MySQL instances to provide metadata and logical organization.

Use any of the built-in Azure Policy definitions related to tagging, such as Require tag and its value to ensure that all resources are created with tags and to notify you of existing untagged resources.

You may use Azure PowerShell or Azure CLI to look up or perform actions on resources based on their tags.

Responsibility: Customer

Azure Security Center monitoring: None

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use Azure Activity Log to monitor network resource configurations and detect changes for network resources related to your Azure Database for MySQL instances. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Responsibility: Customer

Azure Security Center monitoring: None

Logging and Monitoring

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

2.2: Configure central security log management

Guidance: Enable Diagnostic Settings and Server Logs and ingest logs to aggregate security data generated by your Azure Database for MySQL instances. Within Azure Monitor, use Log Analytics Workspace(s) to query and perform analytics, and use Azure Storage Accounts for long-term/archival storage. Alternatively, you may enable and on-board data to Azure Sentinel or a third-party SIEM.

Responsibility: Customer

Azure Security Center monitoring: None

2.3: Enable audit logging for Azure resources

Guidance: Enable Diagnostic Settings on your Azure Database for MySQL instances for access to audit, slow query, and MySQL metrics logs. Ensure that you specifically enable the MySQL Audit log. Activity logs, which are automatically available, include event source, date, user, timestamp, source addresses, destination addresses, and other useful elements. You may also enable Azure Activity Log Diagnostic Settings and send the logs to the same Log Analytics workspace or Storage Account.

Responsibility: Customer

Azure Security Center monitoring: None

2.5: Configure security log storage retention

Guidance: Within Azure Monitor, for the Log Analytics workspace being used to hold your Azure Database for MySQL logs, set the retention period according to your organization's compliance regulations. Use Azure Storage Accounts for long-term/archival storage.

Responsibility: Customer

Azure Security Center monitoring: None

2.6: Monitor and review logs

Guidance: Analyze and monitor logs from your Azure Database for MySQL instances for anomalous behavior. Use Azure Monitor's Log Analytics to review logs and perform queries on log data. Alternatively, you may enable and on-board data to Azure Sentinel or a third-party SIEM.

Responsibility: Customer

Azure Security Center monitoring: None

2.7: Enable alerts for anomalous activities

Guidance: Enable Advanced Threat Protection for Azure Database for MySQL. Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases.

In addition, you may enable Server Logs and Diagnostic Settings for MySQL and send logs to a Log Analytics workspace. Onboard your Log Analytics workspace to Azure Sentinel as it provides a security orchestration automated response (SOAR) solution. This allows for playbooks (automated solutions) to be created and used to remediate security issues.

Responsibility: Customer

Azure Security Center monitoring: None

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Maintain an inventory of the user accounts that have administrative access to the management plane (e.g. Azure portal) of your Azure Database for MySQLinstances. In addition, maintain an inventory of the administrative accounts that have access to the data plane (within the database itself) of your Azure Database for MySQL instances. (When creating the MySQL server, you provide credentials for an administrator user. This administrator can be used to create additional MySQL users.)

Azure Database for MySQL does not support built-in role-based access control, but you can create custom roles based on specific resource provider options.

Responsibility: Customer

Azure Security Center monitoring: None

3.2: Change default passwords where applicable

Guidance: Azure Active Directory (Azure AD) does not have the concept of default passwords.

Upon creation of the Azure Database for MySQL resource itself, Azure forces the creation of an administrative user with a strong password. However, once the MySQL instance has been created, you may use the first server admin account you created to create additional users and grant administrative access to them. When creating these accounts, ensure you configure a different, strong password for each account.

Responsibility: Customer

Azure Security Center monitoring: None

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts that have access to your Azure Database for MySQL instances. Use Azure Security Center Identity and access management to monitor the number of administrative accounts.

Responsibility: Customer

Azure Security Center monitoring: None

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Signing into Azure Database for MySQL is supported both using username/password configured directly in the database, as well as using an Azure Active Directory (Azure AD) identity and utilizing an Azure AD token to connect. When using an Azure AD token, different methods are supported, such as an Azure AD user, an Azure AD group, or an Azure AD application connecting to the database.

Separately, control plane access for MySQL is available via REST API and supports SSO. To authenticate, set the Authorization header for your requests to a JSON Web Token that you obtain from Azure AD.

Responsibility: Customer

Azure Security Center monitoring: None

3.5: Use multi-factor authentication for all Azure Active Directory-based access

Guidance: Enable Azure Active Directory (Azure AD) multifactor authentication and follow Azure Security Center Identity and Access Management recommendations. When utilizing Azure AD tokens for signing into your database, this allows you to require multifactor authentication for database sign-ins.

Responsibility: Customer

Azure Security Center monitoring: None

3.6: Use secure, Azure-managed workstations for administrative tasks

Guidance: Use privileged access workstations (PAWs) with multifactor authentication configured to log into and configure Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Enable Advanced Threat Protection for Azure Database for MySQL to generate alerts for suspicious activity.

In addition, you may use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) for generation of logs and alerts when suspicious or unsafe activity occurs in the environment.

Use Azure AD Risk Detections to view alerts and reports on risky user behavior.

Responsibility: Customer

Azure Security Center monitoring: None

3.8: Manage Azure resources from only approved locations

Guidance: Use Conditional Access Named Locations to allow portal and Azure Resource Manager access from only specific logical groupings of IP address ranges or countries/regions.

Responsibility: Customer

Azure Security Center monitoring: None

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system. Azure AD protects data by using strong encryption for data at rest and in transit. Azure AD also salts, hashes, and securely stores user credentials.

For signing into Azure Database for MySQL it is recommended to use Azure AD and utilize an Azure AD token to connect. When using an Azure AD token, different methods are supported, such as an Azure AD user, an Azure AD group, or an Azure AD application connecting to the database.

Azure AD credentials may also be used for administration at the management plane level (e.g. the Azure portal) to control MySQL admin accounts.

Responsibility: Customer

Azure Security Center monitoring: None

3.10: Regularly review and reconcile user access

Guidance: Review the Azure Active Directory (Azure AD) logs to help discover stale accounts which can include those with Azure Database for MySQL administrative roles. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications that may be used to access Azure Database for MySQL, and role assignments. User access should be reviewed on a regular basis such as every 90 days to make sure only the right Users have continued access.

Responsibility: Customer

Azure Security Center monitoring: None

3.11: Monitor attempts to access deactivated credentials

Guidance: Enable Diagnostic Settings for Azure Database for MySQL and Azure Active Directory (Azure AD), sending all logs to a Log Analytics workspace. Configure desired alerts (such as failed authentication attempts) within Log Analytics.

Responsibility: Customer

Azure Security Center monitoring: None

3.12: Alert on account sign-in behavior deviation

Guidance: Enable Advanced Threat Protection for Azure Database for MySQL to generate alerts for suspicious activity.

Use Azure Active Directory (Azure AD)'s Identity Protection and risk detection features to configure automated responses to detected suspicious actions. You may enable automated responses through Azure Sentinel to implement your organization's security responses.

You can also ingest logs into Azure Sentinel for further investigation.

Responsibility: Customer

Azure Security Center monitoring: None

Data Protection

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

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags to assist in tracking Azure Database for MySQL instances or related resources that store or process sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

4.2: Isolate systems storing or processing sensitive information

Guidance: Implement separate subscriptions and/or management groups for development, test, and production. Use a combination of Private Link, Service Endpoints, and/or firewall rules to isolate and limit network access to your Azure Database for MySQL instances.

Responsibility: Customer

Azure Security Center monitoring: None

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: When using Azure VMs to access Azure Database for MySQL instances, make use of Private Link, MySQL network configurations, network security groups, and service tags to mitigate the possibility of data exfiltration.

Microsoft manages the underlying infrastructure for Azure Database for MySQL and has implemented strict controls to prevent the loss or exposure of customer data.

Responsibility: Customer

Azure Security Center monitoring: None

4.4: Encrypt all sensitive information in transit

Guidance: Azure Database for MySQL supports connecting your MySQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against "man in the middle" attacks by encrypting the data stream between the server and your application. In the Azure portal, ensure "Enforce SSL connection" is enabled for all of your Azure Database for MySQL instances by default.

Currently the TLS versions supported for Azure Database for MySQL are TLS 1.0, TLS 1.1, TLS 1.2.

Responsibility: Shared

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforMySQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Enforce SSL connection should be enabled for MySQL database servers Azure Database for MySQL supports connecting your Azure Database for MySQL server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against 'man in the middle' attacks by encrypting the data stream between the server and your application. This configuration enforces that SSL is always enabled for accessing your database server. Audit, Disabled 1.0.1

4.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification, classification, and loss prevention features are not yet available for Azure Database for MySQL. Implement third-party solution if required for compliance purposes.

For the underlying platform which is managed by Microsoft, Microsoft treats all customer content as sensitive and goes to great lengths to guard against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented and maintains a suite of robust data protection controls and capabilities.

Responsibility: Shared

Azure Security Center monitoring: None

4.6: Use Azure RBAC to control access to resources

Guidance: Use Azure role-based access control (Azure RBAC) to control access to the Azure Database for MySQL control plane (e.g. Azure portal). For data plane access (within the database itself), use SQL queries to create users and configure user permissions. Azure RBAC does not affect user permissions within the database.

Responsibility: Customer

Azure Security Center monitoring: None

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity Log to create alerts for when changes take place to production instances of Azure Database for MySQL and other critical or related resources.

Responsibility: Customer

Azure Security Center monitoring: None

Vulnerability Management

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

5.1: Run automated vulnerability scanning tools

Guidance: Follow recommendations from Azure Security Center on securing your Azure Database for MySQL and related resources.

Microsoft performs vulnerability management on the underlying systems that support Azure Database for MySQL.

Responsibility: Shared

Azure Security Center monitoring: None

Inventory and Asset Management

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

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query and discover all resources (including Azure Database for MySQL instances) within your subscriptions. Ensure you have appropriate (read) permissions in your tenant and are able to enumerate all Azure subscriptions as well as resources within your subscriptions.

Responsibility: Customer

Azure Security Center monitoring: None

6.2: Maintain asset metadata

Guidance: Apply tags to Azure Database for MySQL instances and other related resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

Azure Security Center monitoring: None

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Azure Database for MySQL instances and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

Responsibility: Customer

Azure Security Center monitoring: None

6.4: Define and maintain inventory of approved Azure resources

Guidance: Not applicable; this recommendation is intended for compute resources and Azure as a whole.

Responsibility: Customer

Azure Security Center monitoring: None

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

In addition, use the Azure Resource Graph to query for and discover resources within the subscriptions.

Responsibility: Customer

Azure Security Center monitoring: None

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

For more information, see the following references:

Responsibility: Customer

Azure Security Center monitoring: None

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Use the Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App. This can prevent the creation and changes to resources within a high security environment, such as instances of Azure Database for MySQL containing sensitive information.

Responsibility: Customer

Azure Security Center monitoring: None

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Define and implement standard security configurations for your Azure Database for MySQL instances with Azure Policy. Use Azure Policy aliases in the Microsoft.DBforMySQL namespace to create custom policies to audit or enforce the network configuration of your Azure Database for MySQL instances. You can also make use of built-in policy definitions related to your Azure Database for MySQL instances, such as:

Enforce SSL connection should be enabled for MySQL database servers

Responsibility: Customer

Azure Security Center monitoring: None

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure Policy [deny] and [deploy if not exist] to enforce secure settings across your Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.5: Securely store configuration of Azure resources

Guidance: If using custom Azure Policy definitions for your Azure Database for MySQL instances and related resources, use Azure Repos to securely store and manage your code.

Responsibility: Customer

Azure Security Center monitoring: None

7.7: Deploy configuration management tools for Azure resources

Guidance: Use Azure Policy aliases in the "Microsoft.DBforMySQL" namespace to create custom policies to alert, audit, and enforce system configurations. Additionally, develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

Azure Security Center monitoring: None

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Use Azure Policy aliases in the Microsoft.DBforMySQL namespace to create custom policies to alert, audit, and enforce system configurations. Use Azure Policy [audit], [deny], and [deploy if not exist] to automatically enforce configurations for your Azure Database for MySQL instances and related resources.

Responsibility: Customer

Azure Security Center monitoring: None

7.11: Manage Azure secrets securely

Guidance: For Azure Virtual Machines or web applications running on Azure App Service being used to access your Azure Database for MySQL instances, use Managed Service Identity in conjunction with Azure Key Vault to simplify and secure Azure Database for MySQL secret management. Ensure Key Vault Soft Delete is enabled.

Responsibility: Customer

Azure Security Center monitoring: None

7.12: Manage identities securely and automatically

Guidance: Azure Database for MySQL instance supports Azure Active Directory (Azure AD) authentication to access databases. While creating the Azure Database for MySQL instance, you provide credentials for an administrator user. This administrator can be used to create additional database users.

For Azure Virtual Machines or web applications running on Azure App Service being used to access your Azure Database for MySQL instances, use Managed Service Identity in conjunction with Azure Key Vault to store and retrieve credentials for Azure Database for MySQL instance. Ensure Key Vault Soft Delete is enabled.

Use Managed Identities to provide Azure services with an automatically managed identity in Azure AD. Managed Identities allows you to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code.

Responsibility: Customer

Azure Security Center monitoring: None

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Responsibility: Customer

Azure Security Center monitoring: None

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Microsoft anti-malware is enabled on the underlying host that supports Azure services (for example, Azure Database for MySQL), however it does not run on customer content.

Pre-scan any content being uploaded to non-compute Azure resources, such as App Service, Data Lake Storage, Blob Storage, Azure Database for MySQL, etc. Microsoft cannot access your data in these instances.

Responsibility: Shared

Azure Security Center monitoring: None

Data Recovery

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

9.1: Ensure regular automated back-ups

Guidance: Azure Database for MySQL takes backups of the data files and the transaction log. Depending on the supported maximum storage size, we either take full and differential backups (4 TB max storage servers) or snapshot backups (up to 16-TB max storage servers). These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can optionally configure it up to 35 days. All backups are encrypted using AES 256-bit encryption.

Responsibility: Shared

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforMySQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Geo-redundant backup should be enabled for Azure Database for MySQL Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create. Audit, Disabled 1.0.1

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: Azure Database for MySQL automatically creates server backups and stores them in either locally-redundant or geo-redundant storage, according to the user's choice. Backups can be used to restore your server to a point-in-time. Backup and restore are an essential part of any business continuity strategy because they protect your data from accidental corruption or deletion.

If using Azure Key Vault to store credentials for your Azure Database for MySQL instances, ensure regular automated backups of your keys.

Responsibility: Shared

Azure Security Center monitoring: The Azure Security Benchmark is the default policy initiative for Security Center and is the foundation for Security Center's recommendations. The Azure Policy definitions related to this control are enabled automatically by Security Center. Alerts related to this control may require an Azure Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.DBforMySQL:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Geo-redundant backup should be enabled for Azure Database for MySQL Azure Database for MySQL allows you to choose the redundancy option for your database server. It can be set to a geo-redundant backup storage in which the data is not only stored within the region in which your server is hosted, but is also replicated to a paired region to provide recovery option in case of a region failure. Configuring geo-redundant storage for backup is only allowed during server create. Audit, Disabled 1.0.1

9.3: Validate all backups including customer-managed keys

Guidance: In Azure Database for MySQL, performing a restore creates a new server from the original server's backups. There are two types of restore available: Point-in-time restore and Geo-restore. Point-in-time restore is available with either backup redundancy option and creates a new server in the same region as your original server. Geo-restore is available only if you configured your server for geo-redundant storage and it allows you to restore your server to a different region.

The estimated time of recovery depends on several factors including the database sizes, the transaction log size, the network bandwidth, and the total number of databases recovering in the same region at the same time. The recovery time is usually less than 12 hours.

Periodically test restoration of your Azure Database for MySQL instances.

Responsibility: Customer

Azure Security Center monitoring: None

9.4: Ensure protection of backups and customer-managed keys

Guidance: Azure Database for MySQL takes full, differential, and transaction log backups. These backups allow you to restore a server to any point-in-time within your configured backup retention period. The default backup retention period is seven days. You can optionally configure it up to 35 days. All backups are encrypted using AES 256-bit encryption. Ensure Key Vault Soft Delete is enabled.

Responsibility: Customer

Azure Security Center monitoring: None

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

Azure Security Center monitoring: None

10.2: Create an incident scoring and prioritization procedure

Guidance: Security Center assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Security Center is in the finding or the analytics used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, clearly mark subscriptions (for ex. production, non-prod) and create a naming system to clearly identify and categorize Azure resources.

Responsibility: Customer

Azure Security Center monitoring: None

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems' incident response capabilities on a regular cadence. Identify weak points and gaps and revise plan as needed.

Responsibility: Customer

Azure Security Center monitoring: None

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that the customer's data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Responsibility: Customer

Azure Security Center monitoring: None

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Azure Security Center alerts and recommendations using the Continuous Export feature. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You may use the Azure Security Center data connector to stream the alerts to Azure Sentinel.

Responsibility: Customer

Azure Security Center monitoring: None

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Azure Security Center to automatically trigger responses via "Logic Apps" on security alerts and recommendations.

Responsibility: Customer

Azure Security Center monitoring: None

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: 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: Shared

Azure Security Center monitoring: None

Next steps