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

Область применения:SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics База данных SQL в Microsoft Fabric

Используйте пользователей, содержащихся в базе данных, для аутентификации подключений к SQL Server и База данных SQL Azure на уровне базы данных. Изолированная база данных — это база данных, изолированная от других баз данных и от экземпляра SQL Server или SQL Database (и базы данных master), в котором размещена эта база данных.

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

В этой статье рассматриваются преимущества использования автономной модели базы данных по сравнению с традиционными правилами брандмауэра для входа и пользователя и Windows или сервера. Конкретные сценарии, управляемость или бизнес-логика приложений могут по-прежнему требовать использования традиционных правил брандмауэра для входа или пользователя и уровня сервера.

В традиционной модели подключения пользователи Windows или члены групп Windows подключаются к компоненту ядро СУБД, предоставляя учетные данные пользователя или группы, прошедшие проверку подлинности Windows. Или пользователи могут предоставлять имя и пароль и подключаться с помощью проверки подлинности SQL Server. В обоих случаях master база данных должна иметь имя входа, соответствующее учетным данным подключения.

После того как ядро СУБД подтверждает учетные данные для проверки подлинности Windows или выполняет проверку подлинности учетных данных SQL Server, обычно предпринимается попытка подключения к пользовательской базе данных. Для подключения к пользовательской базе данных имя входа должно быть сопоставлено с пользователем базы данных в этой базе данных (то есть связано с ним). Строка подключения также может содержать указание на подключение к конкретной базе данных, что необязательно в SQL Server, но обязательно в SQL Database.

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

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

Модель пользователя автономной базы данных

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

Модель пользователя автономной базы данных поддерживает как проверка подлинности Windows, так и проверку подлинности SQL Server. Его можно использовать как в SQL Server, так и в База данных SQL.

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

Действие пользователя автономной базы данных ограничено проверкой подлинности базы данных. Учетная запись пользователя базы данных должна быть независимо создана в каждой базе данных, которую требует пользователь. Чтобы сменить базу данных, пользователи SQL Database должны создать новое подключение. Пользователи автономной базы данных в SQL Server могут изменять базы данных, если идентичный пользователь присутствует в другой базе данных.

В Azure SQL Database и Azure Synapse Analytics поддерживаются удостоверения из Microsoft Entra ID (прежнее название — Azure Active Directory) для изолированных пользователей базы данных. База данных SQL поддерживает изолированных пользователей базы данных, использующих проверку подлинности SQL Server, но Azure Synapse Analytics этого не поддерживает. Дополнительные сведения см. в разделе Подключение к базе данных SQL с помощью аутентификации Microsoft Entra.

При использовании проверки подлинности Microsoft Entra пользователи могут подключаться из SQL Server Management Studio с помощью универсальной проверки подлинности Microsoft Entra. Администраторы могут настроить универсальную проверку подлинности, чтобы требовать многофакторную проверку подлинности, которая проверяет удостоверение с помощью телефонного звонка, текстового сообщения, смарт-карты с ПИН-кодом или уведомления мобильного приложения. Дополнительные сведения см. в разделе "Использование многофакторной проверки подлинности Microsoft Entra".

Для SQL Database и Azure Synapse Analytics имя базы данных всегда необходимо в строке подключения. Поэтому вам не нужно изменять строку подключения при переключении с традиционной модели на модель пользователя автономной базы данных. Для подключений к SQL Server имя базы данных необходимо добавить в строку подключения, если его там еще нет.

Important

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

Firewalls

SQL Server

В SQL Server правила брандмауэра Windows применяются ко всем подключениям и одинаково влияют на вход в систему как при подключениях по традиционной модели, так и для пользователей изолированной базы данных. Дополнительные сведения о брандмауэре Windows см. в разделе «Настройка брандмауэра Windows для доступа к компоненту ядро СУБД».

Брандмауэры базы данных SQL

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

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

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

Различия синтаксиса

Традиционная модель	Модель пользователя автономной базы данных
Когда вы подключены к базе данных `master`: `CREATE LOGIN login_name WITH PASSWORD = 'strong_password';` Затем при подключении к пользовательской базе данных: `CREATE USER 'user_name' FOR LOGIN 'login_name';`	При подключении к пользовательской базе данных: `CREATE USER user_name WITH PASSWORD = 'strong_password';`

Традиционная модель	Модель пользователя автономной базы данных
Чтобы изменить пароль в контексте `master` базы данных, выполните следующие действия. `ALTER LOGIN login_name WITH PASSWORD = 'strong_password';`	Чтобы изменить пароль в контексте пользовательской базы данных, выполните следующие действия. `ALTER USER user_name WITH PASSWORD = 'strong_password';`

Управляемый экземпляр SQL

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

Warning

В следующем примере скрипта kill используется инструкция для закрытия всех пользовательских процессов в базе данных. Убедитесь, что вы понимаете последствия этого скрипта и что оно соответствует вашему бизнесу перед его запуском. Кроме того, убедитесь, что другие подключения не активны в базе данных Управляемый экземпляр SQL, так как скрипт будет нарушать другие процессы, выполняемые в базе данных.

USE master;

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

DECLARE @kill_string varchar(8000) = '';
SELECT @kill_string = @kill_string + 'KILL ' + str(session_id) + '; '
FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test') and is_user_process = 1;

EXEC(@kill_string);
GO

sp_configure 'contained database authentication', 1;
GO

RECONFIGURE;
GO

SELECT * FROM sys.dm_exec_sessions
WHERE database_id  = db_id('Test')

ALTER DATABASE Test
SET containment=partial

USE Test;
GO

CREATE USER Carlo
WITH PASSWORD='Enterpwdhere*'

SELECT containment_desc FROM sys.databases
WHERE name='Test'

Remarks

Для каждого экземпляра SQL Server должна быть включена поддержка пользователей автономной базы данных. Дополнительные сведения см. в разделе "Проверка подлинности автономной базы данных" (параметр конфигурации сервера).
Пользователи и учетные записи, содержащиеся в базе данных с непересекающимися именами, могут сосуществовать в приложениях.
Предположим, что в базе данных master существует учетная запись для входа с именем name1. Если вы создаете пользователя автономной базы данных с именем name1, то при указании имени базы данных в строке подключения для подключения к базе данных будет выбран контекст пользователя базы данных, а не контекст входа. То есть пользователь автономной базы данных имеет приоритет перед учетными записями входа с тем же именем.
В База данных SQL имя пользователя автономной базы данных не может совпадать с именем учетной записи администратора сервера.
Учетная запись администратора сервера База данных SQL никогда не может быть пользователем автономной базы данных. Администратор сервера имеет достаточные разрешения для создания пользователей автономной базы данных и управления ими. Администратор сервера может предоставлять разрешения пользователям автономной базы данных для пользовательских баз данных.
Так как пользователи автономной базы данных являются субъектами уровня базы данных, необходимо создать пользователей автономной базы данных в каждой базе данных, где они будут использоваться. Идентификатор ограничен базой данных. Учётная запись не зависит ни в каком отношении от пользователя с тем же именем и тем же паролем в другой базе данных на том же сервере.
Используйте ту же силу паролей, которые обычно используются для входа.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-07-20