> ## 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 > Veja como o Midaz protege as operações financeiras com segurança desde a concepção, modelagem de ameaças STRIDE, controles alinhados à OWASP e um modelo claro de responsabilidade compartilhada. 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: * **S**poofing (por exemplo, autenticação falsa em uma API bancária). * **T**ampering (por exemplo, alterar dados de transação no meio de uma requisição). * **R**epudiation (por exemplo, ausência de logs de auditoria para transações). * **I**nformation Disclosure (por exemplo, vazamento de dados sensíveis por meio de respostas de API). * **D**enial of Service (por exemplo, sobrecarregar a API com requisições falsas). * **E**levation 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](/pt/start-here/evaluate-and-deploy/deployment-models). | Lerian | Cliente | | -------------------------------------- | ------------------------------- | | Desenvolvimento da aplicação | Infraestrutura | | Atualizações de segurança da aplicação | Rede | | | Banco de dados | | | Gestão de Identidade e Acesso | | | Criptografia | | | Dados do usuário | | | Monitoramento | | | Camadas adicionais de segurança | ### 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. Para orientação passo a passo, veja [Recomendações de segurança](/pt/products/midaz/security-recommendations) na seção Instalação e Deploy. ## 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](/pt/platform/access-manager) 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](/pt/platform/multi-tenancy#isolation-modes) `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](/pt/platform/multi-tenancy#isolation-modes) `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](/pt/platform/multi-tenancy/auto-provisioning). 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. 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 o *desempenho e a disponibilidade* de cada tenant contra a carga de outros tenants. Para uma visão geral completa de multi-tenancy, veja [Multi-tenancy](/pt/platform/multi-tenancy). ## 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**](https://github.com/LerianStudio/midaz/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. Não divulgue nenhuma descoberta publicamente até que a revisemos e a resolvamos. Os passos para reportar uma vulnerabilidade: Envie um email 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. Corrigimos o problema e notificamos quem reportou. Coordenamos a divulgação com o pesquisador. Use uma chave PGP para comunicação segura. Priorizamos a confidencialidade e a resolução rápida de todos os relatos de segurança.