APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Dynamic data masking modifica a apresentação de valores para certos utilizadores, mas não equivale a cifragem nem impede toda a inferência por consultas ad hoc. Uma política RLS pode filtrar linhas segundo identidade ou contexto de sessão. Se usa tenant_id fornecido por middleware, esse valor deve vir de identidade validada e ser estabelecido corretamente antes das operações. Um formulário não pode escolher livremente o âmbito de outro cliente. Testa os caminhos de acesso relevantes, incluindo contas privilegiadas e extração de dados, em vez de assumir que o filtro da interface é suficiente. Privilégio mínimo continua necessário mesmo quando existem masking e RLS.
Aplicação guiada
Numa análise externa fictícia, entrega apenas os atributos e operações autorizados e regista acessos relevantes. Auditoria de segurança, change tracking e história de desempenho respondem a perguntas diferentes: alterações de linhas não fornecem automaticamente o trilho de quem fez SELECT. SQL ledger acrescenta evidência contra adulteração, apoiada em digests guardados num destino fiável fora da base. Se a mesma conta puder alterar os dados e a referência de hashes, a verificação perde independência. Ledger também não transforma um input errado em verdade de negócio. Define retenção, responsáveis e processo de verificação, e usa reconciliação para ligar os eventos técnicos à origem funcional.
Uma política RLS baseada em contexto não é segura se o cliente puder fornecer o tenant_id de outra organização sem validação.
Armadilhas comuns
Masking como segredo; contexto não validado; change tracking como auditoria de leitura; digest modificável pelo mesmo atacante.
Tópicos relacionados: Plataforma, capacidade e migração · Identidade, rede e cifragem · Query Store e concorrência
Protege acesso, contexto e referências de evidência separadamente.
Referência: Masking limitations · DP-300 English objectives effective 2026-04-24