O que e Identidade Digital

No mundo fisico, sua identidade e provada por documentos, rosto, voz. No mundo digital, identidade e um conjunto de atributos e credenciais que representam uma entidade — pessoa, sistema ou dispositivo — em ambientes de TI. Entender profundamente o que e uma identidade digital e o alicerce de tudo em IAM.

Identidade nao e so pessoa

Um erro comum de quem esta comecando em IAM e pensar que "identidade" significa apenas "usuario humano". Na pratica moderna, identidades digitais abrangem quatro categorias distintas, cada uma com seus proprios desafios de governanca.

Identidades humanas — a maioria, mas nao todas

Sao as mais familiares: colaboradores, terceiros, clientes, parceiros. Cada pessoa que precisa acessar sistemas corporativos precisa de uma identidade digital. O desafio e que essas identidades mudam constantemente — pessoas sao admitidas, promovidas, transferidas, desligadas — e cada mudanca precisa se refletir nos acessos.

Terceiros merecem atencao especial: prestadores de servico com acesso a sistemas criticos representam um risco significativo pois nao estao sob o mesmo controle que colaboradores diretos. Um contrato encerrado precisa gerar desligamento imediato — algo que processos manuais frequentemente falham em garantir.

Identidades de servico — a parte mais perigosa

Service accounts, APIs e processos automatizados tambem sao identidades. Elas nao tem um humano por tras — sao scripts, integrações, robos de automacao. O problema e que essas identidades frequentemente acumulam privilégios enormes (precisam acessar varios sistemas) e raramente passam por revisao.

Uma service account criada para uma integracao temporaria e esquecida durante anos — com permissoes de administrador — e um vetor de ataque classico. O atacante que compromete essa conta tem acesso amplo sem que ninguem perceba, pois nao ha comportamento humano anomalo para detectar.

Atributos: o que define uma identidade

Uma identidade e muito mais do que um nome e uma senha. E um conjunto rico de atributos que descrevem essa entidade e determinam quais acessos ela deve ter. Em uma plataforma IGA, esses atributos sao coletados de multiplas fontes e consolidados no que chamamos de cubo de identidades.

Fonte de verdade — quem manda no dado?

Em qualquer ambiente de IAM, um dos primeiros principios a definir e qual sistema e a fonte autoritativa (Source of Authority) para cada atributo de identidade. Quando um dado aparece em dois sistemas com valores diferentes, qual prevalece?

A resposta nao e trivial e precisa ser definida explicitamente. Na maioria das organizacoes, o sistema de RH e a fonte autoritativa para dados pessoais e organizacionais (cargo, departamento, gestor, status de emprego). O Active Directory pode ser fonte autoritativa para o login. Um sistema de identidade federado pode ser fonte para dados de parceiros.

Identidade vs. Conta vs. Entitlement

Tres conceitos fundamentais em IGA que precisam estar clarissimos antes de avancar:

Uma identidade e a entidade real (Maria Souza, matricula EMP-00123). Uma conta e a representacao dessa identidade em um sistema especifico (maria.souza no Active Directory, msouza no ERP, maria_souza no CRM). Um entitlement e a permissao especifica concedida a uma conta (perfil "Aprovador de Pagamentos" no ERP).

Uma identidade pode ter dezenas de contas em diferentes sistemas. Cada conta pode ter dezenas de entitlements. O papel da IGA e correlacionar todas essas contas a uma unica identidade e garantir que o conjunto total de entitlements seja apropriado, revisado e conformes.

Evolucao: do IDM ao IGA Moderno

A gestao de identidades passou por cinco ondas de evolucao nas ultimas tres decadas. Cada onda foi forcada por uma combinacao de pressoes tecnologicas, regulatorias e de negocio. Entender essa historia explica por que os sistemas de IGA modernos sao como sao — e para onde estao indo.

Era dos diretorios — os anos 1990

Nas empresas dos anos 1990, cada sistema de TI tinha seu proprio repositorio de usuarios. O servidor de e-mail tinha sua lista de contas. O sistema financeiro tinha a sua. O servidor de arquivos tinha outra. Nao havia comunicacao entre eles.

O protocolo LDAP (Lightweight Directory Access Protocol), criado em 1993, foi uma revolucao: criou um padrao para consultar diretorios de identidade de forma centralizada. O Novell Directory Services (NDS) e o precursor do Active Directory foram os primeiros diretorios corporativos amplamente adotados.

O problema era que cada sistema ainda precisava ser gerenciado separadamente. Quando um colaborador era admitido, o administrador criava manualmente uma conta no AD, outra no sistema financeiro, outra no ERP. Quando era desligado, o risco era que algum sistema fosse esquecido.

IDM e metadiretorios — os anos 2000

Com dezenas, depois centenas de sistemas, a gestao manual tornou-se operacionalmente insustentavel. Surgiram os sistemas de Identity Management (IDM), com o conceito de metadiretorio: um repositorio central que sincronizava identidades automaticamente com todos os outros sistemas.

Produtos como Sun Identity Manager, IBM Tivoli Identity Manager e Novell Identity Manager dominaram essa epoca. A promessa era: altere o dado uma vez no metadiretorio, e todos os sistemas sao atualizados automaticamente.

Essa foi uma avanco imenso operacionalmente. Mas esses sistemas eram ferramentas pesadas, caras, exigiam especialistas dedicados e foco em provisionamento tecnico — nao em governanca. A pergunta "esse acesso e apropriado?" ainda era respondida manualmente, se e que era respondida.

Primeira geracao de IGA — regulamentacao como catalisador

Em 2002, o escandalo Enron sacudiu os mercados financeiros americanos. Executivos haviam manipulado sistemas contabeis para esconder fraudes bilionarias. O Congresso americano respondeu com a Lei Sarbanes-Oxley (SOX), que exigia que empresas de capital aberto provassem, atraves de evidencias auditaveis, que tinham controles sobre quem acessava sistemas financeiros criticos.

Essa exigencia criou a demanda para uma nova categoria de software: ferramentas que nao apenas provisionassem acessos, mas que governassem esses acessos — mantendo historico, executando revisoes periodicas, detectando conflitos de SoD e gerando relatorios para auditores.

A SailPoint Technologies foi fundada em 2005 por ex-executivos da Waveset (adquirida pela Sun) para preencher exatamente essa lacuna. Aveksa, depois adquirida pela RSA, foi outra pioneira. Pela primeira vez, usuarios de negocio — nao apenas administradores de TI — passaram a ser parte do processo: gestores revisando acessos de suas equipes, donos de aplicacao aprovando solicitacoes.

IGA em nuvem — a era do SaaS e do SCIM

A virada para a nuvem nos anos 2010 criou novos desafios. Uma empresa tipica passou a usar dezenas de aplicacoes SaaS — Salesforce, Workday, ServiceNow, Box, Slack — cada uma com seu proprio sistema de identidades. Os conectores tradicionais (LDAP, JDBC) nao funcionavam para sistemas cloud.

Em 2015, o SCIM 2.0 (System for Cross-domain Identity Management) foi publicado como padrao aberto, criando um protocolo REST padronizado para provisionamento em nuvem. Hoje, praticamente todo SaaS enterprise suporta SCIM.

Ao mesmo tempo, OAuth 2.0 e OpenID Connect tornaram-se os padroes de autorizacao e autenticacao federada para APIs e aplicacoes web. JWT (JSON Web Token) substituiu SAML em muitos cenarios. O ecosistema de identidade modernizou-se profundamente.

O conceito de CIAM (Customer Identity and Access Management) emergiu para tratar das especificidades de identidades de clientes: escala de milhoes de usuarios, preferencias de privacidade, login social (Google, Facebook), e experiencia de usuario como prioridade.

IGA moderno com IA — a era atual

A partir de 2020, tres forcas convergiram para criar a geracao atual de IGA: a disponibilidade de machine learning como servico, pressoes regulatorias de privacidade como LGPD e GDPR, e a adocao massiva de Zero Trust como framework de seguranca.

As plataformas de IGA modernas — SailPoint IdentityNow, Saviynt, One Identity Starling — deixaram de ser ferramentas de provisionamento e se tornaram plataformas de governanca continua. Algumas caracteristicas desta geracao:

• Role mining automatico: algoritmos de ML analisam padroes de acesso e sugerem papeis de negocio sem configuracao manual.
• Recomendacoes de certificacao: IA sugere "aprovar" ou "revogar" para cada item, reduzindo o tempo de revisao em ate 80%.
• Deteccao de anomalias em tempo real: comportamento incomum de uma conta e sinalizado imediatamente, sem esperar pela proxima campanha de certificacao.
• ITDR integrado: deteccao e resposta a ameacas de identidade como extensao nativa da plataforma IGA.
• Governanca de identidades nao-humanas: service accounts, bots e identidades cloud gerenciadas com o mesmo rigor que identidades humanas.

O que e IAM

Identity and Access Management (IAM) e o conjunto de processos, politicas e tecnologias que garantem que as pessoas certas tenham acesso aos recursos certos, no momento certo, pelas razoes certas. E uma disciplina, nao um produto — embora existam muitos produtos que a implementam.

A definicao em profundidade

A frase "pessoas certas, recursos certos, momento certo" parece simples, mas cada parte esconde complexidade operacional significativa:

• "Pessoas certas" — requer identificar univocamente cada entidade (pessoa, sistema, dispositivo) e verificar sua identidade de forma confiavel.
• "Recursos certos" — requer mapear todos os ativos que precisam de controle de acesso (sistemas, aplicacoes, dados, APIs) e definir quem pode acessar o que com qual nivel de permissao.
• "Momento certo" — requer que acessos sejam provisionados quando necessarios (admissao, mudanca de funcao) e revogados quando nao mais necessarios (desligamento, mudanca de area).
• "Razoes certas" — requer governanca: documentar, justificar e revisar periodicamente por que cada acesso foi concedido.

Por que IAM e critico — os numeros

IAM nao e uma preocupacao abstrata de seguranca. Os dados sao contundentes:

• Segundo o Verizon DBIR 2024, 74% das violacoes de dados envolvem o elemento humano — credenciais comprometidas, phishing ou abuso de privilegios.
• O Ponemon Institute estima que o custo medio de uma violacao de dados e USD 4,45 milhoes — 15% maior do que 3 anos atras.
• O Gartner aponta que 75% das falhas de seguranca em organizacoes sao resultado de gerenciamento inadequado de privilegios.
• Segundo a IBM, violacoes que envolvem credenciais roubadas demoram em media 328 dias para ser identificadas e contidas — mais do dobro da media geral.

As subdisciplinas do IAM

Autenticacao

Autenticacao e o processo de verificar que uma identidade e realmente quem afirma ser. E a porta de entrada de todo sistema de IAM — antes de qualquer decisao de autorizacao, precisa-se ter certeza de que o usuario e genuino. E o primeiro e mais critico controle de seguranca.

