O que o auditor realmente pede como evidência de controle de acesso

Sua empresa tem política de acesso aprovada, perfis desenhados e um IAM em produção. O auditor pede a amostra de dez concessões do último trimestre e o time de TI passa três dias caçando e-mail e print de tela. O teste falha. Não por ausência do controle, por ausência de evidência de controle de acesso.

Esse é o padrão mais comum em auditoria de acessos. O controle existe na prática e na memória das pessoas. Ele não existe em formato verificável por um terceiro que não estava presente na decisão.

Auditor não avalia intenção. Ele avalia o que consegue reconstituir a partir de registro. Se a trilha de auditoria não amarra solicitação, aprovação, execução e revogação, o controle é tratado como inoperante.

Ter o controle e comprovar o controle são etapas distintas

Evidência de controle de acesso é o conjunto de registros que permite a um terceiro independente confirmar que o controle desenhado operou como descrito, caso a caso, no período avaliado. Sem esse registro, o controle existe apenas como afirmação da própria empresa.

A diferença é operacional. O controle é o que sua empresa faz. A evidência é o que sua empresa mostra depois, com o time trocado e o gestor da época em outra companhia. Três situações separam um do outro:

• O controle é executado por alguém que decide de cabeça, sem rastro do critério aplicado.
• O registro existe, mas está espalhado em e-mail, chat e planilha, sem chave que ligue as peças.
• O registro está reunido, mas é editável por qualquer um, então não sustenta integridade.

Um modelo maduro de governança de acessos resolve isso na origem. O registro nasce como subproduto do fluxo, não como tarefa da véspera.

O conceito de evidência reconstituível

Evidência reconstituível é o registro que responde cinco perguntas sobre qualquer acesso, sem depender de entrevista: quem pediu, quem aprovou, com que justificativa, por quanto tempo e quando foi revogado. Sem resposta documentada para uma delas, a amostra tende a cair.

As cinco perguntas que sustentam o teste

1. 1Quem pediu. Solicitante identificado, data e hora, e o item exato do catálogo.
2. 2Quem aprovou. Aprovador nominal e seu papel formal: gestor, owner da aplicação ou segurança.
3. 3Com que justificativa. Motivo de negócio inteligível, não "conforme solicitado".
4. 4Por quanto tempo. Vigência definida na concessão, com data de término no acesso temporário.
5. 5Quando foi revogado. Revogação com data de execução e confirmação no sistema alvo.

As cinco respostas precisam estar ligadas entre si. Registros soltos em cinco ferramentas obrigam o auditor a acreditar em costura feita à mão, e ele não vai.

Os quatro cenários clássicos de teste de acesso

Auditoria de acessos raramente inventa teste novo. O roteiro cai em quatro cenários.

Amostragem de concessões do período

O auditor lista os acessos concedidos no período, sorteia uma amostra e pede a papelada de cada item. O ponto crítico é a completude da população: lista incompleta invalida a amostra antes de começar.

Teste de desligamento

O auditor cruza os desligados do RH com os acessos ativos e espera revogação tempestiva em todos os sistemas em escopo, com prova de data. Conta de e-mail desativada e acesso ao ERP intacto é achado clássico. Vale igual para terceiros e prestadores.

Teste de revisão periódica

O auditor quer prova de que a revisão ocorreu no período, cobriu o escopo declarado e gerou decisão por item. Campanha aberta não conta. Aprovação em bloco, sem registro de análise, vira fragilidade. Rodar recertificação de acessos com trilha por item transforma a revisão em evidência.

Teste de acesso privilegiado

Contas administrativas, contas de serviço e perfis capazes de alterar configuração recebem atenção desproporcional, com razão. O auditor procura inventário atualizado, owner nomeado, aprovação diferenciada, prazo de validade e revisão mais frequente que a do acesso comum. Contas de serviço sem dono e acessos órfãos costumam aparecer nesse teste.

O que o auditor pede, a evidência aceitável e onde ela nasce

