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

Область применения: База данных SQL Azure Azure Synapse Analytics

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

Примечание.

Эта статья относится как к Базе данных SQL, так и к Azure Synapse Analytics. Для простоты термин база данных применяется к обеим из них. Аналогичным образом, все ссылки на сервер ссылаются на логический сервер, на котором размещаются База данных SQL и Azure Synapse Analytics.

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

Примечание.

Идентификатор Microsoft Entra ранее был известен как Azure Active Directory (Azure AD).

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

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

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

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

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

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

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

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

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

Для сравнения, правило фильтрации IP-адресов можно применить на любом уровне.

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

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

• Администратор сети (роль Участник сети). Включение конечной точки.
• Администратор базы данных (роль Участник SQL Server). Обновление списка управления доступом (ACL) для добавления данной подсети на сервер.

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

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

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

Примечание.

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

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

Ограничения

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

• В брандмауэре для базы данных в Базе данных Azure каждое правило виртуальной сети ссылается на подсеть. Все такие упомянутые подсети должны размещаться в том же географическом регионе, где размещена база данных.
• Каждый сервер может использовать до 128 записей ACL для любой виртуальной сети.
• Правила виртуальной сети применяются только к виртуальным сетям Azure Resource Manager, но не к сетям на основе классической модели развертывания.
• При включении конечных точек службы виртуальной сети для Базы данных SQL также включаются конечные точки для Базы данных Azure для MySQL и Базы данных Azure для PostgreSQL. Если конечные точки включены, подключиться через них к экземплярам Базы данных Azure для MySQL или Базы данных Azure для PostgreSQL не удастся.
  • Основной причиной является то, что для Базы данных Azure для MySQL и Базы данных Azure для PostgreSQL, скорее всего, не настроено правило виртуальной сети. Настройте правило виртуальной сети для Базы данных Azure для MySQL и Базы данных Azure для PostgreSQL.
  • Чтобы определить правила брандмауэра виртуальной сети на логическом сервере SQL, для которого уже настроены частные конечные точки, установите для параметра Deny public network access (Запретить доступ к общедоступной сети) значение Нет.
• В брандмауэре диапазоны IP-адресов применяются к следующим сетевым элементам, но правила виртуальной сети не выполняют следующие действия.
  • виртуальная частная сеть (VPN) типа "сеть — сеть";
  • локальная среда с подключением Azure ExpressRoute.

Рекомендации по использованию конечных точек служб

При использовании конечных точек служб Базы данных SQL обратите внимание на указанные ниже моменты.

• Требуется исходящее подключение к общедоступным IP-адресам Базы данных SQL Azure. Чтобы предоставить возможность подключения, группы безопасности сети (NSG) необходимо открыть для IP-адресов Базы данных SQL. Это можно сделать с помощью тегов службы NSG для Базы данных SQL.

ExpressRoute

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

Чтобы разрешить взаимодействие канала с Базой данных SQL, необходимо создать правила IP-сети для общедоступных IP-адресов NAT.

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

Служба хранилища Azure реализовала ту же функцию, которая позволяет ограничить возможность подключения к учетной записи службы хранилища Azure. Если вы решили применить эту возможность к учетной записи службы хранилища Azure, используемой Базой данных SQL, могут возникнуть проблемы. Ниже приведен список и описание функций Базы данных SQL и Azure Synapse Analytics, на которых это отразится.

PolyBase и инструкция COPY в Azure Synapse Analytics

PolyBase и инструкцию COPY часто используют для загрузки данных в Azure Synapse Analytics из учетных записей службы хранилища Azure для приема данных с высокой пропускной способностью. Если учетная запись службы хранилища Azure, из которой загружаются данные, предоставляет доступ только к набору подсетей виртуальной сети, подключение из PolyBase и инструкции COPY к учетной записи хранения будет прервано. Чтобы обеспечить возможность импорта и экспорта с помощью PolyBase и инструкции COPY в хранилище Azure Synapse Analytics, подключенное к службе хранилища Azure, которая прикреплена к виртуальной сети, выполните действия, описанные в этом разделе.

Необходимые компоненты

• Установите Azure PowerShell. Дополнительные сведения см. в статье Установка модуля Azure Az PowerShell.
• При наличии учетной записи хранения общего назначения версии 1 или учетной записи хранилища BLOB-объектов Azure сначала необходимо выполнить обновление до учетной записи хранения версии 2, выполнив инструкции из этого руководства.
• Необходимо включить параметр Разрешить доверенным службам Майкрософт доступ к этой учетной записи хранения в меню параметров Брандмауэры и виртуальные сети учетной записи службы хранилища Azure. Включение этой конфигурации позволит использовать PolyBase и инструкцию COPY для подключения к учетной записи хранения с помощью строгой проверки подлинности, при которой сетевой трафик остается в магистральной сети Azure. Дополнительную информацию см. в этом руководстве.

