Skip to main content

ADR-0010 — Modelo de Segurança e Autenticação

Status​

Proposto

Contexto​

O sistema EBDbe já possui modelo de controle de acesso (ADR-0003) baseado em RBAC com escopo hierárquico. Este ADR complementa e estende o modelo de segurança com foco em:

  1. Autenticação forte obrigatória para papéis de alto privilégio (ex.: MINISTRY_ADMIN)
  2. Classificação de dados por sensibilidade (público a secreto), garantindo que cada perfil visualize apenas o que lhe compete
  3. Métodos de autenticação diversos (email/senha, OAuth, token QR) com governança adequada
  4. Ativação manual de contas com aprovação por superior na cadeia hierárquica da mesma árvore organizacional
  5. Governança multi-tenant por domínio com administração global controlada

A autenticação inicial será via Firebase Authentication. As regras aqui definidas orientam a implementação e a governança de identidade.

Decisão​

O sistema adotará modelo de segurança em camadas, composto por:

  • Autenticação: como o usuário prova identidade (métodos de login)
  • Classificação: sensibilidade dos dados expostos por perfil
  • Autorização: quem pode criar dados e atribuir perfis (Papel + Escopo, conforme ADR-0003)

1. Métodos de Autenticação​

O sistema suportará três métodos complementares:

1.1 Email e Senha​

  • Cadastro com email e senha.
  • Conta inicia em status PENDING.
  • Verificacao de email por codigo com janela de validade de 30 minutos.
  • Se o codigo expirar, o solicitante deve usar fluxo de reenvio para obter novo codigo.
  • Ativação manual: um usuário com escopo hierárquico superior (mesma unit ou unit ancestral autorizada) deve aprovar a conta.
  • Notificação aos aprovadores quando houver solicitante aguardando (conforme ADR-0011).
  • Política de senha: mínimo de complexidade; renovação conforme política institucional.

1.2 OAuth (Google, Microsoft etc.)​

  • Login via provedor externo.
  • Vínculo com ministry_id e unit_id pode ser automático (domínio) ou manual (aprovação).
  • Quando exigir aprovação, segue o fluxo de ativação manual.
  • Evita gestão de senha pelo sistema; reduz risco de credenciais vazadas.
  • A conta autenticada por OAuth deve manter perfil de aplicação tenant-aware; precedência de foto/avatar e ciclo de vida de status seguem ADR-0013.
  • A implementacao pode ser incremental por provedor, iniciando por Google e expandindo para outros provedores sem alterar as regras de governanca deste ADR.

1.3 Token via QR Code (Delegação Temporária)​

  • Autorizado gera QR Code temporário.
  • Temporário escaneia e obtém acesso limitado e por tempo definido.
  • Casos de uso: visitante, obreiro eventual, suplente.
  • Tempo de validade configurável; revogação imediata pelo emissor.
  • Não substitui conta permanente; é delegação de acesso pontual.

1.4 Politica de Verificacao de Email (codigo, expiracao e reenvio)​

  • O codigo de verificacao deve ter validade maxima de 30 minutos a partir da emissao.
  • Codigo expirado nao pode ser aceito em nenhuma circunstancia.
  • O reenvio deve invalidar o codigo anterior e emitir novo codigo com nova janela de 30 minutos.
  • O backend deve aplicar controle de abuso para reenvio/tentativas (rate limit por usuario/endereco) e registrar auditoria de emissao, reenvio e confirmacao.
  • A verificacao de email nao substitui a ativacao manual por aprovador quando esta for exigida pela politica de papel/escopo.

2. Autenticação Forte para Alto Privilégio​

Papéis de alto privilégio devem usar autenticação forte. O mínimo exigido:

  • TOTP (Time-based One-Time Password) — via app (Google Authenticator, Authy etc.)
  • Recomendado: WebAuthn/Passkeys (Face ID, Touch ID, chave de segurança) quando disponível

2.1 Papéis Obrigatórios​

PapelObrigatório
PLATFORM_ADMINSim
MINISTRY_ADMINSim
MINISTERIAL_EBD_SUPERVISORRecomendado
PRESIDENT_PASTORRecomendado

Implementação: flag requires_strong_auth associada ao Role. Usuário com papel que exige autenticação forte não poderá operar sem TOTP ou WebAuthn configurado. Para PLATFORM_ADMIN, a exigência é mandatória e deve ser validada antes de qualquer operação cross-tenant.

3. Ativação Manual de Contas​

