Настройка безопасности базы данных 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: предоставление доступа.
• Дополнительные сведения о пользователях автономной базы данных см. в статье Пользователи автономной базы данных — создание переносимой базы данных.
• Дополнительные сведения об активной георепликации см. здесь.
• Дополнительные сведения о группах отработки отказа см. в разделе "Отработка отказа".
• Сведения об использовании геовосстановления см. в этом разделе.