Como acertar no seu projeto de IGA: comece pelas personas

Por que os projetos de IGA fracassam mais do que deveriam

A Identity Governance and Administration (IGA) já existe há tempo suficiente para que se esperasse uma taxa de fracasso baixa. Os conceitos são bem estabelecidos, as principais plataformas são maduras, e não faltam profissionais que já as implementaram antes. E, no entanto, os projetos continuam estourando prazos, ficando aquém do escopo original ou entregando uma solução que funciona, mas não exatamente para aquela organização.

Os motivos tendem a se agrupar em torno de um conjunto conhecido de temas.

O apoio da liderança executiva é muito citado, e realmente importa. Sem comprometimento da alta administração, os projetos ficam vulneráveis a serem reduzidos quando os orçamentos apertam ou as prioridades mudam.

As metas do programa são outro culpado comum: ou os objetivos foram estabelecidos de forma ambiciosa demais em relação ao que a tecnologia consegue realmente entregar, ou nunca foram precisos o suficiente para serem mensuráveis desde o início.

Os prazos de entrega escorregam quando o planejamento é sacrificado em favor de apresentar algo rapidamente às partes interessadas. As escolhas tecnológicas dão errado quando a avaliação é conduzida por demonstrações de fornecedores em vez de requisitos documentados. É fácil se deixar atrair por uma plataforma repleta de funcionalidades e descobrir depois que as funcionalidades realmente necessárias eram justamente as que exigiam mais personalização. Os custos estouram quando os requisitos mudam no meio da implementação, ou quando o esforço de configuração e integração é subestimado desde o início.

Todos esses são problemas reais, e todos já foram amplamente discutidos. Mas há um modo de falha que costuma passar despercebido por trás de vários dos outros, e que recebe muito menos atenção: o projeto nunca estabeleceu claramente para quem estava sendo construído.

A maioria dos projetos de IGA com dificuldades pode atribuir ao menos parte do problema a suposições feitas logo no início sobre os tipos de usuários, identidades e cenários de acesso que a solução precisaria tratar, suposições que se revelaram equivocadas.

A solução não é complicada, mas exige disciplina. Ela consiste em começar o projeto construindo um panorama completo do seu cenário de identidades, não da tecnologia, não das integrações, não dos fluxos de trabalho. Apenas as pessoas e identidades que o seu programa de governança precisa cobrir. Tudo o mais decorre disso.

O restante deste artigo explica como construir esse panorama do seu cenário de identidades e por que fazer isso faz uma diferença maior do que a maioria das organizações espera.

Então você está avaliando Identity Governance

A tecnologia em si raramente é o motivo pelo qual os projetos de IGA enfrentam dificuldades: a causa raiz é quase sempre começar por um produto em vez de entender as pessoas.

Seja porque você foi convidado a avaliar uma plataforma de IGA, seja porque já está no meio do projeto e as coisas estão ficando complicadas, você provavelmente já percebeu que a tecnologia geralmente não é a parte difícil.

As plataformas de IGA (o software que controla quem tem acesso a quê, automatiza a admissão e o desligamento, e garante que alguém revise esses direitos de acesso periodicamente) são maduras, bem compreendidas e amplamente capazes. A maioria das principais plataformas trata os casos de uso essenciais sem muitos problemas.

Então, por que tantos projetos de IGA estouram o orçamento, demoram mais do que o esperado, ou acabam com uma solução que não se encaixa bem?

Em nossa experiência, quase sempre volta à mesma causa raiz: a organização começou escolhendo um produto em vez de entender suas pessoas.

A coisa mais valiosa que você pode fazer antes de avaliar um único fornecedor é entender quem realmente trabalha na sua organização e como é a relação dessas pessoas com a identidade.

Não é tão simples quanto "funcionário entra, funcionário sai"

Na superfície, o IGA parece simples. Alguém entra na empresa e recebe contas. Alguém sai e essas contas são desativadas. No meio do caminho, alguém verifica periodicamente se as pessoas ainda precisam do que têm.

A realidade na maioria das organizações é consideravelmente mais confusa. Considere algumas das perguntas que costumam surgir assim que um projeto está em andamento:

O que acontece com prestadores de serviço e funcionários de agência? Eles aparecem no seu sistema de RH? Se não, de onde a plataforma de IGA obtém os dados deles?

E os fornecedores terceirizados que precisam de acesso a sistemas específicos? Como são admitidos e quem gerencia o ciclo de vida deles?

Você tem funcionários que atuam em múltiplas entidades legais ou regiões, possivelmente com papéis diferentes em cada uma?

Existem contas de serviço, contas compartilhadas ou identidades de máquina que precisam ser governadas junto com os usuários humanos?

E os usuários em funções sensíveis (executivos, equipes financeiras, administradores de TI) que podem precisar de controles mais rígidos ou processos de aprovação diferentes?

Alguma das suas personas carrega acesso sobre o qual um regulador ou auditor perguntará especificamente, e isso muda a forma como as permissões precisam ser revisadas ou documentadas?

As permissões devem durar para sempre, ou algumas permissões, especialmente as sensíveis, devem ter duração limitada?

