Gestão de identidades e acessos: ciclo de vida, MFA e modelos de autorização

Toda decisão de controle de acesso que um sistema toma se apoia em dois fatos: quem está pedindo e o que essa pessoa ou esse programa pode fazer. Gestão de identidades e acessos (IAM) é a disciplina de manter esses dois fatos corretos — não só no momento em que a conta é criada, mas ao longo de promoções, transferências, terceirizados, aquisições, serviços desativados e a longa cauda de contas cujo acesso ninguém lembra de ter concedido. É onde a segurança mais falha em silêncio, porque uma permissão obsoleta não gera nenhuma mensagem de erro.

Para um desenvolvedor, IAM aparece como escolhas concretas: quais fatores de autenticação suportar, como armazenar credenciais, de qual modelo de autorização o domínio realmente precisa, como receber contas de usuário a partir do diretório de um cliente e o que fazer com as identidades de máquina, que já são mais numerosas que as humanas. Os protocolos que transportam a identidade entre sistemas — OAuth 2.0 para acesso delegado e OpenID Connect para login federado — são tratados à parte; este guia trata do modelo por baixo deles.

O ciclo de vida da identidade

Contas têm uma vida, normalmente descrita em três etapas: admissão, movimentação e desligamento (joiner, mover, leaver).

Admissão. Uma fonte autoritativa — o sistema de RH para funcionários, um cadastro de contratos para fornecedores, um fluxo de cadastro para clientes — cria a identidade. O acesso é concedido a partir de uma base definida para a função, e não copiando as permissões de um colega, hábito que espalha privilégios como um boato.

Movimentação. Alguém muda de equipe, é promovido ou assume uma atribuição temporária. O padrão perigoso é o acúmulo de privilégios: os novos acessos são concedidos, os antigos nunca são removidos e, depois de alguns anos, um funcionário antigo consegue fazer quase tudo. A movimentação precisa disparar a recertificação de todo o conjunto de permissões, e não um simples acréscimo.

Desligamento. A saída precisa revogar o acesso em todos os lugares, rapidamente, incluindo aplicações federadas, VPNs, caixas de e-mail compartilhadas, tokens de API pessoais, consoles de nuvem e tudo o que a pessoa configurou com as próprias credenciais. É aqui que a identidade centralizada se paga: desabilitar uma única conta no diretório fecha todas as aplicações federadas a ele, enquanto contas gerenciadas localmente sobrevivem indefinidamente.

Duas práticas de apoio tornam o ciclo real. A revisão de acessos é um exercício periódico em que o responsável por um sistema confirma que cada usuário ainda precisa dos seus acessos; funciona quando o revisor vê as permissões em linguagem clara e consegue revogar com um clique, e vira carimbo automático quando exibe apenas nomes de grupos em formato bruto. A segregação de funções codifica as combinações que nenhuma pessoa pode acumular sozinha — cadastrar um fornecedor e aprovar o pagamento dele, por exemplo — e é verificada no momento da concessão, em vez de ser descoberta durante uma auditoria.

Fatores de autenticação

As evidências de autenticação se dividem nas três categorias tradicionais: algo que você sabe, algo que você tem e algo que você é. A robustez real de cada uma varia enormemente.

As passkeys, baseadas em WebAuthn e FIDO2, são a resposta moderna. O registro cria um par de chaves no autenticador; a chave privada nunca sai dele, e a chave pública fica armazenada na relying party. No login, o navegador assina um challenge junto com a origem do site solicitante, de modo que uma credencial para bank.example.com não produz nada que um domínio imitador possa usar. É esse vínculo com a origem que derrota os proxies de phishing em tempo real, e é por isso que as passkeys estão substituindo os códigos de uso único em vez de apenas complementá-los. Passkeys sincronizadas acompanham o usuário entre dispositivos pelo chaveiro da plataforma; chaves vinculadas ao dispositivo, em um token físico, atendem funções que exigem alto nível de garantia.

A autenticação adaptativa, ou baseada em risco, ajusta a exigência ao contexto: um dispositivo novo, uma localização incomum ou uma transferência alta disparam um reforço (step-up), enquanto uma sessão conhecida não. Combinada com os claims acr e amr que um provedor de identidade emite, ela permite que a aplicação exija um fator mais forte para uma operação específica, em vez de em todo login.

Armazenando senhas corretamente

Onde as senhas continuam existindo, as regras são estritas e inegociáveis. Nunca as armazene de forma recuperável. Nunca use um hash rápido puro: SHA-256 sobre uma senha foi projetado para ser rápido, que é justamente a propriedade que um atacante com uma tabela roubada deseja. Use um algoritmo memory-hard, com salt e ajustável: Argon2id como primeira escolha, scrypt em segundo lugar, bcrypt quando uma restrição do ecossistema exigir, e PBKDF2 com um número alto de iterações quando a conformidade exigir uma função aprovada pelo NIST.

// Argon2id com parâmetros ajustados para que a verificação custe algumas centenas de milissegundos no seu hardware
Argon2PasswordEncoder encoder = new Argon2PasswordEncoder(
        16,          // tamanho do salt em bytes
        32,          // tamanho do hash em bytes
        1,           // paralelismo
        1 << 16,     // custo de memória de 64 MiB
        3);          // iterações

String stored = encoder.encode(submittedPassword);        // inclui o algoritmo, os parâmetros e o salt
boolean ok = encoder.matches(submittedPassword, stored);  // comparação em tempo constante, nunca equals()

O salt é individual por usuário e armazenado junto com o hash; ele impede que uma única tabela pré-computada quebre todas as contas de uma vez. Um pepper — um valor secreto mantido fora do banco de dados, em um gerenciador de chaves — acrescenta proteção quando só o banco vaza. Codifique o algoritmo e os parâmetros na string armazenada para poder aumentar o custo ou migrar de algoritmo depois, refazendo o hash de cada senha no próximo login bem-sucedido.

A política importa tanto quanto a criptografia. Permita frases-senha longas e colar a partir de um gerenciador; confronte as senhas candidatas com listas de valores já vazados; abandone regras de composição que empurram as pessoas para Summer2026!; limite a taxa de tentativas e bloqueie com um atraso crescente, em vez de um limite fixo que vira alavanca de negação de serviço; e devolva a mesma mensagem de falha exista a conta ou não. Um gerador de senhas que roda inteiramente no navegador é uma boa indicação para usuários que precisam de um valor forte. Observe que um gerador de hash de uso geral serve para checksums e resumos de mensagens — nunca para fazer hash de senha, justamente porque esses algoritmos são rápidos.

Modelos de autorização

Vale a pena pensar no modelo cedo, porque adaptar um depois sai caro.

As listas de controle de acesso (ACL) associam diretamente a cada objeto os sujeitos autorizados. É assim que funcionam as permissões do sistema de arquivos, descritas em Usuários, grupos e permissões no Linux. São precisas, mas impossíveis de gerenciar em escala: ninguém consegue responder "o que este usuário pode acessar?" sem varrer tudo.

O controle de acesso baseado em papéis (RBAC) agrupa permissões em papéis e atribui os papéis aos usuários. É o cavalo de batalha — compreensível, auditável, suportado em toda parte. Seu modo de falha é a explosão de papéis: os papéis se multiplicam para codificar exceções até existirem mais papéis que usuários, e aí eles já deixaram de ser uma abstração.

O controle de acesso baseado em atributos (ABAC) avalia uma política sobre atributos do sujeito, do recurso, da ação e do ambiente. Ele expressa um contexto que está fora do alcance dos papéis, ao custo de políticas sobre as quais é mais difícil raciocinar e que dão mais trabalho para testar.

permit if
    subject.department == resource.owningDepartment
    and subject.clearance >= resource.classification
    and action in {"read", "list"}
    and environment.time within subject.workingHours

O controle de acesso baseado em relacionamentos (ReBAC) modela a autorização como um grafo — este usuário é editor daquela pasta, que contém aquele documento — e responde às perguntas percorrendo-o. Ele se encaixa em produtos colaborativos e em recursos hierárquicos em que a permissão flui por contenção, e é o modelo por trás de vários serviços de políticas modernos.

Na prática, os sistemas combinam os modelos: papéis de granularidade grossa ou scopes OAuth no perímetro e uma verificação fina por relacionamentos ou atributos na camada de domínio, onde mora a regra de propriedade. Externalizar a política para um motor — um sidecar ou uma biblioteca que avalia regras declarativas — tira a autorização da lógica de negócio e a torna testável, mas só compensa quando vários serviços compartilham as mesmas regras. Seja qual for o modelo, o ponto de decisão precisa estar no servidor, ser aplicado a cada requisição e negar por padrão.