Autenticacao nao e autorizacao

Confusao comum, importante desfazer logo: autenticacao responde "quem e voce?". Autorizacao responde "o que voce pode fazer?". Sao processos distintos, embora ocorram em sequencia.

Voce pode estar autenticado (o sistema sabe quem voce e) mas nao autorizado (voce nao tem permissao para aquele recurso especifico). Da mesma forma, sem autenticacao, nao ha como tomar uma decisao de autorizacao — nao se sabe para quem autorizar.

Os tres fatores de autenticacao

Todo mecanismo de autenticacao se baseia em um ou mais de tres categorias de fatores. A distinção entre as categorias e o que torna o MFA eficaz — combinar dois fatores da mesma categoria nao e MFA.

Por que apenas senha e insuficiente

Senhas sao o elo mais fraco da autenticacao. Usuarios reutilizam senhas entre servicos (62% segundo estudos), escolhem senhas fracas, caem em phishing, e senhas vazadas em uma plataforma sao testadas automaticamente em outras (credential stuffing). Uma senha de 8 caracteres pode ser quebrada por forca bruta em menos de 1 hora com hardware moderno.

Pior: no contexto corporativo, uma senha comprometida da acesso nao apenas a um sistema, mas a todos os sistemas que usam SSO ou que o usuario acessa com a mesma senha. O raio de explosao e enorme.

MFA — a defesa mais eficaz

Multi-Factor Authentication (MFA) exige dois ou mais fatores de categorias diferentes. Mesmo que a senha seja comprometida, sem o segundo fator (token no celular, chave fisica) o acesso e negado. O Microsoft Threat Intelligence relata que MFA bloqueia 99,9% dos ataques automatizados de conta.

Importante: dois fatores da mesma categoria nao e MFA. Senha + pergunta de seguranca sao dois fatores do tipo "algo que voce sabe" — nao e considerado MFA verdadeiro, pois ambos podem ser comprometidos pelo mesmo vetor.

Niveis de garantia — AAL (NIST SP 800-63)

O NIST (National Institute of Standards and Technology) americano publicou o framework SP 800-63 definindo tres niveis de garantia de autenticacao (Authenticator Assurance Level). Cada nivel especifica os requisitos minimos de autenticacao para diferentes graus de risco.

FIDO2 e o fim das senhas

FIDO2 e um conjunto de padroes desenvolvido pela FIDO Alliance que permite autenticacao forte sem senha — ou como segundo fator altamente resistente a phishing. E composto pelo protocolo WebAuthn (W3C) e pelo protocolo CTAP2 (Client to Authenticator Protocol).

No FIDO2, o segredo criptografico nunca sai do dispositivo do usuario. O servidor armazena apenas a chave publica. Durante a autenticacao, o dispositivo assina um challenge com a chave privada local — provando posse do dispositivo sem transmitir nenhum segredo pela rede. Phishing e credential stuffing tornam-se impossiveis: nao ha senha para roubar.

Implementacoes de FIDO2: Windows Hello (biometria no Windows), Apple Face ID / Touch ID, chaves fisicas YubiKey, Google Titan Key.

Autenticacao adaptativa (Risk-based)

Um dos avancamos mais importantes em autenticacao moderna e a capacidade de ajustar o nivel de verificacao exigido dinamicamente, com base no risco calculado da sessao. Em vez de exigir sempre o mesmo nivel (o que cria atrito desnecessario para sessoes de baixo risco), o sistema avalia multiplos sinais em tempo real.

Com base nesses sinais, o sistema pode: (a) permitir o acesso sem MFA adicional (baixo risco, sessao confiavel), (b) exigir MFA adicional (risco medio), (c) exigir MFA com chave fisica (alto risco), ou (d) bloquear e acionar alerta de seguranca (risco muito alto).

Autorizacao

Apos a autenticacao confirmar quem e o usuario, a autorizacao decide o que ele pode fazer. E o mecanismo que transforma "voce e quem diz ser" em "voce pode acessar este recurso com estas permissoes". Autorizacao mal implementada e a causa de acessos excessivos — o combustivel de ataques de privilege escalation e insider threat.

O ciclo completo de uma requisicao de acesso

Mecanismos de autorizacao

A autorizacao pode ser implementada de diversas formas. A escolha do modelo tem impacto direto na granularidade dos controles, na complexidade operacional e na capacidade de auditoria. Os modelos serao explorados em profundidade na proxima secao.

• ACL (Access Control List): lista de quem pode acessar o que, definida diretamente no recurso. Simples, mas nao escala.
• RBAC: permissoes em papeis, papeis em usuarios. Padrao corporativo mais adotado.
• ABAC: decisao baseada em atributos multiplos (usuario, recurso, contexto). Mais granular.
• PBAC: politicas declarativas avaliadas por motor de decisao. Alta flexibilidade.
• ReBAC: baseado em relacionamentos entre entidades. Excelente para sistemas colaborativos.

PEP, PDP, PIP — a arquitetura de autorizacao

Em sistemas de autorizacao mais sofisticados (especialmente ABAC e PBAC), existe uma arquitetura de componentes bem definida:

Modelos de Controle de Acesso

Escolher o modelo certo de controle de acesso e uma das decisoes mais importantes no design de um sistema IAM. Cada modelo tem tradeoffs especificos de granularidade, escalabilidade e complexidade operacional. Na pratica, organizacoes maduras combinam multiplos modelos.

