Проверка подлинности SQL в Azure Synapse Analytics

Azure Synapse Analytics имеет два форм-фактора SQL, которые позволяют управлять потреблением ресурсов. В этой статье объясняется, как два форм-фактора контролируют проверку подлинности пользователя.

Для авторизации в Synapse SQL можно использовать два типа авторизации:

• Авторизация Microsoft Entra
• Авторизация SQL

Авторизация SQL позволяет устаревшим приложениям подключаться к Azure Synapse SQL привычным образом. Однако проверка подлинности Microsoft Entra позволяет централизованно управлять доступом к ресурсам Azure Synapse, таким как пулы SQL. Azure Synapse Analytics поддерживает отключение локальной проверки подлинности, например проверку подлинности SQL, как во время, так и после создания рабочей области. После отключения полномочные пользователи могут в любое время включить локальную проверку подлинности. Дополнительные сведения о проверке подлинности, доступной только для Microsoft Entra, см. в разделе "Отключение локальной проверки подлинности в Azure Synapse Analytics".

Учетные записи администрирования

В качестве администратора выступают две учетные записи (имя администратора SQL и администратор Active Directory для SQL). Чтобы определить эти учетные записи администратора для пулов SQL, откройте портал Azure и перейдите на вкладку свойств рабочей области Synapse.

• Имя администратора SQL

  При создании Azure Synapse Analytics необходимо присвоить имя для входа администратора сервера. SQL Server создает эту учетную запись в качестве имени для входа в базе данных master. Эта учетная запись используется для подключения с использованием проверки подлинности SQL Server (с помощью имени пользователя и пароля). Может существовать только одна такая учетная запись.

• Администратор Active Directory для SQL

  Одна учетная запись Microsoft Entra( отдельная или учетная запись группы безопасности) также может быть настроена как администратор. Это необязательно для настройки администратора Microsoft Entra, но администратор Microsoft Entra должен быть настроен, если вы хотите использовать учетные записи Microsoft Entra для подключения к Synapse SQL.

  • Учетная запись администратора Microsoft Entra управляет доступом к выделенным пулам SQL, а роли Synapse RBAC можно использовать для управления доступом к бессерверным пулам, например с ролью Synapse Администратор istrator и Synapse SQL Администратор istrator.

Учетные записи имени администратора SQL и администратора Active Directory для SQL обладают следующими характеристиками:

• Это единственные учетные записи, которые могут автоматически подключаться к любой базе данных SQL на сервере. (Для подключения к пользовательской базе данных другие учетные записи должны иметь права владельца базы данных или в пользовательской базе данных должна находиться пользовательская учетная запись.)
• Эти учетные записи входят в пользовательские базы данных в качестве пользователя dbo. Они обладают всеми разрешениями в пользовательских базах данных. (Владелец пользовательской базы данных также входит в базу данных в качестве пользователя dbo.)
• Они не входят в базу данных master в качестве пользователя dbo. Для них назначены ограниченные разрешения в базе данных master.
• Не являются членами предопределенной роли sysadmin стандартного сервера SQL Server, недоступной в Базе данных SQL.
• Могут создавать, изменять и удалять базы данных, имена для входа, пользователей в базе данных master и правила брандмауэра для IP-адресов на уровне сервера.
• Могут добавлять и удалять членов в ролях dbmanager и loginmanager.
• Могут просматривать системную таблицу sys.sql_logins.

Примечание.

Если пользователь настроен как администратор Active Directory и Synapse Администратор istrator, а затем удален из роли администратора Active Directory, пользователь потеряет доступ к выделенным пулам SQL в Synapse. Их необходимо удалить, а затем добавить в роль Synapse Администратор istrator, чтобы восстановить доступ к выделенным пулам SQL.

Бессерверный пул SQL

Для управления пользователями с доступом к бессерверному пулу SQL можно использовать следующие инструкции.

Чтобы создать имя входа для бессерверного пула SQL, используйте следующий синтаксис:

CREATE LOGIN Mary WITH PASSWORD = '<strong_password>';
-- or
CREATE LOGIN [Mary@domainname.net] FROM EXTERNAL PROVIDER;

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

CREATE USER Mary FROM LOGIN Mary;
-- or
CREATE USER Mary FROM LOGIN Mary@domainname.net;
-- or
CREATE USER [mike@contoso.com] FROM EXTERNAL PROVIDER;

После создания имени входа и пользователя можно использовать стандартный синтаксис SQL Server для предоставления прав.

Выделенный пул SQL

Путь доступа администратора

