Um sistema pode estar disponível, apresentar telas sem erros e produzir relatórios aparentemente coerentes, mesmo quando parte de suas informações está incompleta, duplicada ou desatualizada. Essas falhas podem permanecer pouco visíveis até afetarem uma decisão, uma entrega ou a execução de um processo.
Em ambientes empresariais, os dados percorrem aplicações, bancos de dados, integrações e plataformas analíticas. Cada etapa pode introduzir transformações legítimas, mas também perdas, alterações indevidas ou interpretações incompatíveis com o significado original.
A Auditoria de Sistemas examina esse percurso e os controles que sustentam a confiabilidade das informações. A avaliação relaciona a origem dos dados, as regras de processamento, os resultados apresentados e as evidências disponíveis para verificar o que ocorreu.
Integridade não significa, isoladamente, informação correta
Proteger um registro contra alterações indevidas é essencial, mas não demonstra que seu conteúdo estava correto quando foi produzido. Um dado incorreto pode ser armazenado e transmitido sem qualquer modificação.
Da mesma forma, informações válidas individualmente podem formar um conjunto incompleto. Um relatório de atendimentos pode apresentar registros corretos e, ainda assim, deixar de incluir uma unidade operacional.
Por isso, convém distinguir as perguntas que orientam a avaliação:
- Integridade: houve alteração ou destruição indevida dos dados?
- Completude: os registros e campos necessários estão presentes?
- Exatidão: o conteúdo corresponde ao fato ou à fonte de referência?
- Consistência: informações relacionadas obedecem às regras e relações esperadas?
- Atualidade: os dados correspondem ao período necessário para sua utilização?
- Rastreabilidade: é possível identificar sua origem e as transformações realizadas?
Os critérios precisam ser definidos conforme o processo. Nem todo campo vazio representa falha, assim como nem toda diferença entre bases representa erro: pode haver períodos de atualização ou regras de seleção distintos.
A análise acompanha o percurso dos dados
O ponto de partida é compreender como a informação utilizada pela organização é produzida. Isso envolve identificar fontes, responsáveis, etapas de tratamento e destinos.
Uma quantidade exibida em um painel executivo, por exemplo, pode depender de cadastros, eventos operacionais, rotinas de importação e filtros de apresentação. Examinar apenas o painel restringe a capacidade de explicar uma divergência.
A auditoria pode selecionar informações críticas e acompanhar seu percurso desde a origem até o resultado. Também pode realizar o caminho inverso: partir de um indicador e verificar quais registros e regras contribuíram para sua formação.
Esse exame deve registrar versões das rotinas, períodos de referência, filtros e condições de extração. Sem essa contextualização, duas consultas realizadas em momentos diferentes podem gerar resultados distintos sem que tenha ocorrido uma falha.
Controles de entrada e armazenamento
Na entrada dos dados, a avaliação pode examinar campos obrigatórios, formatos, limites permitidos e tratamento de valores inválidos. O interesse está em verificar se as regras implementadas correspondem às necessidades do processo e se exceções são identificadas e tratadas.
No banco de dados, restrições de unicidade, obrigatoriedade e relacionamento entre tabelas ajudam a impedir determinadas inconsistências. A documentação do PostgreSQL apresenta esses mecanismos e suas condições de funcionamento. Sua existência, entretanto, precisa ser verificada no ambiente examinado. PostgreSQL — Restrições de dados.
Também importa avaliar o agrupamento de operações que precisam ocorrer de maneira coordenada. Transações permitem tratar um conjunto de alterações como uma unidade, confirmando-as ou desfazendo-as em conjunto. PostgreSQL — Transações.
Na auditoria, esses recursos devem ser relacionados ao desenho efetivo do processo. Uma transação local em um banco não comprova, por si só, que todas as etapas distribuídas entre aplicações foram concluídas corretamente.
Integrações: verificar o que chegou e o que foi processado
Em integrações entre sistemas, é útil distinguir o recebimento de uma mensagem de sua aplicação completa no destino. Uma confirmação de transporte pode não demonstrar que o conteúdo passou pelas validações ou foi incorporado ao resultado final.
Os procedimentos de auditoria podem comparar registros enviados, recebidos, rejeitados e processados. Também devem considerar mensagens pendentes e diferenças legítimas de horário, evitando classificar atrasos previstos como perdas definitivas.
Outro ponto é o comportamento diante de reenvios. Se uma comunicação for interrompida após o processamento, o sistema de origem pode tentar novamente. A avaliação deve verificar como o destino reconhece uma operação já realizada e evita repetir seus efeitos quando isso não é permitido.
A repetição de uma solicitação sem multiplicar seu efeito é conhecida como idempotência. Sua aplicação depende do contexto e deve ser demonstrada para os cenários relevantes, incluindo o período durante o qual a identificação da operação é preservada.
Exemplo: totais iguais podem esconder erros
Considere um cenário hipotético: um sistema registra 10.000 ordens de atendimento e transmite essas informações para uma plataforma gerencial. No destino, também aparecem 10.000 registros.
A comparação da quantidade total sugere correspondência, mas uma verificação por identificador revela que 100 ordens não chegaram e outras 100 foram incluídas duas vezes. O total permaneceu igual, embora o conjunto estivesse incorreto.
Nesse caso, contar linhas seria insuficiente. A auditoria precisaria comparar os identificadores esperados, localizar ausências e duplicidades e examinar os registros de transmissão e reprocessamento.
Mesmo a igualdade dos identificadores não encerraria a análise. Campos relevantes, como situação, unidade responsável ou data de conclusão, também poderiam ter sido alterados durante a integração.
O exemplo mostra por que a conciliação técnica entre origem e destino deve considerar conteúdo, regras e período, além de quantidades. O nível de detalhamento depende do impacto de uma informação incorreta sobre o processo.
Alterações, proteção e limites dos hashes
A avaliação da integridade inclui quem pode modificar os dados, como as alterações são autorizadas e quais registros permitem reconstruí-las. Correções manuais e intervenções administrativas merecem atenção quando podem contornar os controles usuais da aplicação.
A publicação NIST SP 1800-25 aborda a identificação e proteção de ativos contra eventos destrutivos e inclui monitoramento de integridade, registros de eventos, armazenamento protegido e backups em sua arquitetura de referência. Esses mecanismos ajudam a estruturar a proteção, mas precisam ser avaliados conforme o ambiente. NIST — Data Integrity, SP 1800-25.
Um hash criptográfico pode apoiar a comparação do conteúdo de arquivos em diferentes momentos. Para isso, é necessário utilizar um algoritmo apropriado e preservar uma referência confiável para comparação.
O hash não demonstra a veracidade da informação, sua autoria ou a completude do conjunto originalmente extraído. Se um arquivo já foi produzido com registros ausentes, calcular seu hash não corrige nem revela, isoladamente, essa omissão.
Evidências e procedimentos proporcionais ao risco
O trabalho pode combinar análise de regras, inspeção de configurações, consultas autorizadas, comparação de conjuntos e testes em ambiente controlado. A seleção deve considerar a criticidade dos dados e as limitações de acesso.
Consultas e extrações precisam ser documentadas de modo que outro profissional consiga compreender os critérios utilizados. Devem ser identificados a fonte, o período, os filtros, os campos examinados e os procedimentos de tratamento aplicados durante a própria auditoria.
É igualmente necessário verificar a completude da extração entregue ao auditor. Uma análise rigorosa sobre um arquivo parcial pode produzir uma conclusão inadequada se a limitação não for reconhecida.
Quando houver amostragem, o relatório deve indicar sua abrangência e os limites de generalização. A ausência de divergências na amostra não autoriza concluir, automaticamente, que todos os dados do ambiente estão corretos.
O resultado para a organização
O relatório deve distinguir erros comprovados, fragilidades de controle e situações que não puderam ser esclarecidas. Cada constatação precisa relacionar a evidência ao critério adotado e ao possível impacto sobre o uso da informação.
As recomendações podem envolver validações adicionais, revisão de integrações, tratamento de rejeições, controle de reprocessamentos ou melhoria da rastreabilidade. A prioridade deve refletir a criticidade do processo afetado.
Quando a causa exigir exame aprofundado de código, algoritmos ou componentes, a Auditoria de Software pode complementar a avaliação. A Auditoria de Sistemas mantém a visão do conjunto: pessoas, processos, aplicações, infraestrutura e circulação das informações.
Auditoria de Sistemas na IBPTECH
A integridade de dados e a confiabilidade das informações integram o campo da Auditoria de Sistemas, uma das áreas de atuação da IBPTECH. Este portal é dedicado à Divisão de Auditoria de Sistemas e apresenta conteúdos e serviços relacionados a esse domínio.
Conheça os serviços da Divisão de Auditoria de Sistemas para discutir a avaliação dos fluxos de dados, integrações e controles relevantes para sua organização.