IAM (Identity and Access Management): visão prática para aplicações
IAM é o conjunto de processos e controles para garantir que: (1) uma identidade seja corretamente reconhecida (quem é) e (2) receba apenas os acessos necessários (o que pode fazer). Em aplicações, IAM aparece em cadastro, login, recuperação de senha, controle de sessão, emissão/validação de tokens, autorização por perfis e registro de auditoria.
Autenticação vs autorização
Autenticação responde “quem é você?”. Exemplos: senha, biometria, certificado, OTP (código temporário), autenticação multifator (MFA).
Autorização responde “o que você pode fazer?”. Exemplos: acessar tela de administração, aprovar transação, consultar apenas sua própria conta, executar uma API específica.
Erro comum em provas e na prática: confundir “usuário logado” com “usuário autorizado”. Estar autenticado não implica ter permissão para executar uma ação.
Modelos de controle de acesso: RBAC e ABAC
RBAC (Role-Based Access Control)
No RBAC, permissões são atribuídas a papéis (roles), e usuários recebem um ou mais papéis. É simples de administrar e muito usado em sistemas corporativos.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Exemplo: roles “Atendente”, “Supervisor”, “Administrador”. A permissão “aprovar operação” pertence ao role “Supervisor”.
- Ponto de atenção: “explosão de roles” quando se tenta representar muitas variações de regras apenas com papéis.
ABAC (Attribute-Based Access Control)
No ABAC, a decisão de acesso considera atributos do usuário, do recurso, da ação e do contexto (horário, canal, local, risco). É mais flexível e expressivo.
- Exemplo: permitir “aprovar operação” se (cargo=supervisor) E (valor<=limiteSupervisor) E (horário dentro do expediente) E (canal=rede interna).
- Ponto de atenção: exige boa governança de atributos e políticas bem testadas para evitar negações indevidas ou permissões excessivas.
Princípios essenciais: menor privilégio e segregação de funções
Privilégio mínimo (Least Privilege)
Conceder apenas as permissões estritamente necessárias para a tarefa. Isso reduz o impacto de credenciais comprometidas e limita danos por erro operacional.
- Exemplo: um serviço que apenas consulta dados não deve ter permissão de escrita no banco.
- Aplicação prática: separar contas de uso humano (administração) de contas de serviço (APIs), com escopos mínimos e rotação de segredos.
Segregação de funções (SoD – Segregation of Duties)
Evita que uma única pessoa (ou identidade) consiga executar todas as etapas críticas de um processo, reduzindo risco de fraude e erro.
- Exemplo: quem cadastra um beneficiário não deve ser o mesmo que aprova a transferência para esse beneficiário.
- Em sistemas: implementar regras de workflow e autorização por etapa (criar, revisar, aprovar), com trilha de auditoria.
Trilhas de auditoria (Audit Trails)
Auditoria registra “quem fez o quê, quando, de onde e com qual resultado”. É fundamental para investigação, conformidade e detecção de abuso.
- Boas práticas: registrar ID do usuário/serviço, IP/origem, user-agent (quando aplicável), identificador da transação, ação executada, recurso afetado, status (sucesso/erro) e motivo de negação.
- Cuidados: não registrar senhas, tokens completos, CVV, ou dados sensíveis desnecessários. Preferir mascaramento e correlação por IDs.
Fluxos conceituais de login, sessão e tokens
Fluxo de login baseado em sessão (cookie de sessão)
Nesse modelo, após autenticar, o servidor cria uma sessão e envia ao cliente um identificador (geralmente em cookie). O servidor mantém o estado da sessão.
Passo a passo conceitual:
- 1) Cliente envia credenciais (ex.: usuário/senha) via HTTPS.
- 2) Servidor valida credenciais e aplica controles (MFA, bloqueio por tentativas, verificação de risco).
- 3) Servidor cria sessão (ex.: sessionId) e armazena no servidor (memória/redis/banco) com expiração.
- 4) Servidor retorna cookie de sessão ao cliente (idealmente com flags HttpOnly, Secure e SameSite).
- 5) A cada requisição, o cliente envia o cookie; o servidor recupera a sessão e aplica autorização para cada ação.
Riscos típicos: sequestro de sessão (session hijacking), fixação de sessão (session fixation), CSRF (quando cookies são usados automaticamente pelo navegador).
Fluxo baseado em token (ex.: JWT ou token opaco)
Nesse modelo, após autenticar, o servidor emite um token que o cliente apresenta nas requisições (frequentemente no header Authorization). Pode ser um token auto-contido (JWT) ou um identificador opaco validado no servidor.
Passo a passo conceitual:
- 1) Cliente autentica e recebe um access token com expiração curta.
- 2) Cliente chama APIs enviando o token (ex.: Authorization: Bearer ...).
- 3) API valida token (assinatura/expiração/escopo) e aplica autorização (roles, atributos, escopos).
- 4) Quando expira, cliente usa refresh token (mais protegido) para obter novo access token.
Cuidados: armazenar token com segurança (evitar exposição via XSS), usar expiração curta, validar audiência/issuer, e definir escopos mínimos (privilégio mínimo).
Autorização em camadas: endpoint e dado (IDOR)
Uma aplicação segura não verifica apenas “pode acessar a tela”, mas também “pode acessar este recurso específico”. Falha comum: IDOR (Insecure Direct Object Reference), quando o usuário altera um identificador e acessa dados de terceiros.
- Exemplo: GET /api/contas/123 extrai dados da conta 123 sem checar se o usuário é dono/tem permissão.
- Correção: validar no servidor a relação usuário-recurso (ownership) ou política ABAC (atributos do usuário e do recurso).
Vulnerabilidades comuns em aplicações e mitigação
Injeção (SQL/NoSQL/Command Injection)
Injeção ocorre quando dados de entrada são interpretados como parte de um comando/consulta. O atacante manipula a entrada para alterar a lógica, exfiltrar dados ou executar comandos.
Mitigação (ênfase em parâmetros):
- Usar consultas parametrizadas (prepared statements) e evitar concatenar strings para montar queries.
- Validar tipo, formato e tamanho da entrada (ex.: número, data, CPF com máscara/regex), e rejeitar o que não atende.
- Aplicar privilégio mínimo na conta do banco (ex.: conta de leitura não deve ter DROP/ALTER).
Exemplo conceitual (errado vs correto):
// Errado (concatenação): SELECT * FROM usuarios WHERE login = ' + input + ' ...// Correto (parâmetro): SELECT * FROM usuarios WHERE login = ?XSS (Cross-Site Scripting)
XSS ocorre quando a aplicação insere conteúdo não confiável em uma página e o navegador executa como script. Pode roubar sessão/token, alterar telas e capturar dados.
Mitigação:
- Escape/encode de saída conforme o contexto (HTML, atributo, JavaScript, URL). A regra prática: “validar entrada ajuda, mas a defesa principal é codificar a saída”.
- Evitar inserir HTML/JS vindo do usuário; quando necessário, usar sanitização robusta.
- Usar Content Security Policy (CSP) para reduzir impacto.
- Proteger cookies de sessão com HttpOnly (reduz roubo por XSS, embora não elimine XSS).
CSRF (Cross-Site Request Forgery)
CSRF explora o fato de que o navegador envia cookies automaticamente. Um site malicioso induz o usuário logado a disparar uma ação sem intenção (ex.: transferência, alteração de e-mail).
Mitigação (passo a passo):
- 1) Para ações sensíveis, exigir token anti-CSRF único por sessão/requisição.
- 2) Validar o token no servidor e rejeitar se ausente/inválido.
- 3) Configurar cookies com SameSite (Lax/Strict conforme o caso) e Secure.
- 4) Preferir métodos corretos: GET não deve alterar estado; usar POST/PUT/DELETE com validações.
Observação: APIs consumidas por SPA/mobile que usam Authorization header (Bearer token) tendem a ser menos suscetíveis a CSRF do que cookies, mas continuam vulneráveis a XSS e roubo de token se o armazenamento for inadequado.
Falhas de autenticação e gerenciamento de sessão
Incluem senhas fracas, ausência de MFA em operações críticas, mensagens de erro que revelam demais, brute force sem bloqueio, sessão sem expiração, tokens reutilizáveis por muito tempo e reset de senha inseguro.
Mitigação (checklist prático):
- Política de senha e armazenamento seguro (hash forte com salt; nunca armazenar senha em texto).
- Rate limiting e detecção de tentativas (bloqueio progressivo, CAPTCHA quando aplicável).
- MFA para elevação de privilégio e transações sensíveis.
- Expiração de sessão e invalidação no logout; rotação de sessionId após login (mitiga fixation).
- Reset de senha com token de uso único e curto, enviado por canal controlado; invalidar tokens antigos.
- Mensagens de erro neutras (não indicar se usuário existe).
Validação de entradas: abordagem segura e previsível
Validação de entrada deve ser feita no servidor (validação no cliente é apenas usabilidade). A estratégia mais segura é allowlist: aceitar apenas formatos esperados.
Passo a passo para validar entradas
- 1) Definir contrato do campo: tipo (string/número), formato (regex), tamanho mínimo/máximo, obrigatoriedade.
- 2) Normalizar antes de validar (ex.: trim, padronizar encoding, remover caracteres invisíveis).
- 3) Validar e rejeitar cedo (fail fast) com erro genérico e log interno detalhado.
- 4) Usar parâmetros/ORM corretamente para consultas; nunca concatenar comandos.
- 5) Para saída em HTML, aplicar encoding conforme o contexto (defesa contra XSS).
Questões práticas: identificar falhas e propor correções
Cenário 1: usuário acessa dados de outro cliente alterando o ID
Sintoma: ao trocar /api/cliente/100 por /api/cliente/101, o sistema retorna dados de outro cliente.
Falha provável: autorização no nível do objeto (IDOR).
Medidas corretivas:
- Aplicar verificação de ownership/escopo: o usuário só pode acessar recursos vinculados a ele.
- Implementar política ABAC (atributo “clienteId” do token/sessão deve coincidir com o recurso).
- Auditar acessos negados e tentativas sequenciais (indicador de enumeração).
Cenário 2: consulta com filtro livre causa vazamento de dados
Sintoma: campo de busca aceita caracteres especiais e retorna resultados inesperados ou erro de banco.
Falha provável: injeção por concatenação de query.
Medidas corretivas:
- Trocar concatenação por query parametrizada.
- Restringir o filtro a padrões esperados (ex.: apenas letras/números, tamanho máximo).
- Reduzir privilégios da conta de banco usada pela aplicação.
Cenário 3: ação sensível executa ao clicar em link externo
Sintoma: usuário logado tem dados alterados após visitar outro site.
Falha provável: CSRF em endpoint que usa cookie de sessão.
Medidas corretivas:
- Adicionar token anti-CSRF e validar no servidor.
- Configurar SameSite e revisar endpoints que alteram estado via GET.
- Exigir reautenticação/MFA para ações críticas.
Cenário 4: token exposto e reutilizado por muito tempo
Sintoma: access token sem expiração efetiva ou refresh token armazenado de forma insegura.
Falha provável: gestão inadequada de ciclo de vida de tokens/sessões.
Medidas corretivas:
- Definir expiração curta para access token e rotação de refresh token.
- Revogação/blacklist quando necessário (ex.: suspeita de comprometimento).
- Armazenamento seguro: evitar expor tokens a scripts (reduzir superfície de XSS) e proteger em trânsito (HTTPS).
Boas práticas de desenho de autorização em APIs
- Autorização centralizada: políticas aplicadas de forma consistente (middleware/filtros), evitando “esquecer” endpoints.
- Negar por padrão: se não há regra explícita, negar acesso.
- Escopos e permissões: associar tokens a escopos (ex.: contas:ler, contas:movimentar) e validar em cada endpoint.
- Separar autenticação de autorização: autenticar uma vez, autorizar sempre (em cada requisição/ação).
- Logs de auditoria: registrar decisões de autorização e ações sensíveis com correlação de transação.
