Capítulo 28 — Gestão de Usuários e Identidade

28.1 Objetivo do Capítulo

Este capítulo detalha o módulo de Gestão de Usuários e Identidade da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como identidades são criadas, autenticadas, vinculadas a tenants, organizadas em perfis e permissões, e como o ciclo de vida de cada usuário é governado ao longo da parceria.

O capítulo apresenta o módulo sob a perspectiva funcional e operacional — o que o sistema oferece para gestores, administradores e usuários gerenciarem identidades. Os controles técnicos de segurança (Zero Trust, OAuth, PKCE, tokens, mTLS) são detalhados no Capítulo 17. Este capítulo descreve a experiência de uso e as regras de negócio do domínio de identidade.

28.2 Papel do Módulo na Plataforma

O módulo de identidade é a fundação de toda a plataforma. Sem identidade verificada, não há Tenant Context. Sem Tenant Context, não há autorização. Sem autorização, nenhum dado é acessível.

Identidade verificada
    │
Tenant Context derivado
    │
Autorização avaliada
    │
Operação executada com trilha de auditoria

Este módulo responde a duas necessidades distintas: a identidade de usuários internos (atendentes, analistas, gestores, administradores) gerenciada pelo IAM próprio; e a identidade de cidadãos — gerenciada pelo IAM próprio ou federada via GOV.BR, conforme a jornada.

28.3 Categorias de Identidade

A plataforma diferencia as categorias de identidade com regras e mecanismos distintos:

As categorias não são intercambiáveis. Um cidadão autenticado não acessa funcionalidades de usuário interno. Um serviço técnico não tem perfil operacional.

28.4 IAM Próprio — Usuários Internos

28.4.1 Ciclo de Vida do Usuário Interno

Convidado → Cadastro → Ativo → Bloqueado → Inativo → Excluído

Convidado: o administrador do tenant cria o usuário com dados básicos e envia convite por e-mail. O usuário recebe link temporário para definir sua senha e ativar a conta.

Ativo: usuário com credenciais válidas, vínculo ativo com ao menos um tenant e ao menos um perfil. Pode autenticar e operar conforme suas permissões.

Bloqueado: conta temporariamente suspensa por política de segurança (excesso de tentativas de login) ou por ação administrativa. Não pode autenticar. Desbloqueável pelo administrador.

Inativo: usuário que não acessa a plataforma há período superior ao configurado na política do tenant, ou inativado manualmente pelo administrador. Não pode autenticar. Dados preservados conforme retenção.

Excluído: usuário removido com anonimização de dados pessoais identificáveis conforme LGPD. Registros de auditoria que referenciam o usuário preservam o ID técnico sem dados pessoais.

28.4.2 Dados do Usuário Interno

User
  id                    (UUID técnico, imutável)
  tenantId              (tenant primário)
  email                 (identificador de login; único por tenant)
  name
  jobTitle
  organizationalUnit
  status                (ACTIVE, BLOCKED, INACTIVE, DELETED)
  lastLoginAt
  createdAt
  updatedAt
  mfaEnabled
  mfaMethod

28.4.3 Vínculo com Tenant e Unidade

Um usuário pode ter vínculos com múltiplos tenants quando o órgão possui estrutura descentralizada ou quando o profissional atende mais de uma organização. Cada vínculo define: tenant, unidade organizacional, perfis atribuídos e validade (sem validade = permanente até revogação).

O usuário seleciona o contexto ativo ao autenticar quando possui vínculos com mais de um tenant. A alternância de contexto requer nova autenticação ou step-up quando a política define.

28.5 IAM Próprio — Cidadãos

28.5.1 Cadastro do Cidadão

O cidadão cria sua conta na plataforma com dados mínimos:

• nome completo;
• e-mail (usado como identificador de login);
• senha.

O e-mail é validado por link de confirmação enviado imediatamente após o cadastro. A conta não é considerada ativa até a confirmação.

28.5.2 Dados da Conta do Cidadão

A conta do cidadão no IAM é separada do perfil cadastral no Citizen Service. O IAM armazena credenciais, sessões e eventos de autenticação. O Citizen Service armazena dados pessoais completos, endereços, documentos, preferências e consentimentos.

IAM Account (Identity)         Citizen Service (Profile)
  email                          name
  passwordHash                   birthDate
  status                         documents
  lastLoginAt                ←── citizenId (vínculo)
  federatedIdentities            addresses
  sessions                       contacts
                                 preferences
                                 consents

A separação garante que os dados pessoais do cidadão sejam gerenciados pelo domínio responsável, com política de acesso, auditoria e retenção próprias.

28.5.3 Federated Identity — GOV.BR

Quando o cidadão autentica via GOV.BR pela primeira vez na plataforma:

1. identidade GOV.BR retorna com identificador estável do provedor;
2. a plataforma verifica se existe conta interna vinculada a esse identificador;
3. se não existe: cria vínculo (e opcionalmente a conta) com os atributos autorizados pelo GOV.BR;
4. se existe: reutiliza o vínculo existente;
5. a sessão da plataforma é emitida com identidade interna resolvida.

O vínculo é por identificador estável do GOV.BR — não por e-mail ou CPF mutável. Isso garante que alterações de e-mail no GOV.BR não quebrem o vínculo com a conta da plataforma.

28.5.4 Vinculação de Conta Existente

O cidadão que criou conta por IAM próprio pode vincular sua identidade GOV.BR posteriormente. O fluxo exige: autenticação ativa na plataforma, fluxo GOV.BR completo, confirmação do vínculo. A partir daí, pode usar qualquer dos dois mecanismos.

28.6 Autenticação

28.6.1 Por Credencial Local

Fluxo: e-mail + senha → validação de hash → verificação de MFA quando ativo → emissão de token de sessão.

Tentativas falhas são contadas por conta. Após o número configurado pelo tenant, a conta é bloqueada automaticamente e o usuário recebe notificação de segurança por e-mail.

28.6.2 Via GOV.BR

Fluxo Authorization Code + PKCE (detalhado no Capítulo 17). O cidadão é redirecionado ao GOV.BR, autentica e retorna com a sessão da plataforma estabelecida. A plataforma não armazena senha GOV.BR.

28.6.3 Níveis de Autenticação

O GOV.BR trabalha com níveis de confiabilidade (bronze, prata, ouro). A plataforma pode exigir nível mínimo por serviço — um serviço que exige assinatura digital pode requerer nível ouro (com certificado digital ou biometria). O nível de confiabilidade obtido é registrado com a sessão e verificado na jornada quando o serviço exige.

28.6.4 Autenticação Multifator (MFA)

MFA é configurado por tenant e obrigatório para perfis administrativos. O cidadão pode habilitar MFA voluntariamente para maior segurança.

Fatores suportados (conforme implementação do IAM):

• TOTP (Time-based One-Time Password) via aplicativo autenticador;
• envio de código por e-mail;
• envio de código por SMS.

Step-up authentication eleva o nível de autenticação durante a sessão para operações de maior risco (alteração de e-mail, exclusão de conta, exportação de dados), sem exigir novo login completo.

28.6.5 Recuperação de Acesso

O fluxo de recuperação de senha não revela se o e-mail existe ou não na plataforma — a mesma mensagem de confirmação de envio é apresentada independentemente, prevenindo enumeração de contas.

O link de recuperação: é temporário (expiração configurável); é de uso único (invalidado após uso); é enviado ao e-mail registrado; e requer definição de nova senha que respeite a política vigente.

Tentativas excessivas de recuperação são limitadas por rate limiting.

28.7 Sessões

28.7.1 Ciclo de Vida da Sessão

Criada (login)
    │
Ativa (uso normal com renovação de token)
    │
Expirada (inatividade ou tempo máximo)
    │
Revogada (logout, bloqueio, revogação administrativa)

28.7.2 Política de Sessão

Parâmetros configuráveis por tenant:

28.7.3 Sessões Múltiplas

O usuário pode ter sessões ativas em múltiplos dispositivos ou navegadores conforme a política do tenant. Cada sessão possui: dispositivo/canal, data de criação, último uso e possibilidade de revogação individual pelo próprio usuário ou pelo administrador.

28.7.4 Logout

O logout encerra a sessão no backend (revogação) — não apenas no cliente. Uma sessão revogada não pode mais ser usada mesmo que o token ainda não tenha expirado pelo TTL. Logout local sem revogação no backend não é aceito como encerramento seguro de sessão.

28.8 Política de Senha

28.8.1 Regras de Senha

A política de senha é configurável por tenant dentro dos limites mínimos da plataforma:

28.8.2 Armazenamento de Senha

Senhas nunca são armazenadas em texto claro. O hash utiliza algoritmo resistente a força bruta (Argon2 ou bcrypt conforme ADR). O salt é único por senha. Senhas em texto nunca aparecem em logs, traces ou respostas de API.

28.8.3 Verificação de Senhas Comprometidas

Quando configurado pelo tenant, a plataforma verifica se a nova senha foi exposta em vazamentos conhecidos usando serviço de Have I Been Pwned ou equivalente, sem enviar a senha em texto — apenas o prefixo do hash SHA-1 (k-anonymity). Senhas comprometidas são rejeitadas com orientação ao usuário.

28.9 Perfis e Permissões

28.9.1 Modelo de Autorização

Identidade + Tenant + Perfil + Permissão + Recurso + Operação + Escopo

Cada dimensão é verificada independentemente. A ausência de qualquer dimensão resulta em negação de acesso.

28.9.2 Permissões

Permissões são nomeadas no formato RESOURCE_OPERATION:

REQUEST_READ
REQUEST_SUBMIT
REQUEST_APPROVE
REQUEST_REJECT
DOCUMENT_DOWNLOAD
DOCUMENT_CLASSIFY
WORKFLOW_ADMIN
WORKFLOW_EXECUTE
CITIZEN_VIEW
CITIZEN_FULL_ACCESS
AUDIT_VIEW
CAMPAIGN_EXECUTE

Permissões são definidas pela plataforma. Novos tipos de permissão acompanham novos módulos.

28.9.3 Perfis

Perfis agrupam permissões compatíveis com um papel institucional. O administrador do tenant cria perfis customizados ou usa perfis padrão da plataforma:

Perfis padrão:

PLATFORM_ADMIN      → administração global
TENANT_ADMIN        → administração completa do tenant
OPERATIONAL_MANAGER → todos os módulos operacionais
SUPERVISOR          → CRM, BPM, supervisão
ATTENDANT           → atendimento, inbox, ficha do cidadão
ANALYST             → BPM, tarefas, análise de solicitações
DATA_ANALYST        → analytics, exploração de dados
COMMUNICATION_MGR   → templates, campanhas, segmentos
DOCUMENT_MGR        → GED, classificação, retenção
AUDITOR             → consulta à trilha de auditoria, somente leitura

28.9.4 Herança e Composição

Um usuário pode ter múltiplos perfis. As permissões efetivas são a união das permissões de todos os perfis atribuídos, aplicadas no escopo de cada um. Perfis com escopo de unidade limitam o acesso a recursos da unidade, mesmo que a permissão seja ampla.

28.9.5 Revisão de Acessos

A plataforma suporta revisão periódica de acessos:

• lista de usuários ativos por perfil e por unidade para revisão pelo administrador;
• alerta para usuários com perfis elevados que não acessaram a plataforma por período configurado;
• relatório de usuários com vínculos inativos ou próximos da expiração;
• exportação de matriz de acessos para auditoria.

A revisão é uma ação manual do administrador — o sistema fornece as informações necessárias e o mecanismo de revogação.

28.10 Gestão de Consentimentos

28.10.1 Consentimentos do Cidadão

O cidadão gerencia seus consentimentos no portal e no aplicativo:

• consentimento para comunicações de campanha (opt-in);
• consentimento para compartilhamento de dados com órgãos específicos;
• consentimento para uso de dados em análises e melhoria do serviço;
• consentimento para contato por cada canal (e-mail, SMS, WhatsApp).

Consentimentos obrigatórios para o serviço solicitado não são gerenciáveis pelo cidadão — são condição de uso do serviço. Consentimentos opcionais são revogáveis a qualquer momento.

28.10.2 Histórico de Consentimentos

Cada consentimento registra: tipo, data de concessão, canal de registro, versão dos termos no momento da concessão e, quando revogado, data e canal de revogação. O histórico é imutável.

28.10.3 Termos de Uso e Política de Privacidade

Na criação de conta ou em atualizações relevantes dos termos, o cidadão é informado e deve confirmar os termos antes de continuar. A confirmação é registrada com data, versão dos termos e canal. Quando os termos do tenant são atualizados de forma material, cidadãos ativos são notificados e solicitados a confirmar na próxima sessão.

28.11 Auditoria de Identidade

28.11.1 Eventos Auditados

Todos os eventos de identidade são registrados:

28.11.2 Detecção de Anomalias

A plataforma monitora padrões suspeitos:

• múltiplas falhas de login seguidas de sucesso (possível credential stuffing);
• login de localização ou device incomum para o usuário;
• acesso a recursos de tenant diferente do contexto usual;
• criação ou atribuição de perfil elevado fora do horário habitual.

Anomalias geram alerta para o administrador do tenant. A plataforma não bloqueia automaticamente sem configuração explícita — o alerta permite que o humano decida.

28.12 Federação e Integração com GOV.BR

28.12.1 Atributos Disponíveis

O GOV.BR pode fornecer atributos autorizados sobre o cidadão conforme o nível de confiabilidade e os escopos solicitados:

• nome;
• CPF (quando autorizado);
• data de nascimento;
• e-mail verificado;
• telefone verificado;
• foto (quando disponível e autorizado);
• nível de confiabilidade (bronze, prata, ouro).

A plataforma solicita apenas os atributos necessários para a jornada — minimização de dados.

28.12.2 Atualização de Atributos

Os atributos do GOV.BR não são automaticamente atualizados na plataforma a cada login. A plataforma controla o que é sincronizado e quando, seguindo a política de minimização e finalidade. Atributos de alta sensibilidade (CPF) são sincronizados somente quando necessários para a jornada e nunca expostos desnecessariamente.

28.12.3 Desvinculação

O cidadão pode desvincular sua identidade GOV.BR da conta da plataforma. Após a desvinculação, somente o login por credencial local está disponível até nova vinculação. A desvinculação não exclui dados pessoais nem cancela solicitações em andamento.

28.13 Proteção de Dados no Módulo de Identidade

28.13.1 Minimização

O IAM armazena apenas o necessário à autenticação e controle de acesso. Dados pessoais extensos do cidadão residem no Citizen Service. Logs de autenticação não incluem senhas, tokens ou conteúdo de sessão.

28.13.2 Direitos do Titular

Quando o titular solicita exclusão da conta, o IAM:

• inativa a conta e encerra sessões ativas;
• remove ou anonimiza dados pessoais identificáveis (nome, e-mail);
• preserva o ID técnico nos registros de auditoria (sem dados pessoais);
• propaga a solicitação ao Citizen Service para exclusão do perfil completo.

Contas vinculadas a processos administrativos ativos não são excluídas até a conclusão — o cidadão é informado sobre o impedimento e o prazo esperado.

28.13.3 Portabilidade

O cidadão pode solicitar exportação dos dados da sua conta no IAM: dados de registro, histórico de consentimentos, histórico de sessões (sem tokens) e vínculos com tenants. A exportação segue o fluxo assíncrono com link temporário.

28.14 Rastreabilidade com o Anexo III

28.15 Benefícios do Módulo

• identidade verificada como fundação de toda operação na plataforma;
• separação clara entre identidade do cidadão (IAM + GOV.BR) e identidade interna (IAM);
• modelo RBAC com permissões granulares que permite menor privilégio real;
• ciclo de vida completo do usuário interno com estados controlados;
• recuperação de acesso sem enumeração de contas;
• MFA por perfil de risco com step-up para operações sensíveis;
• histórico de consentimentos imutável para conformidade com LGPD;
• revisão periódica de acessos suportada pelo módulo;
• detecção de anomalias com alerta para o administrador.

28.16 Riscos e Mitigações

28.17 Decisões Arquiteturais

28.18 Considerações Finais

O módulo de identidade é o componente mais crítico da plataforma do ponto de vista de segurança. Um erro aqui — um vínculo incorreto de tenant, uma sessão não revogada, uma permissão excessiva — compromete toda a cadeia de controles posteriores.

A solidez do módulo não está apenas nas tecnologias adotadas, mas nos princípios que orientam cada decisão: identidade sempre verificada, menor privilégio sempre aplicado, cada ação sempre auditada, e a revogação sempre processada — no backend, não apenas no cliente.

O Capítulo 29 detalha a Arquitetura de Observabilidade, Operação SRE e Resiliência.

28.19 Controle de Versão

28.20 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 6 — Infraestrutura, Segurança e Governança: itens 6.2 e 6.3 cobertos conforme seção 28.14; item 1.1 pelo suporte a IAM próprio e GOV.BR.
• [ANX-IV] — Capacidades técnicas de IAM, federação GOV.BR, RBAC, MFA, gestão de sessões e auditoria de identidade.
• [ANX-V] Item 2.3 — Proteção do usuário: gestão de consentimentos conforme LGPD, política de senha com verificação de comprometimento, minimização de dados no IAM, direitos do titular suportados (exclusão e portabilidade).
• [PNR] — Plano de Negócio Referencial: plataforma com IAM próprio multi-tenant, integração GOV.BR para cidadãos, controle de acesso por perfil e auditoria completa de identidade.
• [EDITAL] — Edital CP001/2026: plataforma com gestão de identidade segura, RBAC, MFA, auditoria de autenticação e conformidade com LGPD.