Arquitetura
O Midaz foi projetado para funcionar em uma estrutura segura. Para criar um código e arquitetura seguros, o conceito de security by design e threat modeling foi usado na concepção e continua sendo usado para novas funcionalidades.
- Security by design: Controles de segurança são incorporados ao longo de todo o ciclo de vida — do design ao deployment — seguindo diretrizes OWASP como os padrões OWASP Top 10 e OWASP Application Security Verification Standard (ASVS).
- Threat Modeling: Processo estruturado usado para identificar, avaliar e mitigar potenciais riscos de segurança em um sistema antes que possam ser explorados. A metodologia utilizada no Midaz é chamada STRIDE, onde as ameaças são categorizadas em 6 tipos:
- Spoofing (ex.: autenticação falsa em uma API bancária).
- Tampering (ex.: alteração de dados de transação durante a requisição).
- Repudiation (ex.: falta de logs de auditoria para transações).
- Information Disclosure (ex.: vazamento de dados sensíveis via respostas da API).
- Denial of Service (ex.: sobrecarregar a API com requisições falsas).
- Elevation of Privilege (ex.: explorar um bug para obter acesso de administrador).
Modelo de responsabilidade compartilhada
A segurança é uma responsabilidade compartilhada entre a Lerian e o cliente. A divisão exata depende do seu modelo de deployment.
No modelo BYOC
No BYOC (Bring Your Own Cloud), você implanta a Lerian na sua própria infraestrutura. A Lerian protege a camada de aplicação. Você protege o ambiente. O que a Lerian protege:- Construir serviços seguros por design.
- Endereçar vulnerabilidades de forma proativa.
- Lançar atualizações de segurança, incluindo upgrades de dependências, patches de segurança e melhorias contínuas.
- Infraestrutura: Fortalecer imagens de SO e containers, gerenciar patches e aplicar configurações seguras na plataforma de hospedagem.
- Rede: Implementar segmentação, firewalls e sistemas IDS/IPS. Adotar princípios Zero Trust para proteger comunicações internas e externas.
- Banco de dados: Configurar backups, logs de auditoria e seguir as melhores práticas de segurança para armazenamento de dados.
- Identity & Access Management: Controlar o acesso ao ambiente e aproveitar as funcionalidades de RBAC do Midaz para aplicar políticas de menor privilégio dentro da plataforma.
- Criptografia: Criptografar dados sensíveis em repouso e em trânsito. Considerar tokenização ou anonimização quando apropriado.
- Dados do usuário: Todos os dados de usuário armazenados ou processados via Midaz permanecem totalmente sob o controle e responsabilidade do cliente.
- Monitoramento: Estabelecer ferramentas de monitoramento capazes de detectar padrões de acesso incomuns ou comportamentos suspeitos.
- Camadas de segurança adicionais: Reforçar defesas com Web Application Firewalls (WAF), mecanismos anti-DDoS e ferramentas de mitigação de bots.
No modelo SaaS
No SaaS, a Lerian gerencia toda a infraestrutura. A responsabilidade de segurança muda — a Lerian assume significativamente mais. O que a Lerian protege:- Tudo da camada de aplicação do BYOC, mais:
- Infraestrutura cloud, rede e ambiente de computação.
- Provisionamento de banco de dados, criptografia em repouso e backups automatizados.
- Patching de SO e containers.
- Monitoramento, alertas e resposta a incidentes.
- Alta disponibilidade e recuperação de desastres.
- Controle de acesso a nível de negócio: Gerenciar usuários, papéis e permissões dentro da plataforma.
- Segurança de integração via API: Proteger a comunicação entre seus sistemas e as APIs da Lerian.
- Governança de dados do usuário: Definir e aplicar políticas de tratamento de dados que atendam suas obrigações regulatórias.
- Conformidade: Garantir que seu uso da plataforma esteja alinhado com os requisitos regulatórios da sua instituição.
Identity and Access Management
O Midaz é projetado para suportar OAuth 2.0 por padrão, dando aos clientes flexibilidade para escolher como gerenciam identidade e acesso. Você tem duas opções:
- Usar sua própria solução IAM (Identity and Access Management) externa.
- Usar o Plugin Access Manager nativo da Lerian — ideal para clientes sem um sistema IAM existente ou que buscam uma experiência totalmente integrada.
Opção 1: IAM Externo
Se você prefere integrar seu próprio provedor IAM, deve garantir que ele siga práticas modernas de segurança. Para manter o Midaz seguro, recomendamos fortemente:- Usar protocolos comprovados como OAuth 2.0 e OpenID Connect.
- Exigir Multi-Factor Authentication (MFA).
- Aplicar algoritmos fortes de hash de senha, como bcrypt ou argon2.
- Aplicar controles de acesso granulares via RBAC, ABAC ou modelos similares.
- Gerenciar sessões de forma segura, incluindo regras de expiração e políticas de refresh token.
- Proteger endpoints contra ataques de força bruta e replay.
- Habilitar e revisar logs de acesso regularmente.
Opção 2: Plugin Access Manager
Nosso Plugin Access Manager oferece uma forma integrada de gerenciar autenticação e autorização dentro do Midaz. Ele é totalmente integrado e ajuda a simplificar o deployment ao habilitar:- Gerenciamento do ciclo de vida do usuário
- Manipulação de tokens de sessão
- Rotação de refresh tokens
- Registro e gerenciamento de aplicações
Isolamento de tenant em deployments multi-tenant
Em deployments SaaS e BYOC Multi-Tenant, a plataforma aplica isolamento de tenant em cada requisição usando o token JWT emitido pelo Access Manager.
- Cada JWT contém um claim
tenantIdque identifica o tenant autenticado. - O middleware da plataforma resolve o tenant a partir do token e roteia a requisição para o banco de dados correto.
- Organizações, ledgers, contas e transações são completamente isolados entre tenants — não existe caminho na API para acessar dados de outro tenant.
- A separação de dados depende do modo de isolamento (veja modos de isolamento): no modo
DATABASE, cada tenant opera em seu próprio banco de dados dedicado; no modoSCHEMA, os tenants compartilham um banco de dados, mas os dados de cada tenant permanecem isolados e respaldados por suas próprias credenciais distintas. Em ambos os modos, as consultas de um tenant nunca alcançam os dados de outro.
Isolamento de credenciais
Cada tenant tem suas próprias credenciais, e elas nunca são compartilhadas entre tenants — tanto no modo de isolamentoDATABASE quanto no SCHEMA (veja modos de isolamento). Mesmo quando os tenants compartilham uma instância de banco de dados no modo SCHEMA, o acesso de cada tenant é respaldado por suas próprias credenciais distintas, então um tenant nunca consegue se autenticar nos dados de outro tenant.
As credenciais são geradas durante o provisionamento automático e armazenadas em um cofre de credenciais (credentials vault), em vez de arquivos de configuração ou variáveis de ambiente. O cofre suporta rotação sem downtime: as credenciais podem ser rotacionadas de forma agendada ou sob demanda enquanto a plataforma continua atendendo requisições, sem interrupção das operações do tenant.
Limites de recursos por tenant
Deployments multi-tenant aplicam limites de recursos para que nenhum tenant sozinho possa degradar os demais — o problema do noisy neighbor:- Limites de recursos do Kubernetes — limites de CPU e memória são aplicados por tenant, de modo que a carga de um tenant não possa privar os outros de computação. Isso restringe o impacto de um pico ou de uma carga descontrolada ao tenant que o causou.
- Statement timeout do PostgreSQL — queries longas ou descontroladas são interrompidas por um statement timeout, evitando que uma única query retenha recursos indefinidamente.
- Pool de conexões por serviço — cada serviço mantém seu próprio pool de conexões (veja
MULTI_TENANT_MAX_TENANT_POOLSe configurações relacionadas), então a capacidade de conexão é limitada por tenant e um tenant não consegue esgotar as conexões de banco de dados disponíveis para os outros.
Esses limites complementam as garantias de isolamento de dados acima: o isolamento de dados impede que os tenants vejam os dados uns dos outros, enquanto os limites de recursos impedem que os tenants afetem a performance e a disponibilidade uns dos outros.
Proteção de dados
O Midaz aplica princípios de partidas dobradas por design — toda transação deve ter débitos e créditos balanceados. Se um lançamento falhar nessa validação, ele é automaticamente rejeitado. Isso não apenas garante a integridade do ledger, mas também protege o sistema contra vulnerabilidades de race condition e discrepâncias de lançamento.
Proteções nativas
Para manter a consistência e prevenir erros de lógica, o Midaz aplica validação rigorosa em todos os fluxos de transação:- Saldos negativos são bloqueados a menos que explicitamente permitidos.
- O status da conta é verificado antes de permitir qualquer operação.
- Os assets devem estar registrados e válidos no momento do lançamento.
Conformidade com LGPD e GDPR
Enquanto o Midaz lida com validação transacional e comunicação segura (via TLS 1.2 e 1.3), os clientes são responsáveis por proteger informações pessoalmente identificáveis (PII). Para manter a conformidade com LGPD, GDPR e leis de proteção de dados similares, recomendamos:- Aplicar criptografia para dados sensíveis, tanto em repouso quanto em trânsito.
- Usar tokenização ou anonimização quando apropriado.
- Armazenar e gerenciar dados de clientes sob políticas de segurança claramente definidas.
Política de divulgação responsável
Acreditamos que a transparência constrói confiança. Por isso, todas as melhorias e correções de segurança conhecidas são compartilhadas abertamente no nosso GitHub Discussions. Isso permite que a comunidade se mantenha informada sobre patches e aprimoramentos de segurança em andamento. Se você identificar uma vulnerabilidade de segurança no Midaz, por favor reporte diretamente à nossa equipe antes de torná-la pública. Apoiamos totalmente a divulgação responsável e estamos comprometidos em investigar e resolver problemas de forma rápida e completa.
Por favor, evite divulgar publicamente qualquer descoberta até que tenhamos a chance de revisar e tratar o problema.
1
Reporte
Envie um e-mail para security@lerian.studio.
2
Confirmação
Respondemos em até 24 horas.
3
Verificação
Nossa equipe valida o relatório.
4
Avaliação de impacto
Determinamos a severidade e o impacto.
5
Resolução
O problema é corrigido e o reportador é notificado.
6
Divulgação pública
Coordenamos a divulgação com o pesquisador.