Capítulo 43 — IAM — Gestão de Identidade e Acesso
Este capítulo detalha a implementação técnica do IAM (Identity and Access Management) da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como identidades são provisionadas, autenticadas, autorrizadas e au…
43.1 Objetivo do Capítulo
Este capítulo detalha a implementação técnica do IAM (Identity and Access Management) da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como identidades são provisionadas, autenticadas, autorrizadas e auditadas em uma arquitetura multi-tenant.
O capítulo cobre: arquitetura do IAM, protocolos (OAuth 2.0, OpenID Connect, SAML), integração com GOV.BR, gestão de tenants, políticas de autenticação, autorização dinâmica, federação de identidade, gestão de ciclo de vida, conformidade e operação.
43.2 Papel do IAM na Plataforma
O IAM é o fundamento de toda operação:
Cidadão / Usuário solicita acesso
│
IAM autentica (verifica identidade)
│
Tenant Context é estabelecido
│
Autorização é avaliada (verifica permissão)
│
Recurso é acessado com rastreamento
│
Auditoria registra a ação
Sem IAM governado, não há isolamento multi-tenant, não há autorização confiável, não há rastreabilidade.
43.3 Arquitetura do IAM
O IAM é estruturado em camadas:
┌─────────────────────────────────────┐
│ CAMADA DE APRESENTAÇÃO │
│ Portal Web │ Mobile │ Painel │
├─────────────────────────────────────┤
│ CAMADA DE AUTENTICAÇÃO │
│ Credencial Local │ GOV.BR │ MFA │
├─────────────────────────────────────┤
│ CAMADA DE IDENTIDADE │
│ Usuários │ Tenants │ Atributos │
├─────────────────────────────────────┤
│ CAMADA DE AUTORIZAÇÃO │
│ Perfis │ Permissões │ Policies │
├─────────────────────────────────────┤
│ CAMADA DE PERSISTÊNCIA │
│ PostgreSQL │ Cache │ Auditoria │
└─────────────────────────────────────┘
Cada camada tem responsabilidade clara e é testada independentemente.
43.4 Protocolos de Autenticação
43.4.1 OAuth 2.0 e OpenID Connect
O IAM implementa OAuth 2.0 (protocolo de autorização) e OpenID Connect (protocolo de autenticação) como padrões:
Authorization Code Flow + PKCE:
Cliente inicia login
│
Redireciona para IAM com state + code_challenge
│
Usuário autentica (credencial ou GOV.BR)
│
IAM redireciona para Cliente com authorization_code
│
Cliente troca code + code_verifier por token JWT
│
Cliente armazena token seguramente
│
Requisições subsequentes incluem token no header Authorization
PKCE (Proof Key for Code Exchange) é obrigatório para prevenir CSRF e code interception.
43.4.2 JWT (JSON Web Token)
Tokens são JWT com payload estruturado:
{
"sub": "user-uuid",
"iss": "https://iam.platform",
"aud": "api-gateway",
"tenant_id": "tenant-uuid",
"scopes": ["openid", "profile", "email"],
"roles": ["ATTENDANT", "ANALYST"],
"permissions": ["REQUEST_READ", "REQUEST_SUBMIT"],
"iat": 1689433200,
"exp": 1689436800
}
Tokens são assinados com RS256 (RSA) e criptografados com JWE quando conter dados sensíveis.
43.4.3 Refresh Tokens
Access tokens têm TTL curto (15-30 minutos). Refresh tokens permitem obter novo access token sem reautenticação:
Access Token expirado
│
Cliente envia Refresh Token ao IAM
│
IAM valida Refresh Token
│
IAM retorna novo Access Token
│
Cliente continua operação
Refresh tokens têm TTL longo (dias) e são armazenados no banco do IAM com rastreamento de revogação.
43.5 Fluxo de Autenticação com GOV.BR
Cidadão seleciona "Entrar com GOV.BR" no Portal
│
Portal redireciona ao IAM com scope e state
│
IAM inicia Authorization Code Flow com GOV.BR
│
Cidadão é redirecionado ao GOV.BR
│
GOV.BR autentica (credencial ou biometria)
│
GOV.BR redireciona ao IAM com authorization_code
│
IAM troca code por ID Token + Access Token do GOV.BR
│
IAM extrai claims: sub (identificador estável), email, CPF (se autorizado)
│
IAM localiza ou cria vínculo com identidade interna
│
IAM emite Access Token da plataforma
│
Portal armazena token e efetua login do cidadão
O identificador estável (sub) do GOV.BR é a chave do vínculo — não e-mail ou CPF que podem mudar.
43.6 Autenticação Multifator (MFA)
MFA é configurável por tenant e obrigatória para perfis administrativos.
43.6.1 Métodos de MFA
- TOTP (Time-based One-Time Password) — Google Authenticator, Authy
- Email — código enviado ao e-mail registrado
- SMS — código enviado por SMS (quando provedor configurado)
- Push Notification — aprovação via app mobile
- Biometria — no dispositivo (complementar a autenticação, não substitui)
43.6.2 Fluxo de MFA
Credencial validada
│
MFA é configurado para o usuário?
├─ Não → token emitido
└─ Sim → desafio MFA enviado
│
Usuário responde com código/biometria
│
Valido? → token emitido
Inválido? → erro e retenção
Tentativas falhadas de MFA são limitadas por rate limiting.
43.7 Gestão Multi-Tenant no IAM
Cada tenant tem configuração própria no IAM:
Tenant
├─ ID único
├─ Nome
├─ Configuração de autenticação
│ ├─ Políticas de senha
│ ├─ MFA obrigatória?
│ ├─ GOV.BR integrado?
│ └─ Timeout de sessão
├─ Atributos
├─ Usuários
└─ Papéis e permissões
Cada tenant pode customizar:
- Política de senha
- Exigência de MFA
- Integração com GOV.BR
- Timeout de sessão
- Política de retenção de dados
- Branding (logomarca no login)
43.8 Provisionamento de Usuários
43.8.1 Usuários Internos
Administrador do tenant cria usuário:
POST /tenants/{tenantId}/users
{
"email": "atendente@orgao.gov.br",
"name": "João Silva",
"jobTitle": "Atendente",
"organizationalUnit": "Central de Atendimento"
}
Usuário recebe e-mail com link temporário para definir senha.
43.8.2 Cidadãos
Cidadão cria conta:
POST /auth/signup
{
"email": "cidadao@email.com",
"name": "Maria Santos",
"password": "SecurePassword123!"
}
E-mail é validado por link de confirmação.
43.8.3 Integração com Sistemas Externos
SCIM (System for Cross-domain Identity Management) pode ser implementado para sincronização com LDAP/Active Directory:
Diretório externo
│
SCIM Connector
│
IAM (create, update, delete usuários)
A decisão de adotar SCIM é registrada como ADR.
43.9 Políticas de Autenticação
Políticas são configuráveis por tenant:
| Política | Exemplo | Configurável |
|---|---|---|
| Comprimento mínimo de senha | 8 caracteres | Sim |
| Exigência de complexidade | Combinação de tipos | Sim |
| Histórico de senhas | Não reutilizar últimas 5 | Sim |
| Expiração de sessão (inatividade) | 15 minutos | Sim |
| Duração máxima de sessão | 8 horas | Sim |
| Tentativas de login falhadas | 5 antes de bloquear | Sim |
| MFA obrigatória | Por perfil | Sim |
| GOV.BR obrigatório | Forçar federação | Não (alinhado a nível de plataforma) |
43.10 Gerenciamento de Sessões
43.10.1 Sessão no Backend
O IAM mantém registro de sessão no banco:
Session
├─ id (UUID)
├─ user_id
├─ tenant_id
├─ token_hash (hash do token, nunca o token completo)
├─ device (User-Agent)
├─ ip_address
├─ created_at
├─ last_activity
├─ expires_at
├─ revoked_at (null enquanto ativa)
└─ revoke_reason
43.10.2 Múltiplas Sessões por Usuário
Usuário pode ter múltiplas sessões simultâneas (diferentes dispositivos/navegadores):
Usuário: João Silva
├─ Sessão 1: Navegador Chrome em Desktop
├─ Sessão 2: Navegador Safari em iPad
└─ Sessão 3: App Mobile em iPhone
Cada sessão é revogável independentemente.
43.10.3 Revogação de Sessão
Logout e revogação imediata no backend:
POST /auth/logout
Sessão é marcada como revoked_at = agora
Token é invalido a partir daquele instante
Mesmo se TTL não expirou
43.11 Autorização Dinâmica
Autorização é verificada em tempo de requisição, não em cache estático:
Request recebida
│
Token validado
│
Tenant Context extraído
│
Usuário ativo? → Sim
│
Perfil(s) ativo? → Sim
│
Permissão para operação? → Sim
│
Recurso pertence ao tenant? → Sim
│
Autorizado
Se qualquer verificação falhar → 403 Forbidden.
43.12 Rastreabilidade com o Anexo III
| Item ANX-III | Atendimento |
|---|---|
| 6.2 | IAM com autenticação multi-fator e RBAC |
| 6.3 | Auditoria de toda ação de autenticação/autorização |
| 1.1 | Integração com GOV.BR como provedor de identidade |
43.13 Benefícios do IAM
- identidade sempre verificada antes de qualquer operação;
- isolamento multi-tenant estrutural no nível de identidade;
- MFA reduz risco de account takeover;
- integração GOV.BR fornece identidade verificada;
- auditoria completa de acesso e alterações;
- políticas configuráveis por tenant sem alteração de código;
- revogação imediata de sessões em caso de segurança;
- compatibilidade com padrões OAuth 2.0 e OpenID Connect.
43.14 Riscos e Mitigações
| Risco | Mitigação |
|---|---|
| Token em localStorage roubado por XSS | Armazenamento seguro do SO; HttpOnly cookies |
| Sessão não revogada após logout | Revogação imediata no backend |
| Vínculo GOV.BR por e-mail mutável | Vínculo por identificador estável (sub) |
| MFA bypass | Rate limiting, alertas, análise de anomalias |
| Autorização apenas no cliente | Re-validação obrigatória no backend |
43.15 Decisões Arquiteturais
| ADR | Tema |
|---|---|
| ADR-1001 | Tecnologia do IAM próprio |
| ADR-1002 | Protocolo (OAuth 2.0 + OIDC) |
| ADR-1003 | Algoritmo de hash de senha (Argon2 vs. bcrypt) |
| ADR-1004 | Métodos de MFA suportados |
| ADR-1005 | Integração com GOV.BR — escopo e atributos |
43.16 Considerações Finais
O IAM não é um componente isolado — é a fundação de confiança de toda a plataforma. A solidez do IAM determina se a autorização é confiável, se a auditoria é rastreável e se o isolamento multi-tenant é real.
O Capítulo 44 detalha a conformidade com LGPD e proteção de dados pessoais.
43.17 Controle de Versão
| Campo | Valor |
|---|---|
| Documento | Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão |
| Capítulo | 43 — IAM — Gestão de Identidade e Acesso |
| Versão | 1.0 |
| Situação | Concluído |
| Última atualização | 16/07/2026 |
43.18 Rastreabilidade PRODEMGE
- [ANX-III] Bloco 6 — itens 6.2 e 6.3 cobertos conforme seção 43.12.
- [ANX-IV] — Capacidades técnicas de autenticação multi-tenant, GOV.BR, RBAC, auditoria.
- [ANX-V] Item 2.3 — Proteção do usuário: MFA, integração GOV.BR, auditoria de acesso.
- [PNR] — IAM próprio multi-tenant com integração GOV.BR.
- [EDITAL] — Edital CP001/2026: plataforma com gestão de identidade segura, autenticação forte, integração Gov.br.
Capítulo 42 — Arquitetura de Segurança
Este capítulo estabelece os princípios, padrões e controles de segurança da Plataforma de Relacionamento Digital com o Cidadão. A segurança não é um componente adicionado ao final — é um requisito transversal que permeia…
Capítulo 44 — LGPD e Proteção de Dados Pessoais
Este capítulo detalha como a Plataforma de Relacionamento Digital com o Cidadão implementa a Lei Geral de Proteção de Dados (Lei 13.709/2018 — LGPD) em seus processos, tecnologia e operação.