Skip to main content
O CRM gerencia dados sensíveis relacionados à identidade. Estas práticas ajudam você a integrar o CRM corretamente, proteger esses dados e executá-lo com segurança em produção. Estas recomendações complementam o guia Segurança de dados do CRM, que aborda criptografia, hashing e gerenciamento de chaves em detalhes.

​
1. Siga o fluxo de integração correto

O CRM depende de uma ordem específica para criar entidades. Se você pular etapas ou criar entidades fora de ordem, pode quebrar integrações e perder dados posteriormente. O fluxo esperado é:
  1. Crie o titular: a pessoa física ou a organização.
  2. Vincule o titular a uma conta do ledger Midaz: associe o titular a uma conta que já existe no ledger.
  3. Confirme que ambos existem antes de iniciar qualquer fluxo posterior.
Sem um titular vinculado a uma conta do ledger, a maioria dos recursos orientados pelo CRM (tarifas, notificações, cobrança, verificação de identidade) não funciona como esperado.
Confirme que seus identificadores estão corretos antes de criar ou vincular registros. A API do CRM não valida a precisão dos dados enviados. Um ledgerId ou accountId incompatível pode causar falhas de integração com o ledger ou outros componentes.

​
2. Proteja suas chaves de criptografia

O CRM criptografa e faz hash de campos sensíveis antes de armazená-los. A segurança desses dados depende inteiramente de como você gerencia suas chaves.
  • Gere chaves únicas para LCRYPTO_HASH_SECRET_KEY e LCRYPTO_ENCRYPT_SECRET_KEY com openssl rand -hex 32.
  • Armazene as chaves em um gerenciador de segredos (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault ou equivalente). Nunca as codifique diretamente em arquivos de configuração, código-fonte ou controle de versão.
  • Planeje a rotação de chaves. Se uma chave for comprometida, gere uma nova e recriptografe todos os dados afetados. Esse é um processo manual, então planeje seus runbooks operacionais para isso.
  • Use Kubernetes Secrets em produção. Referencie os segredos existentes via useExistingSecret e existingSecretName nos seus valores do Helm em vez de armazenar chaves diretamente.
Para a lista completa de campos protegidos e estratégias de criptografia, consulte Segurança de dados do CRM.

​
3. Nunca armazene dados sensíveis em metadados

O objeto metadata nas entidades do CRM não é criptografado. O CRM o armazena em texto simples apenas para informações auxiliares não sensíveis. Não use metadados para:
  • Números de identificação pessoal (CPF, SSN, passaporte)
  • Dados de contas financeiras
  • Informações de contato (e-mail, telefone)
  • Qualquer dado sujeito à LGPD, ao GDPR ou a regulamentações semelhantes
Se você precisar armazenar um atributo sensível que não esteja na lista de campos protegidos, entre em contato com seu representante da Lerian para discutir as opções.

​
4. Não exponha o CRM diretamente em camadas de borda

O CRM roda dentro do ledger Midaz e expõe uma API interna. Se você o expuser diretamente por meio de API gateways, load balancers ou aplicações frontend, aumenta sua superfície de ataque. Você também contorna os controles de acesso no nível da aplicação. Em vez disso:
  • Roteie o tráfego do CRM pelos seus serviços de backend ou por uma camada de API interna.
  • Use o Access Manager para aplicar autenticação e autorização se precisar de controle granular.
  • Restrinja o acesso de rede aos pods do ledger com Kubernetes NetworkPolicies ou os security groups do seu provedor de nuvem.

​
5. Use soft delete como padrão

O CRM oferece suporte a soft delete e hard delete:
  • Soft delete (padrão): o CRM marca o registro com um timestamp deletedAt. O registro deixa de aparecer nas consultas padrão, mas permanece no banco de dados para auditoria e recuperação.
  • Hard delete: o CRM solicita a remoção do registro, sujeita às regras de retenção e conformidade do seu deploy. Quando obrigações legais, regulatórias, de auditoria ou de manutenção de registros exigem retenção, o CRM não garante a remoção física.
Na maioria dos casos, o soft delete é a opção mais segura. Ele preserva as trilhas de auditoria e permite recuperar dados excluídos por engano. Reserve o hard delete para casos em que regulamentações exigem remoção completa (por exemplo, solicitações de direito ao esquecimento do GDPR).
Confirme sua política de retenção e de bloqueio legal antes de executar um hard delete. O direito ao esquecimento do GDPR (Artigo 17) não é absoluto. Quando obrigações legais, regulatórias, de auditoria ou de manutenção de registros exigem retenção de dados, elas podem prevalecer e restringir a exclusão.

​
6. Valide os dados antes de enviá-los ao CRM

O CRM é uma camada de dados neutra e persistente. Ele não aplica regras de negócio, não valida formatos de documentos nem verifica a conformidade com KYC. A integridade dos dados é responsabilidade sua. Antes de criar ou atualizar um registro:
  • Valide os formatos de documentos (CPF, CNPJ, números de passaporte) na camada da sua aplicação.
  • Confirme que os valores de ledgerId e accountId apontam para entidades reais no Midaz.
  • Sanitize as entradas para não armazenar dados malformados ou inconsistentes.

​
7. Mantenha as versões do CRM e do Midaz alinhadas

O CRM é distribuído dentro do binário do ledger Midaz, então compartilha a versão do Midaz. Antes de fazer upgrade:
  • Confira a tabela de compatibilidade de versões para confirmar sua versão de destino.
  • Teste o upgrade em um ambiente de staging antes de aplicá-lo em produção.
  • Faça backup dos dados do MongoDB e dos valores do Helm antes de qualquer upgrade importante.
Para os procedimentos de upgrade, consulte o guia de upgrade do Helm.

​
8. Monitore a saúde e o desempenho do banco de dados

O CRM usa MongoDB para armazenamento de dados. Em produção:
  • Monitore o uso do pool de conexões. O padrão de MONGO_CRM_MAX_POOL_SIZE é 1000. Ajuste-o de acordo com seus padrões de tráfego e número de réplicas.
  • Configure alertas para uso de disco do MongoDB, atraso de replicação e saturação de conexões.
  • Habilite backups. Seja com o MongoDB Bitnami empacotado, seja com uma instância externa, execute backups automatizados e teste-os regularmente.
  • Habilite o OpenTelemetry (ENABLE_TELEMETRY: true) para coletar traces e métricas do CRM. Integre com sua stack de observabilidade para visibilidade de ponta a ponta.

​
9. Revise as recomendações de segurança

O CRM lida com dados pessoais e sensíveis. Além das práticas específicas do CRM, confirme que seu deploy segue as Recomendações de segurança da plataforma, que abrangem:
  • Segmentação de rede e Zero Trust Architecture
  • Aplicação de TLS 1.2+ em todas as comunicações
  • Configuração de IAM e RBAC
  • Planejamento de resposta a incidentes
  • Gerenciamento de patches e varredura de vulnerabilidades