Использование конечных точек служб и правил виртуальной сети с базой данных Azure для MySQL

Область применения: База данных Azure для MySQL — отдельный сервер

Правила виртуальной сети — это одна из функций безопасности брандмауэра, обеспечивающая управление приемом сервером базы данных Azure для MySQL подключений из определенных подсетей в виртуальных сетях. В этой статье объясняется, почему правила виртуальной сети иногда являются лучшим вариантом для защиты подключений к серверу базы данных Azure для MySQL.

Чтобы создать правило виртуальной сети, требуется виртуальная сеть и конечная точка службы для виртуальной сети, используемая для ссылки. На следующем рисунке показано, как конечная точка службы для виртуальной сети работает с базой данных Azure для MySQL.

Пример того, как работает конечная точка службы виртуальной сети

Примечание

Эта функция доступна во всех областях Azure, где База данных Azure для MySQL развернута для серверов общего назначения и оптимизирована для операций в памяти. В случае пиринга между виртуальными сетями, если трафик проходит через общий шлюз виртуальной сети с конечными точками и должен попадать в кэширующий узел, создайте правило ACL или виртуальной сети, чтобы разрешить Виртуальным машинам Azure в шлюзе виртуальной сети доступ к Базе данных Azure для сервера MySQL.

Для подключений также можно использовать Приватный канал. Приватный канал предоставляет частный IP-адрес в виртуальной сети для сервера Базы данных Azure для MySQL.

Терминология и описание

Виртуальная сеть. С подпиской Azure могут быть связаны виртуальные сети.

Подсеть. Виртуальная сеть содержит подсети. Все ваши виртуальные машины Azure назначены в подсети. Одна подсеть может содержать несколько виртуальных машин или других вычислительных узлов. Вычислительные узлы, которые находятся вне вашей виртуальной сети, не имеют доступа к ней, если только не настроить систему безопасности таким образом, чтобы предоставить им доступ.

Конечная точка службы для виртуальной сети. Конечная точка службы для виртуальной сети — это подсеть, значения свойств которой включают в себя одно формальное имя типа службы Azure или несколько. В этой статье мы рассмотрим тип Microsoft.Sql, который относится к службе Azure, которая называется Базой данных SQL. Этот тег службы также применяется к службам "База данных Azure для MySQL" и "База данных Azure для PostgreSQL". Важно отметить, что при применении тега службы Microsoft.Sql к конечной точке службы виртуальной сети она настроит трафик конечной точки службы для всех серверов Базы данных SQL Azure, Базы данных Azure для MySQL и Базы данных Azure для PostgreSQL в подсети.

Правило виртуальной сети. Правило виртуальной сети для сервера базы данных Azure для MySQL — это подсеть, которая указана в списке управления доступом (ACL) сервера базы данных Azure для MySQL. Для включения в ACL для сервера базы данных Azure для MySQL подсеть должна содержать имя типа Microsoft.Sql.

Правило виртуальной сети предписывает серверу базы данных Azure для MySQL принимать подключения от всех узлов, находящихся в подсети.

Преимущества правила виртуальной сети

Пока вы не выполните соответствующие действия, виртуальные машины в подсети не могут взаимодействовать с сервером базы данных Azure для MySQL. Создание правила виртуальной сети — это единственное действие, которое устанавливает подключение. Чтобы обосновать выбор подхода на основе правил виртуальной сети, требуется сравнить преимущества и недостатки этого подхода с конкурирующими функциями безопасности, предоставляемыми брандмауэром.

A. Разрешение доступа службам Azure

На панели безопасности подключения есть кнопка Вкл./Выкл. с надписью Разрешить доступ к службам Azure. Значение ON (Вкл.) разрешает подключение со всех IP-адресов Azure и из всех подсетей Azure. Эти Azure IP-адреса и подсети могут принадлежать не вам. Возможно, значение Вкл. делает вашу систему более открытой, чем требуется для базы данных Azure для MySQL. Правила виртуальной сети обеспечивают более детализированный контроль.

Б. Правила фильтрации IP-адресов

Брандмауэр базы данных Azure для MySQL позволяет указать диапазоны IP-адресов, подключения с которых принимаются базой данных Azure для MySQL. Эта методика хорошо подходит для постоянных IP-адресов, которые находятся за пределами частной сети Azure. Однако за пределами частной сети Azure используется множество динамических IP-адресов. Динамические IP-адреса могут изменяться, например при перезапуске виртуальной машины. Было бы неразумно указывать динамический IP-адрес в правиле брандмауэра в рабочей среде.

Можно сохранить выбранный IP-адрес, присвоив виртуальной машине статический IP-адрес. Дополнительные сведения см. в разделе Настройка частных IP-адресов для виртуальной машины с помощью портала Azure.

Однако применение статических IP-адресов может усложнить управление и создать дополнительные расходы при увеличении масштаба среды. Правила виртуальной сети проще устанавливать и контролировать.

Сведения о правилах виртуальной сети

В этом разделе приводятся некоторые сведения о правилах виртуальной сети.

Только один географический регион

Каждая конечная точка службы для виртуальной сети может использоваться только в одном регионе Azure. Конечная точка не поддерживает прием подключений из подсети в других регионах.

