4.7 Gestão de identidades e acessos

Visão geral e motivação

Toda requisição que chega aos seus sistemas carrega uma afirmação implícita: eu tenho permissão para fazer isto. A gestão de identidades e acessos (IAM) é a disciplina de decidir se essa afirmação é verdadeira. Ela responde a duas perguntas separadas que as pessoas confundem o tempo todo. A autenticação prova quem você é. A autorização decide o que você pode fazer depois de ter provado. Mantenham essas duas ideias distintas na cabeça e metade da confusão neste campo desaparece.

Para grandes equipes, a identidade silenciosamente virou o controle mais importante que vocês possuem. O capítulo 4.3 defende que a identidade é o novo perímetro, e o capítulo 4.1 constrói a confiança zero em cima dela: quando vocês param de confiar na rede, a única coisa que resta para confiar é uma identidade verificada e uma política explícita. Essa mudança significa que um fluxo fraco de redefinição de senha ou uma conta de serviço esquecida já não é um bug pequeno. É a porta da frente. A maioria das violações reais não são explorações engenhosas de falhas de segurança de memória. São credenciais roubadas, permissões amplas demais e contas que deveriam ter sido desligadas meses atrás.

As apostas sobem em contextos corporativos e governamentais. Uma empresa global lida com dezenas de diretórios sobrepostos, milhares de entradas e saídas por mês e parceiros que precisam de acesso delimitado a uma fatia dos seus sistemas. Uma agência governamental acrescenta credenciais de cartão inteligente, níveis obrigatórios de garantia de identidade e auditores que perguntarão, por escrito, exatamente quem poderia tocar um dado registro num dado dia. Este capítulo tem opinião sobre como construir uma camada de identidade que responda bem a essas perguntas sem paralisar as suas pessoas.

Princípios fundamentais

Autenticação e autorização são problemas diferentes. Provar a identidade e conceder a permissão exigem designs e revisões separados.
Uma identidade, muitos sistemas. Consolidem em uma única fonte de verdade por população de identidades. A proliferação de diretórios é um bug de segurança.
Menor privilégio por padrão. Comecem do acesso zero e acrescentem deliberadamente, para humanos e máquinas igualmente.
Toda credencial é temporária. Prefiram credenciais de curta duração, emitidas automaticamente, a segredos de longa duração.
O desprovisionamento é tão importante quanto o provisionamento. O acesso que sobrevive à sua necessidade é puro risco.
Resistente a phishing vence memorável. Movam a autenticação rumo às passkeys e a fatores apoiados em hardware.
Máquinas também são identidades. Cargas de trabalho, pipelines e serviços precisam de identidade gerenciada, não de chaves estáticas compartilhadas.
O acesso é um ciclo de vida, não um evento. Concedam, revisem e revoguem numa agenda, e provem que o fizeram.

Recomendações

Separe a autenticação da autorização e centralize as duas

Autentiquem por um único provedor de identidade (IdP), um sistema que verifica a identidade e emite tokens em que os outros sistemas confiam. Depois deixem cada aplicação tomar suas próprias decisões de autorização a partir da identidade e dos atributos que esse token carrega. Essa divisão permite reforçar a autenticação uma vez, para todos, mantendo a lógica refinada de permissão perto dos dados que ela protege. Adotem o login único (SSO), em que uma autenticação dá acesso a muitas aplicações, para que as suas pessoas tenham um login forte em vez de quarenta fracos. A federação estende a mesma confiança além das fronteiras organizacionais, permitindo que as identidades de um parceiro acessem os seus sistemas sem que vocês gerenciem as senhas deles.

Use os protocolos modernos para aquilo a que cada um de fato serve

