> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Mejores prácticas
> Sigue las mejores prácticas de producción de CRM sobre el flujo de integración, la gestión de claves de cifrado, la protección de metadatos y los workflows operativos seguros.
CRM gestiona datos sensibles relacionados con la identidad. Estas prácticas te ayudan a integrar CRM correctamente, proteger esos datos y ejecutarlo de forma segura en producción.
Estas recomendaciones complementan la guía de [seguridad de datos de CRM](/es/products/midaz/crm/crm-data-security), que cubre el cifrado, el hashing y la gestión de claves en detalle.
## 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:
1. **Crea el Holder**: la persona o la organización.
2. **Vincula el Holder a una cuenta de ledger de Midaz**: asocia el Holder con una cuenta que ya existe en el ledger.
3. **Confirma que ambos existen** antes de iniciar cualquier flujo posterior.
Sin un Holder vinculado a una cuenta de ledger, la mayoría de las funciones impulsadas por CRM (comisiones, notificaciones, facturación, verificación de identidad) no funcionan como se espera.
Confirma que tus identificadores son correctos antes de crear o vincular registros. La API de CRM **no** valida la exactitud de los datos que envías. Un `ledgerId` o `accountId` no coincidente puede provocar fallas de integración con el ledger u otros componentes.
## 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_KEY` y `LCRYPTO_ENCRYPT_SECRET_KEY` con `openssl 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 `useExistingSecret` y `existingSecretName` en tus valores de Helm en lugar de almacenar las claves directamente.
Para ver la lista completa de campos protegidos y estrategias de cifrado, consulta [seguridad de datos de CRM](/es/products/midaz/crm/crm-data-security).
## 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
Si necesitas almacenar un atributo sensible que no está en la [lista de campos protegidos](/es/products/midaz/crm/crm-data-security#protected-fields), contacta a tu representante de Lerian para conversar sobre las opciones.
## 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](/es/platform/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.
En la mayoría de los casos, el soft delete es la opción más segura. Preserva los registros de auditoría y permite recuperar datos que eliminas por error. Reserva el hard delete para los casos en que las regulaciones exigen la eliminación completa (por ejemplo, solicitudes de derecho al olvido del GDPR).
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 `ledgerId` y `accountId` apuntan 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](/es/platform/deploy/midaz-version-compatibility) 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.
Para los procedimientos de actualización, consulta la [guía de actualización de Helm](/es/platform/deploy/midaz/midaz-upgrade-guide).
## 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_SIZE` es 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](/es/products/midaz/security-recommendations) 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