Seguridad mínima indispensable para plataformas que guardan expedientes de clientes

Un expediente de cliente reúne en un solo lugar lo que un tercero necesitaría para suplantar a una persona: identificación oficial, CURP, RFC, constancia de situación fiscal, comprobante de domicilio y, en el caso de personas morales, actas constitutivas y poderes. Las plataformas de KYC y de cumplimiento PLD guardan miles de estos expedientes. A continuación compartimos los controles que consideramos el piso mínimo, no el techo, a partir de lo que aplicamos y revisamos periódicamente en nuestros propios sistemas.

1. Acceso: mínimo privilegio y aislamiento por cliente

El error más costoso no suele ser un ataque sofisticado, sino que un usuario vea expedientes ajenos.

• Toda consulta a la base de datos debe estar acotada a la organización del usuario, y esa restricción debe vivir en el servidor o en las reglas de la base de datos, no en la interfaz. Ocultar un botón no es un control.
• El identificador de organización de un registro no debe poder modificarse después de su creación. Si un usuario puede editar ese campo, puede mover datos de un cliente a otro.
• Los roles deben tener permisos explícitos: quien captura no necesariamente aprueba, y quien aprueba no necesariamente administra usuarios ni cambia roles, incluido el propio.
• Cada ruta del backend debe declarar su mecanismo de autenticación. Conviene enumerarlas periódicamente para confirmar que ninguna quedó abierta, y documentar como tales las que son públicas por diseño.
• Las credenciales de servicio con acceso total se usan solo en procesos del servidor y nunca como archivos sueltos; en la nube, lo preferible es la identidad propia del servicio.

2. Cifrado y manejo de archivos

• Cifrado en tránsito en todas las conexiones, con HSTS, y cifrado en reposo. Los principales proveedores de nube lo ofrecen por defecto, pero hay que confirmar que también cubre respaldos y exportaciones.
• Archivos en almacenamiento privado. Para descargas, URLs firmadas de vigencia corta, nunca enlaces públicos permanentes.
• Validar los archivos por su contenido y no solo por su extensión: que un PDF sea realmente un PDF, que no esté protegido o dañado, y con límites de tamaño y número de páginas.
• Mensajes de error genéricos hacia el exterior, con un identificador de solicitud para rastrear el detalle internamente. Un error que muestra rutas internas o consultas a la base de datos es información útil para un atacante.

3. Llaves de API y webhooks

Las integraciones son la puerta por la que más datos salen de una plataforma, así que merecen reglas propias.

Para las llaves de API:

• Guardar solo un hash de la llave y mostrarla completa una única vez, al crearla.
• Usar un prefijo reconocible para que las herramientas de detección de secretos la identifiquen si llega a publicarse en un repositorio.
• Emitir una llave por integración, revocable de forma individual y con registro de último uso.
• Comparar secretos en tiempo constante y aplicar límites de tasa para que no se puedan probar llaves por fuerza bruta.
• Guardar los secretos de la plataforma en un gestor de secretos, no en archivos en servidores ni en el código, y rotarlos cuando alguien deja el equipo o hay sospecha de exposición.

Para los webhooks:

• Firmar cada envío, por ejemplo con HMAC sobre el cuerpo y una marca de tiempo, para que el receptor pueda verificar origen e integridad, y rechazar mensajes con marcas de tiempo antiguas.
• Verificar firma o token en todos los webhooks que la plataforma recibe. Un endpoint sin verificación permite disparar procesos con datos falsos.
• Enviar lo mínimo: identificadores y estado, no el expediente completo. El receptor consulta el detalle con sus propias credenciales.

4. Bitácora y retención

• Registrar quién consultó, descargó, modificó o aprobó cada expediente, con fecha y origen. La bitácora debe ser de solo adición y los usuarios de la plataforma no deben poder editarla.
• Definir la retención por tipo de dato. La LFPIORPI obliga a conservar la información y documentación de identificación durante un plazo mínimo; como ese plazo ha sido objeto de reformas, recomendamos confirmar el vigente con el área legal. Por su parte, la legislación de protección de datos personales pide no conservarlos más allá de lo necesario. Ambas obligaciones conviven y deben quedar escritas en una política.
• Los registros técnicos no deben contener datos personales; si inevitablemente los contienen, su retención debe ser corta y automática.
• Los respaldos forman parte de la política de retención: borrar un expediente en producción y conservarlo indefinidamente en un respaldo no es borrarlo.

La pregunta útil no es si la plataforma es segura, sino qué pasa cuando una llave se filtra, un usuario se equivoca de organización o un proveedor tiene un incidente. Cada control de esta lista responde a uno de esos escenarios.

5. Proveedores y modelos de lenguaje

Procesar expedientes con OCR y modelos de lenguaje agrega proveedores y riesgos nuevos.

• Mantener un inventario de los proveedores que tocan datos de expedientes: nube, OCR, modelos de lenguaje, correo, firma electrónica.
• Con modelos de lenguaje, usar contratos o planes empresariales cuyos términos excluyan el uso de los datos para entrenamiento, y revisar la retención y la región de procesamiento del proveedor.
• Enviar al modelo solo lo necesario para la tarea.
• Tratar el texto de los documentos como dato y no como instrucción: un documento puede contener texto diseñado para alterar el comportamiento del modelo. La salida del modelo se valida antes de guardarse y nunca dispara acciones por sí sola.
• Reflejar en el aviso de privacidad el uso de terceros que tratan datos por cuenta de la plataforma.
• Autoalojar las librerías que se ejecutan en el navegador junto a los documentos, o cargarlas con verificación de integridad.

Estos principios son la base con la que construimos Loony: cada expediente vive en un archivero aislado por organización, con versiones, y cada dato extraído conserva la página y el renglón de donde salió, lo que también facilita auditar quién vio qué y cuándo.

Si quieres revisar los controles de tu plataforma con esta lista como punto de partida, Escríbenos.