Três padrões fazem a maior parte do trabalho, e cada um tem a sua função. O OpenID Connect (OIDC) é uma camada de identidade construída sobre o OAuth 2.0. Usem-no para responder quem é este usuário no login web e móvel. O OAuth 2.0 é um framework de autorização para acesso delegado. Usem-no para deixar uma aplicação chamar uma API em nome de um usuário sem nunca ver a senha dele (capítulo 2.3). A Security Assertion Markup Language (SAML) é o padrão de federação mais antigo, baseado em XML, e continua sendo o cavalo de batalha do SSO corporativo para aplicações de negócio estabelecidas. Um erro comum é recorrer ao OAuth para fazer a autenticação diretamente. O OAuth concede acesso a recursos. O OIDC fica por cima dele para estabelecer a identidade. Escolham o OIDC para o novo login voltado ao usuário, mantenham o SAML onde o catálogo corporativo o exigir e não inventem o seu próprio formato de token.

Torne a autenticação resistente a phishing

Senhas sozinhas são indefensáveis em escala. Exijam a autenticação multifator (MFA), que combina algo que você sabe, algo que você tem e algo que você é, para toda conta humana sem exceção. Depois avancem além dos fatores fracos: os códigos de uso único por SMS são passíveis de phishing e de troca de SIM. O destino forte são as passkeys e o padrão subjacente WebAuthn (uma API do navegador para autenticação por chave pública), que amarram um login a uma chave privada guardada em hardware e à origem do site real, de modo que uma página falsa não consegue colher nada que valha a pena roubar. As passkeys também dispensam senha, o que os seus usuários agradecerão. Tratem a recuperação de conta e a redefinição de senha como parte da superfície de autenticação, porque um atacante que não consegue vencer a sua MFA simplesmente atacará o fluxo de redefinição.

Gerencie o ciclo de vida de entrada-mudança-saída e desprovisione depressa

A identidade é um ciclo de vida. Quem entra precisa do acesso certo no primeiro dia. Quem muda de papel precisa de novo acesso e, de forma crítica, precisa ter o acesso antigo removido, ou acumula lentamente as chaves do prédio inteiro. Quem sai precisa perder todo o acesso prontamente, idealmente em minutos depois do último dia, em todos os sistemas. Conduzam isso a partir de uma fonte autoritativa, normalmente o sistema de recursos humanos, para que uma mudança de status ali provisione e desprovisione automaticamente a jusante. Automatizem. As listas manuais de desligamento sempre perdem alguma coisa, e a conta que elas perdem é a que aparece no relatório do incidente.

Escolha um modelo de autorização e expresse-o como política como código

Concedam permissões por controle de acesso baseado em papéis (RBAC), em que se atribuem permissões a papéis de função de trabalho e pessoas a papéis, porque é simples de raciocinar e fácil de auditar. Recorram ao controle de acesso baseado em atributos (ABAC) onde precisarem de decisões sensíveis ao contexto, com base em atributos como departamento, classificação de dados, localização ou hora do dia. A maioria das organizações maduras roda um híbrido: RBAC para as concessões grossas, ABAC para as condições finas. Qualquer que seja a escolha, expressem a autorização como política como código: regras escritas numa forma versionada, testável e revisável em vez de clicadas num console. A política como código torna as decisões de acesso auditáveis, comparáveis e consistentes entre ambientes e permite testar uma mudança de permissão antes de ela ser entregue.

Imponha o menor privilégio com acesso na hora certa e PAM

Apliquem o princípio do menor privilégio: toda identidade recebe o acesso mínimo de que precisa e nada mais. O privilégio permanente é o inimigo, porque uma permissão concedida de forma permanente é uma permissão disponível a qualquer atacante que caia naquela conta a qualquer momento. Prefiram o acesso na hora certa (JIT, just-in-time), em que uma pessoa pede direitos elevados por uma janela limitada, os recebe depois da aprovação e os perde automaticamente quando a janela fecha. Para as contas mais perigosas, adotem o gerenciamento de acesso privilegiado (PAM): um sistema que guarda credenciais administrativas em cofre, intermedeia e grava as sessões privilegiadas e emite a elevação sob demanda. O objetivo é zero acesso administrativo permanente, para que mesmo um notebook totalmente comprometido não renda nada durável.

Dê às máquinas e às cargas de trabalho uma identidade de verdade

Os humanos são só metade das suas identidades. Serviços, pipelines, contêineres e funções todos se autenticam em alguma coisa, e com demasiada frequência o fazem com um segredo de longa duração colado num arquivo de configuração. Substituam as chaves estáticas por identidade de carga de trabalho gerenciada: credenciais de curta duração emitidas automaticamente a uma carga com base em onde ela roda e no que ela é. Usem o TLS mútuo (mTLS), em que os dois lados de uma conexão apresentam certificados, para a autenticação entre serviços. Mantenham os segredos restantes num gerenciador de segredos dedicado, com rotação, nunca no código-fonte nem em imagens (capítulo 4.2). Credenciais de carga de trabalho de curta duração e rotacionadas automaticamente removem a causa isolada mais comum de vazamentos de credenciais na nuvem.

Faça da identidade o plano de controle e revise o acesso continuamente

Numa arquitetura de confiança zero (capítulo 4.1), a identidade é onde a política é decidida e imposta, então invistam ali de acordo. Depois fechem o ciclo com as revisões de acesso, também chamadas de recertificação: numa agenda, o dono de cada sistema confirma que toda pessoa e máquina com acesso ainda precisa dele e revoga o que não consegue justificar. Alimentem cada evento de autenticação e de autorização numa trilha de auditoria que responda quem acessou o quê, quando e sob qual política (capítulo 4.6). As revisões de acesso são como se combate o acúmulo de privilégios, a lenta soma de permissões em que nenhuma concessão isolada parecia irrazoável mas que juntas tornam uma conta poderosa demais.

Compromissos: prós e contras

Decisão	Prós	Contras
IdP centralizado com SSO	Um login forte, política consistente, auditoria fácil	Ponto único de falha. Uma queda tranca todo mundo para fora
RBAC	Simples, auditável, familiar	Explosão de papéis. Grosseiro para necessidades sensíveis ao contexto
ABAC	Refinado, sensível ao contexto, escala com atributos	Mais difícil de projetar, testar e raciocinar
Passkeys / WebAuthn	Resistentes a phishing, sem senha, fortes	Os fluxos de recuperação e de perda de dispositivo exigem design cuidadoso
Acesso na hora certa	Privilégio permanente quase zero	Atrito. Precisa de caminhos de aprovação rápidos e confiáveis
Federação com parceiros	Sem gerenciar senhas externas. Confiança delimitada	A confiança depende da higiene do próprio parceiro
Chaves de serviço de longa duração	Trivialmente fáceis de configurar	Propensas a vazar. A principal causa de violações de credenciais

A tensão central é segurança versus atrito. Todo controle que encolhe a superfície de ataque (MFA em tudo, elevação JIT, credenciais de curta duração) também acrescenta um passo ao dia de alguém, e as pessoas contornam controles que doem demais. Resolvam isso fazendo do caminho seguro o caminho fácil: SSO para que a autenticação forte seja um toque, passkeys para que não haja senha a digitar e provisionamento automatizado para que o acesso certo simplesmente apareça. Gastem o orçamento de atrito onde o raio de impacto é maior, no acesso privilegiado e de produção, e mantenham o acesso do dia a dia quase sem atrito.

Perguntas para discutir com sua equipe

