Pular para o conteúdo principal
O plugin CRM gerencia dados sensíveis relacionados à identidade. Usá-lo bem significa ir além da configuração básica — exige integração cuidadosa, manuseio disciplinado de dados e práticas operacionais sólidas. 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 de criação de entidades. Pular etapas ou criar entidades fora de sequência pode levar a integrações quebradas e dados faltantes em fluxos posteriores. O fluxo esperado é:
  1. Criar o Holder — representando o indivíduo ou organização.
  2. Criar a Alias Account — vinculando o Holder a uma conta do Midaz Ledger.
  3. Verificar ambos — antes de prosseguir com quaisquer fluxos posteriores.
Sem um Holder vinculado a uma Alias Account, a maioria das funcionalidades impulsionadas pelo CRM (taxas, notificações, faturamento, verificação de identidade) não funcionará como esperado.
A API do CRM não valida a exatidão dos dados que você envia. Fornecer identificadores incorretos (como um ledgerId ou accountId que não correspondam) pode causar falhas de integração com o Ledger ou outros plugins. Sempre verifique seus identificadores antes de criar registros.

​
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 usando 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, você deve gerar uma nova e re-criptografar todos os dados afetados. Este é um processo manual — projete seus runbooks operacionais de acordo.
  • 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. Ele é armazenado em texto plano e destinado 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 é um serviço interno. Expô-lo diretamente através de API gateways, balanceadores de carga ou aplicações frontend aumenta sua superfície de ataque e 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 CRM usando 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): Marca o registro com um timestamp deletedAt. O registro é excluído das consultas padrão, mas permanece no banco de dados para fins de auditoria e recuperação.
  • Hard delete: Remove permanentemente os dados sem possibilidade de recuperação.
Para a maioria dos casos de uso, soft delete é a escolha mais segura. Ele preserva trilhas de auditoria e permite recuperação se dados forem excluídos por engano. Reserve hard delete para cenários onde requisitos regulatórios exigem remoção completa (ex.: solicitações de direito ao esquecimento do GDPR).

​
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 registros:
  • 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 correspondem a entidades reais no Midaz.
  • Sanitize as entradas para evitar armazenar dados malformados ou inconsistentes.

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

O plugin CRM é versionado junto com o Midaz Core. Antes de atualizar:
  • Consulte a tabela de compatibilidade de versões para confirmar que suas versões-alvo são compatíveis.
  • Sempre atualize o Midaz Core primeiro, depois o CRM.
  • 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 ambientes de produção:
  • Monitore o uso do pool de conexões. O valor padrão de MONGO_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, garanta que backups automatizados estejam configurados e testados 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 plugin, 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