O Frame do Auditor: Pensando Como um Auditor de SI

Um auditor de SI não é contratado para encontrar cada bug ou configuração incorreta em um sistema. O trabalho é mais restrito e, honestamente, mais difícil: descobrir se os controles implementados oferecem segurança razoável de que os riscos para o negócio estão sendo gerenciados. Essa distinção muda como você aborda quase toda tarefa, desde ler um conjunto de regras de firewall até entrevistar um proprietário de sistema.

Risco primeiro, tecnologia segundo

Um pentester pergunta "consigo quebrar isso?" Um auditor pergunta "isso importa, e se falhar, o que acontece com o negócio?" Antes de tocar em um único controle, um auditor tenta entender o que o sistema faz, quais dados ele toca e o que daria errado se confidencialidade, integridade ou disponibilidade fossem comprometidas. É por isso que programas de auditoria geralmente começam com uma avaliação de risco ou um walkthrough, não um vulnerability scan.

Na prática: se você está auditando controles de acesso em um sistema de folha de pagamento, a primeira pergunta não é "MFA está habilitada?" É "qual é o impacto se uma pessoa não autorizada conseguir alterar dados de salário ou visualizar PII?" Uma vez que você conhece o impacto, pode avaliar se os controles existentes (MFA, workflows de aprovação, segregação de deveres) são proporcionais.

Evidência sobre afirmação

Proprietários de sistema vão dizer que as coisas funcionam. O trabalho de um auditor é verificar, não confiar. Isso significa pedir artefatos: uma captura de tela de uma tela de configuração, uma exportação de direitos de acesso de usuários, um ticket de mudança com timestamps de aprovação, entradas de log mostrando um controle que realmente foi executado. Se alguém diz "fazemos revisão de acesso trimestralmente," o auditor pede para ver os últimos três registros de revisão, não apenas a política que o determina.

Esse hábito baseado em evidência é o que separa um achado de auditoria de uma conversa no corredor. Um achado precisa sobreviver ao escrutínio: o que foi testado, que população foi amostrada, quais critérios foram usados e o que foi realmente observado. Declarações vagas como "controles parecem adequados" não sustentam um relatório que gestão e reguladores lerão.

Design versus efetividade operacional

Uma das divisões mentais mais úteis neste campo é separar o design do controle da operação do controle. Uma política de senha que exige 14 caracteres e MFA é bem projetada no papel. Mas se a última revisão de acesso foi há 11 meses, ou se contas de serviço são isentadas sem documentação, o controle não está operando como pretendido. Auditores testam ambos: o controle existe conforme descrito, e ele está realmente sendo seguido dia a dia?

É por isso que amostragem importa. Testar o acesso de um usuário não te diz muito. Coletar uma amostra de 25 funcionários desligados e verificar se suas contas foram desativadas dentro do SLA (digamos, 24 ou 48 horas) te dá uma base defensável para uma conclusão.

Segregação de deveres como tema recorrente

Uma enorme proporção de achados de auditoria remonta à segregação de deveres (SoD): a mesma pessoa que solicita uma mudança também a aprova, ou um desenvolvedor tem acesso direto ao banco de dados de produção junto com direitos de deployment. Auditores procuram essas sobreposições constantemente, porque falhas de SoD são como fraude e erros não-intencionais passam sem um segundo par de olhos os pegando.

Ao revisar um ambiente, pergunte: quem pode iniciar uma ação, quem pode aprová-la e quem pode executá-la? Se uma pessoa detém dois ou mais desses papéis sem um controle compensatório (como logging detalhado revisado por outra pessoa), esse é um gap que vale a pena documentar.

Escrevendo achados que são corrigidos

Um achado tecnicamente correto que ninguém age é uma auditoria desperdiçada. Bons achados declaram a condição (o que foi observado), os critérios (a política ou padrão que viola), a causa (por que aconteceu) e o efeito (que risco isso cria) — a estrutura clássica de 4C que muitas operações de auditoria usam. Achados vagos como "controles de acesso precisam melhorar" são ignorados. Específicos como "14 de 25 funcionários desligados amostrados retiveram acesso VPN por mais de 5 dias após sua data de desligamento, violando o SLA de desprovisionamento de 24 horas na política SEC-014" são remediados porque o proprietário sabe exatamente o que corrigir.

Construindo o hábito

Você desenvolve esse frame praticando-o em sistemas ordinários, não apenas em engagements formais. Escolha uma aplicação que você usa diariamente e pergunte: qual é o risco se ela falhar, que controles existem e como provaria que funcionam? Faça isso bastante vezes e o instinto do auditor — ceticismo emparelhado com uma demanda por evidência — se torna automático.

Se esse tipo de pensamento sobre controle e risco o interessa, confira os segmentos do Korra Studio sobre modelos de controle de acesso e frameworks de governança de segurança para um aprofundamento técnico maior.