Com que rapidez vocês conseguem de fato revogar todo o acesso de alguém que sai hoje, e como sabem que funcionou? A velocidade do desprovisionamento é uma medida direta da sua maturidade de identidade, porque um desligado cujo acesso permanece é uma conta sem monitoramento com permissões reais. Numa grande organização com dezenas de sistemas desconectados, a resposta honesta muitas vezes é “não temos certeza”, e a lacuna costuma ser as aplicações que nunca foram ligadas ao provedor central de identidade. Levem uma saída real e recente e rastreiem todo sistema que a pessoa podia tocar, conferindo os carimbos de data e hora de quando cada acesso de fato terminou. Decidam uma meta, como a revogação completa em uma hora depois da mudança de status em recursos humanos, e instrumentem-na para poder prová-la em vez de esperar. Se algum sistema depende de alguém se lembrar de um passo manual, essa é a conta que uma violação futura usará.
Onde vocês ainda têm privilégio permanente e credenciais estáticas de longa duração, e o que seria preciso para eliminá-los? Os direitos de administrador permanentes e as chaves de serviço permanentes são os dois ativos que os atacantes mais querem, porque são duráveis e poderosos. Inventariem todo humano com acesso de produção ou administrativo sempre ligado e todo serviço que se autentica com uma chave estática e perguntem com honestidade quais deles poderiam passar para a elevação na hora certa ou para a identidade de carga de trabalho de curta duração. A consideração concorrente é o medo operacional: as equipes mantêm o acesso permanente porque os momentos de emergência (break-glass) parecem mais seguros com ele, então vocês precisam tornar a elevação de emergência rápida e confiável antes de retirar os direitos permanentes. Levem a lista à discussão e classifiquem os itens pelo raio de impacto, mirando primeiro o acesso de produção e administrativo. O estado final a perseguir é zero acesso administrativo permanente e nenhuma chave estática que sobreviva a uma única implantação.
Vocês têm uma identidade autoritativa por pessoa e por carga de trabalho, ou várias, e quanto a proliferação está custando? A proliferação de diretórios, em que o mesmo humano existe como cinco contas em cinco sistemas com atributos que se afastam, é onde nascem as lacunas de desprovisionamento e o acesso órfão. Consolidar em uma única fonte de verdade por população de identidades é um dos investimentos de maior alavancagem que uma grande equipe pode fazer, porque todo controle a jusante depende de saber que dois registros são a mesma pessoa. Levem um inventário dos seus repositórios de identidade e mapeiem quais são autoritativos versus quais são cópias convenientes que ninguém governa. A troca é que a consolidação é uma migração grande e pouco glamorosa que disputa atenção com o trabalho de funcionalidades. Decidam se o custo contínuo da proliferação, em dor de auditoria e risco de violação, justifica financiar essa migração agora e não depois do próximo incidente.
Os seus fatores de autenticação mais fortes são genuinamente resistentes a phishing, e o que impede vocês de aposentar de vez as senhas? O fator que um atacante não consegue pescar é o que acaba com o roubo de credenciais como seu caminho dominante de violação, e as passkeys amarradas ao WebAuthn são a única opção amplamente implantável que passa por essa barra. Numa grande organização o quadro honesto costuma ser misto: passkeys para alguns, códigos de uso único por SMS para outros e uma longa cauda de aplicações legadas que ainda aceitam só uma senha. A consideração concorrente é real, porque as passkeys deslocam o problema difícil para a recuperação e a perda de dispositivo, e um fluxo de recuperação desajeitado vira o novo alvo fácil para o qual um atacante simplesmente migra. Levem os números de cobertura por tipo de fator, a lista de aplicações que ainda recorrem a uma senha e um caminho projetado de recuperação de conta em que vocês confiariam contra uma tentativa determinada de engenharia social. Em contextos corporativos e governamentais, liguem a meta a qualquer nível obrigatório de garantia, já que um sistema de alta garantia que ainda permite um fator passível de phishing tem uma lacuna de conformidade além da de segurança.
Como vocês decidem que acesso cada identidade recebe, e conseguem comparar, testar e provar essa decisão antes de ela ser entregue? A lacuna entre “alguém clicou as permissões num console” e “uma política revisada e versionada” é a diferença entre um modelo de acesso que vocês conseguem auditar e um pelo qual só conseguem se desculpar. Para uma grande equipe a pressão é deixar cada aplicação criar suas regras sob medida, o que produz em silêncio explosão de papéis no lado do RBAC e condições intestáveis no lado do ABAC, até ninguém conseguir dizer o que uma dada concessão de fato permite. A consideração concorrente é a velocidade de entrega, porque expressar a autorização como política como código acrescenta uma etapa de revisão que um clique de console não tem, e as equipes sob prazo ressentem o atrito até a primeira auditoria reprovada ou concessão ampla demais fazer o argumento por vocês. Levem uma mudança de permissão real e rastreiem como ela seria proposta, testada, revisada e revertida, mais uma contagem de quantos papéis vocês têm e quantos ninguém consegue explicar. Em contextos corporativos e governamentais, um auditor pedirá que vocês mostrem exatamente quem podia acessar um registro e sob qual regra num dado dia, e só uma política comparável e testável responde a isso sem correria.
Quando uma revisão de acesso revogou algo real pela última vez, e quem responde quando o acúmulo de privilégios passa sem controle? As revisões de acesso são o controle que combate o lento acúmulo de permissões em que nenhuma concessão isolada parecia irrazoável, e uma revisão que nunca revoga nada é teatro de revisão que produz papelada em vez de segurança. Numa grande organização o modo de falha é o carimbo de borracha: os donos de sistemas recertificam centenas de entradas de uma só vez, aprovando todas porque avaliar de verdade cada uma é tedioso e o incentivo para manter o acesso fluindo é mais forte que o de cortá-lo. A consideração concorrente é que revisões significativas custam tempo dos donos e ocasionalmente quebram o fluxo de trabalho de alguém quando um acesso em que ele silenciosamente se apoiava desaparece, então vocês precisam tornar a revisão direcionada e guiada pelo risco e não uma lista indiferenciada. Levem a taxa de revogação do último ciclo, o número médio de direitos por pessoa e evidência de quem é dono da recertificação de cada sistema. Em contextos corporativos e governamentais, nomeiem o oficial responsável por cada revisão e a cadência a que ele é submetido, porque o acúmulo de privilégios que ninguém é responsável por pegar é exatamente a condição que auditores e atacantes exploram.

