Relacionamento Digitalcom o Cidadão
Parte VI — Segurança e Conformidade
Parte VI — Segurança e ConformidadeCapítulo 43

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íticaExemploConfigurável
Comprimento mínimo de senha8 caracteresSim
Exigência de complexidadeCombinação de tiposSim
Histórico de senhasNão reutilizar últimas 5Sim
Expiração de sessão (inatividade)15 minutosSim
Duração máxima de sessão8 horasSim
Tentativas de login falhadas5 antes de bloquearSim
MFA obrigatóriaPor perfilSim
GOV.BR obrigatórioForçar federaçãoNã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-IIIAtendimento
6.2IAM com autenticação multi-fator e RBAC
6.3Auditoria de toda ação de autenticação/autorização
1.1Integraçã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

RiscoMitigação
Token em localStorage roubado por XSSArmazenamento seguro do SO; HttpOnly cookies
Sessão não revogada após logoutRevogação imediata no backend
Vínculo GOV.BR por e-mail mutávelVínculo por identificador estável (sub)
MFA bypassRate limiting, alertas, análise de anomalias
Autorização apenas no clienteRe-validação obrigatória no backend

43.15 Decisões Arquiteturais

ADRTema
ADR-1001Tecnologia do IAM próprio
ADR-1002Protocolo (OAuth 2.0 + OIDC)
ADR-1003Algoritmo de hash de senha (Argon2 vs. bcrypt)
ADR-1004Métodos de MFA suportados
ADR-1005Integraçã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

CampoValor
DocumentoDocumento Mestre — Plataforma de Relacionamento Digital com o Cidadão
Capítulo43 — IAM — Gestão de Identidade e Acesso
Versão1.0
SituaçãoConcluído
Última atualização16/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.

Nesta página