Arquitetura
O Midaz usa uma arquitetura segura. Ele aplicou security by design e threat modeling desde o início. Ele ainda aplica os dois a cada nova funcionalidade.
- Security by design: O Midaz incorpora controles de segurança ao longo do ciclo de vida, do design ao deployment. Ele segue diretrizes OWASP como o OWASP Top 10 e o OWASP Application Security Verification Standard (ASVS).
- Threat Modeling: Um processo estruturado identifica, avalia e reduz os riscos de segurança antes que um atacante os explore. O Midaz usa a metodologia STRIDE. O STRIDE agrupa as ameaças em seis 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:- Serviços seguros por design.
- Correção proativa de vulnerabilidades.
- Atualizações de segurança: upgrades de dependências, patches de segurança e melhorias.
- Infraestrutura: Fortalecer o SO e as imagens de 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 a comunicação interna e externa.
- Banco de dados: Configurar backups e logs de auditoria. Seguir as melhores práticas de segurança para armazenamento de dados.
- Identity & Access Management: Controlar o acesso ao ambiente. Usar 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 que o Midaz armazena ou processa permanecem sob o seu controle e responsabilidade.
- Monitoramento: Estabelecer ferramentas de monitoramento que detectem 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 Lerian assume uma parte maior da responsabilidade de segurança. 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 aceita um JWT Bearer emitido por um provedor OAuth 2.0 / OpenID Connect. A autenticação fica desligada a menos que você defina
PLUGIN_AUTH_ENABLED=true — e o Midaz se recusa a subir sem ela quando ENV_NAME=production ou a multi-tenancy está habilitada. Você escolhe como gerenciar 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 — uma boa opção para clientes sem um sistema IAM existente, ou que querem uma experiência totalmente integrada.
Opção 1: IAM Externo
Se você integrar seu próprio provedor IAM, garanta que ele siga práticas modernas de segurança. Para manter o Midaz seguro, recomendamos:- 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 com RBAC, ABAC ou modelos similares.
- Gerenciar sessões de forma segura, com 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
O Plugin Access Manager gerencia a autenticação e a autorização dentro do Midaz. Ele é totalmente integrado e oferece:- 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 Lerian SaaS ou BYOC Multi-Tenant, o Midaz isola todos os recursos por tenant na camada de aplicação. Isso abrange organizações, ledgers, contas e transações. Seu token de acesso JWT carrega o contexto de tenant. Em cada requisição, o middleware da plataforma resolve o tenant a partir do claim
tenantId do token. Suas chamadas de API nunca veem dados de outros tenants. Outros tenants nunca veem seus dados.
Esse isolamento funciona de forma independente da hierarquia de organizações. Dois tenants podem criar estruturas organizacionais similares, e seus dados permanecem completamente separados. No modo DATABASE (modos de isolamento), cada tenant opera em seu próprio banco de dados dedicado. No modo SCHEMA, os tenants compartilham um banco de dados, mas os dados de cada tenant permanecem isolados atrás de suas próprias credenciais distintas.
Isolamento de credenciais
Cada tenant tem suas próprias credenciais. O Midaz nunca as compartilha entre tenants, tanto no modoDATABASE quanto no modo SCHEMA (modos de isolamento). No modo SCHEMA, os tenants compartilham uma instância de banco de dados. Ainda assim, o acesso de cada tenant usa suas próprias credenciais distintas. Um tenant nunca consegue se autenticar nos dados de outro tenant.
O Midaz gera as credenciais durante o provisionamento automático. Ele as armazena em um cofre de credenciais (credentials vault), não em arquivos de configuração ou variáveis de ambiente. Você pode rotacionar as credenciais sob demanda enquanto a plataforma continua atendendo requisições. A rotação não causa downtime nem interrompe as operações do tenant.
Limites de recursos por tenant
Deployments multi-tenant aplicam limites de recursos para que nenhum tenant sozinho degrade os demais. Este é o problema do noisy neighbor:- Limites de recursos do Kubernetes — os limites de CPU e memória em cada workload limitam quanto de computação ele pode consumir. Isso restringe o impacto de um pico ou de uma carga descontrolada.
- Statement timeout do PostgreSQL — o Midaz não define um por conta própria. Configure
statement_timeoutnas suas roles ou bases do PostgreSQL para que nenhuma query possa reter recursos indefinidamente. - Pool de conexões por serviço — cada serviço mantém seu próprio pool de conexões, com um pool por tenant ativo. Os limites de pool por tenant vêm das configurações de conexão que cada tenant carrega no Tenant Manager, e pools de tenants ociosos são despejados com o tempo. Isso limita a capacidade de conexão por tenant. Um tenant não consegue esgotar as conexões de banco de dados que os outros precisam.
Esses limites complementam o isolamento de dados acima. O isolamento de dados protege os dados de cada tenant contra outros tenants. Os limites de recursos protegem a performance e a disponibilidade de cada tenant contra a carga de outros tenants.
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. O Midaz rejeita qualquer lançamento que falhe nessa validação. Isso protege a integridade do ledger. Também protege o sistema contra vulnerabilidades de race condition e discrepâncias de lançamento.
Proteções nativas
O Midaz aplica validação rigorosa em todos os fluxos de transação para manter os dados consistentes e prevenir erros de lógica:- O Midaz bloqueia saldos negativos, a menos que você os permita explicitamente.
- O Midaz verifica o status da conta antes de qualquer operação.
- O Midaz exige um asset registrado e válido antes de registrar um lançamento.
Conformidade com LGPD e GDPR
O Midaz lida com a validação de transações e a comunicação segura sobre TLS 1.2 e 1.3. Você protege as informações pessoalmente identificáveis (PII). Para manter a conformidade com LGPD, GDPR e leis de proteção de dados similares, recomendamos:- Aplicar criptografia aos dados sensíveis, em repouso e 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
A transparência constrói confiança. Compartilhamos abertamente todas as melhorias e correções de segurança conhecidas no nosso GitHub Discussions. Isso mantém a comunidade informada sobre patches e aprimoramentos de segurança. Se você encontrar uma vulnerabilidade de segurança no Midaz, reporte-a diretamente à nossa equipe antes de torná-la pública. Apoiamos a divulgação responsável. Investigamos e resolvemos os problemas de forma rápida e completa.
Não divulgue publicamente nenhuma descoberta até que a revisemos e a tratemos.
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
Corrigimos o problema e notificamos o reportador.
6
Divulgação pública
Coordenamos a divulgação com o pesquisador.