TL;DR: Com a GA dos Microsoft Entra server principals e server roles no Azure SQL Database, times brasileiros podem finalmente delegar papéis de servidor (como ##MS_ServerStateReader##) para identidades Entra, gerenciar logins centralmente e desabilitar acessos com um único comando. O principal ganho é eliminar a dependência de SQL authentication, adotar least-privilege em escala e automatizar provisioning via DevOps — sem abrir mão da governança.
Qual problema isso resolve?
Antes dessa atualização, identidades Microsoft Entra no Azure SQL Database só podiam ser criadas como contained database users — principals com escopo limitado a um único banco, sem presença no nível de servidor. Isso gerava três gargalos importantes:
- Sem delegação granular em nível de servidor. Não era possível atribuir papéis como ##MS_ServerStateReader## (para consultar DMVs entre bancos) ou ##MS_LoginManager## (para gerenciar logins) a um principal Entra. Apenas o admin Entra ou um login SQL conseguiam executar essas tarefas.
- Overhead de provisionamento por banco. Cada principal Entra precisava ser criado separadamente como contained database user em cada banco que exigisse acesso, sem herança de permissões.
- Ausência de um “desligamento” centralizado. Para desabilitar um usuário, era preciso localizar e remover o contained user em cada banco — não existia um login de servidor para desativar.
Essas limitações forçavam muitas equipes a manter SQL authentication para tarefas administrativas, mesmo quando já queriam migrar para um modelo password-less com Entra.
O que muda com a GA?
Microsoft Entra logins tornam-se server principals de primeira classe no banco lógico master, exatamente como logins SQL. Essa capacidade já estava em public preview no Azure SQL Database (e em GA no Azure SQL Managed Instance e SQL Server 2022+). Agora, com a GA no Azure SQL Database, três funcionalidades ficam disponíveis para produção:
1. Atribuição de server roles para identidades Entra
Os sete papéis fixos de servidor do Azure SQL Database podem ser atribuídos a server principals Entra. Isso inclui papéis para conectividade, gerenciamento de bancos, leitura de definições/seurança, gerenciamento de logins e leitura/gerenciamento de estado do servidor.
Na prática: você pode dar ao seu service principal de monitoria acesso read-only a DMVs em todos os bancos (##MS_ServerStateReader##), delegar o gerenciamento de logins a um membro da equipe de segurança (##MS_LoginManager##) ou permitir que uma aplicação DevOps crie bancos (##MS_DatabaseManager##) — tudo sem SQL auth, usando identidades Entra.
2. Modelo de login em todo o servidor
Em vez de provisionar contained users independentemente em cada banco, agora é possível criar database users mapeados a um login de servidor (CREATE USER ... FROM LOGIN). Esses usuários herdam automaticamente as permissões de escopo de servidor. Um login, vários bancos — gerenciado de um único lugar.
Para a sintaxe T-SQL, consulte Create and utilize Microsoft Entra server logins.
3. Habilitação/desabilitação centralizada de logins
ALTER LOGIN [[email protected]] DISABLE — um comando bloqueia essa identidade em todos os bancos do servidor. Chega de caça aos contained users durante offboarding ou resposta a incidentes. Ao reabilitar o login, o acesso é restaurado em todos os lugares.
Nota: ALTER LOGIN ... DISABLE se aplica apenas a usuários baseados em login, não a contained database users. Ele bloqueia novas conexões; sessões existentes permanecem ativas até serem encerradas com KILL. Para efeito imediato, é necessário limpar o cache de autenticação. Logins de grupo do Entra não são suportados.
O que isso desbloqueia para sua organização?
Capacidade de ir sem senha. Com server principals e roles em GA, as organizações podem adotar Entra-only authentication sem lacuna funcional remanescente. Os logins Entra trazem paridade com logins SQL, tornando prático desabilitar SQL authentication por completo.
Administração com least-privilege. Papéis de servidor simplificam o gerenciamento de permissões: é possível delegar responsabilidades de monitoria e administração sem exigir privilégios de admin. Dê a seus auditores de segurança o papel ##MS_SecurityDefinitionReader## em vez de 'db_owner'. Dê às suas ferramentas de monitoria ##MS_ServerStateReader## em vez de um papel de admin superprivilegiado.
DevOps zero-touch. Um service principal com ##MS_DatabaseManager## e ##MS_LoginManager## pode automatizar o provisionamento de bancos e usuários ponta a ponta. Após o bootstrap inicial com o admin Entra, nenhum humano precisa intervir nas operações rotineiras.
Resposta a incidentes mais rápida. Quando um principal é comprometido, desabilite o login no nível de servidor. Novas conexões são bloqueadas em todos os bancos imediatamente — sem precisar saber quais bancos o usuário acessava. Para cortar sessões ativas, limpe os caches de autenticação e encerre as sessões com KILL.
Suporte a geo-replicas. Logins Entra criados no servidor primário ficam automaticamente disponíveis nas geo-replicas, com acesso read-only aos bancos replicados.
Pontos-chave para implementação
- Requisitos de bootstrap. O Microsoft Entra admin deve criar o primeiro login Entra. Depois disso, qualquer principal Entra com ALTER ANY LOGIN ou membro de ##MS_LoginManager## pode criar logins adicionais.
- Admin Entra tem precedência. Se um principal for tanto o Entra admin quanto tiver um login, as permissões de admin vencem. As permissões do login não têm efeito adicional.
- Propagação de cache. Alterações de associação a papéis e permissões entram em vigor na próxima conexão. Para efeito imediato, limpe o cache de autenticação com DBCC FLUSHAUTHCACHE e DBCC FREESYSTEMCACHE('TokenAndPermUserStore').
- EXECUTE AS LOGIN não é suportado para logins Entra no Azure SQL Database (é suportado no Managed Instance).
Como começar?
- Configure um admin Microsoft Entra em seu servidor lógico.
- Crie seu primeiro login Entra e atribua server roles (tutorial passo a passo).
- Entenda os papéis de servidor e suas permissões.
- Considere habilitar Entra-only authentication para eliminar SQL auth por completo.
Pronto para migrar de SQL Authentication?
Se você está buscando migrar logins SQL existentes para Entra, confira o guia Securing Azure SQL Database with Microsoft Entra password-less authentication - migration guide. Ele cobre todo o journey: identificar dependências de logins SQL, convertê-los para principals Entra e habilitar o modo Entra-only.
Perguntas Frequentes
- Posso desabilitar completamente a SQL authentication depois dessa GA?
- Sim. Com os server principals e server roles em GA, não há mais lacuna funcional no nível de servidor. É possível adotar o modo Entra-only authentication e eliminar logins SQL, desde que o admin Entra inicial seja configurado e todas as dependências de login SQL sejam migradas.
- Como fica o gerenciamento de geo-replicas?
- Logins Entra criados no servidor primário ficam automaticamente disponíveis nas geo-replicas, com acesso read-only aos bancos replicados. Não é necessário criar logins separados para cada réplica.
- O que acontece se um principal Entra for comprometido?
- Basta executar ALTER LOGIN ... DISABLE no servidor lógico. Novas conexões são bloqueadas em todos os bancos imediatamente. Para cortar sessões ativas, é necessário limpar o cache de autenticação (DBCC FLUSHAUTHCACHE) e usar KILL.
- É possível usar EXECUTE AS LOGIN com logins Entra no Azure SQL Database?
- Não. O EXECUTE AS LOGIN não é suportado para logins Entra no Azure SQL Database (apenas no Managed Instance). Para impersonação, outras abordagens como contained database users ou aplicações com service principals são recomendadas.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
