Seguridad y cumplimiento

Autenticación

Los tokens de acceso son JWT de corta duración (15 minutos), verificados en el gateway de la API; los tokens de actualización duran 30 días de inactividad y 90 días como máximo, rotan en cada uso y se guardan en una cookie HttpOnly, Secure y SameSite. Reutilizar un token de actualización ya rotado revoca toda la cadena.
Las claves de firma rotan cada 90 días con un periodo de solapamiento; las claves públicas se publican en /.well-known/jwks.json.
Los permisos no van incrustados en los tokens: se leen en cada petición, así que un cambio de rol surte efecto de inmediato y cualquier sesión se puede revocar de forma centralizada.
La autenticación de dos factores (TOTP) puede ser opcional, obligatoria para Propietarios y Administradores u obligatoria para todos. El inicio de sesión único con Google Workspace y Apple está disponible en todos los planes. SAML 2.0, las passkeys y el aprovisionamiento SCIM están previstos y aún no están disponibles.
Las claves de API se muestran una vez, se guardan como hash SHA-256, tienen ámbitos de un catálogo cerrado, están limitadas por los permisos de su propietario y se pueden revocar al instante. Consulta Autenticación.
El inicio de sesión tiene límites por IP y por email; diez intentos fallidos bloquean la cuenta durante 30 minutos; los intentos fallidos desde una misma dirección IP se cuentan y se registran, pero por defecto no bloquean esa dirección. Cada inicio de sesión, fallo, renovación, cambio de permisos y acción de administración va al registro de auditoría.

Aislamiento de inquilinos

Cada fila de cada servicio lleva la cuenta a la que pertenece, y cada consulta se filtra automáticamente por ella; desactivar el filtro exige una llamada explícita y autorizada en una lista, que solo usan las operaciones del personal entre inquilinos y que está cubierta por pruebas. Los roles por sitio añaden encima un filtro de sitio. Una petición del recurso de otra cuenta responde 404, nunca 403, para que no se puedan enumerar los ID. Cada endpoint de escritura usa una lista estricta de campos permitidos. Una prueba de acceso entre cuentas es obligatoria para cada endpoint nuevo.

La cabecera X-Account-Id de cada petición se comprueba frente al token, así que un error del cliente o un token reutilizado nunca pueden leer en silencio los datos de otro inquilino.

Cifrado

TLS 1.2 o superior en todos los endpoints públicos, TLS mutuo entre servicios, TLS hacia cada almacén de datos, volúmenes cifrados en reposo y cifrado de sobre por cuenta para los campos sensibles. Los certificados públicos se emiten y renuevan automáticamente; los certificados internos son de corta duración.

Secretos

Todos los secretos, incluidas las claves de tus proveedores BYOK y los secretos de webhooks, viven en un gestor de secretos dedicado, cifrados, limitados por servicio y auditados. Nada está en el control de versiones (se garantiza con un análisis antes de cada commit) ni en las imágenes de contenedor (se comprueba en CI). Los desarrolladores no tienen acceso a los secretos de producción por defecto; el acceso de emergencia requiere dos aprobaciones, es de corta duración y se registra en un canal que no se puede silenciar.

Webhooks

Los envíos salientes se firman con HMAC-SHA256 sobre la marca de tiempo y el cuerpo sin procesar, llevan un nonce y un ID de evento, se rechazan fuera de una ventana de cinco minutos y se reintentan con espera creciente hasta una cola de mensajes fallidos. Los secretos rotan con una ventana de solapamiento y se pueden revocar al instante. Los webhooks entrantes de los proveedores se verifican con el esquema de cada proveedor antes de procesar nada. Detalles: Webhooks.

Límites de uso

Cuatro capas: protección contra DDoS y bots en la red perimetral, límites por IP en el proxy inverso, cubetas de tokens por cuenta y por identidad en el gateway de la API y límites de dominio dentro de los servicios. Los límites están en el resumen de la API.

Auditoría

Cada modificación se escribe en un registro de auditoría de solo anexado y encadenado por hash, con dos clases de conservación: eventos generales y eventos de cumplimiento (solicitudes de los interesados, brechas, subencargados y registros de KYC). La clase se asigna al escribir una entrada; nadie puede editar ni eliminar el registro, y aún no hay una limpieza automática por clase. Los Propietarios y Administradores pueden filtrarlo y exportarlo. Las contraseñas, los tokens y las claves nunca se registran; la capa de registro oculta las claves sensibles conocidas.

Protección de datos

Las solicitudes de los interesados según GDPR, UK GDPR, CCPA y LGPD (acceso, exportación, borrado) se reciben y se siguen en la consola de cumplimiento con plazos. El borrado lo realiza el personal de RolChat y la solicitud solo se cierra cuando lo confirma; aún no hay un borrado automático en todos los módulos.
Residencia de datos: los datos se almacenan en la UE. La región no se elige según el país en el registro; el ajuste de región en la configuración de la cuenta solo se guarda y todavía no traslada datos.
Conservación según el plan: 1, 2 o 3 años. Eliminar una conversación o un contacto lo oculta hasta el final de ese plazo; eliminar una cuenta es una solicitud con 30 días para cancelarla, tras los cuales el personal borra los datos; una cuenta impagada se conserva 90 días y después se borra. La limpieza automática que aplica estos plazos se está desplegando.
Un Acuerdo de tratamiento de datos, la lista de subencargados, la política de privacidad y la política de cookies están publicados en rolchat.com; el acuerdo se acepta al registrarse.
Notificación de brechas en un plazo de 72 horas, como exige el artículo 33 del GDPR.

Gestión de vulnerabilidades

Las dependencias se supervisan continuamente; los archivos de bloqueo se incluyen en el repositorio; las imágenes base se fijan por digest; las acciones de CI se fijan por commit. Desde la beta está prevista una prueba de penetración anual por parte de terceros que cubre la API, el widget y las páginas públicas, además de un escenario interno de brecha supuesta. En la disponibilidad general llegará un programa privado de recompensas por errores. Comunica los problemas de seguridad a security@rolchat.com.

Disponibilidad

La plataforma funciona en varios nodos con conmutación por error automática para los servicios sin estado y replicación gestionada para las bases de datos. Los objetivos de disponibilidad por plan se fijan en tu contrato.

Respuesta a incidentes

Procedimientos para cada servicio, una rotación de guardias, un sistema de avisos externo que funciona aunque nuestra propia infraestructura no lo haga y obligaciones de notificación a los clientes integradas en el proceso.