Configurar e gerir a segurança da Base de Dados SQL para restauro ou ativação pós-falha geográfica

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve os requisitos de autenticação para configurar e controlar grupos ativos de replicação geográfica e failover. Ele também fornece as etapas necessárias para configurar o acesso do usuário ao banco de dados secundário. Finalmente, ele também descreve como habilitar o acesso ao banco de dados recuperado depois de usar a restauração geográfica. Para obter mais informações sobre opções de recuperação, consulte Visão geral da continuidade de negócios.

Recuperação após desastre com utilizadores contidos

Ao contrário dos usuários tradicionais, que devem ser mapeados para logins no master banco de dados, um usuário contido é gerenciado completamente pelo próprio banco de dados. Isto tem duas vantagens. No cenário de recuperação de desastres, os usuários podem continuar a se conectar ao novo banco de dados primário ou ao banco de dados recuperado usando a restauração geográfica sem qualquer configuração adicional, porque o banco de dados gerencia os usuários. Há também potenciais benefícios de escalabilidade e desempenho dessa configuração do ponto de vista de login. Para obter mais informações, veja Contained Database Users - Making Your Database Portable (Utilizadores de Base de Dados Contidos – Tornar a Sua Base de Dados Portátil).

A principal contrapartida é que gerenciar o processo de recuperação de desastres em escala é mais desafiador. Quando você tem vários bancos de dados que usam o mesmo login, manter as credenciais usando usuários contidos em vários bancos de dados pode negar os benefícios dos usuários contidos. Por exemplo, a política de rotação de senha exige que as alterações sejam feitas consistentemente em vários bancos de dados, em vez de alterar a senha do login uma vez no master banco de dados. Por esse motivo, se você tiver vários bancos de dados que usam o mesmo nome de usuário e senha, o uso de usuários contidos não é recomendado.

Como configurar logins e usuários

Se você estiver usando logins e usuários (em vez de usuários contidos), deverá tomar medidas adicionais para garantir que os mesmos logins existam no master banco de dados. As seções a seguir descrevem as etapas envolvidas e considerações adicionais.

Nota

Também é possível usar logons criados a partir do Microsoft Entra ID (antigo Azure Ative Directory) para gerenciar seus bancos de dados. Para obter mais informações, consulte Logons e usuários do Azure SQL.

Configurar o acesso do utilizador a uma base de dados secundária ou recuperada

Para que o banco de dados secundário possa ser usado como um banco de dados secundário somente leitura e para garantir o acesso adequado ao novo banco de dados primário ou ao banco de dados recuperado usando a restauração geográfica, o master banco de dados do servidor de destino deve ter a configuração de segurança apropriada em vigor antes da recuperação.

As permissões específicas para cada etapa são descritas posteriormente neste tópico.

A preparação do acesso do usuário a uma replicação geográfica secundária deve ser executada como parte da configuração da replicação geográfica. A preparação do acesso do usuário aos bancos de dados restaurados geograficamente deve ser realizada a qualquer momento quando o servidor original estiver on-line (por exemplo, como parte do drill DR).

Nota

Se você fizer failover ou restaurar geograficamente para um servidor que não tenha logins configurados corretamente, o acesso a ele será limitado à conta de administrador do servidor.

A configuração de logins no servidor de destino envolve três etapas descritas abaixo:

1. Determine logins com acesso ao banco de dados primário

O primeiro passo do processo é determinar quais os inícios de sessão que têm de ser duplicados no servidor de destino. Isso é feito com um par de instruções SELECT, uma no banco de dados lógico master no servidor de origem e outra no próprio banco de dados primário.

Somente o administrador do servidor ou um membro da função de servidor LoginManager pode determinar os logons no servidor de origem com a seguinte instrução SELECT.

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

Somente um membro da função de banco de dados db_owner, o usuário dbo ou o administrador do servidor, pode determinar todas as entidades de usuário do banco de dados no banco de dados primário.

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

2. Encontre o SID para os logins identificados na etapa 1

Comparando a saída das consultas da seção anterior e combinando os SIDs, você pode mapear o login do servidor para o usuário do banco de dados. Os logons que têm um usuário de banco de dados com um SID correspondente têm acesso de usuário a esse banco de dados como essa entidade de usuário de banco de dados.

A consulta a seguir pode ser usada para ver todas as entidades de usuário e seus SIDs em um banco de dados. Somente um membro da função de banco de dados db_owner ou administrador do servidor pode executar essa consulta.

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

Nota

Os usuários INFORMATION_SCHEMA e sys têm SIDs NULL e o SID convidado é 0x00. O SID dbo pode começar com 0x01060000000001648000000000048454, se o criador do banco de dados foi o administrador do servidor em vez de um membro do DbManager.

3. Crie os logins no servidor de destino

O último passo é aceder ao servidor ou aos servidores de destino e gerar os inícios de sessão com os SIDs adequados. A sintaxe básica é a seguinte.

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

No servidor de destino, não crie um novo login com o SID de administrador do servidor a partir da origem. Em vez disso, torne o login de administrador do servidor de destino uma entidade de banco de dados no banco de dados, como db_owner ou usuário.

Nota

Se quiser conceder acesso de usuário ao secundário, mas não ao principal, você pode fazer isso alterando o login do usuário no servidor primário usando a sintaxe a seguir.

ALTER LOGIN [<login name>] DISABLE

DISABLE não altera a palavra-passe, pelo que pode sempre ativá-la, se necessário.

Próximos passos