Governança de acessos: como transformar pedidos soltos em decisões auditáveis

Todo mês alguém pede acesso a um sistema crítico por e-mail. Alguém responde "ok, liberado". A permissão é criada e ninguém volta para verificar se ela ainda faz sentido. Meses depois a auditoria pergunta quem autorizou aquilo e com base em qual critério. A resposta não existe.

Governança de acessos é a disciplina que fecha esse buraco. Ela define quem pode pedir, quem pode aprovar, sob qual nível de risco, por quanto tempo, e como cada decisão fica registrada. Sem essa camada, sua empresa tem provisionamento funcionando e controle nenhum.

A conta chega em dois momentos: no dia da auditoria e no dia do incidente. Até lá, o privilégio se acumula em silêncio.

O que é governança de acessos

Governança de acessos é o conjunto de políticas, papéis e controles que decide, justifica e comprova cada permissão concedida na empresa. Ela responde quatro perguntas de forma permanente: quem tem acesso a quê, quem autorizou, com base em qual critério de risco, e até quando esse acesso é válido.

A palavra que importa é decisão. Criar um usuário no Active Directory é execução técnica. Definir que ele deve receber perfil de aprovador financeiro é decisão de negócio com consequência de risco. A governança de acessos organiza a segunda coisa.

O escopo vai além das aplicações de negócio. Entram ERP, nuvem, bancos de dados, repositórios de código e contas privilegiadas, mais terceiros e integrações máquina a máquina, que raramente aparecem no inventário.

O que a governança de acessos precisa produzir

Três entregas, nenhuma opcional em ambiente auditado:

• Controle preventivo. O pedido errado é barrado antes da concessão.
• Rastreabilidade. Sempre é possível saber quem solicitou, quem aprovou, por qual motivo e por quanto tempo.
• Evidência. O registro serve ao auditor externo sem mutirão de capturas de tela.

Por que o controle manual de acessos falha

Não é falta de esforço. É falta de estrutura. A governança de acessos apoiada em e-mail, chat e planilha falha sempre pelos mesmos seis pontos.

• O pedido não tem formato. Cada gestor escreve como quer. Sem campo obrigatório de justificativa, escopo e validade, a TI preenche a lacuna por conta própria.
• A aprovação não tem critério. Quem aprova não vê a criticidade da aplicação nem os perfis que o usuário já acumula. Conflitos de segregação de funções passam direto.
• Ninguém é dono da aplicação. Sem owner formalmente designado, a decisão cai em quem responde mais rápido.
• O prazo não existe. Acesso liberado para um projeto de duas semanas segue ativo dois anos depois. É a origem mais comum de privilégio excessivo e contas órfãs.
• A trilha é reconstruída na mão. Na auditoria, o time varre caixas de e-mail e histórico de chat. O que não foi salvo desapareceu.
• O desligamento depende de aviso informal. Se o RH não avisa pelo canal certo, o deprovisionamento atrasa e a conta do ex-colaborador segue viva.

IAM e IGA: onde termina a execução e começa a governança de acessos

IAM (identity and access management) autentica o usuário e executa o provisionamento. IGA (identity governance and administration) decide se aquela permissão deveria existir, registra a justificativa e comprova o controle depois. Um faz acontecer, o outro responde por que aconteceu.

Confundir as duas camadas é o erro mais caro em projeto de controle de acesso corporativo. Uma empresa pode ter SSO e MFA impecáveis e ainda assim não explicar por que um analista de suprimentos aprova pagamento.

O AuditAcesso opera nessa segunda coluna, a da governança de acessos. Fica acima do IAM, consome o Active Directory como catálogo de entrada e devolve a execução ao ITSM ou à API do sistema alvo. Conta com integrações nativas homologadas, entre elas Okta, Microsoft 365, ServiceNow, Jira e GitHub. A lista está na página de integrações.

Os cinco pilares operacionais da governança de acessos

Sem os cinco funcionando juntos, o processo volta a ser aprovação por e-mail com verniz de ferramenta.

• Catálogo governado. Cada item descrito em linguagem de negócio, com dono, criticidade e categoria. O gestor pede "aprovar nota fiscal até dez mil reais", e não "grupo AD_FIN_APRV_02". Essa tradução sustenta uma boa modelagem de papéis em RBAC.
• Owner de aplicação. Um nome, não uma área. Quem aprova precisa entender o que o perfil permite e responder pela concessão.
• Matriz de risco e segregação de funções. A criticidade define o rito de aprovação. A matriz de SoD define o que jamais pode coexistir no mesmo usuário, e combinações tóxicas devem ser barradas na origem. Detalhes no guia de segregação de funções e controle de SoD.
• Vigência e menor privilégio. Todo acesso nasce com prazo e com o menor escopo suficiente. Least privilege sai do slide quando a data de término é campo obrigatório.
• Evidência por construção. O registro nasce dentro do fluxo. É o que permite atender os critérios de acesso lógico de SOC 2 e os controles de acesso do Anexo A da ISO/IEC 27001 sem projeto paralelo de coleta. Aprofundamento em evidência de controle de acesso para SOC 2 e ISO 27001.

O ciclo de vida do acesso em cinco etapas

O ciclo de vida do acesso é a sequência que leva uma necessidade de negócio até uma permissão ativa, controlada e revisada. Cobre o modelo joiner, mover e leaver: entrada, mudança de função e saída. Cada etapa gera registro próprio, e a soma deles é a trilha de auditoria.

1. 1Entrada. O usuário passa a existir no processo pelo catálogo do Active Directory ou por carga massiva aprovada. Onboarding em lote absorve turma de admissão sem dezenas de chamados soltos.
2. 2Solicitação. O gestor escolhe o item no catálogo e preenche justificativa, escopo e validade. Campo vazio não avança, então o pedido chega completo ao aprovador.
3. 3Decisão. A aprovação segue o nível de risco do item, com o owner no fluxo. A validação de SoD roda antes da concessão e bloqueia conflito de função. Alta criticidade pode exigir mais de um nível.
4. 4Execução. O provisionamento sai imediatamente via ITSM ou API. Sem digitação manual e sem divergência entre o que foi aprovado e o que foi criado.
5. 5Revisão. Campanhas trimestrais colocam o owner diante da lista real de quem tem o quê, para manter ou revogar. Desligamento dispara revogação com evidência. O funcionamento das campanhas está no guia de recertificação de acessos.

A visão consolidada do fluxo está na página do ciclo de governança.

Papéis e responsabilidades na política de acesso

Governança de acessos sem dono definido devolve tudo para a TI, que não tem contexto de negócio para decidir. A divisão abaixo é o mínimo viável.

Métricas e maturidade da governança de acessos

Métrica boa mostra onde o controle vaza. As oito abaixo saem do próprio registro do processo, sem pesquisa externa.

• Percentual de aplicações com owner formalmente designado.
• Percentual de acessos ativos com data de término definida.
• Tempo médio entre solicitação e provisionamento efetivo.
• Tempo entre desligamento e revogação confirmada.
• Volume de contas ativas sem dono identificável.
• Taxa de revogação nas campanhas de recertificação.
• Conflitos de SoD abertos e tempo médio até tratamento.
• Percentual de decisões com justificativa recuperável na trilha.

O dashboard de conflitos e aprovações pendentes do AuditAcesso mostra esse passivo em aberto, sem esperar a próxima auditoria.

Níveis de maturidade

Os níveis abaixo descrevem estágios observáveis de governança de acessos. Não são benchmark de mercado. Servem para localizar sua empresa antes de definir o próximo passo.

A passagem do nível 2 para o 3 é a mais difícil, porque exige decisão política: nomear owners e aceitar que aprovar acesso é responsabilidade de negócio.

Checklist prático

Cada item sem resposta clara é uma lacuna na governança de acessos.

• check_box_outline_blankExiste inventário de aplicações com criticidade classificada.
• check_box_outline_blankCada aplicação crítica tem um owner nominal designado.
• check_box_outline_blankTodo pedido tem justificativa e prazo obrigatórios.
• check_box_outline_blankO catálogo está escrito em linguagem de negócio.
• check_box_outline_blankA matriz de SoD é validada antes da concessão.
• check_box_outline_blankAcessos privilegiados têm rito de aprovação diferenciado.
• check_box_outline_blankExiste calendário de recertificação com escopo e responsável.
• check_box_outline_blankO desligamento dispara revogação com evidência registrada.
• check_box_outline_blankContas órfãs e acessos de terceiros são varridos periodicamente.
• check_box_outline_blankÉ possível reconstruir qualquer decisão dos últimos doze meses.
• check_box_outline_blankAs métricas de acesso chegam ao comitê de risco em cadência fixa.

Perguntas frequentes

Qual a diferença entre gestão de acessos e governança de acessos?

Gestão de acessos cuida da operação: criar, alterar e remover permissões. Governança de acessos cuida da decisão e da prova. Define quem aprova, sob qual critério de risco, por quanto tempo, e mantém a trilha que sustenta a resposta na auditoria. A gestão executa dentro dos limites que a governança estabelece.

Governança de acessos substitui o IAM?

Não. As camadas são complementares. O IAM autentica o usuário, mantém o diretório e provisiona a permissão. A camada de governança define o que deveria ser provisionado, valida conflito de função, impõe vigência e produz evidência. Sem IAM, a execução para. Sem governança, a empresa fica sem justificativa nem rastreabilidade.

Com que frequência os acessos devem ser revisados?

Ciclo trimestral funciona bem para aplicações críticas e perfis privilegiados. Sistemas de menor criticidade admitem revisão semestral. Além do calendário, é preciso revisão por evento: mudança de cargo, transferência de área, fim de projeto e desligamento. O gatilho por evento captura o risco que a campanha periódica só encontraria meses depois.

Quem deve aprovar um pedido de acesso?

O owner da aplicação, sempre. O gestor do solicitante justifica a necessidade, mas quem responde pelo risco do perfil é o dono do sistema. Para itens de alta criticidade ou com conflito potencial de segregação de funções, vale aprovação em mais de um nível, incluindo risco ou compliance.

Governança de acessos garante certificação SOC 2 ou ISO 27001?

Nenhuma ferramenta garante certificação. O parecer depende do auditor e do escopo avaliado. O que a governança entrega é o processo desenhado e a evidência de que ele operou no período, que é justamente o que se testa em controle de acesso lógico. Sem esse registro, o controle existe no papel e não passa no teste.

Planilha resolve para empresa pequena?

Por pouco tempo. Planilha não bloqueia conflito de SoD antes da concessão, não expira acesso sozinha e não prova quando cada linha foi alterada. Enquanto o volume é baixo, o custo aparece só na auditoria. Quando o volume cresce, o privilégio acumulado já exige projeto de limpeza.

Próximo passo

Governança de acessos não começa com ferramenta. Começa com inventário, owners nomeados e critério de risco escrito. A automação vem depois e transforma política em controle que opera todo dia, gerando evidência sem esforço extra.

O AuditAcesso é a camada de governança de acessos auditável de ponta a ponta entre o negócio, a matriz de risco e a execução técnica, desenvolvida pelo Grupo LUME, com mais de 40 anos de mercado e mais de 5.000 clientes atendidos.

Marcar reunião técnica para ver o ciclo de vida do acesso aplicado ao seu ambiente.

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