Nenhum desses é um caso excepcional. Em qualquer organização com mais de algumas centenas de pessoas, eles são a regra. E se a plataforma de IGA escolhida não foi avaliada em relação a eles, você vai descobrir isso da forma mais difícil, geralmente durante a implementação, quando mudar de direção sai caro.

Chega a persona

Em termos de governança de identidade, uma persona é um tipo distinto de usuário cujo ciclo de vida de identidade, requisitos de acesso ou fontes de dados diferem significativamente de outros: não pessoas individuais, mas tipos de pessoas.

Existe uma técnica que faz parte da análise estruturada de sistemas há décadas, emprestada originalmente da engenharia de software, que se encaixa perfeitamente para resolver esse problema. Ela recebe nomes diferentes - personas de usuário, atores, arquétipos de identidade - mas a ideia é simples.

Antes de definir o que um sistema precisa fazer, você primeiro define todos os diferentes tipos de pessoas (e não pessoas) que o sistema precisa atender.

Em nossa experiência, uma organização de médio porte tipicamente identifica entre trinta e cinquenta personas de identidade distintas. Para organizações de saúde, educação ou varejo, esse número pode facilmente dobrar.

Alguns exemplos para dar vida a isso:

Um funcionário permanente que entra pelo seu sistema de RH, com uma jornada de admissão padrão, aprovação do gestor direto e um conjunto definido de acessos básicos padrão.

Um prestador contratado por meio de uma agência, cujo registro vive em uma planilha ou portal de fornecedores em vez de no RH, e que pode trabalhar para múltiplos clientes simultaneamente.

Um estudante ou estagiário com um vínculo por prazo determinado e um acesso que precisa expirar de forma limpa ao final do estágio.

Um usuário de TI com privilégios que mantém contas administrativas que precisam de escrutínio elevado, controles de segregação e, potencialmente, acesso just-in-time em vez de permissões permanentes.

Uma identidade não humana, como uma conta de serviço de aplicação ou uma integração de API, que possui permissões, precisa ser governada e definitivamente não vai preencher um formulário de solicitação de acesso self-service.

Cada uma dessas personas interagirá de forma diferente com sua plataforma de IGA. Algumas serão admitidas automaticamente a partir de um sistema de origem. Outras precisarão de processos manuais ou fontes de dados alternativas. Algumas precisarão de cadeias de aprovação especializadas; outras precisarão que o acesso expire conforme um cronograma.

Por que isso importa para a seleção da plataforma

Depois que você tem sua lista de personas, seus requisitos praticamente se escrevem sozinhos.

Você para de perguntar "essa plataforma suporta admissão/mudança/desligamento?" (todas dizem que sim) e passa a fazer perguntas muito mais específicas:

Ela consegue ingerir dados de identidade de múltiplas fontes, como HRIS, planilhas, LDAP e endpoints SCIM, e reconciliá-los em um único registro de identidade?

Ela consegue lidar com identidades que não têm nenhum registro de RH, usando um fluxo de admissão separado?

Ela consegue aplicar políticas de governança diferentes a diferentes tipos de usuário, de modo que seus prestadores tenham um ciclo de revisão de acesso de 90 dias enquanto seus usuários com privilégios tenham um mensal?

Quando alguém muda de função, ela consegue calcular a diferença e provisionar ou desprovisionar as coisas certas sem intervenção humana e sem criar direitos órfãos?

Ela consegue sinalizar quando alguém acumula uma combinação de direitos de acesso que representa um risco, mesmo que cada direito individual parecesse inofensivo quando foi concedido? Ela consegue mostrar a um auditor por que o acesso de cada persona foi aprovado e por quem, em uma cadência de revisão compatível com o risco que essa persona representa?

Uma plataforma de IGA bem projetada deveria conseguir lidar com tudo isso. O exercício das personas mostra quais dessas capacidades são genuinamente críticas para a sua organização e quais são apenas desejáveis.

Ele também mostra o que pedir para ser demonstrado ao avaliar fornecedores. Em vez de assistir a uma apresentação genérica do produto, você pode entregar ao fornecedor um conjunto de personas e pedir que ele mostre, especificamente, como sua plataforma trata cada uma delas.

O exercício das personas transforma a avaliação de um fornecedor de uma comparação de funcionalidades em um teste real de capacidade. É muito mais difícil esconder uma lacuna quando você pediu um cenário específico em vez de uma capacidade geral.

Como fica uma boa implementação na prática

Quando você vê uma implementação de IGA bem configurada, o pensamento baseado em personas fica visível na arquitetura. Diferentes tipos de identidade seguem caminhos de admissão diferentes. O acesso é atribuído com base em função e contexto, não em listas curadas manualmente. Quando as circunstâncias de alguém mudam (uma promoção, uma transferência, uma extensão de contrato), a plataforma responde automaticamente.

As revisões de acesso têm escopo definido de forma inteligente: as pessoas certas revisam os direitos certos, em uma cadência apropriada ao nível de risco. Quando um revisor identifica algo que não deveria estar ali, a remoção é automática e auditável. Quando o acesso é necessário com urgência, existe um fluxo de solicitação e aprovação que deixa um rastro claro.

