Um Ministério Público identificou que usuários com perfis de consulta ampla estão acessando colunas sensíveis de tabelas de réus, como endereços e dados bancários, sem necessidade. Além disso, há o risco de alterações indevidas em tabelas de prazos processuais que não deixam rastros. A administração de dados precisa aplicar camadas de segurança lógica que garantam o menor privilégio, a integridade das transações e uma redundância controlada de logs de acesso para auditoria, sem degradar a performance do sistema judicial. A abordagem técnica que assegura o controle de acesso e a integridade das informações sensíveis é
Acentralizar a lógica de segurança em triggers de validação de sistema, proibindo o uso de views em tabelas críticas e mantendo a redundância de dados em procedures de sincronismo manual.
Bimplementar triggers de auditoria para monitorar o DML em tempo real, utilizando views materializadas para espelhar dados sigilosos em esquemas de acesso público de baixa latência.
Cconfigurar procedures para inserção de dados, desabilitando o uso de views e delegando a redundância controlada a backups lógicos diários realizados em janelas de manutenção.
Dutilizar views para restringir a visibilidade de colunas, procedures para encapsular a lógica de escrita e triggers para alimentar tabelas de auditoria para controle de eventos.
Eestabelecer redundância controlada via triggers de replicação, utilizando views com permissão de escrita direta (updatable) e procedures de limpeza automática de logs de segurança antigos.
Revelar gabarito e comentário▾
GabaritoD — utilizar views para restringir a visibilidade de colunas, procedures para encapsular a lógica de escrita e triggers para alimentar tabelas de auditoria para controle de eventos.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Segurança em Banco de Dados: Views, Procedures e Triggers
Gabarito: letra D. A abordagem que assegura controle de acesso e integridade das informações sensíveis combina views para restringir a visibilidade de colunas, procedures para encapsular a lógica de escrita e triggers para alimentar tabelas de auditoria — exatamente o que a alternativa D descreve. Essa combinação atende aos três requisitos do enunciado: menor privilégio (views), integridade das transações (procedures) e rastreabilidade (triggers de auditoria).
O problema apresentado tem três frentes distintas, e cada uma exige um mecanismo específico do banco de dados relacional. A primeira é o controle de acesso: usuários com perfil de consulta ampla não deveriam enxergar colunas sensíveis como endereços e dados bancários. A segunda é a integridade das transações: alterações em tabelas de prazos processuais precisam ser feitas de forma controlada e consistente. A terceira é a auditoria: toda alteração deve deixar rastro para que se saiba quem fez o quê e quando.
Para a primeira frente, a view é a ferramenta clássica. Uma view é uma tabela virtual, derivada de uma ou mais tabelas base, que apresenta apenas um subconjunto das colunas e/ou linhas. Ao conceder acesso à view em vez da tabela original, o administrador esconde as colunas sensíveis — o usuário simplesmente não as enxerga, pois elas não fazem parte da definição da view. Isso implementa o princípio do menor privilégio: cada usuário vê apenas o que precisa ver. O material de apoio confirma que "o uso de visão em banco de dados é uma forma de aumentar a sua segurança, pois impede o acesso direto aos dados de uma tabela, fornecendo somente os dados considerados necessários".
Para a segunda frente, as procedures (ou stored procedures) encapsulam a lógica de escrita. Em vez de o usuário executar diretamente um INSERT, UPDATE ou DELETE na tabela, ele chama uma procedure que valida os dados, aplica regras de negócio e executa a operação de forma controlada. Isso garante que todas as alterações passem por um ponto único de verificação, preservando a integridade das transações. O usuário pode ter permissão de executar a procedure sem ter permissão direta de escrita na tabela — mais uma camada de controle.
Para a terceira frente, as triggers são o mecanismo de auditoria. Uma trigger é um procedimento que é executado automaticamente em resposta a eventos de DML (INSERT, UPDATE, DELETE) em uma tabela. Ao criar uma trigger que registra em uma tabela de auditoria o usuário, a data, o tipo de operação e os valores antigos/novos, toda alteração fica documentada. Isso resolve o problema de "alterações indevidas que não deixam rastros".
A combinação desses três mecanismos é a abordagem técnica correta. As alternativas incorretas falham por propor combinações que violam princípios de segurança ou criam problemas de performance e consistência. A pegadinha central é que a banca mistura mecanismos válidos com práticas inadequadas — como usar views materializadas para espelhar dados sigilosos em esquemas públicos, ou desabilitar views em tabelas críticas. O critério decisivo é: cada mecanismo deve ser usado para o fim a que se destina, sem criar novas vulnerabilidades.
Segurança em Banco de Dados
1Controle de acesso (menor privilégio)
Views
Restringem colunas sensíveis
2Integridade das transações
Procedures
Encapsulam lógica de escrita
3Auditoria (rastreabilidade)
Triggers
Alimentam tabelas de auditoria
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Centralizar a lógica de segurança em triggers de validação e proibir o uso de views em tabelas críticas é um erro. As views são justamente o mecanismo mais adequado para restringir a visibilidade de colunas sensíveis — proibi-las elimina a principal ferramenta de controle de acesso. Além disso, "redundância de dados em procedures de sincronismo manual" é uma prática arcaica e propensa a erros: a redundância controlada deve ser feita pelo SGBD, não manualmente. A alternativa contraria o princípio do menor privilégio ao remover a camada de views.
Alternativa B — ❌ Incorreta
A alternativa acerta ao mencionar triggers de auditoria, mas erra gravemente ao propor views materializadas para espelhar dados sigilosos em esquemas de acesso público de baixa latência. Espelhar dados sigilosos em um esquema público é uma violação direta da segurança — é exatamente o oposto do que se deseja. Views materializadas são tabelas físicas que armazenam o resultado de uma consulta; usá-las para duplicar dados sensíveis em um local de acesso amplo multiplica a superfície de exposição. A redundância controlada de logs para auditoria não tem relação com espelhar dados em esquemas públicos.
Alternativa C — ❌ Incorreta
Configurar procedures para inserção de dados é válido, mas desabilitar o uso de views novamente é um erro — as views são essenciais para o controle de acesso. Além disso, delegar a redundância controlada a "backups lógicos diários" não atende ao requisito de auditoria em tempo real: backups são para recuperação de desastres, não para rastrear alterações individuais. A alternativa ignora o mecanismo de auditoria (triggers) e remove a camada de visibilidade restrita (views).
Alternativa D — ✅ Correta ⟵ GABARITO
Esta alternativa descreve exatamente a combinação correta: views para restringir a visibilidade de colunas (controle de acesso), procedures para encapsular a lógica de escrita (integridade das transações) e triggers para alimentar tabelas de auditoria (rastreabilidade). Cada mecanismo atende a um requisito específico do enunciado, sem criar vulnerabilidades adicionais. As views escondem as colunas sensíveis, as procedures garantem que as alterações passem por validação, e as triggers registram cada evento para auditoria. É a abordagem tecnicamente correta e alinhada às boas práticas de segurança em bancos de dados relacionais.
Alternativa E — ❌ Incorreta
A alternativa propõe "redundância controlada via triggers de replicação" — conceito confuso, pois triggers não são o mecanismo adequado para replicação (isso é função de replicação do SGBD). Mais grave: views com permissão de escrita direta (updatable) permitiriam que usuários alterassem dados diretamente pela view, contornando a lógica de validação das procedures — exatamente o que se quer evitar. E "procedures de limpeza automática de logs de segurança antigos" é uma prática perigosa: logs de auditoria devem ser preservados, não apagados automaticamente, sob risco de perder evidências de alterações indevidas.
A combinação correta é a da letra D: views para esconder colunas sensíveis, procedures para controlar a escrita e triggers para auditar eventos. Essa tríade atende simultaneamente ao menor privilégio, à integridade e à rastreabilidade, sem degradar a performance — pois views e procedures são mecanismos leves, e triggers de auditoria podem ser otimizados para não impactar significativamente as operações.
NÃO CAIA NESSA!
A banca tenta confundir o candidato misturando mecanismos válidos com práticas inadequadas. A alternativa B, por exemplo, acerta ao mencionar triggers de auditoria, mas erra ao propor espelhar dados sigilosos em esquemas públicos — uma violação flagrante de segurança. A alternativa E erra ao permitir escrita direta via views updatable, o que contornaria a lógica de validação. O candidato deve identificar qual combinação usa cada mecanismo para o fim correto: views para restringir visibilidade, procedures para encapsular escrita e triggers para auditar.
PEGA ESSA DICA!
Para questões de segurança em banco de dados, monte mentalmente a tríade: controle de acesso → views; integridade de escrita → procedures; auditoria → triggers. Se a alternativa propõe usar um mecanismo para uma função que não é a dele (ex.: views para replicação, triggers para backup), está incorreta. Essa associação direta resolve a maioria das questões do tema.