Pular para o conteúdo principal
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 começar qualquer fluxo posterior.
Confirme que seus identificadores estão corretos antes de criar ou vincular registros. O CRM verifica se o ledgerId e o accountId de um Instrumento existem na organização.

​
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.
  • Passe as chaves para o deploy a partir do seu cofre de segredos. Para configurá-las em um deploy do Midaz, consulte o README do chart do Midaz.
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. 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 (hard_delete=true): o CRM remove o registro do banco de dados dele.
Na maioria dos casos, o soft delete é a opção mais segura. Ele preserva as trilhas de auditoria. 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 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.
  • 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 da configuração do seu deploy 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 chart do Helm define MONGO_CRM_MAX_POOL_SIZE como 1000 por padrão. 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