1. Sigue el flujo de integración correcto
CRM depende de un orden específico para crear entidades. Si omites pasos o creas entidades fuera de orden, puedes romper integraciones y perder datos en los procesos posteriores. El flujo esperado es:
- Crea el Holder: la persona o la organización.
- Vincula el Holder a una cuenta de ledger de Midaz: asocia el Holder con una cuenta que ya existe en el ledger.
- Confirma que ambos existen antes de iniciar cualquier flujo posterior.
2. Protege tus claves de cifrado
CRM cifra y aplica hash a los campos sensibles antes de almacenarlos. La seguridad de estos datos depende por completo de cómo gestiones tus claves.
- Genera claves únicas para
LCRYPTO_HASH_SECRET_KEYyLCRYPTO_ENCRYPT_SECRET_KEYconopenssl rand -hex 32. - Almacena las claves en un gestor de secretos (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault o equivalente). Nunca las escribas directamente en archivos de configuración, código fuente ni control de versiones.
- Planifica la rotación de claves. Si una clave se ve comprometida, genera una nueva y vuelve a cifrar todos los datos afectados. Este es un proceso manual, así que diseña tus manuales operativos para ello.
- Usa Kubernetes Secrets en producción. Haz referencia a secretos existentes mediante
useExistingSecretyexistingSecretNameen tus valores de Helm en lugar de almacenar las claves directamente.
3. Nunca almacenes datos sensibles en metadatos
El objeto
metadata en las entidades de CRM no está cifrado. CRM lo almacena en texto plano solo para información auxiliar y no sensible.
No uses metadatos para:
- Números de identificación personal (CPF, SSN, pasaporte)
- Detalles de cuentas financieras
- Información de contacto (correo electrónico, teléfono)
- Cualquier dato sujeto a la LGPD, el GDPR u otras regulaciones similares
4. No expongas CRM directamente en capas de borde
CRM se ejecuta dentro del ledger de Midaz y expone una API interna. Si lo expones directamente a través de puertas de enlace de API, balanceadores de carga o aplicaciones frontend, aumentas tu superficie de ataque. También evitas los controles de acceso en el nivel de aplicación. En su lugar:
- Enruta el tráfico de CRM a través de tus servicios backend o una capa de API interna.
- Usa Access Manager para aplicar autenticación y autorización si necesitas control granular.
- Restringe el acceso de red a los pods del ledger con NetworkPolicies de Kubernetes o los grupos de seguridad de tu proveedor de nube.
5. Usa soft delete como opción predeterminada
CRM admite tanto soft delete como hard delete:
- Soft delete (predeterminada): CRM marca el registro con una marca de tiempo
deletedAt. El registro deja de aparecer en las consultas estándar, pero permanece en la base de datos para auditoría y recuperación. - Hard delete: CRM solicita la eliminación del registro, sujeta a las reglas de retención y cumplimiento de tu implementación. Cuando obligaciones legales, regulatorias, de auditoría o de conservación de registros exigen retención, CRM no garantiza la eliminación física.
Confirma tu política de retención y de retención legal antes de ejecutar una eliminación permanente. El derecho al olvido del GDPR (artículo 17) no es absoluto. Cuando obligaciones legales, regulatorias, de auditoría o de conservación de registros exigen la retención de datos, estas pueden tener prioridad y restringir la eliminación.
6. Valida los datos antes de enviarlos a CRM
CRM actúa como una capa de datos persistente y neutral. No aplica reglas de negocio, no valida formatos de documentos ni verifica el cumplimiento de KYC. La integridad de los datos es tu responsabilidad. Antes de crear o actualizar un registro:
- Valida los formatos de documentos (CPF, CNPJ, números de pasaporte) en tu capa de aplicación.
- Confirma que los valores
ledgerIdyaccountIdapuntan a entidades reales en Midaz. - Depura las entradas para no almacenar datos malformados o inconsistentes.
7. Mantén alineadas las versiones de CRM y Midaz
CRM se distribuye dentro del binario del ledger de Midaz, por lo que comparte la versión de Midaz. Antes de actualizar:
- Consulta la tabla de compatibilidad de versiones para confirmar tu versión de destino.
- Prueba la actualización en un entorno de staging antes de aplicarla a producción.
- Respalda tus datos de MongoDB y tus valores de Helm antes de cualquier actualización mayor.
8. Monitorea el estado y el rendimiento de la base de datos
CRM usa MongoDB para el almacenamiento de datos. En producción:
- Monitorea el uso del pool de conexiones. El valor predeterminado de
MONGO_CRM_MAX_POOL_SIZEes 1000. Ajústalo según tus patrones de tráfico y el número de réplicas. - Configura alertas para el uso de disco de MongoDB, el retraso de replicación y la saturación de conexiones.
- Habilita los respaldos. Ya sea que uses el MongoDB de Bitnami incluido o una instancia externa, ejecuta respaldos automatizados y pruébalos regularmente.
- Habilita OpenTelemetry (
ENABLE_TELEMETRY: true) para recopilar trazas y métricas de CRM. Intégralo con tu stack de observabilidad para obtener visibilidad de extremo a extremo.
9. Revisa las recomendaciones de seguridad
CRM gestiona datos personales y sensibles. Más allá de las prácticas específicas de CRM, confirma que tu implementación siga las recomendaciones de seguridad de toda la plataforma, que cubren:
- Segmentación de red y arquitectura Zero Trust
- Aplicación de TLS 1.2+ para todas las comunicaciones
- Configuración de IAM y RBAC
- Planificación de respuesta a incidentes
- Gestión de parches y análisis de vulnerabilidades

