Configurar e gerenciar a segurança do Banco de Dados SQL do Azure para restauração geográfica ou failover

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Esse artigo descreve os requisitos de autenticação para configurar e controlar replicação geográfica ativa e grupos de failover. Ele também fornece as etapas necessárias para configurar o acesso de usuário no banco de dados secundário. Por fim, 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 as opções de recuperação, confira Visão geral de continuidade dos negócios.

Recuperação de desastre com usuários independentes

Ao contrário de usuários tradicionais, que devem ser mapeados para logons no banco de dados master, um usuário independente é totalmente gerenciado pelo próprio banco de dados. Isso oferece dois benefícios. No cenário de recuperação de desastre, os usuários podem continuar a conectar ao novo banco de dados primário recuperado usando restauração geográfica sem qualquer configuração adicional, pois o banco de dados gerencia os usuários. Também há possíveis benefícios de desempenho e escalabilidade com esta configuração de uma perspectiva de logon. Para obter mais informações, consulte Usuários do banco de dados independente – Tornando o banco de dados portátil.

A principal desvantagem é que gerenciar o processo de recuperação de desastre em grande escala é mais desafiador. Quando você tiver vários bancos de dados que usam o mesmo logon, manter as credenciais usando usuários independentes em vários bancos de dados pode invalidar os benefícios de usuários independentes. Por exemplo, a política de rotação de senha exige que alterações ocorram consistentemente em vários bancos de dados em vez de alterar a senha do logon apenas uma vez no banco de dados master. Por esse motivo, se você tiver vários bancos de dados que usam o mesmo nome de usuário e senha, a utilização de usuários independentes não será recomendada.

Como configurar logons e usuários

Se você estiver usando logons e usuários (em vez de usuários independentes), precisará realizar etapas extras para garantir que os mesmos logons existam no banco de dados master. As seções a seguir descrevem as etapas envolvidas e considerações adicionais.

Observação

Também é possível usar logons criados por meio do Microsoft Entra ID (anteriormente, Azure Active Directory) para gerenciar seus bancos de dados. Para saber mais, confira Logons e usuários do SQL do Azure.

Configurar o acesso do usuário a um banco de dados secundário ou recuperado

Para o banco de dados secundário poder ser usado como banco de dados secundário somente leitura e para garantir o acesso apropriado ao novo banco de dados primário ou o banco de dados recuperado usando a restauração geográfica, o banco de dados master do servidor de destino deve ter a configuração de segurança apropriadas 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 realizada como parte da configuração da replicação geográfica. A preparação do acesso do usuário aos bancos de dados restaurados geograficamente pode ser realizada a qualquer momento em que o servidor original estiver online (ex.: como parte do teste de DR).

Observação

Se o failover ou a restauração geográfica for para um servidor que não tem acesso de logons configurado corretamente, o acesso a ele será limitado à conta do administrador do servidor.

Configurar logons no servidor de destino envolve três etapas descritas abaixo:

1. Determinar os logons com acesso ao banco de dados primário

A primeira etapa do processo é determinar quais logons devem ser duplicados no servidor de destino. Isso é feito com um par de instruções SELECT, uma no banco de dados master lógico do servidor de origem e outra no próprio banco de dados primário.

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

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 de servidores 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. Localizar o SID dos logons identificados na etapa 1

Ao comparar a saída das consultas da seção anterior e fazer a correspondência dos SIDs, é possível mapear o logon do servidor para o usuário do banco de dados. 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 o administrador de servidores pode executar essa consulta.

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

Observação

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. Criar os logons no servidor de destino

A última etapa é acessar o servidor de destino, ou servidores, e gerar os logons com os SIDs apropriados. A sintaxe básica é mostrada a seguir.

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 logon com o SID de administrador do servidor de origem. Em vez disso, faça com que o administrador do servidor de destino faça logon em um banco de dados principal no banco de dados, como db_owner ou usuário.

Observação

Se desejar conceder ao usuário o acesso ao secundário, mas não ao primário, você poderá fazer isso alterando o logon do usuário no servidor primário usando a sintaxe a seguir.

ALTER LOGIN [<login name>] DISABLE

DISABLE não altera a senha, portanto você sempre poderá habilitá-la se necessário.

Próximas etapas