Perspectiva por setor

Startup. Comprem a identidade, não a construam. Um único provedor de identidade hospedado, com SSO, passkeys obrigatórias e desligamento com um clique, dá a um punhado de engenheiros uma postura de nível corporativo por uma taxa por usuário. Apoiem-se na identidade de carga de trabalho embutida do provedor para que não haja uma única chave de nuvem de longa duração no pipeline e usem OIDC e OAuth 2.0 de prateleira em vez de inventar um tratamento de tokens que vocês não podem bancar manter.

Pequena empresa. Sem especialista em identidade na equipe, favoreçam o SSO e a MFA já incluídos nas ferramentas que vocês pagam e liguem-os em vez de procurar uma plataforma separada. Tratem o problema de entrada-mudança-saída como uma curta lista de verificação escrita ligada a quem é dono das contratações e prefiram passkeys porque removem o ônus do atendimento de redefinição de senhas que vocês não têm quem possa tratar. Evitem logins compartilhados, pois são o hábito barato que depois torna impossíveis a atribuição e a revogação.

Grande empresa. O trabalho é consolidação e governança entre muitos diretórios e equipes: um provedor de identidade autoritativo conduzido pelo sistema de recursos humanos, fluxos automatizados de entrada-mudança-saída, RBAC para funções de trabalho com ABAC para o contexto e gerenciamento de acesso privilegiado com gravação de sessões. Expressem a autorização como política como código para que as mudanças sejam comparáveis e testáveis, conduzam revisões de acesso agendadas que de fato revoguem e padronizem a interface para que as aplicações se liguem à identidade central em vez de cada uma criar o seu próprio login.