Внимание

Модуль PowerShell Azure Resource Manager по-прежнему поддерживается База данных SQL Azure, но все будущие разработки Az.Sql для модуля. Исправления ошибок для модуля AzureRM будут продолжать выпускаться как минимум до декабря 2020 г. Аргументы команд в модулях Az и AzureRm практически идентичны. Дополнительные сведения о совместимости см. в статье Знакомство с новым модулем Az для Azure PowerShell.

Шаги

1. Если у вас есть автономный выделенный пул SQL (ранее — хранилище данных SQL), зарегистрируйте сервер SQL с помощью Идентификатора Microsoft Entra с помощью PowerShell:

   Connect-AzAccount
   Select-AzSubscription -SubscriptionId <subscriptionId>
   Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
   

   Этот шаг не требуется для выделенных пулов SQL в рабочей области Azure Synapse Analytics. Назначаемое системой управляемое удостоверение (SA-MI) для рабочей области является членом роли администратора Synapse и поэтому получает более высокий уровень привилегий для выделенных пулов SQL рабочей области.

2. Создайте учетную запись хранения общего назначения версии 2, следуя указаниям из этой статьи.

   • При наличии учетной записи хранения общего назначения версии 1 или учетной записи хранилища BLOB-объектов сначала необходимо выполнить обновление до версии 2, выполнив инструкции из этого руководства.
   • Сведения об известных проблемах с Azure Data Lake Storage 2-го поколения см. в этой статье.

3. На странице своей учетной записи хранения выберите Управление доступом (IAM).

4. Выберите Добавить>Добавить назначение ролей, чтобы открыть страницу Добавление назначения ролей.

5. Назначьте следующую роль. Подробные инструкции см. в статье Назначение ролей Azure с помощью портала Microsoft Azure.

   Параметр	Значение
   Роль	Участник данных хранилища BLOB-объектов
   Назначить доступ для	Пользователь, группа или субъект-служба
   Участники	Сервер или рабочая область размещения выделенного пула SQL, зарегистрированного в идентификаторе Microsoft Entra

   

   Примечание.

   Этот шаг могут выполнять только участники с правами владельца для учетной записи хранения. Сведения о различных встроенных ролях Azure см. в этой статье.

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

   1. Создайте главный ключ базы данных, если он еще не создан.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];
      

   2. Создайте учетные данные базы данных, указав IDENTITY = 'Managed Service Identity':

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      • Не нужно указывать СЕКРЕТ с использованием ключа доступа к хранилищу Azure, так как на самом деле этот механизм использует управляемое удостоверение. Этот шаг не требуется для выделенных пулов SQL в рабочей области Azure Synapse Analytics. Назначаемое системой управляемое удостоверение (SA-MI) для рабочей области является членом роли администратора Synapse и поэтому получает более высокий уровень привилегий для выделенных пулов SQL рабочей области.

      • Имя IDENTITY должно быть Managed Service Identity, чтобы подключения PolyBase работали с учетной записью службы хранилища Azure, прикрепленной к виртуальной сети.

   3. Создайте внешний источник данных с использованием схемы abfss:// для подключения к учетной записи хранения общего назначения версии 2 с помощью PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      • При наличии внешних таблиц, связанных с учетной записью общего назначения версии 1 или учетной записью хранилища BLOB-объектов, сначала удалите эти внешние таблицы. Затем удалите соответствующий внешний источник данных. Затем создайте внешний источник данных с использованием схемы abfss:// для подключения к учетной записи хранения общего назначения версии 2, как показано выше. Повторно создайте все внешние таблицы с помощью этого нового внешнего источника данных. Для удобства вы можете создать сценарии для всех внешних таблиц с помощью мастера создания и публикации сценариев.
      • Дополнительные сведения о схеме abfss:// см. в статье Использование универсального кода ресурса в Azure Data Lake Storage 2-го поколения.
      • Дополнительные сведения см. в статье о CREATE EXTERNAL DATA SOURCE (Transact-SQL).

   4. Выполните запрос как обычно, используя внешние таблицы.

Аудит BLOB-объектов в Базе данных SQL

Аудит SQL Azure позволяет записывать журналы аудита SQL в собственную учетную запись хранения. Если эта учетная запись хранения использует функцию конечных точек службы виртуальной сети, ознакомьтесь с дополнительными сведениями о том, как записать результаты аудита в учетную запись хранения за брандмауэром и виртуальной сетью.

Добавление правила брандмауэра виртуальной сети к серверу

Пока возможности этой функции не были расширены, вам нужно было включить конечные точки службы для виртуальной сети, чтобы реализовать динамическое правило виртуальной сети в брандмауэре. Конечные точки связывают данную подсеть виртуальной сети с базой данных в Базе данных SQL. По состоянию на январь 2018 г. это требование можно обойти, задав параметр IgnoreMissingVNetServiceEndpoint. Теперь вы можете добавить правило брандмауэра виртуальной сети к серверу без включения конечных точек службы для виртуальной сети.

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