DAC — Discretionary Access Control

No DAC, o dono do recurso decide quem pode acessa-lo e com quais permissoes. E o modelo mais simples e o que a maioria das pessoas conhece intuitivamente — permissoes de arquivo no Windows ou Linux (dono, grupo, outros; ler, escrever, executar).

Como funciona: Maria cria um documento e pode compartilha-lo com quem quiser, dando permissao de leitura ou edicao. Ela e a dona e tem controle total sobre quem acessa.

Problema central: a governanca e completamente descentralizada. Cada dono toma decisoes independentes, frequentemente inconsistentes. Nao ha visao centralizada de "quem tem acesso a que". Auditoria e pesadelo. Em organizacoes grandes, o resultado e inevitavelmente um emaranhado de permissoes sem controle.

MAC — Mandatory Access Control

No MAC, as permissoes sao determinadas por classificacoes de seguranca e rotulos definidos por politica central — nao pelo dono do recurso. Cada objeto tem um rotulo de classificacao (Publico, Restrito, Confidencial, Secreto) e cada usuario tem uma autorizacao maxima. Um usuario so pode acessar objetos com classificacao igual ou inferior a sua autorizacao.

Como funciona: Um analista com classificacao "Confidencial" pode ver documentos Publicos, Restritos e Confidenciais, mas nao Secretos. Nenhum dono pode substituir essa regra — e mandatoria.

Uso tipico: Ambientes governamentais e militares (defesa nacional, inteligencia), setores regulados com dados altamente sensiveis. Implementacoes tecnologicas: SELinux, AppArmor.

Limitacoes: Extremamente rigido, dificil de adaptar a necessidades de negocio dinamicas. Nao adequado para a maioria dos ambientes corporativos.

RBAC — Role-Based Access Control

RBAC e o modelo mais adotado em ambientes corporativos modernos. A logica e elegantemente simples: permissoes sao associadas a papeis, e papeis sao atribuidos a usuarios. Para conceder um conjunto de acessos a um usuario, basta atribuir o papel correto.

Vantagens: Simples de administrar (mudar o papel muda todos os acessos). Facil de auditar (quais papeis existem? quem tem cada papel?). Escala bem para grandes organizacoes. Alinhado com estruturas organizacionais.

Limitacoes: Pode gerar "role explosion" — centenas de papeis para cobrir todas as combinacoes possiveis. Nao suporta bem contexto dinamico (acesso apenas em horario comercial, apenas de dispositivo corporativo). Granularidade limitada para cenarios complexos.

ABAC — Attribute-Based Access Control

ABAC toma decisoes de acesso com base em atributos — do usuario, do recurso solicitado e do contexto ambiental. Em vez de perguntar "o usuario tem o papel X?", o motor de politicas pergunta "o departamento do usuario e Financas E o recurso tem classificacao Financeiro E o horario e comercial E o dispositivo e corporativo?"

Vantagens: Granularidade muito alta. Flexivel para contextos dinamicos. Elimina role explosion. Politicas de negocio expressas de forma natural.

Desafios: Mais complexo de configurar e depurar. Requer consistencia nos atributos de todas as fontes. Motor de politicas precisa ser performatico para nao criar latencia.

PBAC — Policy-Based Access Control

PBAC e uma evolucao natural do ABAC — as politicas sao escritas em uma linguagem declarativa formal e avaliadas por um Policy Decision Point (PDP) centralizado. A diferenca principal em relacao ao ABAC e a separacao mais clara entre a logica de negocio (politica) e o codigo da aplicacao.

Tecnologias como XACML (XML-based) e Open Policy Agent (OPA) implementam PBAC. OPA, em particular, tornou-se o padrao de fato para politicas de autorizacao em ambientes de microsservicos e Kubernetes, com sua linguagem declarativa Rego.

Caso de uso tipico: Uma empresa de fintech precisa que sua API de transferencias aplique politicas diferentes dependendo do pais do usuario, do valor da transacao, do historico de risco e do horario. Com OPA, toda essa logica e centralizada em politicas Rego versionadas no Git — fora do codigo das APIs.

ReBAC — Relationship-Based Access Control

ReBAC define acessos com base em relacionamentos entre entidades. "Voce pode editar este documento porque voce e o criador." "Voce pode ver esta pasta porque e membro do time que a criou." "Voce pode aprovar este workflow porque e o gestor do solicitante."

O Google Zanzibar (2019) e a implementacao mais conhecida de ReBAC — e a base de permissoes do Google Drive, YouTube, Maps e Gmail. O paper do Zanzibar inspirou implementacoes open-source como SpiceDB e Ory Keto.

Quando usar ReBAC: Plataformas colaborativas onde o acesso e definido por quem criou o objeto, quem faz parte de um time, quem gerencia quem em uma hierarquia. Muito comum em SaaS modernos (Notion, GitHub, Figma).

Comparativo completo dos modelos

SSO, Federacao e Protocolos de Identidade

Single Sign-On e federacao eliminam a necessidade de multiplas senhas e permitem que usuarios acessem dezenas de sistemas com uma unica autenticacao. Entender os protocolos por tras disso e fundamental para qualquer profissional de IAM.

Single Sign-On (SSO)

SSO permite que o usuario se autentique uma unica vez no Identity Provider (IdP) e acesse todas as aplicacoes configuradas sem inserir credenciais novamente. O IdP emite um token que as aplicacoes aceitam como prova de autenticacao valida.

