Share via

Configurar o acesso isolado a uma réplica nomeada do Hyperscale

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

Este artigo descreve o procedimento para conceder acesso a uma réplica nomeada do Azure SQL Hyperscale sem conceder acesso à réplica primária ou a outras réplicas nomeadas. Esse cenário permite o isolamento de recursos e segurança de uma réplica nomeada - pois a réplica nomeada será executada usando seu próprio nó de computação - e é útil sempre que o acesso isolado somente leitura a um banco de dados SQL Hyperscale do Azure é necessário. Isolado, neste contexto, significa que a CPU e a memória não são compartilhadas entre a réplica primária e a réplica nomeada, as consultas em execução na réplica nomeada não usam recursos de computação da réplica primária ou de quaisquer outras réplicas e as entidades que acessam a réplica nomeada não podem acessar outras réplicas, incluindo a primária.

Nota

Microsoft Entra ID é o novo nome para o Azure Ative Directory (Azure AD). Estamos atualizando a documentação neste momento.

Criar um logon no banco de dados mestre no servidor primário

master No banco de dados no servidor lógico que hospeda o banco de dados primário, execute o seguinte para criar um novo login.

Use sua própria senha forte e exclusiva.

create login [third-party-login] with password = 'Just4STRONG_PAZzW0rd!';

Recupere o valor hexadecimal SID para o login criado na visualização do sys.sql_logins sistema:

select sid from sys.sql_logins where name = 'third-party-login';

Desative o login. Isso impedirá que esse login acesse qualquer banco de dados no servidor que hospeda a réplica primária.

alter login [third-party-login] disable;

Criar um usuário no banco de dados primário de leitura/gravação

Depois que o logon for criado, conecte-se à réplica primária de leitura-gravação do seu banco de dados, por exemplo, WideWorldImporters (você pode encontrar um script de exemplo para restaurá-lo aqui: Restaurar Banco de Dados no Azure SQL) e crie um usuário de banco de dados para esse logon:

create user [third-party-user] from login [third-party-login];

Como etapa opcional, uma vez que o usuário do banco de dados tenha sido criado, você pode descartar o login do servidor criado na etapa anterior se houver preocupações sobre o login ser reativado de alguma forma. Conecte-se ao master banco de dados no servidor lógico que hospeda o banco de dados primário e execute o seguinte:

drop login [third-party-login];

Criar uma réplica nomeada em um servidor lógico diferente

Crie um novo servidor lógico SQL do Azure que será usado para isolar o acesso à réplica nomeada. Siga as instruções disponíveis em Criar e gerenciar servidores e bancos de dados únicos no Banco de Dados SQL do Azure. Para criar uma réplica nomeada, esse servidor deve estar na mesma região do Azure que o servidor que hospeda a réplica primária.

Usando, por exemplo, AZ CLI:

az sql server create -g MyResourceGroup -n MyNamedReplicaServer -l MyLocation --admin-user MyAdminUser --admin-password MyStrongADM1NPassw0rd!

Em seguida, crie uma réplica nomeada para o banco de dados primário neste servidor. Por exemplo, usando AZ CLI:

az sql db replica create -g MyResourceGroup -n WideWorldImporters -s MyPrimaryServer --secondary-type Named --partner-database WideWorldImporters_NR --partner-server MyNamedReplicaServer

Criar um logon no banco de dados mestre no servidor de réplica nomeado

Conecte-se ao master banco de dados no servidor lógico que hospeda a réplica nomeada, criada na etapa anterior. Adicione o login usando o SID recuperado da réplica primária:

create login [third-party-login] with password = 'Just4STRONG_PAZzW0rd!', sid = 0x0...1234;

Neste ponto, os usuários e aplicativos que usam third-party-login ou bob@contoso.com podem se conectar à réplica nomeada, mas não à réplica primária.

Conceder permissões no nível do objeto no banco de dados

Depois de configurar a autenticação de login conforme descrito, você pode usar instruções DENY regulares e REVOKE , para gerenciar permissões de autorização ou de nível de objeto no banco de GRANTdados. Nessas instruções, faça referência ao nome do usuário criado no banco de dados ou a uma função de banco de dados que inclua esse usuário como membro. Lembre-se de executar esses comandos na réplica primária. As alterações serão propagadas para todas as réplicas secundárias, no entanto, elas só serão efetivas na réplica nomeada onde o login no nível do servidor foi criado.

Lembre-se de que, por padrão, um usuário recém-criado tem um conjunto mínimo de permissões concedidas (por exemplo, ele não pode acessar nenhuma tabela de usuário). Se quiser permitir third-party-user ou bob@contoso.com ler dados em uma tabela, você precisa conceder explicitamente a SELECT permissão:

GRANT SELECT ON [Application].[Cities] to [third-party-user];

Como alternativa à concessão de permissões individualmente em cada tabela, você pode adicionar o usuário à db_datareadersfunção de banco de dados para permitir acesso de leitura a todas as tabelas ou pode usar esquemas para permitir o acesso a todas as tabelas novas e existentes em um esquema.

Acesso ao teste

Você pode testar essa configuração usando qualquer ferramenta de cliente e tentar se conectar à réplica primária e nomeada. Por exemplo, usando o , você pode tentar se conectar à réplica primária usando sqlcmdo third-party-login usuário:

sqlcmd -S MyPrimaryServer.database.windows.net -U third-party-login -P Just4STRONG_PAZzW0rd! -d WideWorldImporters

Isso resultará em um erro, pois o usuário não tem permissão para se conectar ao servidor:

Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login failed for user 'third-party-login'. Reason: The account is disabled.

A tentativa de se conectar à réplica nomeada é bem-sucedida:

sqlcmd -S MyNamedReplicaServer.database.windows.net -U third-party-login -P Just4STRONG_PAZzW0rd! -d WideWorldImporters_NR

Nenhum erro é retornado e as consultas podem ser executadas na réplica nomeada, conforme permitido pelas permissões concedidas no nível do objeto.

Para mais informações: