A maioria das implementações de IGA (Identity Governance and Administration, Governança e Administração de Identidade) fracassa. E o problema não é a tecnologia.
É que:
- a maioria das equipes de TI não sabe por onde começar, e
- definitivamente não sabem como sequenciar as coisas corretamente.
O IGA tem tantas peças interdependentes que, sem uma estratégia clara, você acabará com um sistema parcialmente implementado que ninguém usa e que os auditores ainda não confiam.
O que realmente funciona: uma abordagem em fases que gera resultados rápidos no início e depois constrói sofisticação ao longo do tempo. Cada fase prepara você para a próxima, de modo que você não tente resolver tudo de uma vez no primeiro dia.
Antes de entrar nos detalhes, vamos deixar claro o que estamos tentando alcançar. O objetivo do IGA é garantir que as pessoas certas tenham o nível de acesso certo às ferramentas certas no momento certo.
É isso. Todo o resto são apenas detalhes de implementação.
Fase 1: Comece com Revisões de Acesso de Usuários
Se você está se perguntando por onde começar, comece aqui. Não porque as revisões de acesso resolvam tudo — não resolvem — mas porque elas geram momentum e provam valor rapidamente.
As revisões de acesso já estão acontecendo na maioria das organizações porque os frameworks de conformidade as exigem. SOX, HIPAA, GDPR — todos requerem alguma versão de “prove que você sabe quem tem acesso a quê”. Então você não está introduzindo algo completamente novo. Você está apenas fazendo isso de forma melhor e mais sistemática.
Por que isso funciona como ponto de partida:
- Primeiro, você obtém resultados de conformidade rapidamente. Auditores querem ver que você está monitorando ativamente quem tem acesso a sistemas sensíveis. As revisões de acesso fornecem essa prova.
- Segundo, o processo é relativamente direto — os gerentes revisam listas de quem tem qual acesso e então aprovam ou revogam.
- Terceiro, você constrói momentum. Quando você mostra à liderança sênior que eliminou contas órfãs e reforçou os controles em sistemas financeiros, de repente seu projeto de IGA tem suporte executivo.
Os passos práticos são simples. Comece com aplicações de alto valor — seu HRMS (Human Resources Management System, Sistema de Gestão de Recursos Humanos), CRM (Customer Relationship Management, Gestão de Relacionamento com Cliente), sistemas financeiros, provedores de identidade. Esses sistemas armazenam seus dados mais sensíveis, então são onde você precisa de visibilidade primeiro.
Identifique proprietários claros para cada aplicação. Alguém precisa saber quem deve ter acesso e quem não deve. Execute o processo de revisão com esses proprietários, documentando quais mudanças você faz e por quê.
Você começará a ver padrões — talvez a equipe de vendas sempre provisione acesso em excesso no Salesforce, ou a equipe de engenharia tenha muitas pessoas com direitos de administrador.
Registre tudo. Quantas contas você revogou? Quantas licenças você recuperou? Quais lacunas de conformidade você fechou? Essas métricas importam porque provam o ROI (Return on Investment, Retorno sobre Investimento) e mantêm seu projeto financiado.
O benefício adicional que as equipes financeiras adoram: você provavelmente encontrará licenças que pode recuperar. Alguém saiu há seis meses, mas ainda tem uma licença ativa do Salesforce? São US$ 1.800 por ano que você acabou de economizar.
Mas — e isso é crítico — não pare aqui. As revisões de acesso são um ótimo ponto de partida, mas não são o objetivo final. Elas têm limitações sérias que você precisa entender.
Por que apenas revisões de acesso não são suficientes
As revisões de acesso são fotos tiradas em um momento específico. Você as executa trimestralmente ou anualmente, o que significa que há uma lacuna enorme entre revisões onde o acesso pode derivar.
Alguém foi promovido? Eles mantêm o acesso antigo e recebem o novo. Alguém saiu? As contas ficam ativas até o próximo ciclo de revisão. Alguém mudou de departamento? Ninguém se lembra de atualizar as permissões.
A maioria das organizações executa revisões de acesso apenas em suas aplicações consideradas “em escopo” — aquelas com as quais os auditores se preocupam. Isso é adequado para conformidade, mas deixa enormes pontos cegos de segurança. Sua infraestrutura em nuvem, suas ferramentas SaaS (Software as a Service, Software como Serviço), seus ambientes de desenvolvimento — nada disso está sendo revisado, e provavelmente é onde seus maiores riscos vivem.
Há ainda outro problema: as revisões de acesso são inerentemente restritivas. Elas são projetadas para encontrar e remover acesso excessivo. Isso é bom para segurança, mas cria um problema cultural. Gerentes começam a sub-provisionar acesso porque estão preocupados com a próxima auditoria. Novos contratados não recebem tudo o que precisam porque “adicionaremos se eles realmente precisarem”. A produtividade sofre.
O real problema é que as revisões de acesso não ajudam a garantir que as pessoas tenham o acesso certo quando precisam dele. Elas só ajudam a fazer a limpeza depois. Isso não é governança — é limpeza. Então qual é o próximo passo lógico? Automatizar os processos que criam deriva de acesso em primeiro lugar.
Fase 2: Automatize o Gerenciamento do Ciclo de Vida
É aqui que o IGA começa a parecer governança real em vez de manutenção periódica.
O gerenciamento do ciclo de vida de usuários significa automatizar o que acontece quando alguém entra na empresa, muda de função ou sai. Esses são seus processos joiner-mover-leaver (entrada-mudança-saída), e se você os faz manualmente, está desperdiçando enormes quantidades de tempo enquanto cria lacunas de segurança.
Pense no que acontece hoje quando alguém entra:
- O TI recebe um chamado, provisiona manualmente as contas uma a uma, provavelmente esquece algo, e depois precisa voltar quando o novo colaborador reclama que não consegue acessar o Slack.
- Quando alguém sai, o gerente talvez se lembre de avisar o TI, que esperançosamente consegue desprovisioná-lo antes da próxima auditoria.
- Quando alguém muda de departamento, seu acesso simplesmente se acumula porque ninguém quer ser responsabilizado por quebrar algo.
A automação resolve tudo isso — e resolve de forma contínua, não apenas em pontos de verificação trimestrais.
Como isso funciona na prática: seu sistema de RH se torna a fonte de verdade.
Quando o RH cria um novo registro de funcionário, isso aciona o provisionamento automático no seu provedor de identidade. O novo colaborador obtém imediatamente seu acesso básico — e-mail, ferramentas de colaboração, o que todo mundo precisa. Eles também recebem acesso específico do departamento baseado em sua função. Engenharia recebe GitHub, vendas recebe Salesforce, finanças recebe seu ERP (Enterprise Resource Planning, Planejamento de Recursos Empresariais).
Quando alguém muda de função, o sistema detecta essa mudança e ajusta automaticamente o acesso. Quando alguém sai, suas contas são desprovisionadas imediatamente — não em três meses quando alguém finalmente conseguir fazê-lo.
Isso normalmente trata 50% ou mais do seu trabalho de provisionamento sem intervenção manual. Mais importante, isso reduz a janela de risco. Em vez de esperar semanas ou meses para remover o acesso de funcionários que saíram, isso acontece no mesmo dia.
A configuração prática envolve conectar seu sistema de RH ao seu provedor de identidade com sincronização em tempo real ou agendada. Você define o “acesso de nascimento” — o que todos recebem por padrão. Você mapeia atributos de departamento e função para acesso a aplicações. Você configura gatilhos para novas contratações, transferências e saídas. Depois monitora e refina conforme sua organização muda.
O resultado final é que sua próxima revisão de acesso é dramaticamente mais fácil porque o acesso já está majoritariamente correto. Você não está passando horas limpando contas órfãs ou descobrindo por que alguém tem acesso às ferramentas de três departamentos diferentes.
Fase 3: Gerenciamento Granular de Acesso
Até aqui trabalhamos no nível de aplicação — essa pessoa tem acesso ao Salesforce ou não? Mas isso é granularidade grossa demais para um real privilégio mínimo (least privilege).
Dentro do Salesforce, o que eles podem realmente ver? Podem ver todas as oportunidades ou apenas as suas? Podem excluir registros ou apenas lê-los? O mesmo com o Slack — eles estão nos canais da empresa ou também no canal de planejamento executivo? Seu CRM — eles podem ver dados financeiros ou apenas informações de contato?
É aqui que você passa do acesso no nível de aplicação para o acesso no nível de entitlement (direito de acesso). É mais complexo, mas é onde a segurança real acontece.
O desafio é que cada aplicação estrutura permissões de forma diferente. O Salesforce usa perfis e conjuntos de permissões. O Slack usa canais e grupos de usuários. O GitHub usa permissões de repositório e memberships de equipes. Seu ERP provavelmente tem alguma hierarquia de funções complexa que apenas três pessoas em toda a empresa entendem.
Você precisa mapear tudo isso. Para cada aplicação crítica, documente como as permissões funcionam e quem possui quais recursos. O VP de Vendas deve ser dono do acesso ao Salesforce. O Diretor de Engenharia deve ser dono dos repositórios do GitHub. O Controller Financeiro deve ser dono dos módulos do ERP.
Depois você estende sua automação para incluir essas permissões granulares. Quando alguém entra como representante de vendas, não recebe apenas o Salesforce — recebe o perfil específico e os conjuntos de permissões que representantes de vendas precisam, acesso às contas do seu território e participação nos canais Slack apropriados. Permissões de alto risco requerem fluxos de aprovação adicionais.
É também aqui que o controle de acesso baseado em funções (e outros tipos) começa a importar. Você não está mais pensando em departamentos — está pensando em funções de trabalho. Executivos de contas precisam de acesso ao Salesforce diferente dos engenheiros de vendas. Engenheiros de backend precisam de permissões no GitHub diferentes dos engenheiros de frontend.
Use os dados das suas revisões de acesso para informar isso. O resultado é um verdadeiro privilégio mínimo em escala. As pessoas têm exatamente o que precisam para fazer seu trabalho, e nada mais. Sua superfície de ataque se reduz dramaticamente.
Fase 4: Fortaleça a Segurança de Identidade
A esta altura você tem uma governança sólida em vigor. Os usuários são provisionados corretamente, desprovisionados rapidamente e têm acesso granular alinhado às suas funções. Mas você ainda está vulnerável a ataques baseados em identidade — escalada de privilégios, movimento lateral, credenciais comprometidas.
Hora de adicionar controles de segurança.
Comece com uma abordagem baseada em risco. Nem todas as aplicações são igualmente sensíveis. Seu sistema de RH com dados de salário é de alto risco. Sua wiki da empresa é de baixo risco. Seu banco de dados de produção é de alto risco. Seu ambiente de staging é de risco médio. Classifique tudo e aplique controles proporcionalmente.
Sistemas de alto risco recebem MFA (Multi-Factor Authentication, Autenticação Multifator) obrigatório, fluxos de aprovação mais rigorosos e monitoramento adicional. Sistemas de risco médio recebem controles padrão. Sistemas de baixo risco recebem higiene básica de segurança.
Para usuários privilegiados — administradores de banco de dados, engenheiros de infraestrutura, membros da equipe de segurança — implemente acesso com prazo limitado para sistemas críticos com trilhas de auditoria completas. Quando um DBA (Database Administrator, Administrador de Banco de Dados) precisar de acesso ao banco de dados de produção, ele solicita, recebe aprovação, o acesso é concedido pelo tempo exatamente necessário (talvez quatro horas) e depois revogado automaticamente.
Implante monitoramento contínuo e detecção de anomalias. Se alguém que normalmente acessa três aplicações de repente começa a acessar vinte, isso é suspeito. Se alguém está fazendo login de um novo país, isso merece investigação. Se permissões estão sendo alteradas fora dos seus fluxos de trabalho padrão, você precisa saber imediatamente.
Não se esqueça do shadow IT (TI paralelo). Você protegeu todas as suas aplicações conhecidas, mas suas equipes provavelmente estão usando ferramentas SaaS que você nem conhece. Implante ferramentas de descoberta para encontrá-las e decida se vai integrá-las ao seu framework de IGA ou bloqueá-las. De qualquer forma, você precisa de visibilidade.
Fase 5: Habilite Solicitações de Acesso por Autoatendimento
É aqui que você passa de controlar o acesso para habilitar velocidade de negócios — sem sacrificar segurança.
Atualmente, quando alguém precisa de acesso a uma nova ferramenta, provavelmente abre um chamado, espera o TI vê-lo, espera aprovações, espera o provisionamento. Isso leva dias ou semanas. As pessoas contornam o problema compartilhando credenciais (terrível) ou simplesmente não usando as ferramentas de que precisam (também terrível).
O autoatendimento resolve isso. Crie um portal onde os funcionários possam solicitar acesso a aplicações, funções ou recursos específicos. Eles selecionam o que precisam, fornecem justificativa e submetem.
A solicitação é roteada automaticamente para os aprovadores adequados — seu gerente, o proprietário da aplicação, talvez uma revisão de segurança para acesso de alto risco. Uma vez aprovado, o acesso é provisionado automaticamente através dos seus fluxos de trabalho existentes.
Isso não é acesso livre. Você ainda está aplicando políticas e cadeias de aprovação. Solicitações de alto risco requerem justificativa completa e múltiplas aprovações. Mas você está eliminando o embaralhamento manual de chamados e reduzindo os tempos de espera de semanas para horas.
Registre tudo. Quem está solicitando o quê? Existem padrões que você deveria automatizar? Algumas solicitações são consistentemente negadas? Há gargalos no processo de aprovação? Use esses dados para melhorar continuamente.
Como as Cinco Fases se Constroem Umas sobre as Outras
As revisões de acesso oferecem visibilidade e resultados rápidos de conformidade. Você agora sabe quem tem qual acesso e limpou os piores problemas.
O gerenciamento do ciclo de vida automatiza os processos que criam deriva de acesso. Novos contratados são provisionados corretamente, funcionários que saem são desprovisionados imediatamente, e mudanças de função atualizam o acesso automaticamente.
O gerenciamento granular de acesso estende a governança para dentro das próprias aplicações. Você não está apenas controlando quem tem o Salesforce — está controlando o que eles podem fazer no Salesforce.
A segurança de identidade adiciona prevenção de ameaças e monitoramento. Você não está apenas gerenciando acesso — está detectando e prevenindo uso indevido.
As solicitações de autoatendimento dão agilidade às equipes de negócios mantendo supervisão. Você está habilitando produtividade, não bloqueando-a.
Cinco Princípios de Implementação que Determinam o Sucesso
Faça o rollout em fases. Não tente implementar tudo em todo lugar de uma vez. Comece com um grupo piloto ou um único departamento, aprenda o que funciona, conserte o que não funciona e depois expanda. Implementações de IGA falham quando as organizações tentam resolver tudo de uma vez no primeiro dia.
Seu IGA é tão bom quanto seus dados de identidade. Se seu sistema de RH tem informações desatualizadas, departamentos errados ou dados de função ausentes, tudo que vem depois quebra. Invista na limpeza de dados cedo. É um trabalho tedioso, mas é fundamental.
Defina propriedade clara. Quem é dono de cada aplicação? Quem aprova solicitações de acesso? Quem é responsável por revisar entitlements? Sem propriedade clara, seu framework de governança se torna uma bagunça burocrática onde ninguém assume responsabilidade por nada.
Acompanhe métricas que importam. Não apenas conte o número de revisões de acesso concluídas. Acompanhe tempo economizado, contas órfãs removidas, violações de política detectadas e tempo de provisionamento para novos contratados. Essas métricas provam o ROI e ajudam você a melhorar continuamente.
Mantenha-se ágil. Seu cenário de identidade muda constantemente — novas aplicações, aquisições, mudanças organizacionais, novos requisitos de conformidade. Seu programa de IGA precisa se adaptar. Isso não é um projeto de “configure e esqueça”.
IGA como Habilitador de Negócios, Não Apenas Controle de Segurança
IGA não é sobre implementar ferramentas ou marcar caixas de conformidade. É sobre construir um framework que permite ao seu negócio se mover rapidamente enquanto permanece seguro.
Um bom IGA significa que sua equipe de vendas pode provisionar um novo representante e tê-lo produtivo no primeiro dia. Significa que sua equipe financeira sabe exatamente quem pode acessar dados financeiros sensíveis. Significa que sua equipe de segurança pode provar a auditores que você tem controles adequados em vigor. Significa que quando alguém sai, eles perdem acesso imediatamente em vez de permanecer nos seus sistemas por meses.
Mais importante, um bom IGA significa que sua organização pode adotar novas tecnologias, entrar em novos mercados e responder a oportunidades sem que a segurança se torne um gargalo.
Comece com vitórias rápidas, construa momentum, automatize o trabalho repetitivo e depois adicione sofisticação ao longo do tempo. É assim que você constrói um IGA que realmente funciona.
O que essa estratégia significa para empresas brasileiras — e como a WebSIA atua
A abordagem fase a fase descrita pela Zluri responde a um problema real enfrentado por equipes de TI no Brasil: o IGA é frequentemente tratado como um projeto único e monolítico, quando na prática precisa ser construído de forma iterativa. Organizações que tentam implementar governança de identidade de uma vez encontram resistência cultural, dados de identidade inconsistentes e dificuldade em demonstrar valor ao negócio. A metodologia da Zluri resolve isso ao estruturar o rollout em cinco fases progressivas — cada uma com entregáveis tangíveis e ROI mensurável — o que facilita a aprovação interna e o engajamento das áreas de negócio.
O contexto regulatório brasileiro reforça ainda mais a urgência desse tema. A LGPD (Lei Geral de Proteção de Dados) exige que as organizações demonstrem controle sobre quem acessa dados pessoais e sensíveis — exatamente o que um IGA bem implementado garante. Somado a isso, o crescimento acelerado do ambiente SaaS nas empresas brasileiras cria um desafio crescente de visibilidade: aplicações adquiridas por times de negócios sem envolvimento do TI (o shadow IT mencionado na Fase 4) são pontos cegos de risco que auditores e reguladores estão cada vez mais atentos.
A WebSIA é a parceira exclusiva da Zluri no Brasil, responsável pela implementação, integração e suporte consultivo da plataforma para organizações brasileiras. Isso significa que a execução prática da metodologia descrita neste artigo — desde a conexão do sistema de RH ao provedor de identidade até a configuração de fluxos de aprovação e detecção de anomalias — é conduzida pela WebSIA. A WebSIA atua em toda a jornada: mapeamento do ambiente de identidade atual, definição do modelo de acesso e roles, integração com SIEM e outras ferramentas de segurança, e capacitação das equipes internas para operar o ambiente de IGA de forma sustentável.
A tecnologia sozinha não garante governança. A Zluri entrega a plataforma — a WebSIA garante que ela seja implementada corretamente no contexto de cada organização, com dados de identidade limpos, integração funcional com o ecossistema existente e adoção real pelas equipes de TI e negócios. Para empresas que ainda fazem revisões de acesso de forma manual ou que lidam com provisionamento reativo, este é o momento de estruturar uma governança de identidade que escale com o crescimento do negócio.
Converse com um especialista da WebSIA sobre como implementar IGA na sua organização
