Trilha de auditoria incompleta em sistema de folha e risco de fraude
Durante auditoria de um sistema de folha de pagamento de um órgão com 9.400 servidores, a equipe descobre que o módulo de logs registra apenas acessos bem-sucedidos, sem registrar alterações de dados, e que a retenção é de 30 dias. O banco de dados usa uma conta de aplicação com permissão de escrita em todas as tabelas, compartilhada por três sistemas. Existem 214 usuários com perfil de administrador, dos quais 38 estão lotados em unidades de negócio, e não há revisão periódica de acessos. A equipe identificou 17 registros de pagamento alterados fora do horário comercial, mas não é possível saber por quem, pois o log não guarda identificação de usuário em alterações. O gestor afirma que o sistema é seguro porque usa autenticação com senha e que os logs são 'detalhe operacional'.
1. Como a equipe deve avaliar o risco e quais testes pode executar mesmo sem trilha de auditoria confiável?
Read the worked answer
A ausência de trilha de auditoria de alterações é falha grave de controle, não detalhe operacional: sem registro de quem alterou o quê e quando, não há como responsabilizar, detectar fraude ou reconstruir eventos. A retenção de 30 dias e o registro apenas de acessos bem-sucedidos agravam o quadro, pois apagam evidência e ignoram tentativas falhas, que são indicador relevante de ataque.
Mesmo sem logs confiáveis, a equipe pode testar por análise de dados: comparar a folha atual com a do mês anterior e isolar inclusões, exclusões e variações de rubrica; cruzar pagamentos com cadastro de servidores, lotação e situação funcional; verificar pagamentos a contas bancárias de titulares distintos do beneficiário; examinar os 17 registros alterados fora do horário e reconstruir a cadeia de aprovação por documentos e e-mails. Pode também confrontar a conta de aplicação compartilhada com o inventário de sistemas e verificar se há conexões diretas ao banco fora da aplicação.
O achado deve afirmar que a limitação de escopo é causada pelo próprio auditado, o que impede concluir pela ausência de fraude, e não que a ausência de evidência seja prova de regularidade. A recomendação precisa ser específica: registrar identificação de usuário, valores antes e depois, horário, origem e resultado em toda alteração; reter logs por prazo compatível; separar contas por sistema; reduzir perfis administrativos; implantar revisão periódica de acessos.
2. Que princípios de controle de acesso a equipe deve invocar para fundamentar as recomendações?
Read the worked answer
Quatro princípios sustentam as recomendações. Menor privilégio: cada usuário e cada sistema deve ter apenas as permissões necessárias à sua função, o que condena os 214 administradores e a conta de aplicação com escrita em todas as tabelas. Necessidade de conhecer: o acesso a dados de folha deve ser restrito a quem precisa, com justificativa registrada. Segregação de funções: quem cadastra, quem aprova e quem paga não podem ser a mesma pessoa ou o mesmo perfil, e a existência de 38 administradores em unidades de negócio sugere sobreposição indevida. Responsabilização: toda ação relevante deve ser atribuível a um indivíduo, o que exige identificação única e logs invioláveis.
A equipe deve verificar também se há autenticação multifator para perfis privilegiados, gestão de contas de serviço, bloqueio por tentativas e processo de desligamento que revogue acessos. A afirmação de que 'usa senha, logo é seguro' ignora que a senha protege o acesso inicial, mas não impede que um administrador altere dados sem deixar rastro.
O encadeamento lógico do achado é: o risco é alto porque o sistema movimenta pagamentos e não permite atribuição; a causa é a arquitetura de logs e a gestão de acessos; o efeito é a impossibilidade de detectar e responsabilizar desvios. As recomendações devem ser priorizadas por esse encadeamento, começando pela identificação de usuário nos logs e pela redução de privilégios, que são as medidas de maior impacto e menor custo.