Segurança

O Midaz incorpora proteções para integridade de dados, controle de acesso e isolamento de tenant. Ele usa gestão de identidade forte, permissões refinadas e práticas padrão do setor. Esta página descreve a arquitetura de segurança que o Midaz fornece por padrão. Ela também mostra como você executa operações seguras e em conformidade.

​

Arquitetura

---

O Midaz aplicou segurança desde a concepção e modelagem de ameaças desde o início. Ele ainda aplica ambas a cada novo recurso.

• Segurança desde a concepção: O Midaz incorpora controles de segurança em todo o ciclo de vida, do design ao deploy. Ele segue diretrizes da OWASP como o OWASP Top 10 e o OWASP Application Security Verification Standard (ASVS).
• Modelagem de ameaças: Um processo estruturado identifica, avalia e reduz riscos de segurança antes que um atacante os explore. O Midaz usa a metodologia STRIDE. O STRIDE agrupa ameaças em seis tipos:
  • Spoofing (por exemplo, autenticação falsa em uma API bancária).
  • Tampering (por exemplo, alterar dados de transação no meio de uma requisição).
  • Repudiation (por exemplo, ausência de logs de auditoria para transações).
  • Information Disclosure (por exemplo, vazamento de dados sensíveis por meio de respostas de API).
  • Denial of Service (por exemplo, sobrecarregar a API com requisições falsas).
  • Elevation of Privilege (por exemplo, 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 deploy.

​

No modelo BYOC

No BYOC (Bring Your Own Cloud), você faz o deploy da 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 desde a concepção.
• Correções proativas de vulnerabilidades.
• Atualizações de segurança: upgrades de dependências, patches de segurança e melhorias.

O que o cliente protege:

• Infraestrutura: Faça hardening do SO e das imagens de container, gerencie patches e aplique configurações seguras na plataforma de hospedagem.
• Rede: Implemente segmentação, firewalls e sistemas IDS/IPS. Adote princípios de Zero Trust para proteger a comunicação interna e externa.
• Banco de dados: Configure backups e registro de auditoria. Siga as boas práticas de segurança para armazenamento de dados.
• Gestão de Identidade e Acesso: Controle o acesso ao ambiente. Use os recursos de RBAC do Midaz para aplicar políticas de menor privilégio dentro da plataforma.
• Criptografia: Criptografe dados sensíveis em repouso e em trânsito. Considere 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 seu controle e responsabilidade.
• Monitoramento: Estabeleça ferramentas de monitoramento que detectem padrões de acesso incomuns ou comportamento suspeito.
• Camadas adicionais de segurança: Reforce as 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 mais da responsabilidade de segurança. O que a Lerian protege:

• Tudo o que está na camada de aplicação do BYOC, mais:
• Infraestrutura de nuvem, rede e ambiente de computação.
• Provisionamento de banco de dados, criptografia em repouso e backups automatizados.
• Patching de SO e de containers.
• Monitoramento, alertas e resposta a incidentes.
• Alta disponibilidade e disaster recovery.

O que o cliente protege:

• Controle de acesso em nível de negócio: Gerencie usuários, papéis e permissões dentro da plataforma.
• Segurança da integração de API: Proteja a comunicação entre seus sistemas e as APIs da Lerian.
• Governança de dados do usuário: Defina e aplique políticas de tratamento de dados que atendam às suas obrigações regulatórias.
• Conformidade: Garanta que o uso da plataforma esteja alinhado com os requisitos regulatórios da sua instituição.

​

Gestão de Identidade e Acesso

---

O Midaz aceita um Bearer JWT emitido por um provedor OAuth 2.0 / OpenID Connect. A autenticação fica desativada a menos que você defina PLUGIN_AUTH_ENABLED=true. O Midaz se recusa a iniciar sem isso quando você define ENV_NAME=production ou habilita multi-tenancy. Você escolhe como gerenciar identidade e acesso. Você tem duas opções:

• Use sua própria solução externa de IAM (Identity and Access Management).
• Use o Access Manager Plugin nativo da Lerian: uma boa opção para clientes sem um sistema de IAM existente, ou para os que querem uma experiência totalmente integrada.

​

Opção 1: IAM externo

Se você integrar seu próprio provedor de IAM, confirme que ele segue práticas modernas de segurança. Para manter o Midaz seguro, recomendamos que você:

• Use protocolos comprovados como OAuth 2.0 e OpenID Connect.
• Exija Multi-Factor Authentication (MFA).
• Aplique algoritmos fortes de hashing de senha como bcrypt ou argon2.
• Aplique controles de acesso refinados com RBAC, ABAC ou modelos similares.
• Gerencie sessões com segurança, com regras de expiração e políticas de refresh token.
• Proteja endpoints contra ataques de força bruta e replay.
• Habilite e revise os logs de acesso regularmente.

​

Opção 2: Access Manager Plugin

O Access Manager Plugin gerencia autenticação e autorização dentro do Midaz. Ele fornece:

• Gestão do ciclo de vida do usuário
• Tratamento de tokens de sessão
• Rotação de refresh token
• Registro e gestão de aplicações

Essa opção simplifica o controle de acesso seguro. Ela se alinha com o sistema de permissões nativo do Midaz (RBAC).

​

Isolamento de tenant em deploys multi-tenant

---

No Lerian SaaS ou BYOC Multi-Tenant, o Midaz isola todos os recursos por tenant na camada de aplicação. Isso cobre organizações, ledgers, contas e transações. Seu token de acesso JWT carrega o contexto do tenant. A cada requisição, o middleware da plataforma resolve o tenant a partir da claim tenantId no token. Suas chamadas de API nunca veem dados de outros tenants. Outros tenants nunca veem seus dados. Esse isolamento funciona independentemente da hierarquia de organizações. Dois tenants podem criar estruturas de organização similares, e seus dados permanecem completamente separados. No modo de isolamento DATABASE, cada tenant usa 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 por trá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 modo de isolamento DATABASE quanto no SCHEMA. 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 credenciais durante o provisionamento automático. Ele as armazena em um credentials vault, não em arquivos de configuração ou variáveis de ambiente. Você pode rotacionar credenciais sob demanda enquanto a plataforma continua atendendo requisições. A rotação não causa downtime nem interrupção nas operações do tenant.

​

Limites de recursos por tenant

Deploys multi-tenant aplicam limites de recursos para que nenhum tenant degrade os outros. Este é o problema do noisy neighbor:

• Limites de recursos do Kubernetes: Limites de CPU e memória em cada workload limitam quanto de computação ela pode consumir. Isso limita o impacto de um pico ou de um workload descontrolado.
• Statement timeout do PostgreSQL: O Midaz não define um por conta própria. Configure statement_timeout nas suas roles ou bancos de dados PostgreSQL para que nenhuma query sozinha retenha 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 removidos ao longo do tempo. Isso limita a capacidade de conexão por tenant. Um tenant não pode esgotar as conexões de banco de dados que outros precisam.

​

Proteção de dados

---

O Midaz aplica os princípios de partidas dobradas desde a concepção. Toda transação deve ter débitos e créditos equilibrados. 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.

​

Salvaguardas integradas

O Midaz aplica validação estrita 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 ativo registrado e válido antes de lançar uma entrada.

​

Conformidade com a LGPD e o GDPR

O Midaz trata a validação de transações e a comunicação segura sobre TLS 1.2 e 1.3. Você protege informações de identificação pessoal (PII). Para permanecer em conformidade com a LGPD, o GDPR e leis de proteção de dados similares, recomendamos que você:

• Aplique criptografia a dados sensíveis, em repouso e em trânsito.
• Use tokenização ou anonimização quando apropriado.
• Armazene e gerencie dados de clientes sob políticas de segurança claramente definidas.

O Midaz fornece a base. Você constrói as salvaguardas.

​

Política de divulgação responsável

---

Compartilhamos abertamente todas as melhorias e correções de segurança conhecidas nas nossas GitHub Discussions. Isso mantém a comunidade informada sobre patches e melhorias 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 com rapidez e rigor. Os passos para reportar uma vulnerabilidade: