Recertificação de acessos: como transformar a revisão em decisão e evidência

Toda empresa que já passou por auditoria de acesso conhece a cena. A planilha sai do Active Directory, vai por e-mail para vinte gestores, dez respondem, e o consolidado diz que está tudo aprovado. A recertificação de acessos aconteceu no papel. No ambiente, nada mudou.

O problema está no desenho da campanha. Uma revisão de acessos que entrega 400 linhas com nomes técnicos de grupos pede ao gestor uma decisão que ele não tem como tomar. Ele aprova em bloco. Em auditoria isso tem nome: rubber stamping.

O desenho a seguir busca três resultados: decisão registrada, revogação executada e evidência reconstituível.

O que é recertificação de acessos e por que ela existe

Recertificação de acessos é o processo periódico em que o responsável por uma aplicação ou por uma equipe confirma, permissão por permissão, se cada acesso concedido ainda é necessário. O que não é confirmado é revogado. O resultado fica registrado com autor, data e justificativa, formando trilha de auditoria.

Ela existe porque a concessão é um evento e a permissão é um estado permanente. Todo ambiente concede mais do que revoga. Quem muda de área acumula o perfil antigo com o novo.

Esse acúmulo aparece entre os riscos ocultos de um ambiente sem governança com dois nomes conhecidos: privilégio excessivo e acessos órfãos. A revisão corta o estoque acumulado, porque os controles de entrada só olham para frente. Ela fecha o ciclo de governança de acessos.

Os frameworks pedem isso de forma explícita. Os critérios de acesso lógico dos Trust Services Criteria do SOC 2 e os controles do Anexo A da ISO/IEC 27001 esperam revisão periódica com prova de que ela ocorreu e gerou ação.

Por que a revisão em planilha vira rubber stamping

A revisão periódica de permissões em planilha falha por motivos previsíveis. Vale nomear cada um.

• Volume sem priorização. O gestor recebe todas as permissões de todos os subordinados no mesmo arquivo. Leitura na intranet e aprovação de pagamento pesam igual.
• Nome técnico ilegível. Um grupo chamado GRP_SAP_FI_AP_POST_BR não diz nada para quem aprova. O gestor não sabe que aquilo lança pagamento a fornecedor.
• Ausência de contexto. A planilha mostra quem tem. Não mostra desde quando, quem aprovou, com que justificativa, nem se o acesso foi usado.
• Conflito não sinalizado. Combinações de SoD (segregação de funções) que nunca deveriam coexistir aparecem como duas linhas independentes e inofensivas.
• Resultado não executado. Mesmo quando a revogação é marcada, a execução depende de alguém abrir chamado à mão. A planilha some, o chamado não nasce, o acesso permanece.

O efeito colateral é pior que a inação. A campanha produz um artefato que afirma que o acesso foi validado. Na auditoria seguinte, ele prova que a empresa aprovou um privilégio indevido.

Como desenhar o escopo da campanha de revisão de acessos

Campanha única e universal não funciona. O escopo é a primeira decisão de projeto, e se recorta de três formas complementares.

Por aplicação crítica

Uma campanha por aplicação, com o owner do sistema como revisor. É o recorte mais eficiente onde o risco se concentra: ERP financeiro, folha, faturamento e bases de dados pessoais sujeitas à LGPD.

Por área e gestor direto

Uma campanha por estrutura organizacional, em que cada gestor revisa todos os acessos da sua equipe, atravessando sistemas. É o único recorte que enxerga acúmulo por mudança de cargo: aqui aparece quem saiu de compras para o fiscal e manteve o perfil antigo.

Por perfil privilegiado

Uma campanha curta e frequente: administradores de domínio, contas de serviço, root de banco, acessos de emergência e integrações com chave de API. Poucas linhas, revisor sênior, tolerância zero para acesso sem justificativa viva.

Recorte estreito viabiliza cadência alta. Revisar tudo de uma vez leva direto ao rubber stamping.

Cadência de recertificação por criticidade de sistema

