A seção de proteção de dados do exame DP-300 pergunta qual recurso defende contra qual ameaça. Criptografia em repouso, criptografia em trânsito, criptografia do lado do cliente e isolamento de rede abordam vetores de ataque distintos. O gerenciamento de chaves e a visibilidade do DBA variam entre esses recursos, e o exame explora essas diferenças por meio de cenários.
TDE — Guardando os dados em um cofre
Imagine que um invasor entra fisicamente na sala de servidores e sai com um disco rígido. Se ele conectar esse disco a outra máquina, conseguirá ler os arquivos de dados? O Transparent Data Encryption (TDE) existe exatamente para impedir esse cenário.
O TDE criptografa automaticamente os arquivos de dados, arquivos de log e arquivos de backup em nível de página dentro do Azure SQL Database. Não são necessárias alterações no código da aplicação e o impacto no desempenho é mínimo. No Azure SQL Database, o TDE está habilitado por padrão. Na configuração padrão, o Azure gerencia a chave de criptografia usando um Service-Managed Key. Se os requisitos de conformidade exigirem que sua equipe controle a chave, é possível armazenar sua própria chave no Azure Key Vault — abordagem chamada Customer-Managed Key (CMK) ou Bring Your Own Key (BYOK). Com CMK, a equipe de operações controla rotação e revogação da chave. A exclusão da chave bloqueia o acesso ao banco de dados imediatamente.
Always Encrypted — Um envelope lacrado
Agora imagine que a ameaça não é um atacante externo, mas alguém que comprometeu uma conta de DBA. O TDE impede que alguém saia com um disco físico, mas não evita que uma consulta legítima retorne dados em texto simples a um usuário privilegiado. O Always Encrypted preenche essa lacuna.
Com o Always Encrypted, o driver do cliente criptografa os dados antes de enviá-los ao servidor. O Azure SQL Database armazena e consulta apenas os valores criptografados; a chave de descriptografia nunca sai do lado do cliente. Mesmo que um DBA execute um SELECT direto, ele verá apenas bytes criptografados.
Dois tipos de criptografia estão disponíveis. Deterministic significa que o mesmo texto simples sempre produz o mesmo texto cifrado — comparações de igualdade (), GROUP BY e JOIN funcionam, mas ataques de análise de frequência são possíveis. Randomized significa que o mesmo texto simples produz texto cifrado diferente a cada vez, oferecendo maior segurança, mas sem possibilidade de busca ou ordenação. O Always Encrypted with Secure Enclaves executa a descriptografia dentro de um ambiente de execução confiável (TEE) no servidor, permitindo consultas de intervalo (, ) mesmo em colunas Randomized.
Criptografia em trânsito — TLS e strings de conexão
Assim como você não gostaria que alguém lesse seu PIN bancário por cima do seu ombro, o tráfego entre um cliente e um servidor de banco de dados deve ser criptografado para protegê-lo contra espionagem na rede.
O Azure SQL Database impõe TLS 1.2 ou superior por padrão. Definir na string de conexão faz com que todos os dados trafeguem por um canal criptografado. Manter — o padrão — significa que o cliente valida o certificado do servidor, protegendo contra ataques de intermediário. Alguns desenvolvedores alteram esse valor para ao usar certificados autoassinados localmente. Esse hábito nunca deve chegar à produção, pois desabilita a validação do certificado.
Isolamento de rede — Private Link e Private Endpoint
Se o objetivo é bloquear todo o acesso roteado pela internet pública, a criptografia por si só não é suficiente. Um edifício com entrada monitorada e portas controladas por crachá é intrinsecamente mais seguro do que um onde qualquer pessoa pode entrar no lobby.
O Private Link e o Private Endpoint dão ao Azure SQL Database um endereço IP privado dentro de uma VNet. É possível desabilitar o endpoint público completamente, e todo o tráfego trafega apenas pela rede backbone da Microsoft. Após configurar um Private Endpoint, definir a regra de firewall para negar o acesso público torna o banco de dados inacessível de fora da VNet. O Azure SQL Managed Instance integra-se a uma VNet por padrão, sem endpoint público desde o início.
TDE versus Always Encrypted — Qual é a diferença real
Ambos os recursos são chamados de criptografia, mas defendem contra ameaças diferentes e operam em camadas distintas.
| Dimensão | TDE | Always Encrypted | |:--|:--|:--| | Onde ocorre a criptografia | Servidor (camada de armazenamento) | Driver do cliente | | Proprietário da chave | Azure ou equipe de operações (CMK) | Equipe de aplicação | | Visibilidade do DBA | Pode consultar texto simples | Vê apenas texto cifrado | | Capacidade de consulta | Sem restrições | Apenas consultas de igualdade com Deterministic | | Ameaça principal | Roubo de mídia física, vazamento de backups | Ameaça interna privilegiada |
Os dois recursos não são mutuamente exclusivos. Uma configuração típica de produção aplica TDE para proteção ampla em repouso e depois adiciona Always Encrypted nas colunas mais sensíveis, como números de CPF ou cartão de crédito.
!TDE vs Always Encrypted
Escopo de criptografia e gerenciamento de chaves — Como escolher
Fechar toda a casa e ter um cofre pessoal dentro são dois níveis de proteção diferentes. O TDE é como fechar a casa toda; o Always Encrypted é o cofre pessoal lá dentro. Usar os dois significa que nem um atacante externo nem um administrador interno conseguirá ler os dados mais sensíveis sem criptografia.
O Customer-Managed Key do TDE integra-se ao Azure Key Vault e dá à equipe de operações controle total sobre o ciclo de vida da chave. A chave mestra de coluna do Always Encrypted pertence à equipe de aplicação, não à equipe de administração do banco de dados. Essa separação na propriedade das chaves define claramente as responsabilidades quando os dois recursos são implantados juntos.
Cenários armadilha — O que o exame costuma perguntar
"O DBA não deve conseguir ler os valores da coluna nem com uma consulta direta." — A resposta é Always Encrypted, não TDE. O TDE não restringe o acesso para usuários autenticados.
"A política da empresa exige que a equipe gerencie suas próprias chaves de criptografia." — Use TDE com Customer-Managed Key (BYOK) com respaldo do Azure Key Vault. O Service-Managed Key não satisfaz esse requisito.
"Um arquivo de backup foi vazado e não deve expor dados." — O TDE criptografa arquivos de backup, portanto a resposta correta é TDE. O Always Encrypted não protege diretamente os arquivos de backup.
"Bloquear todo roteamento público para o banco de dados." — Use Private Endpoint ou Azure SQL Managed Instance. O TLS protege o canal; o Private Link remove o caminho público completamente.
Resumo do Exame
"Criptografar dados em repouso, sem mudanças no código" -- TDE "Arquivos de backup e log criptografados automaticamente" -- TDE "Chave autogerenciada, integração com Azure Key Vault" -- Customer-Managed Key (BYOK) "DBA não pode ler texto simples, criptografia do lado do cliente" -- Always Encrypted "Comparação de igualdade possível, risco de análise de frequência" -- criptografia Deterministic "Não pode ser pesquisada, segurança máxima" -- criptografia Randomized "Consultas de intervalo e LIKE em colunas Randomized" -- Always Encrypted with Secure Enclaves "Criptografia em trânsito, validação de certificado" -- TLS 1.2+, Encrypt=true "Bloquear endpoint público, endereço IP privado" -- Private Link / Private Endpoint "Integração com VNet por padrão, sem endpoint público" -- Azure SQL Managed Instance "Defesa contra roubo de mídia física" -- TDE "Defesa contra ameaças internas privilegiadas" -- Always Encrypted
TDE = bloqueio na camada de armazenamento, Always Encrypted = lacre do lado do cliente, TLS = proteção do canal de trânsito, Private Link = remoção do acesso público.