This entry is parte 2 de 2 in the series BankLab
wp-content/uploads/2026/05/banklab_icon-1.png
BankLab

Índice

A próxima etapa de segurança da API do BankLab será a introdução de um primeiro MVP inspirado em Zero Trust Architecture.

A ideia não é implementar um ZTA completo neste momento. O objetivo inicial é criar uma base simples e evolutiva para validar operações sensíveis com um fator adicional: a senha transacional.

O primeiro fluxo protegido será a transferência interna.

O que será implementado

O novo fluxo separa autenticação de sessão e confirmação de intenção.

Hoje, o usuário autenticado com JWT pode acessar endpoints protegidos conforme suas permissões. Com o MVP de ZTA, uma operação sensível também exigirá uma autorização curta de step-up.

O fluxo será:

  1. O app mobile solicita uma autorização de step-up para um endpoint_key.
  2. O backend valida a senha transacional.
  3. Se estiver correta, emite um step_up_token curto.
  4. O app chama o endpoint sensível com JWT + X-Step-Up-Token.
  5. O backend valida o token antes de executar o use case.

Para o primeiro corte:

endpoint_key: internal_transfer.create
endpoint protegido: POST /accounts/internal-transfers

Divisão dos backlogs

A implementação foi quebrada em backlogs menores para facilitar o acompanhamento:

  • 006 - zta-mvp-foundation.md: fundação e decisões gerais do MVP.
  • 006a - transaction-password.md: criação da senha transacional, tentativas e bloqueio.
  • 006b - step-up-token.md: autorização de step-up, token curto e uso único.
  • 006c - internal-transfer-step-up-enforcement.md: aplicação do enforcement na transferência interna.
  • 006d - zta-contracts-and-docs.md: contratos HTTP, erros e documentação.

Tasks ativas

O primeiro backlog detalhado é o 006a - transaction-password, com as seguintes tasks:

  1. Criar migration da senha transacional.
  2. Introduzir domínio da senha transacional.
  3. Definir contratos de repositório e hasher.
  4. Implementar persistência Postgres.
  5. Implementar caso de uso de criação.
  6. Implementar endpoint POST /security/transaction-password.
  7. Registrar erros da senha transacional.
  8. Cobrir com testes e documentação mínima.

Decisões principais

  • A senha transacional será um PIN numérico de 6 dígitos.
  • A senha será armazenada apenas como hash.
  • A criação exige confirmação no payload.
  • Após 3 tentativas inválidas, haverá bloqueio temporário de 30 minutos.
  • O desbloqueio será automático após expirar o bloqueio.
  • O step_up_token terá duração de 2 minutos.
  • O token será de uso único.
  • O modelo será híbrido: JWT assinado com jti persistido no backend.
  • No MVP, o token será vinculado ao endpoint lógico, não ao payload da operação.

Caminho esperado

Este MVP cria a primeira base de política de segurança entre a entrada HTTP e os use cases sensíveis.

No futuro, o módulo internal/security poderá evoluir para receber outros fatores de confiança, como dispositivo confiável, prova de vida, biometria local e avaliação de risco.

A senha transacional é apenas o primeiro passo. O objetivo maior é preparar o BankLab para decisões de segurança mais contextuais e progressivas.