A tabela traduz pedido em artefato. A terceira coluna é a que importa mais: mostra em que etapa a evidência precisa ser gerada para existir depois.

O que costuma derrubar o teste

Cinco padrões respondem pela maior parte dos achados de acesso lógico. Todos são falhas de forma.

• Aprovação por e-mail que ninguém acha. A caixa foi limpa, o aprovador saiu ou a thread não cita o sistema concedido. O acesso existe, a autorização não.
• Print de tela sem contexto. Mostra a permissão de hoje. Não mostra quem concedeu, quando nem sob qual aprovação.
• Planilha editável sem controle de versão. Se qualquer pessoa altera a linha depois do fato, não há integridade. O auditor testa isso perguntando quem tem permissão de escrita.
• Revisão sem registro da decisão. A campanha rodou, mas nada registra o que o gestor decidiu por item nem o destino do que ele reprovou.
• Exceção sem dono. Acesso fora da regra, prazo vencido, sem responsável e sem data de reavaliação.

O padrão comum é a perda do vínculo. Cada peça existe sozinha e o conjunto não prova nada, porque não há chave ligando pedido, decisão, execução e revisão. Boa parte dos riscos ocultos em acessos nasce aí.

Como SOC 2, ISO 27001, NIST CSF e LGPD olham a evidência

Cada framework cobra o mesmo material por caminhos diferentes. Esta seção é informativa e não substitui a orientação do auditor ou do jurídico.

SOC 2

Os critérios de acesso lógico dos Trust Services Criteria olham desenho e operação do controle. O auditor quer ver que conceder, alterar e remover acesso é processo definido e que ele funcionou no período. A diferença entre os relatórios importa: o Tipo 1 avalia o desenho em uma data específica, o Tipo 2 avalia a operação efetiva ao longo de um período, com amostragem.

ISO 27001

Os controles de controle de acesso do Anexo A da ISO/IEC 27001 tratam de política de acesso, provisionamento e desprovisionamento de identidades, direitos privilegiados e revisão periódica de direitos. O auditor procura a política aprovada, a prova de aplicação no dia a dia e o resultado documentado das revisões.

NIST CSF

A função de proteção do NIST Cybersecurity Framework trata gestão de identidade, autenticação e controle de acesso como categoria própria, com ênfase em least privilege e separação de funções. O uso mais comum é autoavaliação de maturidade, então a evidência sustenta a nota que sua empresa atribui a si mesma.

LGPD

A LGPD não lista controles técnicos, mas impõe o dever de adotar medidas de segurança e de saber quem tratou dado pessoal. O efeito prático aparece em dois momentos: na resposta a incidente, quando é preciso dizer em horas quais contas tinham acesso à base afetada, e no pedido de titular, quando é preciso demonstrar controle sobre quem consultou o dado.

Do dossiê de evidência à amostragem respondida em minutos

Preparar dossiê na véspera é caro e frágil. O caminho sustentável é deixar o processo produzir a evidência e manter o pacote sempre pronto.

1. 1Defina a população. Liste os sistemas em escopo e a fonte oficial de quem tem acesso em cada um. Sem população confiável, nenhuma amostra se defende.
2. 2Nomeie owners. Cada aplicação e cada grupo crítico precisa de responsável formal que aprova e responde pela revisão.
3. 3Feche as portas laterais e padronize o registro. Enquanto houver concessão por e-mail ou chat, haverá acesso sem trilha. Todo pedido carrega solicitante, aprovador, justificativa, escopo, vigência e checagem de SoD.
4. 4Force a vigência. Data de término compulsória no acesso temporário elimina a maior fonte de privilégio acumulado.
5. 5Rode campanhas com cadência fixa. Revisão fechada, com decisão por item e revogação amarrada à decisão.
6. 6Amarre desligamento a evento, não a lembrete. O gatilho vem do RH ou do diretório e dispara revogação rastreada.
7. 7Trate exceção como item com dono e prazo. Risco aceito, aprovador, compensação e data de reavaliação.
8. 8Ensaie a extração. Sorteie dez concessões e cronometre. Acima de uma hora, o problema é de sistema.