Os beneficios sao duplos: seguranca (uma senha forte gerenciada em um lugar so, com MFA centralizado) e produtividade (usuarios nao desperdicam tempo com multiplos logins ou resets de senha). Empresas que implementam SSO reportam reducao de 25-50% em tickets de helpdesk relacionados a senha.

SAML 2.0 — o protocolo legado que ainda domina

O Security Assertion Markup Language (SAML) 2.0, publicado em 2005, e o protocolo de SSO mais usado em ambientes corporativos — especialmente para aplicacoes enterprise legadas. Funciona com asercoes XML assinadas digitalmente trocadas entre o IdP e o Service Provider (SP).

O fluxo tipico: usuario acessa o SP (ex: Salesforce) sem estar autenticado. O SP redireciona para o IdP. O usuario se autentica no IdP. O IdP emite uma asercao SAML assinada para o SP. O SP valida a assinatura e concede acesso.

SAML ainda e indispensavel para aplicacoes SaaS enterprise que nao suportam OIDC. A maioria dos grandes vendors (Salesforce, ServiceNow, SAP) suporta SAML ha anos.

OAuth 2.0 — autorizacao delegada para APIs

OAuth 2.0 nao e um protocolo de autenticacao — e um framework de autorizacao delegada. Permite que uma aplicacao obtenha acesso limitado a recursos de um usuario em outro servico, sem precisar da senha do usuario.

Quando voce usa "Login com Google" em um app e autoriza o app a ver seus contatos do Gmail, voce esta usando OAuth 2.0. O app recebe um access token com escopo limitado ("ler contatos") — nao sua senha.

OAuth 2.0 define varios grant types (fluxos): Authorization Code (para web apps — o mais seguro), Client Credentials (para machine-to-machine), Device Code (para TVs e IoT), e Implicit (deprecated — nao use).

OpenID Connect (OIDC) — a camada de autenticacao sobre OAuth

OIDC e uma camada de autenticacao construida sobre OAuth 2.0. Enquanto OAuth cuida de "o app pode acessar seus dados", OIDC cuida de "confirmar quem voce e". Adiciona ao fluxo OAuth um ID Token (JWT) que carrega informacoes de identidade do usuario.

OIDC tornou-se o padrao moderno para SSO em aplicacoes cloud e mobile. E mais leve que SAML (JSON em vez de XML), nativamente adequado para APIs REST, e suportado por todos os grandes IdPs.

JWT — o token que viaja

O JSON Web Token (JWT) e o formato de token mais usado em autenticacao e autorizacao modernas. E composto por tres partes separadas por pontos, cada uma codificada em Base64URL:

O receptor valida a assinatura usando a chave publica do emissor (sem precisar consultar o servidor de autenticacao). Se a assinatura e valida e o token nao expirou, o acesso e concedido. Isso permite autorizacao stateless e altamente escalavel.

Acessos Privilegiados — PAM

Contas privilegiadas sao o alvo preferido de atacantes avancados. Uma conta de administrador comprometida pode paralisar uma organizacao inteira. PAM (Privileged Access Management) e a disciplina dedicada a controlar, monitorar e auditar esses acessos de alto poder.

O que torna uma conta "privilegiada"

Uma conta privilegiada tem permissoes que vao muito alem do usuario comum: pode modificar configuracoes de sistemas, acessar dados de todos os usuarios, instalar software, apagar logs, criar ou excluir outros usuarios. O comprometimento de uma conta privilegiada e catastrofico.

Os cinco controles centrais de PAM

Cofre de credenciais (Password Vault)

O cofre armazena e gerencia senhas de contas privilegiadas de forma centralizada. O usuario nunca ve a senha — ele solicita uma "sessao privilegiada" e recebe acesso temporario ao sistema de destino via proxy gerenciado. A senha e automaticamente rotacionada apos o uso (ou periodicamente), garantindo que nenhuma senha privilegiada permaneca a mesma por muito tempo.

O que e IGA

Identity Governance and Administration (IGA) e a disciplina que combina a administracao de identidades (quem tem acesso a que, como e provisionado) com a governanca (esse acesso e apropriado? foi revisado? esta em conformidade?). IGA e o que transforma IAM de uma ferramenta tecnica em um processo de negocio auditavel.

A diferenca entre IAM e IGA

IAM responde "quem pode acessar o que". IGA responde "quem deve acessar o que, por que, e como provar isso para um auditor". E a diferenca entre abrir uma porta e ter um registro assinado de por que essa porta deveria estar aberta, quando foi aberta, por quanto tempo, e quem autorizou.

Por que IGA nao e opcional

Sem IGA, acessos acumulam indefinidamente. Um colaborador recebe acessos quando e admitido. Muda de area — recebe mais acessos. Volta para a area original — mantem todos os acessos anteriores. Apos 5 anos, tem um conjunto de acessos que nenhum gestor consegue mais explicar ou justificar.

Esse fenomeno — chamado de access creep ou privilege creep — e a causa raiz de incidentes de seguranca por insider threat e de violacoes de conformidade em auditorias. IGA e a solucao estrutural para access creep.

Ciclo de Vida de Identidades — JML

O modelo JML descreve os tres eventos criticos no ciclo de vida de uma identidade: Joiner (entrada), Mover (transferencia) e Leaver (saida). Automatizar esses eventos e uma das maiores fontes de valor da IGA — e a diferenca entre uma empresa que sofre incidentes por contas orfas e uma que nao sofre.

Joiner — o primeiro dia importa