При правильной настройке брандмауэра на уровне рабочей области имя администратора SQL и администратор Active Directory для SQL смогут подключаться с помощью таких клиентских средств, как SQL Server Management Studio или SQL Server Data Tools. Все функции и возможности доступны только в последних версиях средств.

На схеме ниже показана типичная конфигурация для двух учетных записей администраторов.

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

Создатели баз данных.

Одной из этих административных ролей является роль dbmanager. Участники этой роли могут создавать базы данных. Чтобы использовать эту роль, создайте пользователя в базе данных master, а затем добавьте его к роли базы данных dbmanager.

Чтобы создать базу данных, пользователь должен быть пользователем на основе имени входа SQL Server в master базе данных или пользователя автономной базы данных на основе пользователя Microsoft Entra.

1. Используя учетную запись администратора, подключитесь к базе данных master.

2. Создайте имя для входа при проверке подлинности SQL Server с помощью инструкции CREATE LOGIN. Пример инструкции:

   CREATE LOGIN Mary WITH PASSWORD = '<strong_password>';
   

   Примечание.

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

   Для повышения производительности имена для входа (субъекты уровня сервера) временно кэшируются на уровне базы данных. Сведения об обновлении кэша проверки подлинности см. в статье DBCC FLUSHAUTHCACHE (Transact-SQL).

3. Создайте пользователя баз данных с помощью инструкции CREATE USER. Пользователь может быть пользователем службы проверки подлинности Microsoft Entra, содержащей базу данных (если вы настроили среду для проверки подлинности Microsoft Entra), или пользователем проверки подлинности SQL Server, содержащим базу данных, или пользователем проверки подлинности SQL Server на основе имени входа проверки подлинности SQL Server (созданного на предыдущем шаге).

   Примеры инструкций:

   Создайте пользователя с идентификатором Microsoft Entra:

   CREATE USER [mike@contoso.com] FROM EXTERNAL PROVIDER; 
   

   Создание пользователя автономной базы данных SQL:

   CREATE USER Ann WITH PASSWORD = '<strong_password>';
   

   Создание пользователя SQL Server на основе имени входа для проверки подлинности SQL Server:

   CREATE USER Mary FROM LOGIN Mary;
   

4. Добавьте нового пользователя в роль базы данных DBManager в master с помощью процедуры sp_addrolemember. Обратите внимание, что инструкция ALTER ROLE не поддерживается в подготовленной среде SQL. Примеры инструкций:

   EXEC sp_addrolemember 'dbmanager', 'Mary'; 
   EXEC sp_addrolemember 'dbmanager', 'mike@contoso.com]'; 
   

   Примечание.

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

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

Теперь пользователь может подключаться к базе данных master и создавать базы данных. Учетная запись, создавшая базу данных, становится владельцем базы данных.

Диспетчеры входа

Другая административная роль — это роль диспетчера входов. Участники этой роли могут создавать учетные записи в базе данных master. При желании можно выполнить те же действия (создание имени для входа и пользователя и назначение ему роли loginmanager), чтобы разрешить пользователю создавать имена для входа в базу данных master. Обычно имена для входа не требуются, так как корпорация Майкрософт рекомендует использовать пользователей автономной базы данных, проверка подлинности которых выполняется на уровне базы данных, а не пользователей с именами для входа. Дополнительные сведения см. в статье Пользователи автономной базы данных — создание переносимой базы данных.

Пользователи без прав администратора

Как правило, для учетных записей без прав администратора не требуется доступ к базе данных master. Создайте пользователей автономной базы данных на уровне базы данных с помощью инструкции CREATE USER (Transact-SQL).

Пользователь может быть пользователем службы проверки подлинности Microsoft Entra, содержащей базу данных (если вы настроили среду для проверки подлинности Microsoft Entra), или пользователем проверки подлинности SQL Server, содержащимся в базе данных, или пользователем проверки подлинности SQL Server на основе имени входа проверки подлинности SQL Server (созданного на предыдущем шаге).

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

CREATE USER Mary FROM LOGIN Mary;
CREATE USER [mike@contoso.com] FROM EXTERNAL PROVIDER;

Изначально создавать пользователей может только один администратор или владелец базы данных. Чтобы разрешить другим пользователям создавать пользователей, предоставьте выбранному пользователю разрешение ALTER ANY USER с помощью следующей инструкции.

GRANT ALTER ANY USER TO Mary;

Чтобы предоставить другим пользователям полный доступ к базе данных, сделайте их участником фиксированной роли базы данных db_owner.