Onde o AuditAcesso entra

O AuditAcesso opera como camada de governança acima do IAM e preserva o vínculo entre solicitação, aprovação, execução e revisão no mesmo registro. O ciclo de governança em cinco etapas cobre entrada, solicitação com justificativa e validade, decisão por nível de risco com bloqueio preventivo de conflito de segregação de funções, execução via ITSM ou API e revisão em campanha com evidência.

Isso muda a resposta à amostragem. O catálogo governado em linguagem de negócio evita justificativa vazia. A automação de vigência dá data de término compulsória. As integrações com Active Directory e ITSM como Jira e GLPI transformam o provisionamento em fonte de evidência: o ticket de execução fica ligado ao pedido e à aprovação que o originaram. A ferramenta produz a trilha. A conclusão da auditoria e qualquer certificação seguem sendo decisão do auditor.

Checklist prático

Use este bloco antes de abrir a janela de auditoria.

• check_box_outline_blankSistemas em escopo com fonte oficial de acessos definida para cada um.
• check_box_outline_blankOwner formal nomeado por aplicação e por grupo privilegiado.
• check_box_outline_blankTodo pedido do período com solicitante, aprovador, justificativa, escopo e vigência.
• check_box_outline_blankZero concessão do período originada em e-mail, chat ou planilha.
• check_box_outline_blankResultado da validação de SoD gravado no momento da decisão.
• check_box_outline_blankCampanhas de revisão encerradas, com decisão por item e revogação confirmada.
• check_box_outline_blankDesligados do período sem acesso residual em sistema em escopo.
• check_box_outline_blankInventário de contas privilegiadas e de serviço com dono e prazo.
• check_box_outline_blankExceções vigentes com risco aceito, aprovador e data de reavaliação.

Perguntas frequentes

Qual evidência de controle de acesso o auditor aceita?

O auditor aceita registro gerado pelo próprio processo, com data, autor identificável e integridade preservada. Solicitação com justificativa, aprovação nominal, ordem de execução e confirmação de revogação formam o pacote básico. Print de tela e planilha servem como apoio, nunca como prova principal, porque não demonstram quem autorizou nem quando a ação ocorreu.

Qual a diferença entre SOC 2 Tipo 1 e Tipo 2 em controle de acesso?

O Tipo 1 avalia se o controle está desenhado de forma adequada em uma data específica. O Tipo 2 avalia se o controle operou efetivamente ao longo de um período, com testes por amostragem de casos reais. Por isso o Tipo 2 exige trilha contínua: descrição de processo, sem registro datado de cada concessão e revisão, não sustenta o teste.

O que a LGPD exige sobre controle de acesso a dado pessoal?

A LGPD exige medidas de segurança adequadas e a capacidade de demonstrar controle sobre o tratamento. Em termos operacionais, sua empresa precisa saber quem tem e quem teve acesso a bases com dado pessoal. Isso pesa na resposta a incidente, quando o prazo é curto, e no atendimento a pedido de titular.

Uma ferramenta de governança garante a certificação?

Não. Nenhuma ferramenta garante certificação ou opinião favorável de auditor. O que uma plataforma de governança faz é padronizar o processo e produzir a trilha de auditoria que o teste exige, reduzindo achado por falha de evidência. A conclusão depende do escopo contratado, do trabalho do auditor e da operação real dos controles.

Próximo passo

Se o próximo ciclo de auditoria já tem data, faça um teste simples: peça dez concessões aleatórias do último trimestre e cronometre a resposta. O resultado mostra se sua empresa tem evidência de controle de acesso ou apenas a convicção de que o controle funciona.

Para ver a trilha de solicitação, aprovação, execução e revisão pronta antes do auditor pedir, agende uma demonstração do AuditAcesso com o time do Grupo LUME.

==============================================================