Cadência é a frequência com que cada conjunto de acessos volta para validação. A recertificação de acessos deve ser proporcional ao risco, e não uniforme. A tabela abaixo serve como ponto de partida.

Revisão por evento, o complemento obrigatório

Calendário não cobre o intervalo entre ciclos. Três eventos disparam revisão imediata. Mudança de cargo, porque o perfil novo entra e o antigo raramente sai. Desligamento, com deprovisionamento de todas as contas e evidência datada, o item mais testado em auditoria. Fim de vigência, porque acesso temporário sem data de término compulsória é acesso permanente com nome errado.

Quem revisa e o que o revisor precisa ver para decidir

A TI não deve ser o revisor. Ela opera a campanha, consolida o resultado, executa a revogação e guarda a evidência. Quem decide se um acesso ainda é necessário é quem responde pelo processo de negócio.

Quem assina a decisão

Duas figuras sustentam a atestação de acesso. O owner da aplicação responde por quem pode ter cada perfil e conhece o efeito de cada permissão. O gestor direto responde pela necessidade daquela pessoa, no cargo atual. Em sistema crítico, os dois revisam, com o owner como instância final.

Owner sem nome é o ponto de falha mais comum. Cada aplicação em escopo precisa de responsável nomeado e substituto formal antes de a campanha abrir.

O que precisa estar na tela

A linha precisa responder sozinha às perguntas óbvias. O mínimo viável são seis campos.

1. 1Nome de negócio da permissão. "Lançar pagamento a fornecedor" em vez do nome do grupo técnico.
2. 2Titular e cargo atual, lidos da fonte de RH e não do pedido original.
3. 3Data da concessão e prazo de vigência, quando houver.
4. 4Quem aprovou e com que justificativa, recuperável na hora, sem abrir chamado.
5. 5Última utilização, quando a aplicação expõe o dado. Perfil crítico sem uso em um trimestre é candidato à revogação.
6. 6Conflito de SoD sinalizado na própria linha, contra a matriz de risco vigente.

O revisor precisa de três opções: manter, revogar e reduzir escopo. Reduzir é a decisão mais frequente em ambiente maduro.

Da decisão à revogação de acessos: execução e evidência

Marcar "revogar" na planilha não revoga nada. A campanha termina quando o acesso sai do sistema de origem, com comprovação. O caminho tem oito passos.

1. 1Congelar a base. Extrair o inventário em escopo com data e hora e trabalhar sobre essa foto.
2. 2Traduzir o técnico para o negócio no catálogo, antes de a linha chegar ao revisor.
3. 3Distribuir por revisor, com data limite e régua de escalonamento definida.
4. 4Registrar decisão linha a linha. Manter perfil crítico exige justificativa escrita.
5. 5Gerar a ordem de execução automaticamente: chamado no ITSM ou chamada de API, sem redigitação.
6. 6Confirmar a execução no alvo. Fechar chamado não basta, é preciso reconciliar contra o sistema de origem.
7. 7Tratar exceção com responsável, motivo e data de reavaliação. Exceção sem data é permissão disfarçada.
8. 8Publicar o relatório de fechamento: escopo, cobertura, decisões, revogações executadas e pendências.

Fechar a campanha com evidência reconstituível

Evidência reconstituível significa que, doze meses depois, a empresa reproduz a campanha sem depender da memória de ninguém. O pacote responde cinco perguntas: qual era o escopo, quem revisou, o que foi decidido, o que foi executado e o que ficou pendente.

O padrão útil é o registro por linha, imutável, com autor e horário, mais um sumário assinado por campanha. Print de tela não sustenta teste de auditoria, porque não prova quem decidiu nem quando. O que caracteriza evidência de controle de acesso aceita em SOC 2 e ISO 27001 é a rastreabilidade da decisão.

A etapa 5 do ciclo do AuditAcesso

Revisão é a etapa 5 do ciclo de governança em cinco etapas do AuditAcesso, depois de Entrada, Solicitação, Decisão e Execução. As etapas anteriores já produziram o contexto que o revisor precisa ver na campanha trimestral.

