Analista Legislativo - Analista de Segurança da Informação
Um analista de segurança da informação do Ministério da Fazenda é responsável por proteger um banco de dados corporativocom informações fiscais e cadastrais de milhões de contribuintes, incluindo CPF, renda, endereços e dados bancários. O SGBDutilizado é um banco de dados relacional moderno, com acesso simultâneo de aplicações web internas, sistemas legados eequipes de suporte que realizam consultas administrativas diretamente via SQL. O analista identificou os seguintes requisitosobrigatórios: 1. Garantir que usuários de suporte vejam apenas os 4 primeiros dígitos do CPF em consultas diretas, mantendo o valorcompleto apenas para aplicações autorizadas. 2. Proteger os dados armazenados em disco contra acesso físico não autorizado ao storage. A infraestrutura atual conta apenas com a autenticação nativa do SGBD (usuário e senha) e permissões básicas(GRANT/REVOKE). Não hả qualquer mecanismo de ofuscação ou criptografia implementado. Considerando esse cenário e as boas práticas de segurança em SGBDs, a solução mais adequada que o analista deveimplementar consiste em
Ausar criptografia de coluna usando AES-256 configurada estaticamente via stored procedures, e mascaramento de CPFnas telas da aplicação (não no banco).
Bsubstituir o banco de dados relacional por um SGBD NoSQL que ofereça criptografia nativa, e utilizar ofuscação estáticade CPF via funções de hash irreversíveis.
Cmascaramento estático de dados (Static Data Masking) aplicar uma única vez sobre a coluna CPF, e criptografia de discofull-disk no storage.
Dusar criptografia em nível de aplicação (antes de enviar ao banco) para todos os dados sensíveis, e visões para controlar oacesso ao CPF.
Eusar criptografia transparente de dados (TDE) para proteger os dados em disco, e mascaramento dinâmico de dados paraofuscar o CPF conforme o perfil do usuário.
Revelar gabarito e comentário▾
GabaritoE — usar criptografia transparente de dados (TDE) para proteger os dados em disco, e mascaramento dinâmico de dados para
ofuscar o CPF conforme o perfil do usuário.
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 SGBDs: TDE e Mascaramento Dinâmico
Gabarito: letra E. A combinação de Transparent Data Encryption (TDE) para proteção em repouso com Dynamic Data Masking (DDM) para ofuscação seletiva por perfil de usuário atende simultaneamente os dois requisitos: proteger os dados em disco contra acesso físico (TDE) e limitar a visualização do CPF a apenas os 4 primeiros dígitos para usuários de suporte (DDM), sem necessidade de alterações nas aplicações.
A banca testa o conhecimento das técnicas de segurança em banco de dados relacionais, especialmente a diferença entre criptografia (proteção em repouso) e mascaramento (ofuscação em consultas). Analisemos cada alternativa:
Técnica
Requisito atendido
Transparência para aplicações
Efeito sobre o dado original
TDE (Transparent Data Encryption)
Proteção em disco (requisito 2)
Sim (automática, sem alteração nas aplicações)
Criptografa o dado em repouso, mantendo-o íntegro para consultas
DDM (Dynamic Data Masking)
Ofuscação seletiva por perfil (requisito 1)
Sim (aplicada na camada do banco, sem alteração nas aplicações autorizadas)
Mascara o dado na consulta, sem alterar o valor armazenado
Alternativa A — ❌ Incorreta
A criptografia de coluna com AES-256 via stored procedures não é transparente (exige alteração nas aplicações para decodificar) e o mascaramento apenas nas telas da aplicação não impede que usuários de suporte vejam o CPF completo em consultas SQL diretas (requisito 1).
Alternativa B — ❌ Incorreta
Substituir o SGBD relacional por NoSQL é desproporcional e inviável para um sistema corporativo consolidado. Além disso, ofuscação estática via hash irreversível impede a recuperação do dado original para aplicações autorizadas.
Alternativa C — ❌ Incorreta
O mascaramento estático (Static Data Masking) é aplicado uma única vez e altera permanentemente o dado, inviabilizando que aplicações autorizadas vejam o CPF completo. A criptografia full-disk atende o requisito 2, mas de forma menos integrada que o TDE (não criptografa apenas os dados do banco).
Alternativa D — ❌ Incorreta
Criptografia em nível de aplicação exige que todas as aplicações gerenciem chaves e decodifiquem os dados, quebrando a transparência. Visões podem ajudar no controle de acesso, mas se os dados estão criptografados, as visões mostrariam apenas o ciphertext, não o valor parcial.
Alternativa E — ✅ Correta ⟵ GABARITO
O TDE criptografa automaticamente os dados em disco (data-at-rest) sem alterar o esquema ou as aplicações. O Dynamic Data Masking permite definir regras de mascaramento na própria definição da coluna (ex.: mostrar apenas os 4 primeiros dígitos do CPF para usuários sem permissão especial). Dessa forma, usuários de suporte veem o CPF mascarado em consultas diretas, enquanto aplicações autorizadas acessam o valor real — exatamente o que os requisitos pedem.
PEGA ESSA DICA!
Grave bem a diferença: TDE protege o dado armazenado (em repouso), DDM protege o dado em exibição (em consultas). Ambos são recursos nativos dos SGBDs modernos (SQL Server, Oracle, PostgreSQL) e frequentemente cobrados em concursos.