Quando um colaborador e admitido, precisa ter acesso aos sistemas necessarios para trabalhar — idealmente no primeiro dia, sem precisar abrir 15 tickets no helpdesk. A IGA, ao receber o evento de admissao do RH, automaticamente: cria a identidade no repositorio central, cria contas nos sistemas de destino, provisiona os acessos de birthright (acessos basicos definidos para o cargo), envia notificacoes ao gestor e ao colaborador, e registra todo o processo na trilha de auditoria.

Em organizacoes sem automacao, esse processo pode levar de 3 a 10 dias uteis. Com IGA, leva minutos. A diferenca em produtividade (e em primeira impressao do novo colaborador) e enorme.

Mover — o evento mais perigoso para SoD

A transferencia de area e o evento mais critico do ponto de vista de governanca. Um colaborador que ja tinha acessos do cargo anterior e recebe os acessos do novo cargo pode acumular uma combinacao de entitlements que viola regras de SoD sem que ninguem perceba.

A IGA deve revogar automaticamente os acessos do perfil anterior que nao se aplicam ao novo. Para acessos que nao podem ser determinados automaticamente (acessos "extralegais" concedidos especificamente a esse colaborador), uma campanha de certificacao e acionada para que o gestor revise e decida.

Leaver — o risco da conta orfao

Contas nao desativadas de ex-colaboradores sao uma das principais causas de incidentes de seguranca. Um estudo da IBM aponta que contas de ex-funcionarios representam 15% das violacoes de dados em organizacoes. O ex-colaborador pode usar a conta por maldade, por descuido, ou a conta pode ser comprometida por um atacante que sabe que ela nao e monitorada.

A automacao de Leaver na IGA garante: bloqueio imediato de todas as contas no momento do desligamento (D+0, nao D+30), revogacao de todos os entitlements, cancelamento de tokens OAuth e sessoes ativas, transferencia de responsabilidades (aprovacoes pendentes, documentos), e arquivamento da identidade com todos os logs para fins legais.

Provisionamento de Identidades

Provisionamento e o processo de criar, modificar e revogar contas e permissoes nos sistemas de destino. E o brace operacional da IGA — transforma decisoes de governanca em acoes reais nos sistemas que as pessoas usam no dia a dia.

Do evento a acao — o fluxo completo

Tipos de provisionamento

Automatico: o conector IGA executa a acao diretamente no sistema de destino via API, SCIM ou LDAP. E o modelo ideal — rapido, sem intervencao humana, totalmente auditavel.

Via ticket (manual): para sistemas sem API disponivel, a IGA abre um chamado no ITSM (ServiceNow, Jira). Um operador executa a acao manualmente e fecha o ticket. E mais lento, mas ainda rastreavel.

Self-service: o usuario solicita acesso adicional via portal IGA. Um fluxo de aprovacao e acionado. Apos aprovacao, o provisionamento pode ser automatico ou manual. Reduz a carga no helpdesk e empodera os usuarios.

Break-glass (emergencial): acesso critico concedido imediatamente com justificativa, auditado post-facto. Usado quando a velocidade e essencial (incidente critico em producao) e o fluxo normal de aprovacao seria muito lento.

Segregacao de Funcoes — SoD

Segregation of Duties (SoD) e um dos controles mais antigos e mais eficazes da contabilidade e da auditoria, agora implementado digitalmente em plataformas IGA. A premissa e simples: para cometer uma fraude, seria necessario o conluio de pelo menos duas pessoas.

A logica por tras do SoD

Imagine o processo de pagamento a fornecedores. Em uma organizacao sem SoD, um unico funcionario pode: cadastrar o fornecedor, criar a ordem de pagamento, aprovar o pagamento e confirmar a quitacao. Esse funcionario tem controle completo do processo — e a capacidade de criar um fornecedor fantasma, gerar um pagamento a ele mesmo e aprova-lo.

Com SoD, essas funcoes sao separadas entre pelo menos duas pessoas distintas. Para a fraude acontecer, seria necessario conluio — o que aumenta dramaticamente o risco de deteccao e reduz a probabilidade do evento.

SoD preventivo vs. detetivo

Plataformas IGA implementam SoD de duas formas complementares:

Preventivo: a IGA bloqueia a concessao de um entitlement que criaria um conflito com entitlements que o usuario ja possui. Quando Pedro solicita o perfil "Aprovar Pagamentos" e ja tem "Criar Fornecedores", a solicitacao e automaticamente rejeitada com explicacao da regra violada.

Detetivo: identifica conflitos em entitlements ja concedidos, frequentemente descobertos em reconciliacao ou durante campanhas de certificacao. O usuario mantem o acesso conflitante ate que seja remediado, mas o conflito e sinalizado para revisao prioritaria.

Construindo a matriz de SoD

A matriz de SoD e uma tabela que define quais combinacoes de entitlements sao conflitantes. Sua construcao e um exercicio colaborativo entre TI, Auditoria Interna, Financas, Juridico e Compliance — pois depende do entendimento dos processos de negocio e dos riscos especificos de cada setor.

Certificacao de Acessos

Certificacao de acessos e o processo pelo qual responsaveis revisam periodicamente os acessos concedidos e tomam uma decisao explicita: manter ou revogar. E o mecanismo de governanca continua que combate o access creep e gera evidencias para auditores.

Por que certificacoes sao necessarias

Mesmo com automacao JML perfeita, acessos acumulam. Um colaborador solicita acesso temporario a um projeto — e o acesso nunca e revogado. Um gestor aprova um acesso para um colaborador sem perceber que ja existia um similar. Um entitlement deixa de ser necessario para o cargo mas ninguem percebe.