Combinações sensíveis de acesso (por exemplo, a capacidade de gerar um pedido de compra e também aprová-lo) são identificadas proativamente, não descobertas durante uma auditoria. As exceções são gerenciadas com supervisão, em vez de se acumularem silenciosamente.

Nada disso exige uma plataforma particularmente exótica. O que exige é que alguém, no início do projeto, tenha se dedicado a entender quais tipos de pessoas e identidades a organização realmente tem, e tenha projetado a solução em torno delas.

O retorno aparece em todos os pontos em que o acesso toca o negócio: os direitos se movem mais rápido porque não precisam de intervenção manual, são mais precisos porque estão ligados ao contexto em vez de a listas estáticas, e a conformidade deixa de ser uma correria porque as evidências foram capturadas conforme o trabalho acontecia, não reconstruídas depois.

A vantagem prática

Além de tornar seu projeto de IGA mais propenso a ter sucesso, o exercício das personas traz alguns efeitos colaterais úteis.

Ele também beneficia outros projetos. A identidade toca praticamente tudo em uma organização. Sua lista de personas será igualmente útil ao avaliar soluções de Privileged Account Management (PAM), ferramentas de gerenciamento de endpoints, ou qualquer outra coisa que precise saber quem são seus usuários e o que eles fazem.

Ele facilita as conversas com as partes interessadas. Quando você pode se referir a "a persona do prestador" ou "a persona do administrador com privilégios" em vez de descrever um requisito técnico abstrato, a conversa se torna mais concreta. As partes interessadas do negócio entendem personas de um jeito que nem sempre entendem esquemas de direitos de acesso.

Ele gera uma entrada natural para a governança do projeto. Se você usa uma matriz RACI (Responsible, Accountable, Consulted, Informed) para gerenciar as responsabilidades do projeto, sua lista de personas fornece a matéria-prima. Por trás de cada persona há um dono do negócio, um responsável técnico e um conjunto de partes interessadas, todos os quais precisam ser consultados, informados ou diretamente envolvidos.

Onde uma plataforma como o Netwrix Identity Manager se encaixa

Nada disso é motivo para adiar a escolha de uma plataforma. É motivo para escolher uma construída para trabalhar do jeito que sua lista de personas funciona, não contra ela.

O Netwrix Identity Manager governa identidades internas, externas, de convidados, técnicas, de IoT e de agentes de IA sob o mesmo modelo, de modo que um prestador vindo de uma planilha, uma conta de serviço da qual ninguém no RH jamais ouviu falar, um agente de IA provisionando seu próprio acesso, e um funcionário permanente que chega pelo seu feed de RH recebem todos a mesma disciplina de ciclo de vida, em vez de quatro soluções alternativas diferentes. Identidades de terceiros e não humanas têm seu próprio caminho de ciclo de vida, incluindo acesso limitado no tempo que expira conforme o previsto, em vez de persistir depois que um contrato ou estágio termina. A admissão de novos sistemas também não exige um projeto de integração sob medida: conectores padrão cobrem AD, LDAP, SQL, CSV e SCIM prontos para uso, com conectores avançados e APIs genéricas disponíveis para qualquer coisa mais específica do seu ambiente.

O gerenciamento de funções funciona da mesma forma. Você define modelos de função e política por persona em vez de uma única política para todos, e o role mining usa machine learning para analisar padrões reais de acesso, descobrir estruturas de função e manter o modelo atualizado à medida que o uso muda, de modo que ele não apenas reflita o organograma do dia em que foi criado.

O lado do risco é construído para essa mesma realidade. Um mecanismo de políticas detecta e previne conflitos de segregação de funções, e o monitoramento contínuo sinaliza contas órfãs e anomalias antes que surjam em uma auditoria, em vez de depois.

Nada disso substitui o exercício das personas. É o que torna possível uma transição rápida do design para a implementação: cada identidade é definida e governada em seus próprios termos, em vez de ser forçada por um único canal e remendada com exceções para se encaixar. O resultado é menor risco, implementação mais rápida e menor custo.

Em resumo

As plataformas de Identity Governance são maduras e capazes. A tecnologia geralmente não é o que faz os projetos terem dificuldades. O que faz os projetos terem dificuldades é começar por um produto e tentar encaixar a realidade da organização nele depois.

A alternativa (identificar primeiro suas personas de identidade, usá-las para definir os requisitos e então avaliar as plataformas em relação a esses requisitos) soa óbvia quando descrita. Mas é surpreendentemente rara na prática, e a lacuna que ela preenche é significativa.

Ela não exige ferramentas especializadas nem conhecimento técnico profundo. Exige tempo, boas perguntas e a disposição de envolver as pessoas certas de toda a empresa desde o início do processo.

Acerte nas personas, e o restante do projeto se torna consideravelmente mais simples. Erre nelas, ou pule essa etapa por completo, e você pode acabar adaptando uma solução, depois do fato, a um problema que não entendeu totalmente quando a comprou.

Você está tendo problemas com o seu programa de identidade? Podemos ajudá-lo a entender suas personas e como o Netwrix Identity Manager pode tornar seu projeto bem-sucedido. Solicite uma demo.