Otimizando a Migração de Logins SQL Server para o Cloud SQL

A jornada de modernização de bancos de dados é um passo estratégico crucial para empresas que buscam escalabilidade e eficiência. Após planejar e configurar o Database Migration Service (DMS) do Google Cloud, sincronizar seus dados para uma instância totalmente gerenciada de Cloud SQL for SQL Server, você pode se deparar com um obstáculo inesperado:

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user'.

Este erro comum ocorre porque os logins do SQL Server não foram migrados juntamente com os dados. Este artigo explora as razões por trás dessa lacuna, como ela contribui para a segurança de sua organização e a solução prática utilizando ferramentas padrão do SQL Server.

Por que o DMS não migra logins: Segurança e Conformidade

O DMS é uma ferramenta poderosa para replicar esquemas e dados transacionais, mas ele omite intencionalmente objetos em nível de instância, como o banco de dados do sistema master e os logins e permissões do servidor. Essa decisão de design é fundamentada em três pilares essenciais:

1. Isolamento de Segurança e Limites de Privilégio: Ambientes on-premises e o Cloud SQL operam sob paradigmas de segurança distintos. A replicação direta do banco de dados master poderia resultar em escalonamento de privilégios indevido. Um login sysadmin local não deve ter acesso irrestrito ao Cloud SQL, que, por ser um serviço gerenciado, requer controle granular para garantir a operação correta e a segurança gerenciada pelo provedor de nuvem.

2. Conformidade e Governança de Auditoria: A migração automatizada de hashes de senhas criptografados e credenciais de segurança em nível de servidor, sem supervisão explícita do administrador, pode violar frameworks de conformidade empresarial como PCI-DSS ou SOC 2. Ao tratar a migração de objetos de segurança como um passo deliberado e administrado, as organizações garantem que apenas identidades aprovadas sejam provisionadas no ambiente de nuvem.

3. Oportunidade para Modernização de Identidade: A migração para a nuvem é o momento ideal para revisar e desativar credenciais obsoletas. Instâncias on-premises frequentemente acumulam logins legados que não são mais necessários. Migrá-los cegamente para um serviço gerenciado é um anti-padrão de segurança. Além disso, a migração para o Cloud SQL pode ser o catalisador para a adoção de soluções de identidade modernas e nativas da nuvem, como o Customer-Managed Active Directory (CMAD), em detrimento da autenticação SQL legado.

Entendendo Logins vs. Usuários: A Conexão via SID

Para uma migração bem-sucedida, é fundamental compreender a distinção no gerenciamento de segurança do SQL Server:

• Logins (nível de servidor): Armazenados no banco de dados master, são responsáveis pela autenticação de uma conexão com a instância do SQL Server.
• Usuários (nível de banco de dados): Armazenados dentro de bancos de dados individuais, autorizam as ações que uma conexão pode realizar naquele banco de dados específico.

Ao realizar backup e restauração de um banco de dados, ou ao usar o DMS para replicá-lo, os usuários em nível de banco de dados (e seus SIDs correspondentes) são migrados dentro dos arquivos do banco de dados. No entanto, se o login correspondente em nível de servidor não existir no banco de dados master de destino, ou se existir com um SID diferente, a vinculação se quebra. Isso resulta em usuários "órfãos", que possuem permissões de acesso ao banco de dados, mas sem autenticação em nível de servidor.

A Solução Recomendada: Replicando Logins com sp_help_revlogin

Em vez de recriar manualmente cada login e tentar adivinhar os hashes de senha, é possível utilizar um script clássico fornecido pela Microsoft: sp_help_revlogin.

Este script gera uma consulta T-SQL com a instrução CREATE LOGIN para cada login de autenticação SQL Server na sua instância de origem, incluindo seu hash de senha original criptografado e seu SID exato.

Passo 1: Crie os procedimentos auxiliares na sua instância de origem

Conecte-se à sua instância SQL Server de origem usando o SQL Server Management Studio (SSMS). Copie e execute o script oficial da Microsoft para criar os dois procedimentos armazenados necessários no seu banco de dados master de origem: sp_hexadecimal e sp_help_revlogin.

Passo 2: Gere o script de migração

Com os procedimentos criados, execute a seguinte instrução na janela de consulta do SSMS. Certifique-se de configurar a saída para Results to Text (Ctrl + T) para copiar o resultado de forma limpa:

EXEC master.dbo.sp_help_revlogin;

O resultado será uma série de comandos SQL que você poderá executar na sua instância Cloud SQL. É crucial revisar este script antes da execução para garantir que apenas os logins desejados sejam migrados e com as permissões adequadas.

Considerações Finais

Migrar logins e usuários do SQL Server para o Cloud SQL é um passo essencial para a conclusão bem-sucedida da modernização de seus bancos de dados. Embora o DMS se concentre na replicação de dados e esquemas, a gestão de identidades e acessos requer atenção adicional. Utilizar ferramentas como sp_help_revlogin garante que a transição seja segura, eficiente e esteja em conformidade com as políticas de segurança da sua organização. Ao abordar proativamente a migração de logins, você assegura que suas aplicações possam se conectar ao Cloud SQL sem interrupções e com a segurança fortalecida.

Recomendado pelo autor

SQL Para Análise de Dados: Técnicas Avançadas Para Transformar Dados em Insights

Ver Oferta

* Link de afiliado — o preço pode variar. Ao comprar, você apoia este blog sem custo extra.

Recomendado pelo autor

Lean Analytics: Use Data to Build a Better Startup Faster (English Edition)

Ver Oferta

* Link de afiliado — o preço pode variar. Ao comprar, você apoia este blog sem custo extra.