No exame DP-300, a seção de conformidade exige saber qual recurso de segurança se encaixa em cada cenário. A criptografia protege os dados, mas os órgãos reguladores exigem mais — quem consultou o quê e quando, se colunas sensíveis estão ocultas de usuários sem permissão e se algum registro foi adulterado. O Azure SQL Database aborda cada requisito em uma camada diferente.
SQL Audit — Registrar Tudo Como um Sistema de Câmeras
O SQL Audit é o equivalente a instalar câmeras de segurança no banco de dados. Cada login, consulta e modificação de dados é registrado em um log durável que pode ser apresentado como evidência durante uma auditoria de conformidade.
Uma política em nível de servidor aplica-se automaticamente a todos os bancos de dados desse servidor — útil para manter uma linha de base consistente. Uma política em nível de banco de dados restringe-se a um único banco de dados e pode ser executada junto com a política de servidor para um controle mais granular.
Os logs de auditoria podem ser enviados a três destinos: Storage Account, Log Analytics Workspace ou Event Hub. O Storage Account é adequado para retenção de longo prazo. O Log Analytics permite consultas Kusto imediatas. O Event Hub conecta eventos a pipelines de streaming em tempo real. Nos cenários do exame, "apresentar evidências a um regulador" aponta para o Storage Account; "integrar com detecção de anomalias em tempo real" aponta para o Event Hub.
Dynamic Data Masking — O Comprovante com Dados Ocultos
Quando você paga em um café, o comprovante mostra apenas os últimos quatro dígitos do cartão. O Dynamic Data Masking (DDM) funciona da mesma forma. O valor real permanece no banco de dados; usuários sem privilégio suficiente recebem uma versão mascarada na consulta.
Existem cinco tipos de regras de mascaramento. substitui números por 0, strings por X e datas por 1900-01-01. expõe a primeira letra e o sufixo do domínio. combina prefixo, bloco de X e sufixo. substitui por número aleatório num intervalo definido. exibe caracteres nas extremidades, mascarando o centro.
O ponto mais importante sobre DDM é a permissão — qualquer usuário com essa permissão vê o valor original. Administradores com db_owner também ignoram o mascaramento. DDM controla apenas a camada de apresentação. Quando um cenário exige "nem o DBA deve ver o texto simples", a resposta é Always Encrypted.
Row-Level Security — Crachás Diferentes para Cada Andar
Na sede de uma grande empresa, o crachá de vendas abre o andar de vendas, mas não o laboratório de P&D. O Row-Level Security (RLS) aplica essa ideia às linhas de um banco de dados: dois usuários consultando a mesma tabela podem receber resultados completamente diferentes com base no contexto de suas sessões.
O RLS é construído a partir de duas peças. Uma codifica a lógica de "este usuário pode ver esta linha?". Uma vincula essa função à tabela. Um remove silenciosamente linhas que não atendem à condição no SELECT. Um também impede INSERT, UPDATE e DELETE que violam a política.
O RLS é mais comum em arquiteturas SaaS multi-tenant: uma única tabela contém dados de muitos clientes, e o RLS garante que cada cliente veja apenas suas próprias linhas — sem tabelas ou views separadas por cliente.
Ledger — O Documento Reconhecido em Cartório
Um documento reconhecido em cartório não pode ser alterado após a assinatura; qualquer mudança é detectável como fraude. O Azure SQL Ledger aplica o mesmo conceito: uma cadeia de hash criptográfico protege o histórico de cada tabela ledger, e qualquer modificação fora do fluxo normal é detectada na verificação.
Existem dois tipos de tabela Ledger. Uma permite modificações, mas cada alteração é anexada a uma tabela de histórico protegida pela cadeia de hash. Uma permite apenas INSERT; UPDATE e DELETE são bloqueados. Quando o exame menciona "detecção de adulteração" ou "prova criptográfica de integridade", Ledger é a resposta.
Defender for SQL — O Segurança na Portaria
Um segurança na entrada de uma fábrica percebe padrões incomuns de acesso e reporta imediatamente. O Microsoft Defender for SQL analisa padrões de consulta e comportamento de acesso para identificar atividades anômalas automaticamente.
O Defender for SQL tem duas capacidades. O verifica configurações incorretas, privilégios excessivos e vulnerabilidades sem correção, fornecendo orientação de remediação. O gera alertas para tentativas de injeção SQL, logins de localizações incomuns e ataques de força bruta. Se o SQL Audit é "registrar o que aconteceu", o Defender for SQL é "alertar quando algo parece suspeito."
Comparando os Controles de Segurança
O Always Encrypted é frequentemente comparado ao DDM: o DDM armazena o texto simples e apenas mascara a saída, enquanto o Always Encrypted faz com que o próprio servidor nunca descriptografe os dados — apenas o cliente com a chave de criptografia pode ler o texto simples.
Para referência rápida: o SQL Audit registra o histórico de acesso sem bypass (evidência de conformidade). O DDM oculta o valor exibido, mas pode ser contornado com UNMASK (ocultar colunas sensíveis). O RLS restringe o acesso a linhas, mas db_owner o ignora (isolamento multi-tenant). O Always Encrypted não pode ser contornado sem a chave do cliente (servidor nunca vê o texto simples). O Ledger detecta adulterações imediatamente (prova de imutabilidade criptográfica).
!Comparação de 4 controles de proteção de dados
Armadilhas Práticas — Bypass e Design em Camadas
O DDM não oferece proteção quando um DBA se conecta diretamente pelo SQL Server Management Studio — o mascaramento não se aplica. O RLS também não se aplica ao db_owner. Quando um cenário afirma "mesmo os administradores não devem acessar o texto simples", Always Encrypted é a resposta obrigatória.
O Ledger se especializa em detecção de adulterações, mas não fornece controle de acesso. Combiná-lo com SQL Audit oferece registro imutável e log de quem escreveu. O Defender for SQL é um serviço de detecção de ameaças, não de mascaramento ou bloqueio de acesso. O Data Discovery & Classification rotula automaticamente colunas sensíveis, alimentando regras DDM e políticas de auditoria.
Resumo do Exame
"Registrar quem executou qual consulta e quando" -- SQL Audit "Retenção de longo prazo de logs de auditoria para reguladores" -- destino Storage Account "Transmitir eventos de auditoria para um pipeline em tempo real" -- destino Event Hub "Mostrar apenas parte do número do cartão para usuários do app" -- Dynamic Data Masking "Nem o DBA deve ver o texto simples" -- Always Encrypted "Mesma tabela, mas cada departamento vê apenas suas próprias linhas" -- Row-Level Security (FILTER predicate) "Permitir inserções mas bloquear atualizações e exclusões" -- Append-only ledger table "Provar matematicamente que nenhum registro histórico foi adulterado" -- Azure SQL Ledger "Detecção em tempo real de tentativas de injeção SQL" -- Defender for SQL (Advanced Threat Protection) "Verificar configurações incorretas e permissões excessivas" -- SQL Vulnerability Assessment "Descobrir e rotular automaticamente colunas sensíveis" -- Data Discovery & Classification "Isolar dados de clientes em uma tabela multi-tenant" -- Row-Level Security
SQL Audit = registrar, DDM = mascaramento de exibição, RLS = isolamento de linhas, Ledger = prova de integridade, Defender = detecção de ameaças