Governo. As regras de contratação, a transparência e a responsabilização pública conduzem o design. Amarrem a autenticação a credenciais de hardware como os cartões inteligentes PIV ou CAC, definam níveis de garantia de identidade segundo a NIST SP 800-63 para que sistemas de maior risco exijam fatores de maior garantia e mantenham logs de auditoria imutáveis que respondam exatamente quem acessou o quê e quando. Publiquem o tratamento em linguagem simples da identidade voltada ao cidadão, mantenham separadas as pilhas de identidade de clientes e da força de trabalho e garantam que toda ação privilegiada num sistema sensível seja intermediada e registrada para os auditores que perguntarão.

Exemplos

Startup. Uma startup de vinte pessoas não consegue dotar de pessoal uma equipe de identidade, então compra uma. Todo funcionário entra por um único provedor de identidade hospedado, com SSO para e-mail, hospedagem de código, console de nuvem e o aplicativo interno, e as passkeys são obrigatórias para que não haja senhas a pescar. O desligamento é um clique: desativar a pessoa no provedor de identidade corta o acesso em todo lugar de uma vez. Para o próprio produto, usam OIDC no login de usuários e OAuth 2.0 para deixar integrações chamarem sua API com tokens delimitados. A autenticação do serviço à nuvem usa a identidade de carga de trabalho embutida do provedor, então não há uma única chave de nuvem de longa duração em lugar nenhum do pipeline. Isso custa uma modesta taxa por usuário e compra uma postura de identidade mais forte que a de muitas empresas.

Grande empresa. Um banco multinacional passou uma década acumulando quatro diretórios e centenas de aplicações, algumas federadas por SAML, algumas com seus próprios logins locais. Ele financia um programa de consolidação: um provedor de identidade autoritativo, conduzido pelo sistema de recursos humanos, com fluxos automatizados de entrada-mudança-saída que provisionam na contratação e revogam em minutos depois do desligamento. O RBAC cobre as funções de trabalho padrão enquanto o ABAC impõe regras de residência de dados e de habilitação para o acesso entre fronteiras. Os administradores não têm acesso de produção permanente. Pedem elevação na hora certa por um sistema de gerenciamento de acesso privilegiado que grava cada sessão. As revisões trimestrais de acesso obrigam os donos de sistemas a recertificar ou revogar, e toda decisão é expressa como política como código para que os auditores possam comparar exatamente o que mudou e quando.

Governo. Uma agência federal emite cartões inteligentes de verificação de identidade pessoal (PIV), e o equivalente militar, o common access card (CAC), à sua força de trabalho, de modo que a autenticação é amarrada a uma credencial de hardware e não a uma senha. Seu programa de identidade segue a abordagem de gestão federal de identidade, credencial e acesso (FICAM) e define níveis de garantia de identidade segundo a diretriz NIST SP 800-63 do National Institute of Standards and Technology, de modo que sistemas de maior risco exigem credenciais de maior garantia. Os serviços voltados ao cidadão usam uma pilha separada de identidade de clientes num nível de garantia mais baixo, com MFA forte. As revisões de acesso e os logs imutáveis de auditoria alimentam diretamente a evidência de autorização contínua da agência (capítulo 4.6), e toda ação privilegiada num sistema classificado é intermediada e registrada.

Justificativa de negócio: motivações, ROI e TCO

O retorno do investimento em identidade vem de tirar o seu vetor de violação dominante da zona de perigo. As credenciais roubadas e as contas com permissões em excesso conduzem uma grande parcela dos incidentes reais, e cada um carrega uma cauda pesada: resposta a incidentes, multas regulatórias, notificação de violação e dano duradouro à reputação. Só a MFA resistente a phishing elimina o caminho de intrusão mais comum, e o desprovisionamento automatizado fecha a lacuna da conta órfã que transforma uma saída rotineira numa exposição. Estão entre as reduções de risco mais baratas disponíveis por dólar gasto.

