Настройка безопасности базы данных SQL Azure и управление ею для геовосстановления или отработки отказа

Применимо к: База данных SQL Azure

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

Аварийное восстановление с поддержкой автономных пользователей

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

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

Настройка имен для входа и пользователей

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

Настройка доступа пользователей к базе данных-получателю или восстановленной базе данных

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

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

Настройка имен входа на целевом сервере включает три шага.

1. Определение учетных записей с доступом к базе данных-источнику

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

Только администратор сервера или член роли сервера LoginManager может определить имена входа на исходном сервере с помощью следующей SELECT инструкции.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

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

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Поиск ИД безопасности для учетных записей, определенных на шаге 1

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

Следующий запрос можно использовать для просмотра всех субъектов-пользователей и их ИД безопасности в базе данных. Этот запрос могут выполнять только учетные записи базы данных с ролью db_owner или администратор сервера.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

3. Создание имен для входа на целевом сервере

Последним шагом является переход к целевому серверу или серверам и создание учетных записей с соответствующими ИД безопасности. Базовый синтаксис выглядит так.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

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

ALTER LOGIN [<login name>] DISABLE

Связанный контент

• Авторизация доступа к Базе данных SQL, Управляемому экземпляру SQL и Azure Synapse Analytics
• Пользователи автономной базы данных: создание переносимой базы данных
• Активная георепликация
• Обзор групп переключения при отказе и передовые методы (база данных Azure SQL)
• Геовосстановление