Seguridad
Cómo se protegen los fondos y los datos
Un servicio que convierte activos digitales concentra dos cosas codiciadas: fondos en tránsito y expedientes de identidad completos. Esta página describe la arquitectura que los separa, las reglas de acceso que los rigen y lo que aún no podemos garantizar.
Custodia de los fondos
El principio fundacional: somos un flujo, no un custodio. Lo que no se posee no puede ser robado.
- Sin saldo reutilizable
- Su cuenta no tiene saldo. Un depósito está vinculado a una orden, se convierte y luego se paga. No hay función de almacenamiento, ni retiro a un tercero, ni transferencia entre cuentas.
- Tiempo de tenencia mínimo
- El tiempo que los fondos permanecen bajo nuestro control se limita a la confirmación de la red, los controles de cumplimiento y la emisión del pago. Acortar esa ventana es la medida de seguridad más eficaz, por delante de cualquier dispositivo técnico.
- Dirección de depósito dedicada
- Cada orden recibe su propia dirección. Por tanto, un depósito es inequívocamente atribuible, y una dirección no puede reutilizarse para engañar a un cliente sobre el destino.
- Separación en frío y en caliente
- Solo la fracción operativa necesaria para liquidar órdenes en curso permanece en firmantes conectados. El resto se mantiene fuera de línea, con claves divididas y un umbral de multifirma.
- Fondos de clientes segregados
- Los fondos en proceso de conversión se contabilizan por separado de los fondos propios. No financian ninguna actividad de la empresa y no se prestan ni se pignoran.
- Doble aprobación en los pagos
- Por encima de un umbral, una instrucción de pago requiere dos aprobaciones separadas. Por tanto, un único acceso interno comprometido no basta para mover fondos.
Cifrado y datos
Los archivos de verificación de identidad son los datos más sensibles del producto. Se tratan en consecuencia.
- Cifrado en tránsito
- Todo el tráfico se ejecuta a través de TLS, sin excepción y sin respaldo en texto plano. El transporte estricto se aplica mediante cabecera, lo que impide una solicitud inicial no cifrada.
- Cifrado en reposo
- Las bases de datos, las copias de seguridad y el almacenamiento de documentos están cifrados. Las imágenes de documentos de identidad y las capturas de vida se guardan en un almacén separado de los datos de la cuenta.
- Secretos y claves
- Ningún secreto en el código ni en los registros. Las claves de cifrado las gestiona un servicio dedicado, con rotación programada y separación entre quien posee la clave y quien accede a los datos.
- Registros depurados
- Los identificadores bancarios, las claves de pago y el contenido de los documentos se eliminan de los registros de aplicación en el momento de la escritura. Por tanto, un incidente en los registros no expone datos de pago utilizables.
- Contraseñas
- Se almacenan como un hash con una función de derivación lenta y una sal única. No podemos leerlas, por lo que no podemos recordarle una: solo permitirle restablecerla.
Acceso interno
La mayoría de los incidentes no provienen de una falla exótica, sino de un acceso interno demasiado amplio. Ahí es donde se concentra el esfuerzo.
- Mínimo privilegio
- El acceso se concede por rol y para una tarea. El soporte no ve documentos de identidad; el cumplimiento no puede cambiar un importe; la ingeniería no accede a los archivos de clientes en producción.
- Segundo factor obligatorio
- Ningún acceso interno sin un segundo factor de hardware. Los códigos por mensaje de texto no se aceptan para el acceso interno: son vulnerables al secuestro del número.
- Registro de accesos
- Cada apertura de un archivo de verificación se registra con el agente y una marca de tiempo. Los registros se conservan y revisan periódicamente.
- Sin datos de producción en otros lugares
- Los entornos de desarrollo y prueba funcionan con datos sintéticos. Está prohibido copiar una base de datos de producción en una estación de trabajo, y técnicamente se impide.
- Desvinculación y revisión de accesos
- El acceso se revoca cuando alguien se va y se revisa periódicamente. El acceso no utilizado se elimina en lugar de mantenerse "por si acaso".
Lo que usted controla en su cuenta
Parte de la seguridad depende de usted. El producto está diseñado para que esos pasos sean simples y difíciles de eludir.
- 01
Active un segundo factor
Aplicación de autenticación o clave de hardware. Se vuelve obligatorio por encima del segundo nivel de verificación. La ausencia de un segundo factor sigue siendo la causa principal de desvío de pagos observada en este sector.
- 02
Revise sus sesiones
Las sesiones activas se enumeran con su dispositivo, ubicación aproximada y fecha. Puede revocar una de forma remota sin cambiar su contraseña.
- 03
Período de reflexión para un nuevo beneficiario
Añadir una cuenta de destino activa una notificación y un retraso antes de que pueda recibir un importe elevado. Ese retraso existe para que un acceso fraudulento no se convierta instantáneamente en una transferencia.
- 04
Notificaciones de cambios
Cambio de contraseña, alta de beneficiario, segundo factor activado o desactivado: cada evento envía un mensaje a la dirección registrada, incluso cuando lo has hecho tú mismo.
- 05
Reconocer el phishing
Nunca le pediremos su frase de recuperación, nunca le pediremos que deposite en una dirección enviada por mensaje, nunca le pediremos que convierta fondos para «proteger» una cuenta. Una dirección de depósito solo existe dentro de su orden.
Lo que impone el navegador
Estas cabeceras las establece el servidor en cada respuesta. Puede comprobarlas usted mismo en las herramientas de desarrollador de su navegador.
| Cabecera | Efecto |
|---|---|
| Strict-Transport-Security | Obliga al navegador a usar solo conexiones cifradas, incluso si un enlace apunta a una versión no segura. |
| X-Frame-Options: DENY | Impide que el sitio se incruste en un marco de terceros, lo que neutraliza el clickjacking. |
| X-Content-Type-Options: nosniff | Impide que el navegador adivine el tipo de un archivo, una fuente clásica de ejecución no intencionada. |
| Referrer-Policy | Limita lo que se filtra a un sitio de terceros cuando sigue un enlace saliente: el origen, nunca la ruta completa. |
| Permissions-Policy | Corta el acceso al micrófono, la geolocalización y la interfaz de pago. La cámara permanece permitida en nuestro propio origen, para la verificación de identidad. |
| Cross-Origin-Opener-Policy | Aísla la ventana del sitio de otros contextos de navegación, bloqueando una clase de ataques de ventana compartida. |
Estas cabeceras provienen de la configuración del servidor, no de una capa opcional. No sustituyen los controles de la aplicación: cierran las puertas que solo el navegador puede cerrar.
Continuidad e incidentes
Un plan de incidentes que nunca se ha ensayado no es un plan. Aquí está el procedimiento y lo que usted vería de él.
- 01
Detección y triaje
Alertas sobre accesos anómalos, series de autenticaciones fallidas y desajustes de conciliación. Una alerta es triada por una persona, nunca se cierra automáticamente.
- 02
Contención
Revocación del acceso afectado, congelación de pagos si la duda toca un movimiento de fondos, aislamiento del componente afectado. El servicio puede interrumpirse deliberadamente: preferimos una caída a un pago dudoso.
- 03
Notificación
Una violación de datos personales que pueda crear un riesgo se notifica a la autoridad de control en un plazo de 72 horas, y directamente a las personas afectadas cuando el riesgo es alto.
- 04
Vuelta al servicio
Restauración a partir de copias de seguridad cifradas cuyo procedimiento de restauración está probado: una copia de seguridad que nunca se ha restaurado no es una copia de seguridad.
- 05
Nota pública
Publicamos una nota de incidente que describe qué ocurrió, qué se expuso y qué cambió, incluso cuando no se requiere notificación individual.
Divulgación responsable
Preferimos enterarnos de una falla por un investigador que por un incidente. Los plazos siguientes son compromisos.
| Gravedad | Primera respuesta | Objetivo de corrección |
|---|---|---|
| Crítico: fondos, claves o datos de identidad expuestos | 4 h | Corrección o mitigación en un plazo de 72 horas |
| Alto: elusión de autenticación o autorización | 24 h | Corrección en un plazo de 14 días |
| Medio: fuga de información limitada, denegación parcial de servicio | 72 h | Corrección en un plazo de 60 días |
| Bajo: defecto de configuración sin impacto demostrado | 120 h | Se gestiona en el flujo de desarrollo habitual |
Lo que no garantizamos
Una página de seguridad creíble declara sus límites. Aquí están, sin suavizar.
- Sin auditoría externa hasta la fecha
- No se ha realizado ninguna prueba de penetración de terceros ni certificación. Por lo tanto, no mostramos ningún logotipo de auditoría, sello ni afirmación de certificación. El día que se realice una auditoría, su alcance y fecha aparecerán aquí.
- Una transacción en cadena no se puede deshacer
- Ninguna medida de seguridad hace reversible una transferencia confirmada en una red pública. Es una propiedad de la red, no una brecha por nuestra parte.
- Un dispositivo comprometido
- Si su ordenador o teléfono está comprometido, un segundo factor basado en una aplicación puede ser eludido. Una clave de hardware sigue siendo la única protección genuinamente resistente en ese caso.
- Proveedores de pago
- Una vez que la instrucción llega a la institución de pago, el enrutamiento depende de su infraestructura y de los bancos intermediarios. Elegimos a nuestros proveedores, no los operamos.
- Riesgo cero
- No lo prometeremos. Lo que podemos prometer es una superficie reducida, detección rápida y una comunicación que no minimiza.
Preguntas frecuentes sobre seguridad
¿Mantiene usted mi cripto?
No. No hay saldo, ni cartera, ni función de almacenamiento. Un depósito está vinculado a una orden, se convierte y luego se paga. El tiempo que los fondos permanecen bajo nuestro control se limita al procesamiento de la operación.
¿Qué ocurre si su sistema se ve comprometido durante mi orden?
Los pagos se congelan tan pronto como se clasifica un incidente que afecte a un movimiento de fondos. Una orden ya convertida sigue siendo debida: la conversión y la obligación de pago se registran independientemente del componente afectado.
¿Se acepta un segundo factor por mensaje de texto?
Para una cuenta de cliente, sí, pero recomendamos una aplicación de autenticación o una llave de hardware: el secuestro del número de teléfono es un ataque común y barato. Para el acceso interno, no se aceptan mensajes de texto.
¿Están certificados o auditados?
No, y no lo mostramos en ningún sitio. Ninguna prueba de penetración externa ni certificación se ha llevado a cabo hasta la fecha. El día que eso cambie, el alcance exacto y la fecha aparecerán en esta página.
He encontrado una vulnerabilidad. ¿Qué debo hacer?
Escriba a la dirección de seguridad con el componente afectado, el impacto y los pasos para reproducirlo. El alcance autorizado, las reglas de prueba y nuestro compromiso de no perseguir la investigación de buena fe están publicados.