O catálogo categórico governado guarda cada permissão em linguagem de negócio, então a linha chega legível ao gestor. A solicitação original preservou justificativa, escopo e validade. A validação de SoD e criticidade sinaliza o conflito. A administração por RBAC, com herança por cargo, define quem revisa o quê.

A revogação decidida vira execução via ITSM ou API, com os conectores nativos homologados para Active Directory, Jira, GLPI, Okta, Microsoft 365 e ServiceNow, entre outros. A automação de vigência com data de término compulsória reduz o volume da próxima campanha. O AuditAcesso não substitui o IAM: entrega a camada de governança e evidência acima dele.

Checklist prático da recertificação de acessos

Antes de abrir a campanha:

• check_box_outline_blankEscopo definido por aplicação, área ou perfil privilegiado, com criticidade
• check_box_outline_blankOwner nomeado para cada aplicação, com substituto formal
• check_box_outline_blankCatálogo de permissões traduzido para linguagem de negócio
• check_box_outline_blankMatriz de SoD carregada, com os conflitos a sinalizar
• check_box_outline_blankBase de RH conciliada, com cargo e área atuais

Durante a campanha:

• check_box_outline_blankCada revisor vê apenas o que lhe compete, com prazo e escalonamento
• check_box_outline_blankTrês opções por linha: manter, revogar, reduzir
• check_box_outline_blankJustificativa obrigatória para manter perfil crítico ou privilegiado

No fechamento:

• check_box_outline_blankToda revogação virou chamado ou chamada de API, com identificador
• check_box_outline_blankExecução reconciliada contra o sistema de origem
• check_box_outline_blankExceções com responsável, motivo e data de reavaliação
• check_box_outline_blankRelatório de fechamento arquivado, com cobertura e pendências
• check_box_outline_blankAchados recorrentes devolvidos à etapa de concessão

Perguntas frequentes

Qual a diferença entre recertificação de acessos e revisão de acessos?

Na prática de mercado, os termos funcionam como sinônimos. Recertificação enfatiza o ato formal de reconfirmar. Revisão de acessos, ou user access review, descreve o exercício de examinar as permissões concedidas. O que importa é o resultado: decisão por linha, revogação executada e evidência arquivada.

Com que frequência fazer recertificação de acessos?

Trimestral para sistemas críticos e contas privilegiadas, semestral para sistemas relevantes e anual para aplicações de apoio sem dado sensível. Acessos de terceiros seguem ciclo trimestral e revisão no fim do contrato. Três eventos disparam revisão imediata: mudança de cargo, desligamento e vencimento de acesso temporário.

Quem deve aprovar a revisão de acessos, a TI ou o gestor?

O gestor de negócio e o owner da aplicação decidem. A TI conduz a campanha, executa as revogações e guarda a evidência, sem julgar necessidade de acesso. Colocar a decisão na TI cria um revisor sem conhecimento do processo, e essa é a origem da aprovação em bloco.

Como evitar que o gestor aprove tudo em bloco?

Reduza o escopo por revisor, traduza a permissão para linguagem de negócio, mostre desde quando o acesso existe, quem aprovou e a última utilização, e sinalize o conflito de SoD. Exija justificativa para manter perfil crítico. Aprovação em bloco cai quando manter custa mais que revogar.

O que o auditor pede como evidência de revisão de acessos?

Ele pede prova de que a revisão ocorreu no período e de que gerou ação: escopo, população revisada, decisão por usuário com revisor e data, comprovante de execução das revogações no sistema de origem e tratamento das exceções. Nenhuma ferramenta garante certificação, o auditor avalia o processo.

Próximo passo

Se a última campanha de revisão da sua empresa terminou em planilha aprovada em bloco, o processo é o problema, e não o gestor. Vale ver como a campanha trimestral funciona quando o revisor recebe nome de negócio, histórico de aprovação, SoD sinalizado e revogação comprovada.

Solicitar demonstração para ver a etapa de Revisão aplicada ao inventário de acessos do seu ambiente.

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