O conteúdo oficial atual do DP-900 não traz segurança como um item separado. Mesmo assim, as unidades do Microsoft Learn sobre Azure SQL, Azure Storage e Azure Cosmos DB apresentam recursos de segurança como criptografia, Microsoft Defender for SQL, auditoria e autenticação com Microsoft Entra ID, e bancos de questões de prática e materiais antigos continuam perguntando sobre regras de firewall do SQL, mascaramento dinâmico de dados e Always Encrypted. Segurança não pesa muito na prova, mas este post reúne o básico para que essas perguntas não derrubem você.
Este post é um complemento de Tipos de instruções SQL da nossa série de estudos do DP-900. Ele amplia o assunto de controle de acesso que começou lá com DCL (GRANT e REVOKE) e percorre, nesta ordem, os três estados dos dados, a defesa em camadas, os recursos de segurança do Azure SQL Database e a autenticação e a criptografia no Azure Storage e no Cosmos DB.
---
Os três estados dos dados e como protegê-los
Pense em como o dinheiro em espécie é protegido. Ele é guardado de um jeito no cofre, de outro no carro-forte e de outro enquanto é contado no caixa. Os dados também têm três estados, em repouso, em trânsito e em uso, e cada um precisa de uma proteção diferente.
| Estado | Significado | Proteção no Azure | |------|------|------| | Em repouso (at rest) | Dados guardados em discos e backups | TDE no Azure SQL, criptografia do serviço Azure Storage (SSE), criptografia padrão do Cosmos DB | | Em trânsito (in transit) | Dados passando pela rede | TLS (HTTPS), a opção de transferência segura obrigatória nas contas de armazenamento | | Em uso (in use) | Dados sendo consultados ou processados | Always Encrypted (incluindo enclaves seguros); mascaramento dinâmico de dados para limitar a exposição |
A maioria dos serviços de dados do Azure já vem com a criptografia em repouso ativada por padrão. O Azure Storage aplica criptografia AES de 256 bits a todas as contas de armazenamento e ela não pode ser desativada, e o Cosmos DB também criptografa os dados em repouso por padrão.
Dica de prova: "Criptografar arquivos de banco de dados e backups em disco sem alterar o aplicativo" → TDE (em repouso). "Proteger os dados que passam pela rede" → TLS (em trânsito).
---
Bloquear camada por camada: defesa em profundidade
Para entrar em um castelo, é preciso atravessar o fosso, ser identificado no portão e só entrar nas salas permitidas. Se uma camada cai, a próxima ainda segura; essa abordagem se chama defesa em profundidade. Uma solicitação que tenta chegar aos dados passa, em sequência, pelas camadas de rede, autenticação, autorização e proteção de dados.
!Camadas de segurança que uma solicitação cruza até os dados
| Camada | Pergunta que faz | Recursos típicos | |------|------|------| | Rede | De onde vem a conexão? | Regras de firewall, redes virtuais, endpoints privados | | Autenticação | Quem é você? | Microsoft Entra ID, autenticação SQL, chaves de acesso | | Autorização | O que você pode fazer? | RBAC do Azure, GRANT/DENY/REVOKE, SAS, ACLs | | Proteção de dados | Como os próprios dados são protegidos? | TDE, TLS, Always Encrypted, mascaramento dinâmico de dados | | Monitoramento | Aconteceu algo estranho? | Auditoria, Microsoft Defender for SQL e for Storage |
Dois princípios valem em todas as camadas. O privilégio mínimo é conceder só as permissões de que o trabalho realmente precisa. A Confiança Zero (Zero Trust) segue três princípios, "verificar explicitamente, usar acesso com privilégio mínimo e presumir a violação", para que nem a rede interna seja considerada confiável automaticamente.
Dica de prova: "Dar ao autor de relatórios só permissão de leitura" → privilégio mínimo. "Proteger com várias camadas em vez de depender de um único controle de segurança" → defesa em profundidade.
---
Segurança do Azure SQL Database
Regras de firewall: nível de servidor vs nível de banco de dados
Quando você cria um novo servidor lógico, o firewall de nível de servidor bloqueia todas as conexões ao endpoint público. Só é possível conectar depois de adicionar regras para os intervalos de endereços IP que você quer permitir.
| Aspecto | Regras de firewall de IP no nível do servidor | Regras de firewall de IP no nível do banco de dados | |------|------|------| | Escopo | Todos os bancos do servidor lógico | Um banco específico | | Como configurar | Portal do Azure, PowerShell, T-SQL | Só com T-SQL (sp_set_database_firewall_rule) | | Onde ficam | No banco de dados master | No próprio banco de dados | | Ordem de avaliação | Quando nenhuma regra do nível do banco corresponde | Verificadas primeiro |
Ativar a opção "Permitir que serviços e recursos do Azure acessem este servidor" libera conexões vindas de outros serviços do Azure e conta como uma única regra de firewall do servidor. Para não passar pela internet pública de jeito nenhum, use regras de rede virtual ou endpoints privados.
Autenticação e recursos de proteção de dados
O Azure SQL suporta tanto a autenticação SQL, em que você entra com nome de usuário e senha, quanto a autenticação do Microsoft Entra, que gerencia de forma centralizada as contas da organização e suporta logon único. Além disso, os recursos a seguir protegem os dados.
| Recurso | O que faz | O que lembrar | |------|------|------| | TDE (criptografia de dados transparente) | Criptografa em tempo real, em repouso, o banco de dados, os backups e o log de transações | Ativada por padrão nos novos bancos do Azure SQL; sem mudanças no aplicativo | | Always Encrypted | O driver do cliente criptografa as colunas sensíveis antes de enviá-las | As chaves nunca são expostas ao mecanismo do banco, então nem os DBAs veem o texto puro | | Mascaramento dinâmico de dados | Oculta valores sensíveis nos resultados das consultas para usuários sem privilégio | Os dados armazenados não mudam | | Segurança em nível de linha | Limita quais linhas cada usuário pode ver | Por exemplo, cada vendedor vê só os clientes da sua região | | Auditoria | Registra os eventos do banco em um log de auditoria | Conformidade e identificação de atividades incomuns | | Microsoft Defender for SQL | Avaliação de vulnerabilidades mais Advanced Threat Protection | Detecta e alerta sobre ataques de injeção de SQL e padrões de acesso anômalos |
Dica de prova: "A equipe da central de atendimento deve ver só parte do endereço de e-mail" → mascaramento dinâmico de dados. "Nem o administrador do banco pode ver os números de documento em texto puro" → Always Encrypted. "Detectar e alertar sobre tentativas de injeção de SQL" → Microsoft Defender for SQL. "Permitir conexões a um único banco só a partir do IP de um escritório, configurado com T-SQL" → regra de firewall no nível do banco de dados.
---
Segurança do Azure Storage e do Cosmos DB
Azure Storage
Os dados do Azure Storage são criptografados automaticamente em repouso com AES de 256 bits, e essa criptografia não pode ser desligada. As chaves gerenciadas pela Microsoft são o padrão, e chaves gerenciadas pelo cliente podem ser usadas no Blob Storage e no Azure Files quando necessário. O acesso aos dados é concedido das formas a seguir.
| Método | Características | Recomendação | |------|------|------| | Microsoft Entra ID + RBAC do Azure | Atribui funções a usuários e identidades gerenciadas; sem chaves no código | Recomendado pela Microsoft | | Chave compartilhada (chave de acesso da conta) | Permissões totais sobre a conta inteira | Alto risco de exposição; evite sempre que possível | | Assinatura de acesso compartilhado (SAS) | Um token delegado limitado em tempo, permissões e escopo | Se usar, a SAS de delegação de usuário é a recomendada | | ACLs (Data Lake Gen2) | Permissões POSIX por arquivo e pasta | Com o namespace hierárquico |
Do lado da rede, firewalls de armazenamento, regras de rede virtual e endpoints privados estreitam os caminhos de acesso, e a opção de transferência segura obrigatória só permite HTTPS. O Microsoft Defender for Storage detecta ameaças como acessos incomuns e upload de arquivos maliciosos.
Azure Cosmos DB
O Cosmos DB também criptografa os dados em repouso por padrão. Os dados podem ser acessados com as chaves da conta (primária e secundária), mas a Microsoft recomenda aplicar o privilégio mínimo com o controle de acesso baseado em funções do plano de dados do Microsoft Entra ID e com identidades gerenciadas. Se você precisar continuar usando chaves, faça a rotação delas regularmente; a configuração recomendada é desativar o acesso pela rede pública e usar apenas endpoints privados.
Dica de prova: "Compartilhar um contêiner somente leitura com um parceiro externo temporário por sete dias" → SAS. "Fazer um aplicativo acessar o armazenamento sem chaves" → identidade gerenciada + RBAC do Azure. "A criptografia de uma conta de armazenamento pode ser desligada?" → Não.
---
Pratique com cenários
Decida sua resposta primeiro e depois confira as colunas da direita.
| Situação | Resposta | Por quê | |------|------|------| | Os PCs do escritório não conseguem se conectar a um servidor lógico do Azure SQL recém-criado | Adicionar uma regra de firewall de nível de servidor para o IP do escritório | Todas as conexões públicas são bloqueadas por padrão | | Os desenvolvedores que consultam o banco de produção só podem ver os quatro últimos dígitos dos cartões | Mascaramento dinâmico de dados | Oculta os resultados e os valores guardados não mudam | | Nem os operadores da nuvem podem ver a coluna de salários | Always Encrypted | As chaves nunca são expostas ao mecanismo do banco | | Criptografar arquivos do banco e backups sem alterar o aplicativo | TDE | Criptografia em repouso em tempo real, ativada por padrão | | Cada vendedor consulta só os pedidos da sua região | Segurança em nível de linha | Filtro de linhas por usuário | | Detectar e alertar sobre logins incomuns e tentativas de injeção de SQL | Microsoft Defender for SQL | Advanced Threat Protection | | Permi