Questão de Segurança da Informação — Análise de Tráfego e Logs — FCC 2026

Trilhas de auditoria imutáveis e rastreabilidade de acessos

Gabarito: letra C. O redesign que atende à exigência de integridade e rastreabilidade forte é a implementação de trilhas de auditoria imutáveis e apenas de inclusão (append-only), com registros assinados digitalmente e horário sincronizado, armazenadas em repositório segregado do banco transacional. Isso porque a integridade exige que os registros não possam ser alterados ou apagados, e a rastreabilidade exige que cada acesso seja registrado de forma confiável e à prova de adulteração — exatamente o que a alternativa C descreve, alinhada aos controles da norma ISO/IEC 27001 (A.12.4.1, A.12.4.2 e A.12.4.3) e ao conceito de não repúdio.

O cenário do enunciado apresenta três problemas concretos: (1) os acessos às declarações são registrados na mesma tabela de negócio, misturando dados de auditoria com dados transacionais; (2) os registros podem ser alterados por DBAs, o que compromete a integridade; e (3) registros antigos são apagados para liberar espaço, o que destrói a rastreabilidade histórica. O redesign correto precisa atacar esses três pontos simultaneamente, sem prejudicar a disponibilidade do sistema.

A solução ideal é a trilha de auditoria imutável e append-only: um repositório separado do banco transacional, onde os registros só podem ser adicionados (nunca alterados ou excluídos), protegidos por assinatura digital (que garante autenticidade e não repúdio) e com horário sincronizado (que garante a confiabilidade da linha do tempo). Essa abordagem é amplamente reconhecida em normas e boas práticas de segurança da informação, como a ISO/IEC 27001, que exige a proteção dos logs contra acesso não autorizado e adulteração, e o registro das atividades de administradores e operadores.

A integridade é garantida pela imutabilidade dos registros: como não é possível alterar ou apagar um log, qualquer tentativa de adulteração fica evidente. A rastreabilidade é garantida pela assinatura digital e pelo horário sincronizado, que permitem identificar quem acessou o quê, quando e de onde. A disponibilidade é preservada porque os logs ficam em repositório segregado, não competindo por recursos com o banco transacional de produção.

A pegadinha desta questão está em alternativas que parecem razoáveis (como restringir permissões ou exportar logs para arquivo externo), mas que não resolvem o problema central: a possibilidade de alteração ou exclusão dos registros. A banca explora a confusão entre "auditoria nativa do SGBD" (que pode ser desativada ou ter logs alterados por DBAs) e "trilha de auditoria imutável" (que é à prova de adulteração).

Guarde o critério decisivo: a solução correta deve garantir que os registros de auditoria sejam imutáveis, à prova de adulteração e segregados do banco transacional. É exatamente nesse critério que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Restringir permissões de administrador e habilitar auditoria nativa do SGBD apenas para eventos críticos, mantendo os registros na mesma tabela de negócio, não resolve o problema de integridade. A auditoria nativa do SGBD pode ser desativada ou ter seus logs alterados por DBAs com privilégios elevados, e manter os registros na mesma tabela de negócio perpetua a mistura entre dados transacionais e de auditoria. A alternativa não garante imutabilidade nem segregação, portanto não atende à exigência de integridade e rastreabilidade forte.

Alternativa B — ❌ Incorreta

Configurar rotina de limpeza automática que exclua periodicamente os logs mais antigos destrói a rastreabilidade histórica, que é justamente o que a fiscalização pediu. A exclusão de logs antigos impede a investigação de acessos passados e viola o princípio de preservação de evidências. Embora a política de backup e restauração ajude na disponibilidade, ela não compensa a perda de integridade e rastreabilidade causada pela exclusão dos registros.

Alternativa C — ✅ Correta ⟵ GABARITO

Implementar trilhas de auditoria imutáveis e apenas de inclusão (append-only), com registros assinados digitalmente e horário sincronizado, armazenadas em repositório segregado do banco transacional, atende plenamente à exigência de integridade e rastreabilidade forte. A imutabilidade garante que os registros não possam ser alterados ou apagados; a assinatura digital garante autenticidade e não repúdio; o horário sincronizado garante a confiabilidade da linha do tempo; e a segregação do repositório preserva a disponibilidade do banco transacional. Essa é a solução alinhada às boas práticas da ISO/IEC 27001 (A.12.4.1, A.12.4.2 e A.12.4.3) e ao conceito de trilha de auditoria.

Alternativa D — ❌ Incorreta

Consolidar dados de negócio e logs em uma única tabela particionada, mesmo com triggers para impedir alterações manuais, mantém os registros no mesmo esquema lógico do banco transacional, o que não resolve a segregação necessária. Além disso, triggers podem ser desabilitados por DBAs, e a consolidação em uma única tabela não garante imutabilidade real. A alternativa não atende à exigência de rastreabilidade forte, pois os registros continuam vulneráveis a alterações e exclusões.

Alternativa E — ❌ Incorreta

Implementar um job diário que exporta os logs para arquivo externo assinado digitalmente e remove os registros antigos da base transacional compromete a rastreabilidade, pois a remoção dos registros da base transacional impede a consulta imediata e a correlação com os dados de negócio. Embora a assinatura digital ajude na integridade do arquivo exportado, a exclusão dos registros originais viola o princípio de preservação de evidências e dificulta a auditoria. A alternativa não atende à exigência de rastreabilidade forte.

A regra de ouro para esta questão: trilha de auditoria forte = imutável + assinada + segregada. Qualquer solução que permita alteração, exclusão ou mistura com dados transacionais não atende à exigência de integridade e rastreabilidade.

Gabarito: letra C