Seguridad

Borrador pendiente de revisión legal. Este documento es un borrador fundamentado y NO constituye asesoría legal ni la versión vigente hasta su revisión y aprobación por un abogado.

La verificación de identidad es un negocio de confianza: Belfort trata datos personales sensibles —biométricos y de identidad— por cuenta de sus clientes. Esta página describe las prácticas de seguridad reales de la plataforma. Distinguimos con honestidad lo que ya opera de lo que está en proceso o en el roadmap: nunca presumimos una certificación que no tenemos.

Protección de datos

• Cifrado en tránsito y en reposo. (Ya opera.) Todo el tráfico viaja sobre TLS. Los campos de identidad del expediente de la persona —nombre, CURP, RFC, clave de elector, correo, teléfono, domicilio— y los archivos capturados (identificación y selfie) se almacenan cifrados a nivel de aplicación, no solo por el cifrado del disco.
• Búsqueda sin descifrar. (Ya opera.) Localizar a una persona por CURP, RFC, correo o nombre no requiere descifrar el expediente: la búsqueda corre sobre índices ciegos (HMAC), incluida la coincidencia fonética en español de México.
• Derecho al olvido. (Ya opera.) El bloqueo y la supresión son ejercitables por solicitud ARCO, con purga durable de datos y archivos. Ver la Política de datos biométricos.
• Gestión de llaves. (Estado real.) Hoy la llave maestra de cifrado la gestiona Belfort y es común a la plataforma. Las llaves por cliente (DEK per-tenant) y BYOK —que permiten al cliente revocar unilateralmente el acceso a sus datos— están en el roadmap y son un prerequisito que nos fijamos antes de operar con una entidad financiera regulada.

En proceso — lo que aún no puedes exigirnos

Somos explícitos con esto porque un cliente en due diligence lo va a verificar:

• PII enmascarada por defecto y bitácora de accesos. (En proceso.) Hoy el enmascarado por defecto y el registro de cada descifrado con actor, finalidad y motivo operan en el flujo de revisión manual, y se están extendiendo al resto de las superficies de lectura. Hasta que se complete, no lo consideres una medida vigente en toda la plataforma.
• Retención ejecutada por TTL. (Parcial.) La evidencia biométrica y documental sí se elimina automáticamente al vencer su plazo: un proceso periódico destruye del almacenamiento el único ejemplar cifrado del archivo y marca el registro, sin que medie solicitud alguna. Las retenciones bajo bloqueo legal quedan exceptuadas, y una eliminación sólo se da por ejecutada cuando el almacenamiento la confirma. En cambio, los datos personales conservados en base de datos se suprimen a solicitud del titular, tras el periodo de bloqueo que corresponda a la finalidad —no por vencimiento automático—. Un proceso de revisión periódica audita ambos ciclos.

Control de acceso

• Roles y mínimo privilegio. El acceso al producto está segmentado por roles (propietario, administrador, oficial de cumplimiento, revisor); cada quien ve solo lo que su rol permite.
• Aislamiento por tenant. Los datos de cada organización están aislados; una organización nunca puede acceder a los recursos de otra (defensa anti-IDOR en cada punto de acceso).
• Llaves de API con alcance. Las llaves se emiten con scopes y límites de tasa; las publishable keys del navegador están acotadas por origen. Los secretos de webhook son rotables.

Defensa del pipeline de verificación

• Prueba de vida y face match. El mismo motor en el navegador y en la app: ninguna de las dos señales depende del canal.
• Anti-deepfake, solo dentro de la app. La detección de inyección de cámara, face swap e identidades sintéticas exige la captura nativa de la app Belfort Verify. En un navegador no hay forma de distinguir un video que entró por la cámara de uno inyectado en el flujo, así que no lo ofrecemos ahí en lugar de fingirlo.
• Integridad del dispositivo. La app reporta si el equipo está emulado, rooteado o con hooks. Esa señal suma al riesgo del trust score; hoy no rechaza por sí sola.
• Fail-closed con fuentes gubernamentales. Si una fuente (CURP/RENAPO, INE) está caída o responde con error, el caso cae a revisión manual, nunca se auto-aprueba con la fuente caída.
• Decisiones auditables. Cada veredicto se congela con la política vigente y su desglose de trust score, de modo que sea reproducible y defendible ante una auditoría.
• Webhooks firmados. Los eventos se firman con HMAC; el integrador puede verificar la autenticidad de cada entrega.

Continuidad y estado del servicio

• Status page pública. Publicamos el estado de la plataforma y de las fuentes de datos en status.belfort.ai, con historial de disponibilidad por componente.
• Reglas de nivel de servicio. Las reglas de medición, exclusiones y ventanas de mantenimiento están en el SLA.

Certificaciones — estado honesto

El estándar de la industria de verificación de identidad es SOC 2 Type II e ISO 27001 como piso, y sellos específicos de liveness/anti-deepfake como iBeta PAD. Este es nuestro estado real:

Certificación	Estado	Nota
SOC 2 Type II	En proceso	Prioridad del roadmap de cumplimiento.
ISO/IEC 27001	En el roadmap	Posterior a SOC 2.
iBeta PAD (L1/L2)	En el roadmap	Sello de detección de ataques de presentación (liveness/anti-deepfake).

Cuando cada reporte esté disponible lo compartiremos bajo acuerdo de confidencialidad (NDA) con clientes y prospectos en proceso de due diligence.

Divulgación de vulnerabilidades

Si encuentras una vulnerabilidad, repórtala de forma responsable — ver Divulgación responsable. Contacto: security@belfort.ai.