Задать параметр IgnoreMissingVNetServiceEndpoint можно с помощью PowerShell. Дополнительные сведения см. в статье Создание конечной точки и правила службы виртуальной сети для Базы данных SQL с помощью PowerShell.

Примечание.

Аналогичные инструкции для Azure Synapse Analytics см. в статье Правила брандмауэра для IP-адресов Azure Synapse Analytics.

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

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

Примечание.

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

Если конечные точки службы не включены для подсети, портал предложит их включить. Нажмите кнопку Включить в той же области, в которой вы добавляете правило.

Необходимые компоненты

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

• В нашем случае именем типа конечной точки является Microsoft.Sql.
• Если ваша подсеть не помечена именем типа, см. раздел Проверка того, является ли подсеть конечной точкой.

Инструкции для портала Azure

1. Войдите на портал Azure.

2. Найдите и выберите Серверы SQL, а затем — свой сервер. В разделе "Безопасность" выберите "Сеть".

3. На вкладке "Общедоступный доступ" убедитесь, что для общедоступного доступа задано значение Select networks, в противном случае параметры виртуальных сетей скрыты. Выберите + Добавить существующую виртуальную сеть в разделе Виртуальные сети.

   

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

   Совет

   Необходимо указать правильный префикс адреса для подсети. Значение префикса адреса можно найти на портале. Выберите Все ресурсы>Все типы>Виртуальные сети. Фильтр отобразит ваши виртуальные сети. Выберите виртуальную сеть, а затем — Подсети. Столбец Диапазон адресов содержит интересующий вас префикс адреса.

   

5. Созданное правило виртуальной сети отобразится в области Брандмауэр.

   

6. Для параметра Разрешить доступ к серверу службам и ресурсам Azure установите значение Нет.

   Внимание

   Если вы оставьте службу и ресурсы Azure для доступа к этому серверу , сервер принимает связь из любой подсети в границе Azure. Это подключение, которое исходит из одного из IP-адресов, распознаваемых в пределах диапазонов, определенных для центров обработки данных Azure. Выход из элемента управления может быть чрезмерным доступом с точки зрения безопасности. Используя конечные точки службы для виртуальной сети Microsoft Azure с правилами виртуальной сети Базы данных SQL, можно уменьшить контактную зону системы безопасности.

7. Нажмите кнопку OK в нижней части области.

Примечание.

К правилам применяются следующие статусы или состояния:

• Готово. Указывает, что операция, которую вы инициировали, завершена успешно.
• Сбой. Указывает, что операция, которую вы инициировали, завершена сбоем.
• Удалено: применяется только к Delete операции и указывает, что правило удалено и больше не применяется.
• Выполняется. Указывает, что операция выполняется. Старое правило применяется, когда операция находится в этом состоянии.

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

Создать правило виртуальной сети можно также с помощью скрипта PowerShell. Для этого используйте командлет PowerShell New-AzSqlServerVirtualNetworkRule или az network vnet create. Дополнительные сведения см. в статье Создание конечной точки и правила службы виртуальной сети для Базы данных SQL с помощью PowerShell.

Создание правила виртуальной сети с помощью REST API

На внутреннем уровне командлеты PowerShell для действий виртуальной сети SQL вызывают REST API. REST API можно вызывать напрямую. Дополнительные сведения см. в статье Правила виртуальной сети: операции.

Устранение неполадок при ошибках 40914 и 40615

Ошибка подключения 40914 относится к правилам виртуальной сети, указанным в области Брандмауэр на портале Azure.
Ошибка 40615 отличается от предыдущей тем, что относится к правилам IP-адресов в брандмауэре.

Ошибка 40914

Текст сообщения. "Невозможно открыть сервер [имя-сервера], запрашиваемый именем входа. Клиенту запрещен доступ к серверу".

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

Устранение ошибки. В области Брандмауэр портала Azure с помощью элемента управления правилами виртуальных сетей добавьте правило виртуальной сети для этой подсети.

Ошибка 40615

Текст сообщения. "Не удается открыть сервер {0}, запрашиваемый при попытке входа. Для клиента с IP-адресом {1} доступ к серверу запрещен".

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

Устранение ошибки. Введите IP-адрес клиента в качестве правила IP-адреса. Это следует сделать в области Брандмауэр на портале Azure.

Связанные статьи

• Конечные точки служб для виртуальной сети Azure
• Правила брандмауэра уровня сервера и уровня базы данных

Следующие шаги

• Создание конечной точки службы и правила виртуальной сети для Базы данных SQL с помощью PowerShell
• Правила виртуальной сети: операции с REST API