Описание функций безопасности
База данных Azure для MySQL . Гибкий сервер предоставляет несколько функций, предназначенных для защиты и защиты данных и операций. Рассмотрим каждую из этих функций.
Сеть
База данных Azure для MySQL — гибкий сервер предоставляет надежные параметры брандмауэра для защиты подключения к базе данных для общедоступного доступа, а также виртуальная сеть Azure (виртуальные сети). Существует три параметра подключения к гибкому серверу MySQL: общедоступный доступ, частный доступ и приватный канал. Во всех случаях подключения по-прежнему должны проходить проверку подлинности с помощью сервера.
Общедоступный доступ предоставляет общедоступный разрешенный DNS-адрес, доступный через Интернет, в списке разрешенных диапазонов IP-адресов. По умолчанию IP-адреса запрещены. Вы можете добавить IP-адреса во время или после создания. Вы также можете разрешить доступ с любого IP-адреса Azure (включая другие подписки клиентов в других регионах).
Частный доступ использует делегированную подсеть для размещения гибких серверов MySQL и предоставляет DNS-адрес, разрешаемый из своей виртуальной сети или одноранговой виртуальной сети. Это блокирует доступ к базе данных только вашей виртуальной сетевой инфраструктуре. Правила брандмауэра группы безопасности сети (NSG) можно настроить для более точного фильтрации сетевого трафика. Вы можете использовать частный доступ для безопасного подключения к гибкому серверу MySQL из одной виртуальной сети, из другой виртуальной сети с помощью пиринга или даже из локальной среды с помощью ExpressRoute или VPN-подключения.
Приватный канал предоставляет частную конечную точку IP-адреса в подсети виртуальной сети для подключения к гибкому серверу MySQL напрямую. Приватный канал Azure по сути приносит службы Azure в частную виртуальную сеть через IP-адрес, как и любой другой ресурс виртуальной сети. Можно создать несколько частных конечных точек, например один из них для каждого подключающегося приложения или ресурса Azure PaaS. В сочетании с правилами брандмауэра NSG частные каналы обеспечивают точное управление доступом к базе данных службами.
Microsoft Defender для облака
Microsoft Defender для облака отслеживает базу данных для необычных и потенциально опасных действий. Defender для облака предоставляется в качестве плана надстройки для решения потенциальных угроз без необходимости создавать или управлять мониторингом безопасности. Defender для облака имеет многооблачную доступность на База данных Azure для MySQL — гибкий сервер, а также MySQL в AWS Aurora и RDS. Defender для облака также поддерживает PostgreSQL и MariaDB.
Defender для облака обнаруживает такие угрозы базы данных, как:
- Атаки на метод подбора: ненормально высокий уровень входа и успешный вход после многих сбоев.
- Необычные шаблоны входа: если пользователь впервые входит в систему в течение двух месяцев.
- Необычные расположения входа: если пользователь входит из необычной базы данных Azure или другого поставщика облачных служб или IP-адрес, помеченный как подозрительный.
Defender для облака отправляет оповещения об обнаружении в портал Azure и по электронной почте. К оповещениям относятся:
- Сведения о подозрительном действии.
- Связанный MITRE ATT&CK (состязательная тактика, методы и общие знания).
- Предложения по изучению и устранению атаки.
- Дополнительные возможности для изучения с помощью Microsoft Sentinel.
Проверка подлинности
База данных Azure для MySQL предлагает два режима проверки подлинности: проверка подлинности MySQL (имя пользователя и пароль) и проверка подлинности Идентификатора Microsoft Entra. Вы можете включить оба одновременно.
Проверка подлинности идентификатора Microsoft Entra обеспечивает проверку подлинности на основе удостоверений на гибком сервере MySQL с помощью удостоверений, предоставляемых идентификатором Microsoft Entra. Это централизованное управление пользователями для базы данных и других службы Майкрософт.
По умолчанию гибкий сервер MySQL использует только проверку подлинности MySQL (имя пользователя и пароль). Этот параметр можно изменить, чтобы использовать проверку подлинности идентификатора Microsoft Entra только (без пользователей базы данных) или объединить управляемые удостоверения с проверкой подлинности MySQL.
При использовании проверки подлинности идентификатора Microsoft Entra есть две учетные записи администратора: исходный администратор MySQL и администратор Идентификатора Microsoft Entra. Администратор идентификатора Microsoft Entra может быть пользователем или группой пользователей. Если администратор является группой, любой член группы может управлять проверкой подлинности идентификатора Microsoft Entra. Группы администраторов проще управлять, так как она централизованно управляет пользователями в идентификаторе Microsoft Entra, а не требуется напрямую обновлять пользователей или разрешения MySQL. Можно настроить только одного администратора идентификатора Microsoft Entra, будь то один пользователь или одна группа пользователей.
На следующей схеме показаны два режима управления проверкой подлинности.
Когда пользователи или приложения пытаются подключиться к гибкому серверу MySQL с помощью удостоверения Microsoft Entra, маркер выдается, чтобы разрешить вход. Удостоверение связано с пользователем базы данных с помощью уникального идентификатора пользователя Microsoft Entra, а не их имени или других атрибутов.
Шифрование данных
Гибкие серверы MySQL шифруют данные во время передачи. По умолчанию серверы требуют подключения к протоколу TLS 1.2 и запрету незашифрованных подключений или подключений с использованием устаревших протоколов TLS 1.0 и 1.1. Вы можете отключить зашифрованные подключения (возможно, устаревшее приложение не поддерживает шифрование), либо разрешить версии до версии 1.2 или использовать TLS 1.3, что является рекомендуемой настройкой для разработки новых приложений.
По умолчанию База данных Azure для MySQL — гибкий сервер шифрует неактивных данных (включая резервные копии и временные файлы, созданные при выполнении запросов) с помощью симметричного ключа шифрования данных AES 256-разрядной версии (DEK). С помощью ключей, управляемых клиентом (CMK), вы можете принести собственный ключ (BYOK), чтобы добавить еще один уровень шифрования, зашифровав DEK службы.
BYOK обеспечивает полный контроль над шифрованием данных и жизненным циклом ключей: создание, передача, смена и удаление. Управление жизненным циклом ключей позволяет выравнивать смену ключей с политиками компании и обеспечивает разделение обязанностей группы безопасности, DBA и системного администратора.
Включение CMK требует связывания базы данных с управляемым удостоверением, назначенным пользователем (UMI), а затем указание ключа, который хранится в Azure Key Vault, для использования. При создании копии сервера копия будет зашифрована, а также можно добавить управляемые удостоверения и ключи в существующие реплики.