Vamos trazer primeiramente um fato: a maioria dos projetos de IGA ou de PAM não nasce porque a organização decidiu evoluir sua maturidade de segurança. Eles normalmente aparecem por dois motivos muito claros: atendimento a uma exigência regulatória ou reação a um incidente de segurança. Alguém auditou, alguém perguntou quem tem acesso a quê, ou pior, alguém entrou onde não deveria.
A partir daí o projeto chega na mesa da diretoria. E quem já participou desse momento sabe o que acontece. Quando olhamos as soluções do mercado, os custos são altos, as implementações são complexas e rapidamente surge a pergunta que todo executivo faz: qual é o ROI disso?
E aqui está a primeira verdade desconfortável. Projetos de identidade raramente se pagam olhando apenas para eficiência financeira. Em alguns casos conseguimos falar em redução de esforço operacional ou redução de contas privilegiadas, mas o verdadeiro objetivo é outro: reduzir risco. Reduzir fraude, reduzir vazamento de informação sensível e reduzir o abuso de identidades privilegiadas.
O problema é que quando a implementação começa, a realidade aparece. O ambiente é grande demais, existem sistemas demais, integrações demais, exceções demais. Então o projeto precisa fazer escolhas. E essas escolhas criam o que eu gosto de chamar de zona cinzenta da identidade.
Nunca vi um projeto de IGA automatizar 100% do ambiente. Quase sempre ele cobre uma parcela dos sistemas. Muitas vezes os considerados “críticos”. O resto continua no processo manual, dependendo de e-mail, planilha, ITSM, muitos recursos, não executam revisões de acesso ou boa vontade de alguém aprovar ou remover acesso(Olha as contas órfãs ai!!!).
Imagine o primeiro cenário. Uma empresa possui 100 sistemas. O BIA define que apenas 10 são críticos. São esses que entram no projeto de governança de acesso. Os outros 90 permanecem fora. A pergunta é simples: eles realmente não são críticos ou apenas ainda não foram explorados por um atacante?
Agora pense em outro cenário comum. A organização implementa um PAM para proteger acessos ao banco de dados ou aos servidores de produção. Parece correto. Mas os ambientes de homologação, testes ou desenvolvimento ficam de fora. E nesses ambientes, muitas vezes, existem cópias de bases produtivas, dados sensíveis mascarados de forma incompleta ou até credenciais reutilizadas.
É nesse ponto que mora o lado escuro dos projetos de identidade.
Criamos uma ilha de controle que nos dá a sensação de segurança, enquanto uma parte significativa do ambiente continua operando da mesma forma que antes. Automatizamos o que conseguimos justificar no orçamento e deixamos o restante na expectativa de uma fase dois que muitas vezes nunca chega e é mantida manualmente (Devido a custo).
O mercado reforça essa complexidade onde as organizações acabam adotando diversas ferramentas isoladas para resolver partes diferentes do problema de identidade, o que gera sobreposição de funcionalidades, custos elevados e lacunas operacionais entre os controles.
Enquanto isso, o ambiente continua crescendo. Novos sistemas aparecem, integrações surgem, APIs se multiplicam e identidades de máquinas passam a superar em muito, muito e muito o número de usuários humanos, ampliando ainda mais a superfície de ataque se não houver governança adequada.
Então a provocação que sempre deixo é simples.
O verdadeiro desafio de identidade não está apenas em implementar IGA ou PAM. Está em entender até onde vai o seu controle e, principalmente, onde ele termina, porque muitas vezes o risco não está no sistema que você protegeu, ele está exatamente naquele que ficou de fora do projeto.
E no mundo da segurança atualmente, o atacante está entrando pela porta da frente se passando pelo José que é um colaborador, terceiro ou uma identidade não humana.
