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

  • Статья

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

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

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

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

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

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

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

Примечание.

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

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

Чтобы база данных-получатель использовалась как база данных-получатель только для чтения, и чтобы обеспечить надлежащий доступ к новой базе данных-источнику или базе данных, восстановленной с помощью геовосстановки, 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'

Примечание.

Пользователи 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*/

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

Примечание.

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

ALTER LOGIN [<login name>] DISABLE

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

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