Любое правило виртуальной сети ограничена регионом, в котором используется базовая конечная точка.

На уровне сервера, а не базы данных

Каждое правило виртуальной сети применяется ко всему серверу базы данных Azure для MySQL, не только к одной конкретной базе данных на сервере. Другими словами, правило виртуальной сети применяется на уровне сервера,а не на уровне базы данных.

Роли администратора безопасности

Роли безопасности для администрирования конечных точек служб для виртуальной сети разделены. Требуется действие каждой из следующих ролей:

  • администратор сети:   включение конечной точки;
  • администратор базы данных:   обновление списка управления доступом (ACL) для добавления данной подсети на сервер базы данных Azure для MySQL.

Альтернатива Azure RBAC.

Роли администратора сети и администратора базы данных имеют больше возможностей, чем требуется для управления правилами виртуальной сети. На самом деле для этого требуется только часть их возможностей.

Вы сможете применить управление доступом на основе ролей (Azure RBAC) в Azure, чтобы создать одну настраиваемую роль с минимально необходимым набором возможностей. Именно настраиваемую роль следует использовать вместо администратора сети или администратора базы данных, так как она обеспечит минимальную контактную зону для рисков безопасности по сравнению с добавлением пользователя в две другие основные роли администратора.

Примечание

Иногда база данных Azure для MySQL и подсеть виртуальной сети относятся к разным подпискам. В этих случаях необходимо обеспечить следующую конфигурацию:

  • Обе подписки должны быть в одном клиенте Azure Active Directory.
  • Пользователь должен иметь необходимые разрешения для запуска операций, например для включения конечных точек службы или добавления подсети виртуальной сети к заданному серверу.
  • Убедитесь, что в обеих подписках зарегистрированы Microsoft.Sql и поставщик ресурсов Microsoft.DBforMySQL. Дополнительные сведения см. в разделе resource-manager-registration

Ограничения

Для базы данных Azure для MySQL правила виртуальной сети имеют следующие ограничения:

  • Веб-приложения можно сопоставить с частным IP-адресом в виртуальной сети или подсети. Даже если конечные точки службы включены в определенной виртуальной сети или подсети, при подключении из веб-приложения к серверу в качестве источника будет использоваться открытый IP-адрес Azure, виртуальная сеть или подсеть. Чтобы обеспечить подключение из веб-приложения к серверу, на котором установлены правила брандмауэра виртуальной сети, включите параметр Разрешить службам Azure доступ к серверу на сервере.

  • В брандмауэре для базы данных Azure для MySQL каждое правило виртуальной сети ссылается на подсеть. Все такие упомянутые подсети должны размещаться в том же географическом регионе, где размещена база данных Azure для MySQL.

  • Каждый сервер базы данных Azure для MySQL может использовать до 128 записей ACL для любой заданной виртуальной сети.

  • Правила виртуальной сети применяются только к виртуальным сетям Azure Resource Manager, но не к сетям на основе классической модели развертывания.

  • Включение конечных точек службы виртуальной сети для Базы данных Azure для MySQL с помощью тега службы Microsoft.Sql также включает конечные точки для всех служб баз данных Azure: Базы данных Azure для MySQL, Базы данных Azure для PostgreSQL, Базы данных SQL Azure и Azure Synapse Analytics.

  • Поддержка конечных точек службы виртуальной сети предназначена только для серверов общего назначения и серверов, оптимизированных для операций в памяти.

  • Если Microsoft.Sql включен для подсети, значит для подключения будут использоваться только правила виртуальной сети. Правила брандмауэра, не связанные с виртуальной сетью, в такой подсети работать не будут.

  • К приведенным ниже элементам сети применяются диапазоны IP-адресов в брандмауэре, а правила виртуальной сети — нет:

ExpressRoute

Если сеть подключена к сети Azure с использованием ExpressRoute, то для каждого канала настроены два общедоступных IP-адреса в Microsoft Edge. Эти два IP-адреса используются для подключения к службам Майкрософт, таким как служба хранилища Azure, с помощью общедоступного пиринга Azure.

Чтобы разрешить взаимодействие канала с базой данных Azure для MySQL, необходимо создать правила IP-сети для общедоступных IP-адресов каналов. Чтобы найти общедоступные IP-адреса канала ExpressRoute, отправьте запрос по ExpressRoute в службу поддержки через портал Azure.

Добавление правила брандмауэра виртуальной сети к серверу без включения конечных точек службы виртуальной сети

Само по себе правило брандмауэра не обеспечит безопасность сервера в виртуальной сети. Для безопасности нужно включить конечные точки службы виртуальной сети. При включении конечных точек службы подсеть виртуальной сети будет простаивать, пока не будет выполнен переход из состояния Выкл. в состояние Вкл. Это особенно верно в случае с большими виртуальными сетями. С помощью параметра IgnoreMissingServiceEndpoint можно уменьшить или исключить время простоя во время перехода.

Задать параметр IgnoreMissingServiceEndpoint можно с помощью Azure CLI или портала.

Дальнейшие действия

Статьи о создании правил виртуальной сети см. по следующим ссылкам: