Capítulo 29 — Gestão de Perfis e Permissões

29.1 Objetivo do Capítulo

Este capítulo detalha o módulo de Gestão de Perfis e Permissões da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como o controle de acesso é modelado, configurado, aplicado e revisado para garantir que cada usuário tenha acesso apenas ao que precisa para executar sua função — dentro do contexto do seu tenant e da sua unidade organizacional.

O Capítulo 28 detalhou o ciclo de vida de usuários e identidade. Este capítulo foca no modelo de autorização: como permissões são definidas, como perfis as agrupam, como são atribuídas a usuários, como o Tenant Context as delimita, e como a revisão periódica mantém o princípio de menor privilégio ao longo do tempo.

29.2 Papel do Módulo na Plataforma

O controle de acesso é a segunda linha de defesa após a autenticação. Autenticação responde "quem é esse usuário?". A gestão de perfis e permissões responde "o que esse usuário pode fazer, onde e em qual contexto?".

Usuário autenticado
    │
Tenant Context resolvido
    │
Perfil(s) do usuário no tenant
    │
Permissões efetivas
    │
Recurso + Operação + Escopo organizacional
    │
Autorizado ou Negado
    │           │
Executa      403 Forbidden
    │
Auditado (quando exigido)

O controle de acesso é sempre verificado no backend. A interface do Painel do Gestor pode ocultar elementos para melhorar a experiência, mas isso é experiência de usuário — não controle de segurança. O backend re-valida toda operação independentemente do que o frontend exibe.

29.3 Princípios

1. Menor privilégio — cada usuário recebe apenas as permissões estritamente necessárias para sua função. Ampliar o acesso é exceção, não padrão;
2. Negação por padrão — o que não está explicitamente permitido é negado. Não existe permissão implícita;
3. Autorização no backend — ocultar um botão no React não é controle de acesso. O backend valida toda operação;
4. Tenant como contexto, não como filtro — o tenant delimita o escopo de toda permissão; permissões não atravessam fronteiras de tenant;
5. Granularidade por operação — permissões nomeiam operações sobre recursos, não menus ou telas;
6. Revisão periódica — acessos acumulados ao longo do tempo são revertidos por processo de revisão sistemática;
7. Segregação de funções — operações críticas que não devem ser executadas pela mesma pessoa são separadas por design;
8. Contas nominativas — não existem contas compartilhadas ou genéricas para uso operacional; toda ação é atribuível a um indivíduo identificado.

29.4 Modelo de Autorização

29.4.1 Dimensões

O modelo de autorização combina sete dimensões:

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

A autorização efetiva é a interseção de todas as dimensões. A ausência ou negação de qualquer uma resulta em acesso negado.

Identidade: quem está solicitando. Verificado pela autenticação.

Tenant: em qual contexto organizacional. Derivado da identidade autenticada e seus vínculos — nunca aceito de parâmetro enviado pelo cliente como único fator.

Perfil: qual conjunto de permissões o usuário carrega no tenant.

Permissão: qual capacidade específica está sendo exercida (REQUEST_APPROVE, DOCUMENT_DOWNLOAD).

Recurso: qual objeto específico está sendo acessado (a solicitação req-uuid, o documento doc-uuid).

Operação: qual ação sobre o recurso (ler, criar, aprovar, excluir).

Escopo organizacional: em qual unidade o recurso se encontra e se o usuário tem acesso a ela.

29.4.2 RBAC — Controle Baseado em Papel

RBAC é o mecanismo base. Perfis agrupam permissões compatíveis com um papel institucional. Usuários recebem perfis, não permissões individuais diretamente.

Permissão REQUEST_READ
Permissão REQUEST_SUBMIT
Permissão DOCUMENT_UPLOAD
    │
Agrupadas no perfil ATTENDANT
    │
Atribuído ao usuário João Silva
no contexto do tenant Secretaria de Educação

29.4.3 Autorização por Recurso (BOLA)

RBAC garante que o usuário tem a permissão. A autorização por recurso garante que o recurso pertence ao contexto do usuário. As duas verificações são independentes e obrigatórias.

João tem permissão REQUEST_READ?               (RBAC — sim)
    │
A solicitação req-uuid pertence ao tenant João? (BOLA — verificar)
    │
A unidade da solicitação está no escopo de João? (Escopo — verificar)
    │
Autorizado

Passar na verificação RBAC sem passar na verificação de recurso não concede acesso. Um atendente com REQUEST_READ não acessa solicitações de outro tenant — mesmo que envie o ID correto.

29.4.4 ABAC — Autorização por Atributo

ABAC complementa o RBAC em operações que dependem de atributos do recurso ou do contexto:

Exemplos de regras ABAC:

Um analista pode aprovar uma solicitação SE:
  role = ANALYST
  AND tenant = solicitação.tenantId
  AND solicitação.unidade IN usuário.unidades
  AND solicitação.status = IN_ANALYSIS

Um supervisor pode visualizar todos os atendimentos SE:
  role = SUPERVISOR
  AND tenant = interação.tenantId
  (sem restrição de unidade)

Um atendente visualiza apenas atendimentos DA SUA FILA SE:
  role = ATTENDANT
  AND tenant = interação.tenantId
  AND interação.queueId IN usuário.queues

ABAC não é utilizado em toda operação — apenas quando RBAC isolado não representa fielmente a regra de negócio.

29.5 Catálogo de Permissões

As permissões são definidas pela plataforma no formato RESOURCE_OPERATION. Exemplos por domínio:

Catálogo (Serviços)

SERVICE_READ        → consultar serviços publicados
SERVICE_CREATE      → criar serviço
SERVICE_EDIT        → editar rascunho ou versão em revisão
SERVICE_PUBLISH     → publicar serviço
SERVICE_SUSPEND     → suspender serviço

Solicitações

REQUEST_READ              → consultar solicitação
REQUEST_SUBMIT            → abrir solicitação (cidadão)
REQUEST_STATUS_CHANGE     → alterar situação
REQUEST_COMPLEMENT_ASK    → solicitar complementação
REQUEST_APPROVE           → deferir solicitação
REQUEST_REJECT            → indeferir solicitação
REQUEST_CANCEL            → cancelar solicitação

Documentos

DOCUMENT_READ             → consultar metadados
DOCUMENT_DOWNLOAD         → baixar arquivo
DOCUMENT_UPLOAD           → enviar documento
DOCUMENT_CLASSIFY         → classificar tipo
DOCUMENT_APPROVE          → aprovar documento em solicitação
DOCUMENT_REJECT           → rejeitar documento

BPM

WORKFLOW_DEFINITION_VIEW  → visualizar definições de processo
WORKFLOW_DEFINITION_EDIT  → editar e versionar processo
WORKFLOW_DEFINITION_PUBLISH → publicar processo
WORKFLOW_INSTANCE_VIEW    → visualizar instâncias
WORKFLOW_INSTANCE_CANCEL  → cancelar instância

Atendimento (CRM)

INTERACTION_READ          → consultar interação
INTERACTION_REPLY         → responder
INTERACTION_ASSIGN        → atribuir atendente
INTERACTION_TRANSFER      → transferir
INTERACTION_CLOSE         → encerrar
CITIZEN_FULL_ACCESS       → acesso completo à ficha do cidadão

Comunicação

TEMPLATE_READ             → visualizar templates
TEMPLATE_EDIT             → editar template
TEMPLATE_APPROVE          → aprovar template
CAMPAIGN_CREATE           → criar campanha
CAMPAIGN_APPROVE          → aprovar campanha
CAMPAIGN_EXECUTE          → executar campanha

Analytics

ANALYTICS_VIEW            → dashboards básicos
ANALYTICS_EXPORT          → exportar dados analíticos
DATA_EXPLORE              → exploração de Data Products
QUALITY_RULE_MANAGE       → gerenciar regras de qualidade

Administração

TENANT_CONFIG_VIEW        → visualizar configuração do tenant
TENANT_CONFIG_EDIT        → editar configuração
USER_VIEW                 → listar e consultar usuários
USER_CREATE               → criar usuário
USER_EDIT                 → editar dados de usuário
USER_DEACTIVATE           → inativar usuário
ROLE_ASSIGN               → atribuir perfil a usuário
ROLE_REVOKE               → revogar perfil
INTEGRATION_MANAGE        → configurar integrações
AUDIT_VIEW                → consultar trilha de auditoria

29.6 Perfis Padrão da Plataforma

Os perfis padrão agrupam permissões compatíveis com os papéis institucionais mais comuns. O administrador do tenant pode criar perfis customizados combinando permissões disponíveis.

29.6.1 TENANT_ADMIN — Administrador do Tenant

Acesso completo à administração do tenant. Não tem acesso a configurações globais da plataforma.

Permissões: todas as permissões com prefixo TENANT_, USER_, ROLE_, INTEGRATION_, AUDIT_VIEW, leitura de todos os módulos.

29.6.2 OPERATIONAL_MANAGER — Gestor Operacional

Visão completa de todos os módulos operacionais e analytics do tenant. Não tem acesso a configurações administrativas.

Permissões: leitura e exportação de todos os módulos; ANALYTICS_VIEW, ANALYTICS_EXPORT, DATA_EXPLORE.

29.6.3 SUPERVISOR — Supervisor

Supervisão de atendimento e processos em tempo real. Pode redistribuir e intervir.

Permissões: INTERACTION_*, WORKFLOW_INSTANCE_VIEW, WORKFLOW_INSTANCE_CANCEL, ANALYTICS_VIEW, CITIZEN_FULL_ACCESS (limitado ao tenant).

29.6.4 ATTENDANT — Atendente

Atendimento ao cidadão e abertura de solicitações em nome do cidadão quando autorizado.

Permissões: INTERACTION_READ, INTERACTION_REPLY, INTERACTION_CLOSE, REQUEST_READ, DOCUMENT_READ, DOCUMENT_DOWNLOAD, acesso à ficha do cidadão conforme perfil de unidade.

29.6.5 ANALYST — Analista / Executor

Execução de tarefas de processo e análise de solicitações.

Permissões: REQUEST_READ, REQUEST_STATUS_CHANGE, REQUEST_APPROVE, REQUEST_REJECT, REQUEST_COMPLEMENT_ASK, DOCUMENT_READ, DOCUMENT_DOWNLOAD, DOCUMENT_APPROVE, DOCUMENT_REJECT, WORKFLOW_INSTANCE_VIEW.

29.6.6 SERVICE_MANAGER — Gestor de Serviços

Gerenciamento do catálogo de serviços do tenant.

Permissões: SERVICE_*, WORKFLOW_DEFINITION_*, formulários, templates vinculados a serviços.

29.6.7 COMMUNICATION_MANAGER — Gestor de Comunicação

Templates, campanhas e segmentos.

Permissões: TEMPLATE_*, CAMPAIGN_*, segmentos, ANALYTICS_VIEW de comunicação.

29.6.8 DOCUMENT_MANAGER — Gestor Documental

GED, classificação e políticas de retenção.

Permissões: DOCUMENT_*, TENANT_CONFIG_VIEW para políticas de GED, categorias e retenção.

29.6.9 DATA_ANALYST — Analista de Dados

Exploração analítica e qualidade de dados.

Permissões: ANALYTICS_VIEW, ANALYTICS_EXPORT, DATA_EXPLORE, QUALITY_RULE_MANAGE.

29.6.10 AUDITOR — Auditor

Somente leitura da trilha de auditoria. Sem acesso a dados operacionais.

Permissões: AUDIT_VIEW e nenhuma outra por padrão.

29.7 Perfis Customizados

O administrador do tenant cria perfis customizados para atender necessidades específicas do órgão:

Exemplo: Analista de Habilitação

Permissões:
  REQUEST_READ (solicitações do tipo habilitação)
  REQUEST_APPROVE
  REQUEST_REJECT
  DOCUMENT_READ
  DOCUMENT_DOWNLOAD
  DOCUMENT_APPROVE
  DOCUMENT_REJECT
Escopo: unidade "Departamento de Habilitação"

Regras para perfis customizados:

• um perfil customizado não pode ter permissões que excedam as permitidas ao administrador que o cria;
• perfis customizados são documentados com nome, finalidade e responsável;
• alterações em perfis customizados são auditadas;
• a desativação de um perfil revoga todas as atribuições ativas;
• perfis não são excluídos — apenas desativados, para preservar rastreabilidade histórica.

29.8 Atribuição de Perfis

29.8.1 Atribuição Individual

O administrador do tenant atribui um ou mais perfis a cada usuário, especificando:

• o perfil;
• a unidade organizacional de escopo (quando o perfil tem escopo de unidade);
• a data de início;
• a data de fim (opcional — sem data de fim equivale a permanente até revogação).

Usuário: Maria Fernandes
Tenant: Secretaria de Saúde

Perfil 1: ATTENDANT
  Unidade: Central de Atendimento
  Início: 2026-07-01
  Fim: (sem fim)

Perfil 2: DATA_ANALYST
  Unidade: (escopo de todo o tenant)
  Início: 2026-07-01
  Fim: 2026-12-31

29.8.2 Permissões Efetivas

As permissões efetivas de um usuário são a união das permissões de todos os perfis ativos no momento da requisição, com os escopos correspondentes a cada perfil.

Não existe negação explícita de permissão individual — a negação é feita pela não atribuição do perfil ou pela limitação de escopo. Se um usuário tem dois perfis, um com REQUEST_READ no escopo de Unidade A e outro com REQUEST_APPROVE no escopo de Unidade B, as permissões são aplicadas em cada escopo separadamente.

29.8.3 Escalação Temporária

Para situações que exigem acesso temporário elevado (ausência de colega, operação de emergência), a plataforma suporta atribuição de perfil com data de início e fim explícitas. A atribuição temporária é auditada normalmente. O acesso é revogado automaticamente ao atingir a data de fim, sem necessidade de ação manual.

29.9 Segregação de Funções

A plataforma implementa segregação de funções para operações de alto risco identificadas pelo órgão:

A segregação de quatro olhos (two-person rule) pode ser configurada pelo tenant para operações críticas. O fluxo exige que uma segunda pessoa com o perfil de aprovação confirme a ação antes da execução.

29.10 Revisão Periódica de Acessos

29.10.1 Objetivo

Acessos acumulados ao longo do tempo violam o princípio de menor privilégio. Usuários mudam de função, saem de projetos, são remanejados de unidade — e nem sempre os perfis são atualizados prontamente. A revisão periódica corrige esse acúmulo de forma sistemática.

29.10.2 Ciclo de Revisão

O administrador do tenant configura a frequência de revisão (mensal, trimestral, semestral). No início de cada ciclo, o módulo gera o relatório de revisão para o revisor responsável.

29.10.3 Relatório de Revisão

O relatório apresenta para cada usuário do tenant:

• nome e e-mail;
• perfis ativos com data de atribuição;
• unidades de escopo;
• último acesso à plataforma;
• data do último login bem-sucedido;
• ação recomendada (manter, revisar, revogar).

A recomendação é gerada automaticamente com base em: perfis sem acesso há mais de N dias, perfis atribuídos há mais de M meses sem revisão registrada, usuários inativos com perfis ainda ativos.

29.10.4 Ações do Revisor

Para cada usuário no relatório, o revisor confirma: manter sem alteração, revogar perfil específico, revogar todos os perfis (inativar usuário), ou adiar revisão com justificativa.

As ações do revisor são registradas na trilha de auditoria com data, responsável e decisão. A revisão concluída fecha o ciclo; a próxima abertura na frequência configurada.

29.10.5 Alertas de Acesso

Além da revisão periódica, alertas automáticos são gerados para:

• usuários com perfis elevados (TENANT_ADMIN, SUPERVISOR) que não acessam há mais de 30 dias;
• perfis temporários próximos da data de expiração;
• usuários com mais de N perfis ativos (possível acúmulo);
• usuário inativado que ainda consta em filas ativas.

29.11 Contas Privilegiadas e Break Glass

29.11.1 Controles Reforçados

Contas com perfis TENANT_ADMIN e PLATFORM_ADMIN têm controles adicionais:

• MFA obrigatório sem exceção;
• sessão com timeout reduzido;
• notificação por e-mail a cada login;
• alertas de acesso em horários atípicos;
• auditoria reforçada de toda ação.

Contas administrativas são sempre nominativas. Contas genéricas (admin, root-team, suporte) não são utilizadas para operação cotidiana.

29.11.2 Break Glass

A plataforma suporta mecanismo de acesso emergencial para situações em que os caminhos normais de autenticação estão indisponíveis:

• credencial fortemente protegida em cofre físico ou digital;
• uso restrito a situações de emergência declaradas;
• ativação gera alerta imediato para a equipe de segurança;
• toda ação executada com a credencial de emergência é auditada;
• revisão obrigatória posterior com registro da justificativa.

Break glass não é canal de suporte rotineiro. Uso não justificado é tratado como incidente de segurança.

29.12 Interface de Gestão de Perfis no Painel do Gestor

O administrador do tenant acessa a área de perfis e permissões pelo Painel do Gestor:

29.12.1 Gestão de Perfis

• listar perfis padrão e customizados do tenant;
• criar perfil customizado com nome, finalidade e permissões;
• editar permissões de perfil customizado;
• desativar perfil (com verificação de atribuições ativas);
• visualizar usuários atribuídos a um perfil;
• visualizar histórico de alterações por perfil.

29.12.2 Atribuição de Perfis a Usuários

• selecionar usuário;
• atribuir perfil com escopo de unidade e datas;
• revogar perfil com justificativa;
• visualizar todos os perfis ativos do usuário;
• visualizar permissões efetivas resultantes da composição de perfis.

29.12.3 Revisão de Acessos

• iniciar ciclo de revisão;
• visualizar relatório de revisão com filtros;
• registrar ação por usuário;
• concluir ciclo e gerar evidência;
• configurar frequência de revisão e responsáveis.

29.12.4 Matriz de Acessos

Visão matricial do tenant:

           | REQUEST_READ | REQUEST_APPROVE | DOCUMENT_DOWNLOAD | ...
-----------+--------------+-----------------+-------------------+----
João Silva | ✓ (Unidade A)|       ✗         |     ✓ (Unidade A) |
Maria Lima |      ✓       |    ✓ (Global)   |         ✓         |
Pedro Assis|      ✗       |       ✗         |         ✗         |

A matriz é exportável para revisão externa e auditoria.

29.13 Modelo de Dados

Permission
  code              (REQUEST_READ, DOCUMENT_DOWNLOAD...)
  resource          (REQUEST, DOCUMENT, CAMPAIGN...)
  operation         (READ, CREATE, APPROVE, DELETE...)
  description
  module
  createdAt

Role
  id
  tenantId          (null = perfil padrão da plataforma)
  name
  description
  purpose
  status            (ACTIVE, DEPRECATED)
  permissions[]     (lista de Permission.code)
  createdBy
  createdAt
  updatedAt

UserRoleAssignment
  id
  userId
  tenantId
  roleId
  organizationalUnitId   (null = escopo de todo o tenant)
  validFrom
  validTo                (null = sem expiração)
  status                 (ACTIVE, REVOKED, EXPIRED)
  assignedBy
  assignedAt
  revokedBy
  revokedAt
  revokedReason

AccessReviewCycle
  id
  tenantId
  reviewerId
  status             (OPEN, IN_PROGRESS, COMPLETED)
  periodStart
  periodEnd
  frequency
  startedAt
  completedAt

AccessReviewDecision
  id
  cycleId
  userId
  roleAssignmentId
  decision           (MAINTAIN, REVOKE, DEFER)
  justification
  decidedBy
  decidedAt

29.14 Auditoria do Módulo

Toda ação de gestão de perfis e permissões é registrada:

29.15 Rastreabilidade com o Anexo III

29.16 Benefícios do Módulo

• menor privilégio aplicado de forma sistemática com revisão periódica;
• permissões granulares por operação, não por tela ou menu;
• perfis padrão prontos para uso com customização governada;
• escopo de unidade organizacional que limita acesso mesmo dentro do tenant;
• ABAC complementa RBAC nas regras de negócio contextuais;
• segregação de funções configurável para operações críticas;
• matriz de acessos exportável para auditoria e conformidade;
• escalação temporária com expiração automática;
• break glass com controle estrito para emergências.

29.17 Riscos e Mitigações

29.18 Decisões Arquiteturais

29.19 Considerações Finais

A gestão de perfis e permissões transforma o princípio de menor privilégio em realidade operacional. Não basta definir permissões granulares se elas são atribuídas em excesso por conveniência e nunca revisadas. A combinação de catálogo de permissões detalhado, perfis com finalidade declarada, escopo de unidade organizacional, revisão periódica sistemática e alertas automáticos garante que o acesso se mantenha alinhado à necessidade real ao longo do ciclo de vida da parceria.

O Capítulo 30 detalha o módulo de Integrações e Interoperabilidade.

29.20 Controle de Versão

29.21 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 6 — Infraestrutura, Segurança e Governança: itens 6.2, 6.3 e 6.4 cobertos conforme seção 29.15.
• [ANX-IV] — Capacidades técnicas de RBAC, ABAC, autorização por recurso, segregação de funções e revisão periódica de acessos.
• [ANX-V] — Sustentabilidade: perfis com finalidade declarada, revisão periódica suportada pelo módulo, permissões extensíveis por módulo, atribuições com ciclo de vida gerenciado.
• [PNR] — Plano de Negócio Referencial: plataforma com controle de acesso granular por perfil, menor privilégio aplicado sistematicamente e auditoria de autorização.
• [EDITAL] — Edital CP001/2026: plataforma com RBAC configurável por tenant, segregação de funções e revisão periódica de acessos para conformidade com requisitos de governança.