Приватный канал Azure для базы данных SQL Azure и Azure Synapse Analytics
Применимо к:
База данных SQL Azure Azure Synapse Analytics (только выделенные пулы SQL)
Приватный канал позволяет подключаться к различным службам PaaS в Azure через частную конечную точку. Чтобы получить список служб PaaS, поддерживающих функции Приватного канала, перейдите на страницу документации по Приватному каналу. Частная конечная точка — это частный IP-адрес в определенной виртуальной сети и подсети.
Внимание
Эта статья применима к Базе данных Azure SQL и выделенному пулу SQL (ранее — SQL DW) в Azure Synapse Analytics. Эти параметры применяются ко всем базам данных Базы данных SQL Azure и выделенного пула SQL (ранее SQL DW), связанным с сервером. Для простоты термин "база данных" применяется к обеим из них. Аналогичным образом, сервером называется логический сервер, на котором размещены База данных SQL Azure и выделенный пул SQL (ранее — Хранилище данных SQL) в Azure Synapse Analytics. Эта статья не применима к Управляемому экземпляру SQL Azure или выделенным пулам SQL в рабочих областях Azure Synapse Analytics.
Настройка Приватного канала
Процесс создания
Частные конечные точки можно создавать с помощью портала Azure, PowerShell или Azure CLI:
Процесс утверждения
После того как администратор сети создаст частную конечную точку (PE), администратор SQL может управлять подключением частной конечной точки (PEC) к Базе данных SQL.
Перейдите к ресурсу сервера в портал Azure.
Перейдите на страницу утверждения частной конечной точки:
- В База данных SQL Azure в меню "Безопасность" выберите "Сеть". Выберите вкладку "Закрытый доступ ".
- В рабочей области Synapse в разделе "Безопасность " в меню ресурсов выберите подключения к частной конечной точке.
На странице показана следующая страница:
- Список всех Подключение частных конечных точек (PECs)
- Созданные частные конечные точки (PE)
Если частных конечных точек нет, создайте ее с помощью кнопки "Создать частную конечную точку ". В противном случае выберите отдельный PEC из списка, выбрав его.
Администратор SQL может утвердить или отклонить PEC и при необходимости добавить короткий текст ответа.
После утверждения или отклонения в списке отобразится соответствующее состояние вместе с текстом ответа.
Наконец, выберите имя частной конечной точки
При этом вы перейдете на страницу обзора частной конечной точки . Выберите ссылку "Сетевые интерфейсы", чтобы получить сведения о сетевом интерфейсе для подключения к частной конечной точке.
На странице сетевого интерфейса показан частный IP-адрес для подключения к частной конечной точке.
Внимание
При добавлении подключения к частной конечной точке общедоступная маршрутизация на логический сервер не блокируется по умолчанию. В области брандмауэра и виртуальных сетей параметр "Запретить доступ к общедоступной сети" не выбран по умолчанию. Чтобы отключить доступ к общедоступной сети, установите параметр Запретить доступ к общедоступной сети.
Отключение общедоступного доступа к логическому серверу
В База данных SQL Azure логический SQL Server предполагается, что вы хотите отключить весь общедоступный доступ к логическому серверу и разрешить подключения только из виртуальной сети.
Сначала убедитесь, что включены и настроены подключения к частной конечной точке. Затем, чтобы отключить общий доступ к логическому серверу, сделайте следующее:
Перейдите на страницу "Сеть " логического сервера.
Установите флажок Запретить доступ к общедоступной сети.
Проверка подключения к базе данных SQL из виртуальной машины Azure в той же виртуальной сети
В этом сценарии предположим, что вы создали виртуальную машину Azure с последней версией Windows в той же виртуальной сети, что и частная конечная точка.
Запустите сеанс удаленного рабочего стола и подключитесь к виртуальной машине.
Затем можно выполнить некоторые проверки подключения, чтобы убедиться, что виртуальная машина подключается к Базе данных SQL через частную конечную точку, используя следующие средства:
- Telnet
- PsPing
- Nmap
- SQL Server Management Studio (SSMS)
Проверка подключения с помощью Telnet
Клиент Telnet — это компонент Windows, который можно использовать для проверки подключения. В зависимости от версии ОС Windows может потребоваться явно включить эту функцию.
Откройте окно командной строки после установки Telnet. Выполните команду Telnet и укажите IP-адрес и частную конечную точку базы данных в База данных SQL.
telnet 10.9.0.4 1433
При успешном подключении Telnet выводит пустой экран в командном окне, как показано на следующем рисунке:
Используйте команду PowerShell для проверка подключения:
Test-NetConnection -computer myserver.database.windows.net -port 1433
Проверка Подключение чувствительность с помощью PsPing
PsPing можно использовать следующим образом, чтобы проверка, что частная конечная точка прослушивает подключения через порт 1433.
Запустите PsPing следующим образом, указав полное доменное имя для логического СЕРВЕРА SQL и порта 1433:
PsPing.exe mysqldbsrvr.database.windows.net:1433
Это пример ожидаемых выходных данных:
TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms
В выходных данных показано, что PsPing может связать частный IP-адрес, связанный с частной конечной точкой.
Проверка подключения с помощью Nmap
Nmap (модуль сопоставления сети) — это бесплатное средство с открытым кодом, используемое для обнаружения сетевых ресурсов и аудита безопасности. Дополнительные сведения и ссылку для скачивания можно получить по адресу https://Nmap.org. С помощью этого средства можно убедиться, что частная конечная точка ожидает передачи данных на порте 1433.
Запустите Nmap следующим образом, указав диапазон адресов подсети, на котором размещена частная конечная точка.
Nmap -n -sP 10.9.0.0/24
Это пример ожидаемых выходных данных:
Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds
В результате отображается, что работает один IP-адрес, который соответствует IP-адресу частной конечной точки.
Проверка подключения с помощью SQL Server Management Studio (SSMS)
Примечание.
Используйте полное доменное имя (FQDN) сервера в строках подключения для клиентов (<server>.database.windows.net). Любые попытки входа, выполненные непосредственно по IP-адресу или с помощью полного доменного имени частного канала (<server>.privatelink.database.windows.net), будут завершаться ошибкой. Такое поведение предусмотрено, так как частная конечная точка направляет трафик в шлюз SQL в регионе. При этом для успешного входа нужно указать правильное значение FQDN.
Выполните следующие действия, чтобы использовать SSMS для подключения к базе данных SQL. После подключения к База данных SQL с помощью SSMS следующий запрос должен отражать client_net_address, соответствующий частному IP-адресу виртуальной машины Azure, из которую вы подключаетесь:
SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Использование политики подключения перенаправления с частными конечными точками
Мы рекомендуем клиентам использовать приватный канал с политикой подключения перенаправления для уменьшения задержки и повышения пропускной способности. Чтобы подключения использовали этот режим, клиенты должны соответствовать следующим предварительным требованиям:
Разрешить входящий обмен данными с виртуальной сетью, на котором размещена частная конечная точка, к диапазону портов 1433 до 65535.
Разрешить исходящий обмен данными из виртуальной сети, на котором размещен клиент, к порту от 1433 до 65535.
Используйте последнюю версию драйверов с поддержкой перенаправления. Поддержка перенаправления включается в драйверы ODBC, OLEDB, NET SqlClient Data Provider, Core SqlClient Data Provider и JDBC (версия 9.4 или более поздней). Подключения, исходящие от всех остальных драйверов, проходят через прокси.
После выполнения предварительных требований клиенты должны эксплуативно выбрать политику подключения перенаправления.
Если невозможно изменить параметры брандмауэра, чтобы разрешить исходящий доступ в диапазоне портов 1433-65535, альтернативным решением является изменение политики подключения на proxy.
Существующие частные конечные точки, использующие политику подключения по умолчанию, должны быть проксированы, т. е. они будут использовать политику подключения прокси-сервера с портом 1433. Причина этого заключается в том, чтобы избежать нарушений трафика клиента от достижения базы данных SQL из-за необходимых диапазонов портов для перенаправления.
Локальные подключения через частный пиринг
Когда клиенты подключаются к общедоступной конечной точке из локальных компьютеров, их IP-адреса необходимо добавить в брандмауэр на основе IP-адресов, используя правило брандмауэра на уровне сервера. Хотя эта модель отлично подходит для предоставления доступа к отдельным компьютерам для рабочих нагрузок разработки или тестирования, управлять ею в рабочей среде сложно.
Используя Приватный канал, клиенты могут включить перекрестный доступ к частной конечной точке с помощью ExpressRoute, частного пиринга или VPN-туннелирования. После этого клиенты могут отключить доступ через общедоступную конечную точку и не использовать брандмауэр на основе IP-адресов для разрешения каких-либо IP-адресов.
Варианты использования Приватного канала для Базы данных SQL Azure
Клиенты могут подключаться к частной конечной точке из той же виртуальной сети, одноранговой виртуальной сети в том же регионе или через виртуальную сеть для подключения между регионами. Кроме того, клиенты могут подключаться из локальной среды с помощью ExpressRoute, частного пиринга или VPN-туннелирования. На следующей упрощенной схеме показаны распространенные варианты использования.
Кроме того, службы, которые не работают непосредственно в виртуальной сети, но интегрируются с ней (например, Служба приложений веб-приложения или функции) также могут обеспечить частное подключение к базе данных. Дополнительные сведения об этом конкретном варианте использования см. в статье о сценарии архитектуры с частным подключением веб-приложений к базе данных SQL Azure.
Подключение из виртуальной машины Azure в пиринговых виртуальная сеть
Настройте пиринг виртуальных сетей, чтобы установить подключение к базе данных SQL из виртуальной машины Azure в одноранговой виртуальной сети.
Подключение из виртуальной машины Azure в виртуальной сети в среду виртуальной сети
Настройте подключение VPN-шлюза типа "виртуальная сеть — виртуальная сеть", чтобы установить подключение к базе данных SQL из виртуальной машины Azure в другом регионе или подписке.
Подключение из локальной среды через VPN
Чтобы установить подключение из локальной среды к базе данных SQL, выберите и реализуйте один из вариантов.
Рассмотрите также сценарии конфигурации DNS, так как FQDN службы может разрешаться в общедоступный IP-адрес.
Подключение из Azure Synapse Analytics в служба хранилища Azure с помощью PolyBase и инструкции COPY
PolyBase и инструкцию COPY часто используют для загрузки данных в Azure Synapse Analytics из учетных записей службы хранилища Azure. Если учетная запись служба хранилища Azure, из которой вы загружаете данные, ограничивает доступ только к набору подсетей виртуальной сети через частные конечные точки, конечные точки службы или брандмауэры на основе IP-адресов, подключение из PolyBase и инструкция COPY к учетной записи будет нарушена. Чтобы обеспечить возможность импорта и экспорта в хранилище Azure Synapse Analytics, подключенном к службе хранилища Azure, которая прикреплена к виртуальной сети, выполните действия, описанные здесь.
Предотвращение кражи данных
Кража данных в Базе данных SQL Azure происходит тогда, когда пользователь, например администратор базы данных, может извлекать данные из одной системы и перемещать их в другое расположение или систему за пределами организации. Например, пользователь перемещает данные в учетную запись хранения, принадлежащую третьей стороне.
Рассмотрим сценарий с пользователем, запускающим SQL Server Management Studio (SSMS) в виртуальной машине Azure, подключенной к базе данных SQL. Эта база данных находится в центре обработки данных в западной части США. В следующем примере показано, как ограничить доступ к общедоступным конечным точкам на База данных SQL с помощью элементов управления доступом к сети.
- Отключите весь трафик службы Azure к Базе данных SQL, проходящий через общедоступную конечную точку, установив для параметра Allow Azure Services (Разрешить использование служб Azure) значение Выкл. Убедитесь, что в правилах брандмауэра на уровне сервера и базы данных не разрешены никакие IP-адреса. Дополнительные сведения см. в статье Средства контроля сетевого доступа Базы данных SQL Azure и Azure Synapse Analytics.
- Разрешите трафик в базу данных SQL с использованием только частного IP-адреса виртуальной машины. Дополнительные сведения см. в статьях, посвященных конечной точке службы и правилам брандмауэра виртуальной сети.
- На виртуальной машине Azure сузьте область исходящего подключения с помощью групп безопасности сети (NSG) и тегов служб, как показано ниже.
- Укажите правило NSG, чтобы разрешить трафик для тега службы = SQL. WestUs — только разрешение подключения к База данных SQL на западе США.
- Укажите правило NSG (с более высоким приоритетом), чтобы запретить трафик для тега службы = SQL — запрет подключений к База данных SQL во всех регионах.
После завершения установки виртуальная машина Azure может подключаться к базам данных SQL только в западной части США. Но возможность подключения не ограничивается одной базой данных SQL. Виртуальная машина по-прежнему может подключаться к любым базам данных в западной части США, включая базы данных, которые не входят в подписку. Хотя мы сократили масштабы кражи данных в приведенном выше сценарии до определенного региона, мы не полностью устранили ее.
Используя Приватный канал, клиенты теперь могут настроить средства контроля сетевого доступа, например группы безопасности сети, чтобы ограничить доступ к частной конечной точке. Затем отдельные ресурсы Azure PaaS сопоставляются с конкретными частными конечными точками. Злоумышленник внутри организации может получить доступ только к сопоставленному ресурсу PaaS (например, к базе данных SQL) и больше ни к какому другому ресурсу.
Связанный контент
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по