В Базе данных SQL Azure или бессерверной среде Synapse используйте инструкцию ALTER ROLE.

ALTER ROLE db_owner ADD MEMBER Mary;

В выделенном пуле SQL используйте EXEC sp_addrolemember.

EXEC sp_addrolemember 'db_owner', 'Mary';

Примечание.

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

Группы и роли

При эффективном управлении доступом используются разрешения, назначенные группам и ролям, а не отдельным пользователям.

• При использовании проверки подлинности Microsoft Entra поместите пользователей Microsoft Entra в группу Microsoft Entra. Создайте пользователя автономной базы данных для группы. Поместите одного или нескольких пользователей базы данных в роль базы данных, а затем назначьте разрешения для этой роли.

• При использовании проверки подлинности SQL Server создайте пользователей автономной базы данных в базе данных. Поместите одного или нескольких пользователей базы данных в роль базы данных, а затем назначьте разрешения для этой роли.

Роли базы данных могут быть встроенными ролями, например db_owner, db_ddladmin, db_datawriter, db_datareader, db_denydatawriter и db_denydatareader. Роль db_owner обычно используется для предоставления полных прав ограниченному числу пользователей. Другие фиксированные роли можно использовать для быстрого получения простых баз данных при разработке, но их не рекомендуется использовать для большинства рабочих баз данных.

Например, фиксированная роль базы данных db_datareader предоставляет доступ (как правило, строго обязательный) на чтение к каждой таблице в базе данных.

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

Разрешения

Существует более 100 разрешений, которые можно по отдельности предоставлять или отменять в базе данных SQL. Многие эти разрешения являются частью других разрешений. Например, разрешение UPDATE на схеме включает в себя разрешение UPDATE для каждой таблицы в этой схеме. Как и в большинстве систем разрешений, отмена разрешения переопределяет предоставление.

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

Изучите список разрешений на этой странице и ознакомьтесь с графическим представлением разрешений для ядра СУБД.

Рекомендации и ограничения

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

• При выполнении инструкций CREATE/ALTER/DROP DATABASE необходимо подключиться к базе данных master.
• Пользователя базы данных, соответствующего имени для входа администратора сервера, нельзя изменить или удалить.
• Администратор сервера будет отключен, если включена проверка подлинности только для Microsoft Entra.
• Языком по умолчанию для имени для входа администратора сервера является американский вариант английского языка.
• Только администраторы (имя входа администратора сервера или администратор Microsoft Entra) и члены роли базы данных dbmanager в master базе данных имеют разрешение на выполнение CREATE DATABASE инструкций и DROP DATABASE инструкций.
• При выполнении инструкций CREATE/ALTER/DROP LOGIN необходимо подключиться к базе данных master. В то же время использовать имена входа не рекомендуется. Вместо них используйте пользователей автономной базы данных. Дополнительные сведения см. в статье Пользователи автономной базы данных — создание переносимой базы данных.
• Для подключения к пользовательской базе данных необходимо указать имя базы данных в строке подключения.
• Только имя для входа на уровне сервера и члены роли базы данных loginmanager в базе данных master имеют разрешение на выполнение операторов CREATE LOGIN, ALTER LOGIN и DROP LOGIN.
• При выполнении инструкций CREATE/ALTER/DROP LOGIN и CREATE/ALTER/DROP DATABASE в приложении ADO.NET не разрешается использовать параметризованные команды. Дополнительные сведения можно найти в статье Команды и параметры.
• Если применяется инструкция CREATE USER с параметром FOR/FROM LOGIN, то она должна быть единственной инструкцией в пакете Transact-SQL.
• Если применяется инструкция ALTER USER с параметром WITH LOGIN, то она должна быть единственной инструкцией в пакете Transact-SQL.
• CREATE/ALTER/DROP LOGIN и CREATE/ALTER/DROP USER операторы не поддерживаются, если для рабочей области Azure Synapse включена проверка подлинности только для Microsoft Entra.
• Для выполнения инструкций CREATE/ALTER/DROP пользователю требуется разрешение ALTER ANY USER для базы данных.
• Если владелец роли базы данных пытается добавить или удалить другого пользователя базы данных в роль или из роли базы данных, может произойти следующая ошибка: В этой базе данных не существует пользователь или роль "Имя". Эта ошибка возникает, потому что данный пользователь не является видимым для владельца. Чтобы устранить эту проблему, предоставьте владельцу роли разрешение VIEW DEFINITION по отношению к данному пользователю.

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

Дополнительные сведения см. в статье Пользователи автономной базы данных — создание переносимой базы данных.