Возможности и задачи безопасности
SQL Server и службы SQL Azure уделяют больше внимание безопасности в первую очередь потому, что являются корпоративными решениями. В этом уроке вы узнаете о различных возможностях безопасности, связанных с безопасностью сети и управлением доступом. В следующих уроках вы получите практический опыт работы с некоторыми из этих возможностей.
Безопасность сети
Первый уровень безопасности — это сеть. Возможности сети и задачи различаются между База данных SQL Azure и Управляемый экземпляр SQL Azure. Сведения о Управляемый экземпляр SQL Azure сетевых возможностях см. в разделе "Архитектура подключения" для Управляемый экземпляр SQL Azure.
База данных SQL Azure сетевой безопасности
Защита сети для базы данных SQL Azure включает четыре основных варианта:
- Разрешение доступа службам Azure
- Использование правил брандмауэра
- Использование правил виртуальной сети
- Использование Приватного канала Azure
Помимо этих основных вариантов, у вас есть возможность заблокировать весь общедоступный доступ (только с Приватный канал Azure) и применить минимальную версию TLS. Наименее безопасный метод, но самый простой в настройке — разрешить доступ к службам Azure. Самый безопасный метод — использовать Приватный канал. В следующих разделах рассматриваются возможности, а также описывается настройка и обслуживание каждого варианта.
Разрешение доступа службам Azure
Во время развертывания База данных SQL Azure у вас есть возможность задать для этого сервера разрешение доступа к службам и ресурсам Azure на "Да". В этом случае вы разрешите любому ресурсу из любого региона или подписки получить доступ к вашему ресурсу. Этот параметр позволяет легко приступить к работе и подключить базу данных SQL Azure к другим службам, например к виртуальным машинам Azure, Службе приложений Azure или даже Azure Cloud Shell, поскольку разрешает любые подключения через Azure.
Разрешение доступа к службам Azure не подразумевает свободный доступ для любых объектов за пределами Azure (например, для локальной среды).
Самая безопасная конфигурация — задать для этого сервера разрешение доступа к службам и ресурсам Azure, которое блокирует все подключения и сети, кроме тех, которые вы явно добавили с различными параметрами, приведенными в следующих разделах.
Правила брандмауэра
Следующий вариант — применить правила брандмауэра. Результаты могут быть похожи на разрешения доступа к этому серверу служб и ресурсов Azure, за исключением того, что для каждой службы (на следующем изображении виртуальной машины) необходимо добавить уникальное правило брандмауэра, чтобы разрешить подключение. Правила брандмауэра также позволяют локальной среде подключаться к ресурсу База данных SQL Azure, так как можно добавить правила для компьютеров и приложений в локальной среде.
Для подключения к Azure вы также можете разрешить доступ к службам Azure, а затем добавить правила брандмауэра только для локальных подключений. Как упоминалось ранее, разрешить доступ к службам и ресурсам Azure к этому серверу не так безопасно, так как он разрешает весь трафик Azure. Рекомендуется использовать исключительно правила брандмауэра.
Рассмотрим предыдущий пример с настроенными правилами брандмауэра. Из средства, поддерживающего Transact-SQL (T-SQL), например SQL Server Management Studio (SSMS), можно выполнить следующий запрос из виртуальной машины Azure в виртуальной сети SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Результат должен быть таким: 203.0.113.1. Это общедоступный IP-адрес виртуальной машины Azure. Несмотря на то, что мы используем правила брандмауэра, все устанавливаемые подключения являются общедоступными.
Правила виртуальной сети
Если вы хотите использовать только правила брандмауэра, это может быть сложно для настройки. Использование только правил брандмауэра означает, что необходимо указать диапазон IP-адресов для всех подключений, которые иногда могут иметь динамические IP-адреса. Гораздо проще использовать правила виртуальной сети для создания и управления доступом из определенных сетей, содержащих виртуальные машины или другие службы, которым требуется доступ к данным.
Если вы настраиваете доступ из виртуальной сети с помощью правила виртуальной сети, все ресурсы в этой виртуальной сети могут получить доступ к логическому серверу базы данных SQL Azure. Это может упростить задачу настройки доступа ко всем статическим и динамическим IP-адресам, которым необходим доступ к данным. Используя правила виртуальной сети, вы можете указать одну или несколько виртуальных сетей и при этом охватить все ресурсы в этих сетях. Вы также можете использовать технологии виртуальных сетей для подключения сетей из разных регионов к Azure и локальной среде.
В этом примере, как и в предыдущем разделе, можно выполнить тот же запрос из виртуальной машины Azure в виртуальной сети SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Теперь результат будет выглядеть как 10.0.0.2 — это частный IP-адрес виртуальной машины Azure. Этот результат приближает вас к созданию частных подключений к логическому серверу базы данных SQL Azure, поскольку теперь ресурсы подключаются через виртуальную сеть.
Еще одна распространенная стратегия анализа подключения — это проверка иерархии службы доменных имен (DNS). На той же виртуальной машине Azure в командной строке можно выполнить следующую команду:
nslookup aw-server.database.windows.net
С помощью этой команды можно получить сведения, связанные с инфраструктурой DNS. Результаты будут похожи на следующие:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 203.0.113.1
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
В неавторитетном ответе есть некоторые важные моменты, которые следует посмотреть:
- Имя: конечная точка, которая начинается с
cr2и является частью общедоступной иерархии DNS. Не получая слишком много в иерархию, предположим, чтоcr2это кольцо управления 2 и что под ним есть несколько срезов данных. - Адрес: IP-адрес, возвращенный здесь, должен соответствовать общедоступному IP-адресу виртуальной машины Azure. Хотя в последнем прыжке SSMS может использоваться частный IP-адрес виртуальной машины, общедоступный IP-адрес виртуальной машины по-прежнему используется для подключения в некоторой емкости.
- Псевдонимы: псевдонимы — это различные точки в иерархии DNS. В этом случае определенные данные "срез" и конечная точка, к к которому вы подключаетесь.
Примечание.
В предыдущем блоке выходных данных адрес: 168.63.129.16 — это виртуальный общедоступный IP-адрес, используемый для упрощения канала связи с ресурсами платформы Azure. Он подходит для всех регионов и всех национальных облаков и остается неизменным.
Хотя подключение через SSMS выполняется через частный IP-адрес виртуальной машины Azure, вы по-прежнему подключаетесь через общедоступную конечную точку.
Приватный канал для База данных SQL Azure
Вы узнали, как настроить самую безопасную сеть с помощью базы данных в База данных SQL Azure с общедоступной конечной точкой. Этот метод защиты базы данных в базе данных SQL Azure применяется уже много лет. Однако в 2019 году в Azure начался переход к концепции приватного канала, которая больше напоминает развертывание управляемого экземпляра SQL Azure. С помощью Приватный канал Azure вы можете подключиться к базе данных в База данных SQL и нескольких других предложениях paaS с помощью частной конечной точки. Это означает, что у нее есть частный IP-адрес в определенной виртуальной сети.
В предыдущем примере вы заметите, что общая сетевая инфраструктура не изменилась, и вы по-прежнему можете применить стратегии подключения к виртуальной сети из правил виртуальной сети. При этом правила виртуальной сети создавать не нужно. Ресурсы, которым требуется подключение к серверу базы данных, должны иметь доступ к виртуальной сети, где находится конечная точка. В примере конечная точка — SQLDBVNet-EUSэто . Доступ получают только подключения через частную конечную точку, а все остальные подключения (например, из Интернета) отклоняются.
По мере продолжения работы с этим примером на виртуальной машине Azure в виртуальной сети SQLDBVNet-EUSможно еще раз выполнить следующую команду T-SQL:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Теперь результатом будет 10.0.0.2частный IP-адрес виртуальной машины Azure в этом примере. Добавив доступ из виртуальной сети, подключения к База данных SQL Azure из виртуальной машины будут отображаться через частный IP-адрес виртуальной машины. Это такой же результат, который вы получили при применении правил виртуальной сети.
Однако для изучения иерархии DNS можно ввести в командной строке следующую команду:
nslookup aw-server.database.windows.net
При использовании предыдущей команды результаты будут отличаться настроенной частной конечной точкой:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
В неавторитетном ответе есть некоторые важные моменты, которые следует посмотреть:
- Имя. Обратите внимание, что вы больше не указываете на общедоступную иерархию DNS только на Приватный канал DNS. Это означает, что общедоступных данных о вашем сервере базы данных будет меньше.
- Адреса. Для правил виртуальной сети возвращаемый адрес — это общедоступный IP-адрес виртуальной машины, но теперь он должен быть одним или несколькими частными IP-адресами в иерархии Приватный канал (одна — частная конечная точка База данных SQL Azure).
- Псевдонимы: как и в случае с полем "Имя", здесь не отображаются никакие данные, связанные с иерархией DNS, но сохраняется возможность подключения к имени сервера (например,
aw-server.database.windows.net).
Одна вещь, которую вы можете задуматься, если вы подключаетесь к частной конечной точке, почему вы по-прежнему используете то же имя сервера? В серверной части при использовании только Приватный канал метода подключения к База данных SQL Azure (т. е. без правил брандмауэра или виртуальной сети) информация обрабатывается следующим образом:
aw-server.database.windows.net- Разрешено службой для
aw-server.privatelink.database.net- Разрешено службой для
10.0.0.5(IP-адрес частной конечной точки)
- Разрешено службой для
- Разрешено службой для
Кроме того, служба будет блокировать для вас прямое подключение через другие методы, кроме aw-server.database.windows.net.
Управление доступом
После того как вы узнали сетевой доступ, следует рассмотреть следующий уровень управления доступом.
Управление доступом на основе ролей
Все типы операций Azure для База данных SQL Azure управляются с помощью управления доступом на основе ролей (RBAC). RBAC в настоящее время отделяется от безопасности SQL Azure, но вы можете рассматривать его как права безопасности за пределами базы данных в База данных SQL с областью, включающей подписку, группу ресурсов и ресурс. Права применяются к операциям на портале Azure, в Azure CLI и Azure PowerShell. RBAC позволяет распределять обязанности между развертыванием, управлением и использованием.
Встроенные роли доступны для уменьшения необходимости более высокого уровня РОЛЕЙ RBAC, таких как владелец или участник. Фактически эти роли можно использовать для развертывания определенных пользователей ресурсов SQL Azure (или управления политиками безопасности), но предоставить другим пользователям фактический доступ к использованию или управлению базой данных. Например, участник SQL Server может развернуть сервер и назначить пользователя администратором сервера и баз данных. Встроенные роли для База данных SQL Azure включают:
- Участник базы данных SQL. Может создавать базы данных и управлять ими, но не может получить доступ к базе данных (например, не удается подключить и считывать данные)
- Диспетчер безопасности SQL: может управлять политиками безопасности для баз данных и экземпляров (например, аудитом), но не имеет к ним доступа.
- Участник SQL Server: может управлять серверами и базами данных, но не может получить к ним доступ.
Проверка подлинности
Во время развертывания логического сервера База данных SQL Azure можно указать следующий метод проверки подлинности:
- Использование только проверки подлинности Microsoft Entra
- Использование проверки подлинности SQL и Microsoft Entra
- Использование аутентификации SQL
Администратор сервера должен быть задан во время развертывания. Для баз данных в База данных SQL Azure администратор сервера является субъектом уровня сервера для логического сервера База данных SQL Azure.
Если вы переносите рабочую нагрузку, требующую проверка подлинности Windows или вашей организации, использует идентификатор Microsoft Entra ID, можно использовать идентификатор Microsoft Entra. Администратор сервера Microsoft Entra можно назначить с помощью портала или средств командной строки.
Проверка подлинности только для записей Майкрософт — это параметр по умолчанию при настройке нового сервера. Введены имена входа сервера, позволяющие субъектам сервера Microsoft Entra, которые являются именами входа в виртуальной master базе данных База данных SQL. Вы можете создавать имена входа Microsoft Entra из пользователей, групп и субъектов-служб Microsoft Entra. При использовании проверки подлинности, доступной только для Microsoft Entra, можно создать имена входа проверки подлинности SQL, а существующие имена входа останутся. Однако только имена входа проверки подлинности Microsoft Entra и пользователи могут подключаться к логическому серверу. Дополнительные сведения о проверке подлинности только для Microsoft Entra см. в статье microsoft Entra-only authentication with Azure SQL.
В зависимости от того, как ваша организация настроила экземпляр Microsoft Entra, вы можете подключиться к нему с помощью любого из следующих трех методов (например, в SSMS):
Идентификатор Microsoft Entra — интегрированный: неинтерактивный метод, который можно использовать, если вы вошли в Windows с учетными данными Microsoft Entra из федеративного домена.
Идентификатор Microsoft Entra — пароль: неинтерактивный метод, позволяющий подключаться к имени субъекта Microsoft Entra с помощью управляемого идентификатором Майкрософт домена. Из документации:
Это может применяться к собственным или федеративным пользователям Microsoft Entra. Собственный пользователь является явным образом создан в идентификаторе Microsoft Entra и проходит проверку подлинности с помощью имени пользователя и пароля, а федеративный пользователь — это пользователь Windows, домен которого федеративный с идентификатором Microsoft Entra. Последний метод (с использованием имени пользователя и пароля) можно использовать, если пользователь хочет использовать учетные данные Windows, но локальный компьютер не присоединен к домену (например, с помощью удаленного доступа). В этом случае пользователь Windows может указать свою учетную запись домена и пароль и пройти проверку подлинности в База данных SQL или Azure Synapse Analytics (ранее — хранилище данных SQL) с помощью федеративных учетных данных.
Идентификатор Microsoft Entra — универсальный с многофакторной проверкой подлинности (MFA) — интерактивный метод, который защищает доступ к данным при выполнении требований организации к процессу единого входа с многофакторной проверкой подлинности Microsoft Entra.
Для База данных SQL Azure есть несколько нюансов. Вы можете иметь имена входа, существующие в виртуальной master базе данных, пользователей базы данных и даже содержащихся пользователей базы данных для учетных записей Microsoft Entra (рекомендуется). Хотя администратор сервера для База данных SQL Azure имеет sysadmin права, вы можете создавать более ограниченные администраторы с помощью ролей уровня сервера или базы данных. Две роли уровня базы данных доступны для База данных SQL, которые существуют только в виртуальной master базе данных:
- loginmanager: роль уровня базы данных, которая позволяет участникам создавать имена входа для сервера базы данных.
- dbmanager: роль уровня базы данных, которая позволяет членам создавать и удалять базы данных для сервера базы данных.
Ниже приведен список ролей уровня сервера в База данных SQL Azure:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
В конечном итоге при настройке проверки подлинности и авторизации достаточно соблюдать четыре следующих принципа:
- Развертывание выполнять с администратором сервера
- При необходимости создавать других администраторов
- Администраторы могут создавать пользователей
- Доступ предоставляется так же, как в SQL Server
Другие возможности
После ознакомления с некоторыми возможностями сети и проверки подлинности далее в этом модуле вы узнаете о других возможностях — защиты данных, мониторинга, ведения журнала и аудита — и связанных с ними задачах.