O custo total de propriedade é real mas limitado. Inclui o licenciamento do provedor de identidade, uma plataforma de gerenciamento de acesso privilegiado e de segredos, a engenharia para ligar cada aplicação à identidade central e o esforço contínuo das revisões de acesso. O maior custo é organizacional: consolidar diretórios e adaptar o SSO a aplicações legadas é um trabalho lento e pouco glamoroso que disputa com as funcionalidades. Pesem-no contra a alternativa. A identidade fragmentada gasta o mesmo dinheiro para sempre na forma de desligamento manual, correrias de auditoria e redefinições de senha no atendimento, mais o custo eventual da violação que a fragmentação torna provável. Ao defender o caso junto à liderança, enquadrem a identidade como o plano de controle da confiança zero: a consolidação e a automação são um investimento único que reduz tanto o risco de violação quanto o custo recorrente de auditorias, desligamentos e suporte de acesso.

Antipadrões e armadilhas

Contas órfãs. Acesso que sobrevive à pessoa ou à finalidade, em especial contas de serviço sem monitoramento e contratados esquecidos.
Administrador permanente em toda parte. Acesso privilegiado sempre ligado em vez de elevação na hora certa, dando poder durável a qualquer conta de administrador comprometida.
Chaves estáticas de longa duração. Credenciais de serviço coladas em configuração ou CI que nunca expiram e eventualmente vazam.
Proliferação de diretórios. A mesma pessoa como muitas contas sem governança, de modo que nenhuma mudança jamais se propaga por completo.
Contas compartilhadas. Credenciais usadas por várias pessoas, destruindo a atribuição e tornando impossível a revogação.
SMS como fator forte. Tratar códigos de uso único passíveis de phishing e de troca de SIM como MFA suficiente.
Explosão de papéis. Tantos papéis estreitos de RBAC que o modelo se torna inauditável e ninguém sabe o que um papel concede.
Desprovisionamento como lista manual. Passos humanos de desligamento que inevitavelmente perdem a conta que importa.
OAuth usado para autenticação. Tratar um token de acesso como prova de identidade em vez de usar o OIDC.
Teatro de revisão. Recertificações de acesso carimbadas sem que ninguém avalie de verdade a necessidade.

Modelo de maturidade

Nível 1, Iniciar: Cada aplicação tem seu próprio login. Senhas sem MFA consistente. O provisionamento e o desligamento são manuais, reativos e lentos, e as contas órfãs se acumulam. As credenciais de serviço são chaves estáticas de longa duração. Sem revisões de acesso, as permissões são concedidas e nunca revisitadas.
Nível 2, Desenvolver: O SSO cobre as principais aplicações por meio de um provedor central de identidade, mas a cobertura é desigual entre as equipes. A MFA é exigida para a maior parte do acesso humano. Existe um RBAC básico. A entrada-mudança-saída é parcialmente automatizada a partir do sistema de recursos humanos. Algumas contas privilegiadas ficam em cofre. As revisões de acesso acontecem ocasional e inconsistentemente.
Nível 3, Padronizar: Um provedor de identidade consolidado é autoritativo para a força de trabalho, com provisionamento automatizado e desprovisionamento imediato impostos em toda a organização. A MFA resistente a phishing é padrão e documentada. O RBAC mais o ABAC são expressos como política como código. O gerenciamento de acesso privilegiado com gravação de sessões está no lugar. A identidade de carga de trabalho substitui a maior parte das chaves estáticas. As revisões agendadas de acesso são impostas e auditadas segundo uma política escrita que toda equipe segue.
Nível 4, Gerenciar: O programa de identidade é medido contra linhas de base e controlado com dados. Vocês acompanham o tempo de desprovisionamento da mudança de status em recursos humanos até a revogação completa, a cobertura de MFA e de passkeys por população, a contagem de contas com acesso privilegiado permanente, o número de chaves estáticas de longa duração ainda em uso, a contagem de contas órfãs e as taxas de revogação das revisões de acesso. As métricas carregam metas, como a revogação completa em uma hora e zero concessões novas líquidas de administrador permanente, e a violação de um limiar dispara investigação e não um dar de ombros. As mudanças de autorização são testadas no pipeline, e cada decisão de seguir ou não com uma concessão de acesso é conduzida por evidências e não por hábito.
Nível 5, Orquestrar: A identidade é o plano de controle da confiança zero, continuamente melhorado, integrado à segurança, ao risco e ao planejamento de entrada-mudança-saída em toda a organização. As passkeys são o padrão e as senhas estão sendo aposentadas. O privilégio permanente zero é alcançado por elevação na hora certa, e todas as cargas de trabalho usam credenciais de curta duração, rotacionadas automaticamente, e mTLS. A autorização é totalmente política como código. As revisões de acesso são contínuas e guiadas pelo risco, o desprovisionamento é quase instantâneo e toda decisão produz evidência de auditoria automaticamente. O modelo se adapta conforme os sinais de risco mudam, apertando ou relaxando o acesso dinamicamente e não numa cadência fixa.