Certificacoes criam um mecanismo de revisao periodica que forca decisoes explicitas sobre cada acesso: "esse acesso ainda e necessario para essa pessoa fazer seu trabalho?" Se o revisor nao consegue justificar, a resposta deve ser revogar.

O fluxo de uma campanha de certificacao

1. Definicao de escopo: quais acessos revisar? Todos os acessos privilegiados? Todos os acessos de um sistema critico? Todos os acessos de terceiros?
2. Coleta de estado atual: a IGA executa uma agregacao para garantir que a visao dos acessos esta atual.
3. Atribuicao de revisores: cada item e atribuido a um revisor responsavel (gestor direto, dono da aplicacao, dono do entitlement).
4. Notificacao e prazo: revisores recebem notificacao com link direto para o portal de revisao. Um prazo e definido.
5. Revisao: revisor analisa cada item e toma decisao: Aprovar (manter o acesso) ou Revogar.
6. Execucao das revogacoes: decisoes de revogacao sao executadas automaticamente via provisionamento.
7. Geracao de relatorio: relatorio da campanha e arquivado como evidencia de compliance.

Papeis, Perfis e Role Management

Gerenciamento de papeis e a disciplina que organiza entitlements em agrupamentos logicos alinhados com funcoes de negocio. Um modelo de papeis bem construido e a diferenca entre uma IGA que escala e uma que se torna um pesadelo operacional.

Hierarquia de papeis

Role Mining — deixar os dados falarem

Role mining e o processo de analisar os acessos existentes na organizacao para identificar padroes e sugerir papeis de negocio que reflitam a realidade. Em vez de designers de IAM inventando papeis do zero (muitas vezes incorretos), o algoritmo descobre quais conjuntos de entitlements costumam aparecer juntos para perfis similares de usuarios.

Com IA, o processo e amplificado: algoritmos de clustering (como k-means ou analise de componentes principais) agrupam usuarios com padroes de acesso similares, calculam metricas de cobertura (quantos usuarios o papel atenderia) e ruido (quantos entitlements no papel seriam "extras" para alguns usuarios), e apresentam sugestoes rankeadas para que um analista de IGA valide e formalize.

Role Explosion — o inimigo do RBAC

Role explosion e o fenomeno em que uma organizacao cria centenas ou milhares de papeis para cobrir cada combinacao especifica de acesso. Em vez de 20 papeis bem definidos, ha 2.000 papeis com nomes como "Analista-Financas-SP-Nivel3-Aprovador-ERP-SAP-Modulo-FI-apenas-leitura". O modelo colapsa sob seu proprio peso.

Estrategias para evitar role explosion:

• Usar ABAC para variacoes contextuais (localizacao, horario) em vez de criar um papel por contexto
• Parametrizar papeis (papel "Analista" com parametro "departamento")
• Executar role mining periodicamente para identificar papeis redundantes ou nao utilizados
• Definir um processo de aposentadoria de papeis com mais de X meses sem atribuicao

Zero Trust

Zero Trust e uma mudanca fundamental de paradigma em seguranca: do modelo "confiar em tudo dentro do perimetro" para "nunca confiar, sempre verificar". A identidade torna-se o novo perimetro — e IAM/IGA sao a infraestrutura que torna Zero Trust possivel.

O colapso do perimetro

O modelo de seguranca tradicional baseia-se em perimetro: o firewall separa "dentro" (confiavel) de "fora" (hostil). Quem esta dentro da rede corporativa e basicamente confiavel. Esse modelo funcionava quando os dados e aplicacoes viviam dentro do datacenter e colaboradores trabalhavam no escritorio.

Hoje, essa realidade nao existe mais. Dados estao no Salesforce, no Google Workspace, no AWS S3. Colaboradores trabalham de casa, de cafes, de aeroportos. O "perimetro" desapareceu. Um colaborador remoto acessando o ERP nao esta "dentro" de nenhuma rede segura — e um atacante dentro da rede corporativa pode se mover lateralmente sem ser questionado.

Os seis pilares do Zero Trust (NIST SP 800-207)

1. Verificar identidades de forma continua: autenticacao forte (MFA, FIDO2) para toda requisicao. Re-autenticacao adaptativa baseada em risco.
2. Validar dispositivos: apenas dispositivos conformes (gerenciados pelo MDM, com antivirus atualizado, sem jailbreak) recebem acesso.
3. Tratar toda rede como nao confiavel: mesmo dentro da rede corporativa. Trafego e criptografado e inspecionado.
4. Menor privilegio estrito: JIT access, permissoes apenas para o recurso especifico necessario, por tempo limitado.
5. Microsegmentacao: sistemas isolados uns dos outros. Comprometimento de um nao da acesso automatico aos demais.
6. Inspecao e monitoramento continuo: todo comportamento e registrado e analisado. Anomalias geram alertas ou bloqueios automaticos.

Inteligencia Artificial na Governanca de Identidades

A IA transformou IGA de um processo periodico e reativo em uma governanca proativa e continua. Machine learning identifica padroes invisíveis ao olho humano, automatiza decisoes de baixo risco e amplifica a capacidade dos times de seguranca de detectar e responder a ameacas.

Role Mining automatico com ML

