Identity & Access Management

Resumo curto

O IAM é um conjunto de processos, políticas e ferramentas que fornecem a quem acessa o quê, sob quais condições e como isso é controlado. Os objetivos são minimizar os direitos redundantes, reduzir a superfície de ataque, acelerar o controle e a auditoria, adequar-se aos requisitos (PCI DSS, GDPR etc.) e medir a confiabilidade do acesso.

Conceitos básicos

Identidade: pessoa (funcionário, contratante), serviço/aplicativo, dispositivo.
Autenticação (AuthN): verificação de «quem» (senha → MFA → esquemas sem barras FIDO2/passkeys).
Permissão (AuthZ): solução «o que é permitido» (RBAC/ABAC/ReBAC, políticas).
Credencials: senhas, chaves, tokens, certificados (mTLS).
Gestão de segredo: KMS/HSM/Vault, roteiros, TTL curtos, segredos dinâmicos.
Ciclo de vida: Joiner-Mover-Leaver (JML) - criar, alterar papéis, rever.

Arquitetura alvo do IAM

• IdP (provedor de identidade): SSO, MFA, diretório, federação (OIDC/SAML), políticas de risco.
• PDP/PEP: Decision/Enforcement - Motor de políticas (OPA/Cedar) + Pontos de Aplicação (passarelas API, proxy, serviço-mesh).
• Diretórios/HR: fonte de verdade para funcionários e papéis.
• Mantiming: SCIM/Automation para criar/alterar/rever acessibilidade.
• Auditoria: logs centralizados, UEBA, relatórios de papéis e acessibilidade.

• SSO (+ MFA) → Lançamento do Tocen (OIDC/JWT/SAML) → PEP verifica o token/contexto → o PDP decide a política (papel/atributos/risco) → o aplicativo emite/nega o acesso.

Autenticação: de senhas para passkeys

Senhas: apenas com gerentes de senhas, mínimo de 12 a 14 caracteres, sem rotação de calendário, mas obrigatório no incidente.
MFA padrão: TOTP/WebAuthn/Push; evitar SMS como fator principal.
Entrada sem paróquia: FIDO2/passkeys para domínios críticos.
AuthN adaptativa: leve em conta o sinal de risco (geo, ASN, dispositivo, anomalias) → exija um fator adicional/bloqueio.

Autorização: RBAC, ABAC, ReBAC

RBAC: papéis correspondentes às funções (Suporte, Finance, DevOps). Simples e compreensível, mas «cresce».
ABAC: regras sobre atributos (divisão, nível de risco, hora, área, rótulos de recursos). Escalável.
ReBAC: relacionamentos de «quem se refere a quê» (proprietários de projetos, membros de comandos). Confortável para cenários multifacetados.

• Combinar RBAC (malha básica) + ABAC/ReBAC (contexto/limites).
• JIT (Just-In-Time): emissão de privilégios temporários através de solicitação/aproximação, revisão automática.
• JEA (Just-Enough Access): direito mínimo suficiente para a operação.
• PAM: Acessibilidade isolada «forte» (ADM/nuvem) com corretor de sessões, gravação de tela/comandos e emissão de créditos de curta duração.

Federação e SSO

Protocolos: OIDC (JWT-Tokens), SAML 2. 0- para provedores/parceiros externos.
SSO: ponto de entrada unificado com MFA, redução de phishing, revisão centralizada.
B2B/B2C: federação com parceiros, limitação de áreas, políticas de domínio.
mTLS/m2m: Use x.509 (SPIFFE/SVID) ou OAuth2 Clientes Credentals para os serviços.

Ciclo de vida (JML) e mantimentos

Joiner: Mantimentos SCIM automáticos e papéis básicos de HR/catálogo.
Mover: os papéis mudam automaticamente por atributos (divisão, projeto, localização).
Leaver: Reveja imediatamente SSO, chaves, tokens, acessos a repositórios/nuvens/CI/CD.
Processos: Pedidos de Acesso (ITSM), Matriz de SoD (Divisão de Responsabilidades), abreviações periódicas.

Segredos, chaves e roteiros

KMS/HSM: Guarde as chaves de raiz/crítica, inclua a auditoria das operações.
Vault/Segredos gerentes: credos dinâmicos (BB, nuvens), revezamento automático quando a TTL é concluída.
Rotativos: tokens OAuth, chaves de assinatura JWT, senhas de serviços - agendados e incidentes.
mTLS: certificados de curta duração (horários/dias), translação automática.

Políticas e motores de solução

Declaração: guarde as políticas no Git; verifique em CI (policy-tests).
Contexto: tempo/localização/ASN/nível de risco/estado do dispositivo (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Monitoramento, SLO e auditoria

• Sucesso de AuthN/AuthZ (%), p95 tempo de login/decisão, participação MFA/ingressos sem tarja.
• Em escalas de JIT/PAM, duração média de privilégios.
• Revestimento de dispositivos compliant, proporção de segredos de curta duração.

• Disponibilidade SSO/IdP ≥ 99. 95% por mês.
• p95 AuthZ decision ≤ 50 мс.
• 100% de desligamento ≤ 15 minutos após o offboarding.
• Auditoria e UEBA: logs centralizados (acessibilidade, alterações de papéis, entradas fracassadas, soluções PDP), análise comportamental e ansiedade por anomalias.

Incidente de respeito no IAM

Comprometimento de tokens/chaves: revogação imediata, logout forçado, rotação de chaves de assinatura, e-issue segredos de curta duração.
Abuso de permissões: suspende a contagem, bloqueia o JIT/JEA, execute o acess review nas entidades vizinhas.
IdP não disponível: modos offline (validação em dinheiro temporário de tokens com TTL curto), procedimentos prioritários de recuperação.
Phishing: MFA obrigatório, verificação de risco de sessões, notificações aos usuários, treinamento.

Nuvens e Kubernetes (pattern)

Público Cloud IAM: Use papéis nativos com o princípio least privege; em vez das chaves «eternas» - cargas de trabalho com a federação OIDC para a nuvem (IRSA/Workload Identity).
Kubernetes: RBAC em neymspace/papéis, limitar 'cluster-admin'; segredos - através de gerentes externos; serviço-mesh + OPA para políticas L7; Controladores Adesion (imagens assinadas, proibido «: latest»).
Passarelas API: verificação de JWT/mTLS, limitações de velocidade, assinaturas de solicitação (HMAC) para endpoint sensíveis.

Prática para iGaming/Fintech

Domínios de acesso: pagamentos, antifrode, PII, provedores de conteúdo - isolar papéis e segmentos de rede.
SoD: Impede a combinação de papéis em conflito (por exemplo, criação de promo + aprovação de pagamentos).
PAM e JIT: para acesso a PSP/bancos e prod-BD - apenas através de um corretor de sessões, gravação e levantamento automático.
Complacência: PCI DSS - MFA, privilégios mínimos, segmentação de área CHD; GDPR - Princípio de minimização de dados e logs pontuais de acesso ao PII.
Associados e provedores de conteúdo - federação e políticas pro-tenant; tokens de curta duração e IP/ASN allow-list.

Erros típicos

Chaves e tokens «eternos»: falta de rotação e TTL → alto risco de fuga.
Offboarding manual: atrasos na retirada de permissões → acessos «fantasmas».
Papéis monolíticos: um «super-papel» em vez de composição e atributos.
MFA apenas no Admin: MFA deve ser para todas as entradas e operações críticas.
Logs para lado nenhum: falta de centralização e UEBA → mais tarde detecção de incidentes.

Mapa de trânsito da implementação do IAM

1. Inventário de usuários/serviços/recursos; mapa de dados e sensibilidade.
2. SSO + MFA para todos, incluir fatores phishing-resistant.
3. Modelo de papéis: RBAC básico + atributos (ABAC) para o contexto; matriz SoD.
4. Provimento SCIM: automação/alteração/revogação de direitos de HR/catálogo; inscrições e apruvas no ITSM.
5. PAM e JIT/JEA: para acesso privilegiado; gravação de sessões, TTL curtos.
6. Gestão secreta: rejeição de chaves estáticas; segredos dinâmicos, roteiros, mTLS com certificados curtos.
7. Políticas em Git + CI: testes de regras, controle de mudanças, implantação de políticas canárias.
8. Observabilidade e SLO: dashboards AuthN/AuthZ, alertas, regulares access review.

Exemplos de artefatos

AWS IAM Policy (mínimo para leitura de relatórios S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (namespace-scoped desenvolvedor)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: afirmações para ABAC (exemplo)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

A política pode exigir 'device _ compliant = true' e 'tenant', que corresponde ao recurso.

Lista de controle (check-elist)

• O SSO está ativado para todos os aplicativos; MFA padrão, passkeys prioridade.
• RBAC definido; ABAC/ReBAC adicionam contexto; implementados pelo JIT/JEA.
• PAM protege acessibilidade privilegiada; a gravação das sessões está em andamento.
• Mantimentos SCIM de HR; offboarding totalmente automatizado.
• Segredos dinâmicos, com TTL curto; rotações automatizadas.
• As políticas são versionizadas em Git, testadas em CI; Há canários.
• Dashboards e SLO por AuthN/AuthZ; logs centralizados e UEBA.
• Verificações periódicas de access review e SoD; relatórios para a complacência.

FAQ

Todos precisam de ReBAC?
Não. Para ambientes simples, o RBAC + ABAC é suficiente. É útil para a complexa hierarquia de posse de recursos e multifacetação.

Podemos deixar as aulas locais?
Somente para break-glass e cenários offline, com restrições severas e verificações periódicas.

Como reduzir a explosão de papéis?
Elevar a granularidade de recursos, usar modelos/AVAS, automatizar o revezamento e abrir mão de papéis não utilizados.

Resultado

Arquitetura IAM madura é SSO + MFA, direitos mínimos necessários, JML automatizado, políticas centralizadas e observabilidade. Ao combinar RBAC com modelos atributos e relacionais, aplicar JIT/JEA e PAM e automatizar mantimentos e rotações de segredos, você tem acesso controlado, verificável e escalável, adequado aos requisitos de segurança e negócios.