Seguridad

1. Qué es esta página

Esta página describe las medidas técnicas que Cardim aplica hoy, escritas a partir del código tal como está publicado. No es un contrato: los compromisos contractuales están en las Condiciones del Servicio, y lo que hacemos con los datos personales, y con qué base, está en la Política de Privacidad.

Cardim es un producto reciente, gestionado por un equipo muy pequeño. Preferimos decirlo aquí, al principio, antes que dejarlo implícito: la sección 7 enumera lo que no existe.

2. Dónde están los datos

Las reservas y los datos de los clientes están en una base de datos Postgres alojada por Neon en Londres, Reino Unido, sobre infraestructura AWS en la región eu-west-2. La aplicación se ejecuta en Vercel, los correos transaccionales los entrega Resend y los informes de error van a Sentry. La lista completa de proveedores, con la finalidad de cada uno, está en la sección 5 de la Política de Privacidad.

Todo el tráfico se sirve sobre HTTPS. El cifrado del almacenamiento en disco es el que publican esos proveedores y no es nuestro; en la capa de aplicación, lo que ciframos o convertimos en hash es exactamente lo que enumera la sección siguiente, y nada más.

3. Contraseñas, claves y enlaces

Nada de esta lista se guarda de una forma que una lectura de la base de datos haga reutilizable, con una excepción señalada: los tokens de calendario hay que devolverlos al proveedor, así que se cifran en lugar de convertirse en hash.

• Contraseñas de los comerciantes — nunca se guardan. Guardamos el resultado de scrypt, con una sal distinta por usuario, y la verificación se hace con una comparación en tiempo constante.
• Enlaces de restablecimiento de contraseña — 32 bytes de aleatoriedad criptográfica, y la base de datos guarda solo el SHA-256 del token: leer la base de datos no permite restablecer la contraseña de nadie.
• Tokens de Google Calendar y de Outlook — cifrados con AES-256-GCM antes de escribirse, con un juego de claves que permite sustituir la clave sin invalidar lo que ya está guardado.
• Sesiones y enlaces de reserva — identificadores de 128 bits generados por el generador criptográfico del sistema. La sesión viaja en una cookie httpOnly y caduca a los 30 días.

El enlace que el cliente recibe por correo es, en sí mismo, la autorización para ver, cambiar o cancelar esa reserva: por parte del cliente no hay cuenta ni contraseña. Por eso esos enlaces, y las direcciones de correo, se eliminan de los informes de error antes de salir de la aplicación, y por eso los formularios públicos limitan el número de intentos por origen.

4. Lo que la base de datos no deja ocurrir

Dos reservas no pueden ocupar el mismo recurso a la misma hora, y la garantía no está en el código de la aplicación: cada fila de ocupación guarda su propio intervalo de tiempo, y una restricción de exclusión de Postgres rechaza cualquier solapamiento. Dos peticiones que lleguen en el mismo instante no pueden ganar las dos, pase lo que pase por encima de la base de datos.

Un disparador aparte impide que un mismo cliente acabe con dos reservas solapadas. En las mesas y salas de capacidad compartida, el recuento de plazas se valida dentro de la misma transacción, con bloqueos por recurso tomados siempre en el mismo orden, para que dos peticiones simultáneas no se queden esperando la una a la otra.

5. Quién ve qué

Cada pantalla del panel consulta únicamente los datos del comerciante de la sesión, y las solicitudes de exportación y de borrado exigen ese mismo ámbito: un comerciante no puede exportar ni borrar los registros de otro.

Existe una consola interna, usada para operar el servicio, cuyo acceso está limitado a una lista cerrada de direcciones de correo definida en la configuración del servidor. Cuando esa lista no está configurada, la consola rechaza a todo el mundo en lugar de dejar entrar.

6. Conservación, borrado y exportación

Periódicamente se ejecuta una limpieza que borra lo que ya no sirve para nada:

• sesiones cuya validez ha expirado — una sesión abandonada es una credencial viva mientras exista la fila;
• reservas temporales de plaza que ya han caducado;
• registros de limitación de intentos de más de 24 horas, que además guardan un hash y no la dirección original;
• inscripciones en lista de espera para fechas de hace más de 30 días, que son un nombre, un teléfono y un correo de alguien que nunca llegó a ser cliente.

Las reservas y los clientes no se borran por temporizador: son el registro del negocio del comerciante. El borrado se hace a petición y es una anonimización en su sitio — la reserva, la hora y el importe siguen existiendo, la identidad de la persona desaparece, incluidas las observaciones en texto libre y los eventos reflejados en el calendario conectado. Si alguno de esos eventos no se puede borrar, se informa de ello al comerciante en lugar de tranquilizarlo.

Un comerciante puede solicitar la exportación de sus datos y el borrado completo de la cuenta.

7. Lo que no tenemos

Esta lista existe porque la alternativa es dejar la pregunta sin respuesta y confiar en que nadie la haga:

• no tenemos certificación SOC 2, ISO 27001 ni ninguna otra;
• no ha habido auditoría de seguridad externa ni prueba de intrusión por terceros;
• no ofrecemos acuerdo de nivel de servicio de disponibilidad, y la disponibilidad real depende de los proveedores indicados en la sección 2;
• no tenemos programa de recompensas por comunicación de vulnerabilidades.

8. Comunicar un problema

Si has encontrado un fallo de seguridad, escribe a support@usecardim.com con los pasos para reproducirlo. Responderemos y corregiremos lo que esté a nuestro alcance, y te pedimos que no lo divulgues públicamente antes de que esté corregido.