> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Segurança > Entenda como o Midaz protege suas operações financeiras com segurança por design, modelagem de ameaças e controles alinhados ao OWASP. Segurança não é apenas uma funcionalidade. É a base de qualquer sistema financeiro. O Midaz é projetado com **segurança em seu núcleo**, oferecendo proteções nativas como garantia de integridade de dados, controle de acesso e prevenção contra fraudes. Através de gerenciamento robusto de identidade, permissões granulares e adesão às melhores práticas do mercado, o Midaz garante resiliência em todas as camadas. Esta página descreve a arquitetura de segurança que o Midaz oferece por padrão — e como ele ajuda você a executar operações seguras, em conformidade e robustas desde o primeiro dia. ## 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: * **S**poofing (ex.: autenticação falsa em uma API bancária). * **T**ampering (ex.: alteração de dados de transação durante a requisição). * **R**epudiation (ex.: falta de logs de auditoria para transações). * **I**nformation Disclosure (ex.: vazamento de dados sensíveis via respostas da API). * **D**enial of Service (ex.: sobrecarregar a API com requisições falsas). * **E**levation 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](/pt/deployment-models). | Lerian | Cliente | | -------------------------------------- | ------------------------------- | | Desenvolvimento da aplicação | Infraestrutura | | Atualizações de segurança da aplicação | Rede | | | Banco de dados | | | Identity & Access Management | | | Criptografia | | | Dados do usuário | | | Monitoramento | | | Camadas de segurança adicionais | ### 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. **O que o cliente protege:** * **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. **O que o cliente protege:** * **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. Quer orientações práticas sobre este tema? Confira nossas [Recomendações de Segurança](/pt/midaz/security-recommendations) na seção Instalação & Deploy. ## 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](/pt/platform/access-manager/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 Esta opção simplifica o controle de acesso seguro enquanto se alinha com o sistema nativo de permissões do Midaz (RBAC). ## 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 `tenantId` que 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](/pt/multi-tenancy#modos-de-isolamento)): no modo `DATABASE`, 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 e respaldados por suas próprias credenciais distintas. Em ambos os modos, as consultas de um tenant nunca alcançam os dados de outro. Você não precisa incluir identificadores de tenant em headers ou no corpo das requisições. O token define o escopo automaticamente. ### Isolamento de credenciais Cada tenant tem suas próprias credenciais, e elas **nunca são compartilhadas entre tenants** — tanto no modo de isolamento `DATABASE` quanto no `SCHEMA` (veja [modos de isolamento](/pt/multi-tenancy#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](/pt/multi-tenancy/auto-provisioning) 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_POOLS` e 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. Para uma visão completa de como o multi-tenancy funciona, veja [Multi-tenancy](/pt/multi-tenancy). ## 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. Essas verificações reduzem riscos e garantem que as operações financeiras estejam alinhadas com regras de negócio e expectativas regulatórias. ### 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. A proteção de dados não é uma camada única — é um compromisso compartilhado. O Midaz fornece a base. Você constrói as proteções. ## 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**](https://github.com/LerianStudio/midaz/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. Os passos para reportar uma vulnerabilidade: Envie um e-mail para [security@lerian.studio](mailto:security@lerian.studio). Respondemos em até 24 horas. Nossa equipe valida o relatório. Determinamos a severidade e o impacto. O problema é corrigido e o reportador é notificado. Coordenamos a divulgação com o pesquisador. Use uma chave PGP para comunicações seguras. Priorizamos a confidencialidade e a resolução rápida de todos os relatórios de segurança.