Skip to content
EBDbe

ADR-0012 — Multitenancy por Domínio e Papel PLATFORM_ADMIN

Status

Section titled “Status”

Proposto

Contexto

Section titled “Contexto”

O EBDbe evoluiu para atender múltiplos ministérios de forma isolada, com necessidade explícita de:

  • Um domínio de internet por ministério (ex.: ministerio-a.ebdbe.app)
  • Isolamento de dados e operações por tenant ministerial
  • Governança central da plataforma para operação transversal entre ministérios

Os ADRs atuais já definem RBAC com escopo hierárquico e backend como autoridade, mas ainda não formalizam:

  1. Resolução obrigatória de tenant por domínio
  2. Regras para atuação cross-tenant
  3. Papel global de administração da plataforma (PLATFORM_ADMIN)

Decisão

Section titled “Decisão”

O sistema adotará multitenancy lógico por ministério, com resolução de tenant por domínio e suporte ao papel global PLATFORM_ADMIN.

1. Unidade de Tenant

Section titled “1. Unidade de Tenant”
  • Cada Ministry representa um tenant lógico
  • ministry_id permanece a chave estrutural de isolamento
  • Todo acesso de usuário não global ocorre em contexto de tenant ministerial

2. Resolução de Tenant por Domínio

Section titled “2. Resolução de Tenant por Domínio”

O backend deve resolver tenant da requisição pela seguinte ordem:

  1. Domínio de entrada (host) mapeado para ministry_id
  2. Contexto autenticado do usuário (claims e vínculos aprovados)
  3. Regras de autorização por papel e escopo (ADR-0003)

Se houver divergência entre domínio e escopo autorizado, a requisição deve ser negada (FORBIDDEN_SCOPE_MISMATCH).

3. Papel Global PLATFORM_ADMIN

Section titled “3. Papel Global PLATFORM_ADMIN”

PLATFORM_ADMIN é papel de governança da plataforma, com capacidade de operar entre ministérios para funções administrativas globais.

Regras obrigatórias:

  • Exige autenticação forte (MFA) em toda sessão ativa
  • Toda operação cross-tenant deve ser auditada
  • Operações destrutivas/sensíveis devem registrar justificativa operacional
  • Ações em dados ministeriais devem ocorrer com contexto explícito de tenant-alvo

4. Contexto Explícito para Ações Cross-Tenant

Section titled “4. Contexto Explícito para Ações Cross-Tenant”

Para evitar bypass de escopo:

  • Toda operação cross-tenant deve declarar target_ministry_id
  • O backend valida PLATFORM_ADMIN + permissão da ação + tenant alvo
  • Não existe acesso implícito lateral por conveniência

5. Modelo de Dados e Configuração

Section titled “5. Modelo de Dados e Configuração”

O Ministry deve manter metadados de tenancy, incluindo:

  • domains[] (domínios válidos do ministério)
  • tenant_status (ACTIVE, SUSPENDED, MIGRATING)
  • security_policy_ref (referência de políticas específicas, quando aplicável)

Esses metadados são fonte de verdade para resolução de tenant no backend.

Regras Arquiteturais Derivadas

Section titled “Regras Arquiteturais Derivadas”
  1. Backend authority: tenant, papel e escopo são sempre validados no backend.
  2. Sem bypass de escopo: frontend nunca define tenant de forma autoritativa.
  3. Firestore em infrastructure: queries com filtro obrigatório de ministry_id para dados ministeriais.
  4. Auditoria obrigatória: toda ação de PLATFORM_ADMIN em tenant alvo gera trilha auditável.
  5. Princípio do menor privilégio: papel global não elimina checagem de permissão por ação.

Integração com ADRs existentes

Section titled “Integração com ADRs existentes”
  • ADR-0001: passa a explicitar multitenancy por domínio na arquitetura geral
  • ADR-0002: inclui domínio como fronteira de entrada do ministério
  • ADR-0003: incorpora PLATFORM_ADMIN e regras de escopo global/controlado
  • ADR-0010: autenticação forte obrigatória para PLATFORM_ADMIN

Consequências

Section titled “Consequências”
  • O backend precisa de componente central de resolução de tenant por domínio.
  • APIs devem receber/propagar contexto de tenant de forma explícita.
  • Fluxos de suporte operacional ganham governança clara para atuação cross-tenant.
  • A auditoria passa a ser requisito mínimo para administração global.
  • Novas mudanças de estratégia de tenancy exigirão ADR complementar.