Ideias para discussão

O que seria preciso para chegar a zero acesso administrativo permanente, e que caminho de emergência (break-glass) o tornaria seguro?
Onde o ABAC vale a sua complexidade no seu ambiente versus ficar com o RBAC simples?
Com que agressividade vocês devem aposentar as senhas em favor das passkeys, e que fluxo de recuperação as substitui?
Quais aplicações ainda estão fora do seu provedor central de identidade, e o que as mantém lá?
Como vocês dão a parceiros e clientes um acesso delimitado sem herdar a higiene de segurança deles?
Que métrica única melhor captura a sua velocidade de desprovisionamento, e vocês a estão medindo hoje?

Principais conclusões

A autenticação prova quem você é. A autorização decide o que você pode fazer. Projetem e revisem as duas separadamente.
Consolidem em um único provedor autoritativo de identidade com SSO. A proliferação de diretórios é um defeito de segurança, não uma conveniência.
Automatizem o ciclo de vida de entrada-mudança-saída e tornem o desprovisionamento rápido e comprovável.
Usem OIDC para o login de usuários, OAuth 2.0 para o acesso delegado a APIs e SAML onde o catálogo corporativo precisar. Não usem o OAuth como autenticação.
Movam a autenticação rumo às passkeys resistentes a phishing e ao WebAuthn. Exijam MFA em toda parte e tratem os fatores fracos como paliativo.
Imponham o menor privilégio com acesso na hora certa e gerenciamento de acesso privilegiado. Mirem zero direitos de administrador permanentes.
Deem às máquinas identidade de verdade, com credenciais de carga de trabalho de curta duração e mTLS. Eliminem as chaves estáticas de longa duração.
Façam da identidade o plano de controle da confiança zero (capítulo 4.1) e fechem o ciclo com revisões contínuas de acesso e evidência de auditoria (capítulo 4.6).

Referências e leitura complementar

National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines (identity assurance, authentication, and federation levels)
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
National Institute of Standards and Technology, SP 800-53: Security and Privacy Controls, Access Control (AC) and Identification and Authentication (IA) families
The OAuth 2.0 Authorisation Framework, IETF RFC 6749, and the OAuth 2.0 Security Best Current Practice
OpenID Connect Core 1.0 specification, OpenID Foundation
Security Assertion Markup Language (SAML) 2.0 specification, OASIS
Web Authentication (WebAuthn) Level 2, W3C Recommendation, and FIDO2 / FIDO Alliance passkey specifications
Federal Identity, Credential, and Access Management (FICAM) architecture and playbooks, U.S. General Services Administration
FIPS 201, Personal Identity Verification (PIV) of Federal Employees and Contractors
Open Policy Agent (OPA) documentation, Cloud Native Computing Foundation (policy-as-code for authorisation)