Diretórios, provisionamento e federação

Os diretórios LDAP continuam sendo o repositório de usuários de referência na maioria das grandes organizações. Um diretório é uma árvore hierárquica de entradas identificadas por nomes distintos (DN), com usuários e grupos como objetos e atributos como uid, mail e memberOf. Historicamente, as aplicações se conectavam direto ao LDAP para autenticar; hoje é melhor deixar o provedor de identidade conversar com o diretório e dar à sua aplicação um login federado, para que as credenciais nunca passem pelo seu código.

O SCIM (RFC 7644) resolve a outra metade: colocar contas dentro de uma aplicação e, mais importante, tirá-las de lá. É um protocolo REST sobre um esquema JSON padrão de usuário, que um provedor de identidade usa para criar, atualizar, desativar e excluir contas conforme o diretório muda.

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: app.example.com
Content-Type: application/scim+json
Authorization: Bearer <provisioning token>

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace", "path": "active", "value": false }
  ]
}

Suportar SCIM transforma o desprovisionamento de um chamado manual em consequência automática de uma mudança no diretório, e essa é a coisa mais valiosa que uma aplicação de negócio pode fazer pela postura de segurança dos seus clientes. Definir active como false deve encerrar imediatamente as sessões e revogar os tokens, e não apenas esconder a conta de uma lista.

Identidades privilegiadas, de máquina e na nuvem

Contas de administrador merecem tratamento à parte. Gestão de acessos privilegiados (PAM) significa: nenhum direito administrativo permanente, elevação solicitada para uma tarefa e concedida por tempo limitado, contas separadas para o trabalho administrativo, gravação de sessões quando o risco justificar e autenticação baseada em hardware em todo login privilegiado. Credenciais de emergência (break-glass) existem, lacradas, monitoradas e testadas — e o uso delas dispara um alerta automaticamente.

As identidades de máquina já são mais numerosas que as humanas. Serviços, jobs, pipelines e contêineres precisam se autenticar, e a resposta errada é uma chave de API compartilhada em um arquivo de configuração. Prefira uma identidade emitida pela plataforma para a carga de trabalho em execução: uma role de instância em uma conta de nuvem, um token de service account projetado no Kubernetes, um certificado de curta duração emitido por uma autoridade interna para TLS mútuo. Nos termos dos serviços essenciais da AWS, é a diferença entre uma access key commitada em um repositório e uma role assumida por uma instância em execução, sem credencial estática em lugar nenhum. Quando um segredo estático for inevitável, restrinja-o a uma única ação, faça a rotação automaticamente e gere alertas para uso a partir de origens inesperadas.

Por fim, auditoria. Toda autenticação, toda decisão de autorização sobre um recurso sensível, toda concessão de permissão e toda elevação de privilégio deve gerar uma entrada de log com o ator, a ação, o alvo, o resultado e o horário, gravada em um lugar que o ator não possa editar. É esse registro que faz um incidente deixar de ser especulação e virar uma linha do tempo.

Principais conclusões

• Identidade é um ciclo de vida, não um formulário de cadastro; quem muda de função acumula privilégios e quem sai precisa perder o acesso em todos os lugares, rapidamente.
• Passkeys baseadas em WebAuthn são vinculadas à origem e resistentes a phishing, e é por isso que hoje superam os códigos de uso único e as aprovações por push.
• Armazene senhas com Argon2id ou uma função memory-hard equivalente, com salt e parametrizada, e prefira comprimento e triagem a regras de composição e troca forçada.
• Escolha o modelo de autorização de que o domínio precisa — papéis para permissões de granularidade grossa, atributos ou relacionamentos quando contexto e propriedade decidem — e aplique-o no servidor, sempre.
• Federe a autenticação ao diretório e suporte SCIM para que a criação e, sobretudo, a desativação de contas sejam automáticas.
• Dê às identidades privilegiadas e de máquina o mesmo rigor das humanas: nenhum direito permanente, nenhum segredo estático onde a plataforma puder emitir segredos de curta duração, e uma trilha de auditoria que ninguém possa reescrever.