3.1 Fluxo​

  1. Solicitante realiza cadastro (email/senha ou OAuth).
  2. Status inicial: PENDING.
  3. Sistema identifica aprovadores (nível superior na mesma unit).
  4. Sistema notifica aprovadores (mensagem instantânea e email) — conforme ADR-0011.
  5. Um aprovador aprova ou rejeita.
  6. Sistema notifica o solicitante do resultado.
  7. Se aprovado, status passa a ACTIVE.

3.2 Regra de Aprovação​

Aprovador é usuário que:

  • Possui papel de nível estritamente menor (mais poder) que o papel solicitado, na mesma hierarquia
  • Está vinculado à mesma unit ou à unit pai da unit do solicitante
  • Possui role_status APPROVED

Exemplo: solicitante na unidade X com papel EBD_TEACHER → EBD_SUPERINTENDENT ou LOCAL_PASTOR da mesma unidade X ou de unidade ancestral autorizada podem aprovar.

3.3 Notificação​

Quando houver solicitante aguardando aprovação, o sistema deve notificar os aprovadores. Sem essa notificação, o fluxo de ativação manual fica inviável.

4. Classificação de Dados​

Além de Papel e Escopo (ADR-0003), os dados terão nível de sensibilidade. A regra de visibilidade:

Pode ver = (Papel ≥ nível exigido) ∧ (Escopo inclui ministry_id/unit_id) ∧ (Nível do papel ≥ Sensibilidade do dado)

4.1 Níveis de Sensibilidade​

NívelDescriçãoExemplo
PUBLICAcessível a todos autenticados no escopoNome da igreja, materiais da lição
INTERNALPapéis operacionaisLista de classes, presença agregada
CONFIDENTIALDados pessoais limitadosNomes de alunos, e-mails
SECRETDados sensíveis ministeriaisDados de pastores, decisões estratégicas

4.2 Atribuição​

Cada entidade ou recurso terá sensitivity_level. A atribuição será feita conforme modelo de domínio (ADR-0005) e regras de negócio.

5. Autorização: Criação e Atribuição de Dados​

Criação de dados e atribuição de perfis seguem:

Permissão = Papel + AccessType + Escopo Organizacional (ADR-0003)

5.1 Regras Gerais​

  • Criação de usuário: papéis com INSERT_UPDATE em Users, dentro do escopo.
  • Atribuição de Role: quem tem nível ≥ ao papel a ser atribuído, dentro do escopo.
  • Aprovação de Role: quem pode aprovar na mesma unit ou superior na hierarquia.
  • Registro de presença: EBD_TEACHER, EBD_SECRETARY na mesma Lesson/ClassGroup.

O backend validará todas as operações; o frontend nunca será autoridade.

5.2 Operações Cross-Tenant​

  • Permitidas somente para PLATFORM_ADMIN
  • Exigem target_ministry_id explícito
  • Devem validar coerência com o domínio e política do tenant alvo (ADR-0012)
  • Devem gerar log de auditoria com justificativa operacional

6. Auditoria​

Devem ser registrados em log:

  • Ativação e rejeição de contas (quem aprovou/rejeitou, quando, solicitante)
  • Atribuição e aprovação de Roles
  • Alterações em dados CONFIDENTIAL ou SECRET
  • Uso de token QR (emissão, consumo, revogação)
  • Configuração/remoção de autenticação forte

7. Integração​

  • ADR-0002: Escopo hierárquico (Ministry → OrganizationalUnit)
  • ADR-0003: RBAC com escopo; extensão, não substituição
  • ADR-0005: User, Role, RoleAssignment, status
  • ADR-0006: Minimização de dados; consentimento
  • ADR-0011: Notificações na ativação manual
  • ADR-0012: Multitenancy por domínio e PLATFORM_ADMIN
  • ADR-0013: Perfil de usuário, matriz de transição de status e preferências segmentadas

Consequências​

  • Autenticação forte obrigatória para MINISTRY_ADMIN.
  • Autenticação forte obrigatória para PLATFORM_ADMIN.
  • Implementação de TOTP via Firebase Auth (MFA) ou provedor compatível.
  • Fluxo de ativação manual com notificação aos aprovadores.
  • Fluxo de verificacao de email com codigo (TTL 30 minutos), politica de reenvio e controles de abuso no backend.
  • Modelo de dados estendido com sensitivity_level onde aplicável.
  • Backend continua como autoridade final de segurança.
  • Alterações no modelo de segurança exigirão novo ADR.
Last updated on