将本地 MySQL 迁移到 Azure Database for MySQL：安全性
适用于：
Azure Database for MySQL - 单一服务器 Azure Database for MySQL - 灵活服务器
先决条件
概述
迁移到基于云的服务并不意味着整个 Internet 都可以随时访问它。 Azure 提供一流的安全性，可确保持续保护数据工作负载免受不良执行组件和恶意程序的侵害。
身份验证
Azure Database for MySQL 支持 MySQL 用户连接的基本身份验证机制，但也支持与 Microsoft Entra ID 的集成。 这种安全集成通过在 MySQL 登录过程中发出类似于密码的令牌来工作。 配置 Active Directory 集成非常简单，不仅支持用户，还支持 Microsoft Entra 组。
注意
MySQL 5.7 及更高版本支持此安全功能。 只要提供了 clear-text 选项，就支持大多数应用程序驱动程序。
审核日志
MySQL 具有强大的内置审核日志功能。 默认情况下，Azure Database for MySQL 中的此审核日志功能处于禁用状态。 可以通过更改 audit\_log\_enabled 服务器参数来启用服务器级日志记录。 启用后，可以开启诊断日志记录，通过 Azure Monitor 和 Log Analytics 访问日志。
要查询用户连接相关事件，请运行以下 KQL 查询：
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
MySQL 实例中的数据默认为静态加密。 任何自动备份也经过加密，以防止数据可能泄露给未经授权的各方。 此加密通常使用创建实例时创建的密钥执行。 除了此默认加密密钥之外，管理员还可以选择自带密钥 (BYOK)。
使用客户管理的密钥策略时，了解与密钥生命周期管理相关的职责至关重要。 客户密钥存储在 Azure Key Vault 中，然后通过策略访问。 遵循密钥管理的所有建议至关重要，丢失加密密钥等同于丢失数据访问权限。
数据可以在传输过程中使用 SSL/TLS 进行加密。 如前所述，可能需要修改你的应用程序来支持此更改和配置适当的 TLS 验证设置。
防火墙
设置好用户并加密静态数据后，迁移团队应审查网络数据流。 Azure Database for MySQL 提供了多种机制，通过仅向授权的用户、应用程序和设备提供访问权限来保护网络层。
保护 MySQL 实例的第一道防线是实施防火墙规则。 通过内部或外部 IP 访问实例时，IP 地址可以限制为仅有效位置。 如果 MySQL 实例旨在仅服务于内部应用程序，则限制公共访问。
将应用程序与 MySQL 工作负载一起移至 Azure 时，很可能会设置采用中心辐射模式的多个虚拟网络，且需要配置虚拟网络对等互连。
专用链接
要将 Azure Database for MySQL 的访问权限限制为仅向内部 Azure 资源提供，请启用专用链接。 专用链接确保 MySQL 实例被分配一个私有 IP 而不是公共 IP 地址。
注意
还有许多其他的 Azure 网络基本注意事项需要考虑，但这不是本指南的重点。
查看一组可跨所有 Azure 资源实施的潜在安全基线任务。 并非参考链接中描述的所有项目都适用于特定数据工作负载或 Azure 资源。
安全清单
尽可能使用 Microsoft Entra 身份验证。
启用高级威胁防护。
启用所有审核功能。
请考虑自带密钥 (BYOK) 策略。
实现防火墙规则。
利用专用终结点实现不通过 Internet 传输的工作负载。