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

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

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 em fluxos posteriores. O fluxo esperado é:
  1. Criar o holder — o indivíduo ou a organização.
  2. Vincular o holder a uma conta do ledger do Midaz — associe o holder a uma conta que já existe no ledger.
  3. Certifique-se de que ambos existam — antes de iniciar qualquer fluxo posterior.
Sem um holder vinculado a uma conta do ledger, a maioria das funcionalidades impulsionadas pelo CRM (taxas, notificações, faturamento, verificação de identidade) não funciona como esperado.
Certifique-se de que seus identificadores estejam corretos antes de criar ou vincular registros. A API do CRM não valida a exatidão dos dados que você envia. Um ledgerId ou accountId incorreto pode causar falhas de integração com o ledger ou outros componentes.

​
2. Proteja suas chaves de criptografia

O CRM criptografa e aplica hash nos 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 secrets (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault ou equivalente). Nunca codifique-as 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 re-criptografe todos os dados afetados. Este é um processo manual, então projete seus runbooks operacionais para isso.
  • Use Kubernetes Secrets em produção. Referencie secrets existentes via useExistingSecret e existingSecretName nos seus valores de Helm em vez de armazenar chaves inline.
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 metadata

O objeto metadata nas entidades do CRM não é criptografado. O CRM o armazena em texto plano apenas para informações auxiliares não sensíveis. Não use metadata para:
  • Números de identificação pessoal (CPF, SSN, passaporte)
  • Detalhes de contas financeiras
  • Informações de contato (email, telefone)
  • Quaisquer dados sujeitos à LGPD, GDPR ou regulamentações similares
Se você precisa armazenar um atributo sensível que não está na lista de campos protegidos, entre em contato com seu representante Lerian para discutir opções.

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

O CRM é executado dentro do ledger do Midaz e expõe uma API interna. Se você o expõe diretamente através de API gateways, balanceadores de carga 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 através dos seus serviços backend ou uma camada de API interna.
  • Use o Access Manager para aplicar autenticação e autorização se você precisar de controle granular.
  • Restrinja o acesso de rede aos pods do ledger com Kubernetes NetworkPolicies ou os grupos de segurança do seu provedor de nuvem.

​
5. Use soft delete como padrão

O CRM suporta tanto soft delete quanto 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 da sua implementação. Quando obrigações legais, regulatórias, de auditoria ou de manutenção de registros exigem a retenção, o CRM não garante a remoção física.
Para a maioria dos casos, soft delete é a escolha mais segura. Ele preserva trilhas de auditoria e permite que você recupere dados que exclui por engano. Reserve hard delete para casos onde as 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 retenção legal (legal hold) 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 a retenção de dados, elas podem prevalecer e restringir o apagamento.

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

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

​
7. Mantenha o CRM e o Midaz alinhados em versões

O CRM é distribuído dentro do binário do ledger do Midaz, portanto compartilha a versão do Midaz. Antes de atualizar:
  • Consulte a tabela de compatibilidade de versões para confirmar sua versão-alvo.
  • Teste a atualização em um ambiente de staging antes de aplicá-la em produção.
  • Faça backup dos seus dados do MongoDB e valores de Helm antes de qualquer atualização maior.
Para procedimentos de atualização, consulte o guia de atualização 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 valor padrão de MONGO_CRM_MAX_POOL_SIZE é 1000. Ajuste-o com base nos seus padrões de tráfego e quantidade de réplicas.
  • Configure alertas para uso de disco do MongoDB, atraso de replicação e saturação de conexões.
  • Habilite backups. Seja usando o MongoDB Bitnami incluído ou uma instância externa, execute backups automatizados e teste-os regularmente.
  • Habilite 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, certifique-se de que seu deploy siga as Recomendações de segurança da plataforma, que cobrem:
  • Segmentação de rede e Arquitetura Zero Trust
  • Aplicação de TLS 1.2+ para todas as comunicações
  • Configuração de IAM e RBAC
  • Planejamento de resposta a incidentes
  • Gerenciamento de patches e varredura de vulnerabilidades