No exame DP-300, a seção de autenticação e autorização pergunta como você projeta 'quem pode entrar no banco de dados' e 'o que essa pessoa pode fazer depois de entrar.' Esses conceitos correspondem a Autenticação e Autorização, e no Azure SQL cada um opera em uma camada completamente diferente. O exame avalia a capacidade de escolher a opção certa para um cenário concreto, não a memorização pura.
SQL Authentication vs Microsoft Entra ID Authentication
Imagine duas maneiras de entrar em um prédio: um PIN emitido pela administração do próprio prédio, ou um crachá emitido pelo RH da empresa. SQL Authentication é a primeira opção. O motor do banco de dados armazena e valida nomes de usuário e senhas diretamente. É compatível com o SQL Server local e clientes legados, mas exige gerenciar separadamente a rotação de senhas e desativação de contas.
Microsoft Entra ID authentication é o modelo do crachá corporativo. O sistema de identidade central gerencia a autenticação, portanto nenhuma senha é armazenada no motor SQL. Quando a conta Entra ID de um funcionário é desativada, o acesso ao SQL é automaticamente revogado. MFA, Acesso Condicional e gerenciamento de permissões por grupos estão disponíveis nativamente.
Submodos do Entra ID: (login silencioso via federação com AD local), (credenciais do Entra ID diretamente), (login interativo com MFA — mais frequente no exame), e (não interativos, para aplicações).
!Autenticação SQL vs autenticação do Microsoft Entra ID
Login, User e Contained User
Para entrar em um restaurante, primeiro você passa pela porta (credencial de entrada) e depois é alocado em uma mesa. A segurança do SQL Server segue exatamente essas duas etapas.
Um é uma entidade de segurança no nível do servidor armazenada no banco . Um é uma entidade no nível do banco de dados. Você deve mapear um Login a um User dentro de um banco específico para acessar tabelas. O problema surge ao mover o banco para outro servidor: o User existe, mas o Login está ausente — o 'usuário órfão' (orphaned user).
Os resolvem isso. A autenticação fica dentro do próprio banco, não no master, portanto o banco pode ser movido sem quebrar a autenticação — abordagem recomendada para Azure SQL Database. Crie um usuário do Entra ID como Contained User com . Registre um grupo inteiro do Entra ID e todos os membros ganham acesso de uma vez.
Modelo de Permissões Baseado em Funções
Em um escritório de 100 funcionários, distribuir chaves individuais é inviável. Você emite cartões por função — 'Cartão de Vendas,' 'Cartão de Dev' — para que quando alguém muda de equipe, apenas troca o cartão.
Fixed Server Roles no nível do servidor: (autoridade completa), (criar, modificar, excluir bancos), (gerenciamento de Logins + GRANT/REVOKE/DENY). Nota crítica: pode conceder permissões que ele próprio não possui, habilitando escalada ao nível de sysadmin — risco frequentemente avaliado no exame.
Fixed Database Roles: (tudo), (SELECT em todas as tabelas), (INSERT/UPDATE/DELETE), (gerenciamento de funções + GRANT/REVOKE), (apenas adicionar ou remover contas). O Azure SQL Database não suporta — use User-Defined Database Roles.
GRANT, DENY e REVOKE
Um gerente concede ao funcionário A acesso a uma sala de armazenamento. Mais tarde chega inventário sensível. Como bloquear A sem remover todas as permissões?
atribui uma permissão. remove uma permissão concedida ou negada. recusa explicitamente uma permissão. A regra decisiva: DENY sempre prevalece sobre GRANT. Mesmo que uma entidade herde GRANT por associação a uma função, um DENY direto vence. permite que o destinatário transfira a mesma permissão a outros. GRANT no nível de esquema aplica-se a todos os objetos desse esquema; GRANT no nível de objeto aponta para tabelas ou views específicas. Privilégio mínimo: sempre comece pelo escopo mais restrito.
Managed Identity — Sem Senhas no Seu Código
Um desenvolvedor incorpora senha na string de conexão e por engano envia esse arquivo para um repositório público. Managed Identity elimina esse risco na origem.
Managed Identity é uma identidade baseada em Entra ID atribuída automaticamente a um recurso do Azure — máquina virtual, App Service ou Azure Functions. A plataforma Azure emite e rotaciona tokens automaticamente, sem senha ou certificado no código. System-Assigned Managed Identity compartilha o ciclo de vida do seu recurso. User-Assigned pode ser compartilhada entre vários recursos. Para usar com Azure SQL, configure como administrador do Entra ID no servidor SQL, ou registre como Contained User e atribua as funções adequadas.
Comparação de Métodos de Autenticação
| Cenário | Método Recomendado | |---------|---| | App legada, mesmo modelo do SQL local | SQL Authentication | | Login com conta da organização e MFA | Entra ID Universal with MFA | | Login automático com credenciais de domínio AD local | Entra ID Integrated | | App Azure conecta ao SQL sem armazenar credenciais | Managed Identity | | Autenticação entre serviços, gerenciamento de segredos aceitável | Service Principal |
A diferença fundamental: SQL Authentication guarda credenciais no motor do banco; Entra ID as guarda no sistema de identidade central. Para alinhar o acesso ao ciclo de vida do funcionário, Entra ID authentication é o único caminho viável.
Armadilhas Comuns do Exame
Se um bibliotecário tem uma chave mestra para cada livro, isso não é privilégio mínimo. O exame DP-300 constrói armadilhas em torno de escolhas com permissões excessivas.
"Eliminar o gerenciamento de senhas SQL, usar contas da empresa" — escolha Entra ID authentication. "Todas as tabelas legíveis, sem modificações" — escolha (não ). "Delegar apenas concessão e revogação de permissões" — escolha , não (que só adiciona ou remove contas). "Conectar app Azure ao SQL sem credenciais no código" — escolha Managed Identity. falha no Azure SQL Database — PaaS remove o escopo do servidor. pode conceder permissões além das próprias, criando escalada ao nível de sysadmin.
Resumo do Exame
"Eliminar gerenciamento de senhas SQL, login com conta da empresa" -- Microsoft Entra ID authentication "App Azure conecta ao SQL sem credenciais no código" -- Managed Identity "Login automático com credenciais de domínio AD local" -- Entra ID Integrated (requer federação AD) "Login interativo com MFA" -- Universal with MFA "Mover banco de dados, autenticação intacta" -- Contained Database User "Registrar grupo do Entra ID em um banco de dados" -- CREATE USER [nome-do-grupo] FROM EXTERNAL PROVIDER "Privilégio mínimo somente leitura" -- db_datareader "Gerenciar permissões apenas, sem acesso a dados" -- db_securityadmin "Apenas adicionar ou remover contas de usuário" -- db_accessadmin "DENY sempre prevalece sobre GRANT" -- Regra de prioridade do DENY "Delegação de permissões no nível do servidor, função arriscada" -- securityadmin (efetivamente nível sysadmin) "CREATE SERVER ROLE falha no Azure SQL Database" -- PaaS, usar User-Defined Database Role
Microsoft Entra ID = ciclo de vida de identidade central, Managed Identity = sem segredos no código, Contained User = migração de BD segura, DENY = sempre vence