Criar um modelo de papeis manualmente e uma tarefa exaustiva que poucos profissionais de IGA tem tempo de fazer bem. Algoritmos de clustering — como k-means, DBSCAN ou analise de componentes principais — analisam os acessos de todos os usuarios e identificam grupos com padroes similares.

O resultado e uma lista de papeis candidatos, cada um com: cobertura (% de usuarios que teriam esse papel), ruido (% de entitlements no papel que nem todos os membros precisariam), e sugestao de nome baseado nos atributos dos membros. Um analista valida, ajusta e formaliza — o processo que levaria meses e feito em dias.

Recomendacoes em certificacao

Durante campanhas de certificacao, a IA analisa cada par usuario-entitlement e gera uma recomendacao fundamentada. Os fatores considerados incluem:

• Frequencia de uso real: o usuario acessou esse recurso nos ultimos 90 dias? (dados de logs de acesso do sistema de destino)
• Analise de grupo de pares (peer group): colegas com mesmo cargo e departamento tem esse entitlement?
• Historico de decisoes: esse entitlement foi aprovado ou revogado nas ultimas campanhas para perfis similares?
• Tempo de inatividade: ha quanto tempo o acesso nao e utilizado?
• Risco do entitlement: e um entitlement critico (admin, financeiro, dados pessoais)?

O revisor ve a recomendacao com o racional, pode aceitar com um click ou sobrescrever com justificativa. Organizacoes que implementam IA em certificacao relatam reducao de 60-80% no tempo de revisao e melhora significativa na qualidade das decisoes.

Deteccao de anomalias comportamentais (UEBA)

UEBA (User and Entity Behavior Analytics) cria um perfil comportamental para cada identidade — horarios tipicos de acesso, sistemas frequentados, volumes de operacao, localizacoes habituais. Qualquer desvio e pontuado como anomalia e pode acionar alertas ou respostas automaticas.

Deteccao de outliers de acesso

Mesmo sem comportamento anomalo em tempo real, um usuario pode ter um perfil de acessos muito diferente de seus pares. Se todos os 20 analistas financeiros tem em media 15 entitlements nos sistemas relevantes, e um deles tem 47, ele e um outlier — independentemente de estar usando todos esses acessos ou nao.

A IA identifica esses casos automaticamente, prioriza-os nas campanhas de certificacao e pode acionar revisoes out-of-cycle para os casos de maior risco.

Auto-remediation e respostas automaticas

Nos sistemas mais avancados, a IA nao apenas detecta — ela responde. Quando um conflito de SoD e detectado, o sistema sugere automaticamente qual entitlement revogar (com menor impacto operacional). Quando uma anomalia critica e identificada, contas podem ser suspensas automaticamente para investigacao. Quando um acesso nao e utilizado por X dias, uma notificacao de auto-expiracao e enviada.

ITDR — Identity Threat Detection and Response

ITDR e a categoria mais nova do ecossistema IAM, formalmente definida pelo Gartner em 2022. Combina capacidades de deteccao de ameacas especificas a identidades com resposta automatizada — e o ponto onde IAM encontra o SOC (Security Operations Center).

Por que ITDR emergiu

As ferramentas tradicionais de seguranca (SIEM, EDR) detectam ameacas em logs e endpoints, mas frequentemente nao tem contexto suficiente sobre identidades para identificar ataques sofisticados baseados em credenciais. IAM e IGA tradicionais governam acessos, mas nao foram construidos para detectar ataques em tempo real.

ITDR preenche esse gap: monitora especificamente os vetores de ataque que exploram identidades — credential stuffing, pass-the-hash, Golden Ticket, privilege escalation, account takeover — e responde em tempo real.

A integracao ITDR + IGA — resposta automatizada

A combinacao mais poderosa e integrar ITDR com IGA para criar resposta automatizada a incidentes de identidade:

1. ITDR detecta comportamento anomalo na conta de Joao (login impossivel + acesso a sistemas criticos)
2. ITDR notifica a IGA com o evento de risco e score de confianca
3. IGA automaticamente suspende a conta de Joao e revoga tokens ativos
4. Ticket de incidente e criado automaticamente no ITSM
5. Time de seguranca investiga e resolve
6. Apos resolucao, IGA reprovisiiona os acessos de Joao (manualmente ou via fluxo de aprovacao)
7. Todo o ciclo fica registrado com evidencias para analise forense

Esse ciclo, que manualmente poderia levar horas ou dias, e executado em minutos — drasticamente reduzindo o tempo de exposicao.

Compliance e Regulamentacoes

Governanca de identidades nao e apenas boa pratica de seguranca — e obrigacao legal em muitos setores. IAM e IGA sao a base tecnica para atender as principais regulamentacoes de seguranca, privacidade e controles internos.

As principais regulamentacoes e seus requisitos de IAM

Como IGA gera evidencias de compliance

O valor de uma plataforma IGA para compliance vai alem de controlar acessos — ela gera as evidencias documentadas que auditores exigem:

• Relatorios de certificacao: provam que todos os acessos foram revisados no periodo exigido, com quem aprovou e quando.
• Trilha de auditoria: cada provisionamento, revogacao e decisao de acesso e registrada com timestamp, usuario responsavel e justificativa.
• Relatorios de SoD: demonstram que funcoes conflitantes sao separadas, com historico de violacoes detectadas e remediadas.
• Relatorios de terceiros: lista de todos os fornecedores e prestadores com acesso, com data de concessao, validade e historico de revisoes.
• Metricas de JML: tempo medio de provisionamento (joiner), tempo medio de revogacao (leaver) — indicadores de efetividade dos controles.