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

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных SQL Azure

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

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

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

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

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

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

Примечание

Для управления базами данных можно также использовать имена для входа Azure Active Directory (AAD). Дополнительные сведения см. в статье Контроль и предоставление доступа к базе данных SQL и хранилищу данных SQL.

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

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

Далее в этом разделе описываются конкретные разрешения для каждого шага.

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

Примечание

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

Настройка учетных данных для входа на целевом сервере включает следующие три действия.

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'

Примечание

Пользователи INFORMATION_SCHEMA и sys имеют ИД безопасности NULL, а ИД безопасности пользователя guest — 0x00. ИД безопасности Dbo может начинаться с 0x01060000000001648000000000048454, если базу данных создал администратор сервера, а не участник DbManager.

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

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

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

Примечание

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

ALTER LOGIN [<login name>] DISABLE

DISABLE не изменяет пароль, поэтому при любой необходимости можно вернуть ENABLE.

Дальнейшие действия