Declaración de seguridad

Esta declaración describe las medidas técnicas y organizativas que protegen el servicio RavSolutions y los datos que contiene. Está redactada para poder comprobarse: menciona medidas realmente implantadas, y la sección 15 indica con la misma claridad de qué no disponemos.

No es una garantía ni crea compromiso alguno de nivel de servicio; las condiciones contractuales están en los Términos y Condiciones. Cuando una misma medida aparece también en la información sobre el RGPD o en la información sobre el encargo del tratamiento, debe decir lo mismo en sustancia.

Se refiere al servicio que operamos. La seguridad de las cuentas, los dispositivos y las contraseñas dentro del espacio de trabajo de un suscriptor corresponde a este; ninguna medida descrita aquí protege un espacio de trabajo cuyas credenciales se hayan compartido o reutilizado en otro sitio.

El servicio se compone de tres interfaces —el sitio web, la aplicación y el portal de clientes—, una única API, una base de datos PostgreSQL, una instancia de Redis y almacenamiento de objetos. Las interfaces alcanzan la API únicamente por HTTPS.

Todo salvo el almacenamiento de objetos se ejecuta detrás de un proxy inverso en la infraestructura de RackForest Zrt. en Hungary (EU). La base de datos y Redis están conectadas solo a una red interna y no publican ningún puerto, de modo que no son accesibles desde Internet; únicamente la API puede comunicarse con ellas.

Los archivos subidos no residen en los servidores de aplicaciones, sino en el almacenamiento de objetos Cloudflare R2, configurado para European Union. El bucket es privado: sin acceso público y sin dominio propio delante, y cada archivo se sirve mediante un enlace firmado por la API.

Los secretos —credenciales de la base de datos, claves de firma, claves de API de los proveedores— se suministran a través del entorno en el despliegue y nunca se incorporan al repositorio de código fuente.

Todo el tráfico hacia el sitio web, la aplicación, el portal y la API se sirve por HTTPS. Los certificados los emite y renueva automáticamente Let's Encrypt, y las peticiones HTTP en claro se redirigen a HTTPS.

El proxy inverso envía HTTP Strict Transport Security con una vigencia de un año, incluidos los subdominios y con precarga, de modo que un navegador que ya ha visitado el sitio no vuelve a una conexión sin cifrar.

Las respuestas incluyen X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, una política de referente strict-origin-when-cross-origin y una política de permisos que deniega cámara, micrófono y geolocalización. Se eliminan las cabeceras que identifican el servidor y el marco de trabajo. La API solo acepta peticiones de origen cruzado desde los orígenes de la aplicación y del portal.

El sitio web, la aplicación y el portal se sirven con una Content Security Policy. Los scripts solo pueden cargarse desde el propio servicio y, en la aplicación, además desde Google Identity Services para iniciar sesión con Google; el sitio web y el portal no admiten ningún script de terceros. Se rechazan la incrustación en un marco, el contenido de complementos y la reescritura de la base del documento, y la API responde con una política que no permite absolutamente nada.

La contraseña debe tener al menos ocho caracteres e incluir una mayúscula, una minúscula y un dígito. Las contraseñas se guardan únicamente como resumen criptográfico con sal generado por el algoritmo de ASP.NET Core Identity, nunca en forma legible: por eso no podemos devolver una contraseña olvidada, solo permitir establecer una nueva.

Tras diez intentos fallidos de inicio de sesión, la cuenta queda bloqueada quince minutos. El recuento se lleva contra la cuenta y no contra quien llama, de modo que un intento repartido entre muchas direcciones también se detiene aunque cada dirección se mantenga por debajo del límite por llamante.

Es posible iniciar sesión con una cuenta de Google. El token de identidad emitido por Google se verifica ante Google antes de crear cualquier sesión, y nunca recibimos la contraseña de Google.

El registro envía un mensaje de confirmación a la dirección indicada, que se marca como confirmada al utilizar el enlace incluido. La contraseña olvidada se restablece mediante un enlace de un solo uso enviado a la dirección registrada; un restablecimiento correcto levanta además un bloqueo vigente, porque suele ser precisamente el bloqueo lo que lo motiva.

Los tokens de acceso son JSON Web Tokens válidos durante quince minutos. En cada petición se comprueban emisor, destinatario, firma y caducidad, sin tolerancia alguna de desfase horario.

El token de actualización consta de sesenta y cuatro bytes procedentes de un generador criptográfico de números aleatorios. La base de datos guarda solo su resumen SHA-256, de modo que el token en sí no puede extraerse de una copia de la base de datos.

Cada actualización sustituye el token: el anterior se revoca y se emite uno nuevo. Los tokens de actualización caducan a los treinta días y el cierre de sesión revoca el token de inmediato.

La actualización se deniega si el usuario ha sido desactivado o el espacio de trabajo se ha marcado como inactivo, por lo que la retirada de un acceso surte efecto, a más tardar, cuando caduca el token de acceso vigente.

Cada usuario tiene un rol en el espacio de trabajo y los puntos de acceso lo comprueban. Las funciones que dependen del plan están además protegidas por sus propias políticas de autorización, de modo que una función ajena al plan contratado la rechaza la API y no se limita a ocultarse en la interfaz.

Los espacios de trabajo están separados a nivel de datos: cada registro lleva el identificador del espacio al que pertenece y toda consulta se circunscribe al espacio de quien llama. Un registro de otro espacio no se oculta del resultado: nunca llega a entrar en él.

El espacio de trabajo se toma de una reclamación del token de acceso firmado y se resuelve en el servidor. Ningún identificador de espacio enviado por el cliente se considera fiable para ningún fin.

Las conexiones en tiempo real usan la misma autenticación que el resto de la API; una conexión sin token válido se rechaza, el tamaño de los mensajes entrantes está acotado y la información detallada de errores solo se devuelve en el entorno de desarrollo.

El cliente recibe un enlace con un token generado aleatoriamente, asociado a un único trabajo y con fecha de caducidad. El token abre ese trabajo y nada más del espacio de trabajo.

Antes de mostrar el trabajo, el visitante debe confirmar la dirección de correo electrónico o el número de teléfono registrados para ese cliente. Una confirmación correcta genera una prueba válida durante doce horas, firmada con HMAC mediante una clave derivada del secreto de firma del servidor pero criptográficamente independiente de él, y verificada en tiempo constante.

Los intentos de confirmación se limitan por llamante y deliberadamente no por token: limitar por token permitiría que cualquiera dejara a un cliente fuera de su propio trabajo sin más que agotar su cupo.

Las subidas se restringen a una lista fija de tipos de archivo —JPEG, PNG, WebP, PDF, DOCX, XLSX y texto sin formato— y a un tamaño máximo que depende del plan contratado. Las imágenes se recodifican en el servidor antes de almacenarse.

Los archivos se sirven mediante enlaces firmados de corta duración generados por la API. Como el propio bucket es privado, un enlace caducado o alterado no da acceso a nada.

La subida y la descarga tienen límites separados por llamante, de manera que un enlace filtrado o un cliente descontrolado no puedan consumir sin fin almacenamiento y ancho de banda.

Los archivos almacenados los cifra en reposo el proveedor de almacenamiento.

La API aplica límites de frecuencia particionados por llamante: por el espacio de trabajo y el usuario del token cuando lo hay, y por la dirección del cliente en caso contrario. El inicio de sesión, el inicio de sesión con Google, el restablecimiento de contraseña y la confirmación del portal se limitan a diez intentos por minuto; el registro, a cinco.

Los limitadores leen la dirección real de quien llama en las cabeceras reenviadas por el proxy, y solo se confía en el propio proxy para fijarlas. Sin esa configuración, toda petición parecería proceder del proxy y un único cupo lo compartirían todos: la protección se convertiría en una interrupción del servicio.

El proxy inverso aplica delante de la aplicación un límite global adicional, de modo que el tráfico queda acotado antes incluso de llegar a la API.

Los datos entrantes se validan en el servidor antes de alcanzar la lógica de negocio, y los errores se devuelven como mensajes estructurados: al cliente no se le envían trazas de pila, mensajes de la base de datos ni rutas internas.

La base de datos y Redis residen únicamente en la red interna y solo aceptan conexiones desde la API; ninguna de las dos está expuesta a Internet.

El almacenamiento de objetos cifra en reposo los archivos guardados y el bucket no es de lectura pública.

Se realizan copias de seguridad periódicas y se prueba su restauración. Los datos suprimidos al terminar una suscripción desaparecen de las copias de seguridad a medida que estas caducan según su rotación habitual y, hasta entonces, no se utilizan para ninguna otra finalidad.

La aplicación escribe registros de servidor y mantiene, por espacio de trabajo, un historial de actividad que indica qué usuario cambió qué y cuándo. El historial es consultable por el suscriptor dentro de la aplicación.

Los registros de servidor, de aplicación y de seguridad se conservan 90 días, salvo que una entrada concreta deba conservarse más tiempo por una investigación de seguridad en curso.

Los registros existen para operar el servicio e investigar incidentes. No registramos contraseñas, tokens de sesión ni datos de tarjetas de pago.

El acceso a los sistemas y a los datos de producción se limita al personal que lo necesita para la operación o el soporte, conforme al principio de mínimo privilegio y bajo un deber de confidencialidad que subsiste tras el fin de su relación.

Las dependencias de terceros están fijadas a versiones concretas y se gestionan de forma centralizada, de modo que una versión se cambia en un solo lugar; aplicamos las actualizaciones de seguridad de la plataforma y de sus dependencias en cuanto están disponibles.

Los cambios en el esquema de la base de datos se aplican como migraciones versionadas al arrancar el servicio, de modo que el esquema en producción siempre coincide con el código que se ejecuta sobre él.

Los proveedores que tratan datos por cuenta nuestra —alojamiento, almacenamiento de objetos, entrega de correo, pago y facturación— se nombran, con su función y su región, en la sección 5 de la información sobre el RGPD y en la sección 8 de la información sobre el encargo del tratamiento.

Un nuevo proveedor se anuncia al menos 30 días antes de que comience el tratamiento, para que el suscriptor que se oponga tenga tiempo de actuar.

Llevamos un registro interno de violaciones de la seguridad de los datos personales y seguimos un procedimiento que cubre la detección, la evaluación, la contención y la notificación.

Cuando una violación entrañe probablemente un riesgo para los derechos y libertades de las personas físicas, la notificamos a la autoridad de control competente sin dilación indebida y, de ser posible, en el plazo de 72 horas desde que tenemos conocimiento de ella (art. 33 del RGPD); si el riesgo es alto, informamos además a los afectados en lenguaje claro (art. 34 del RGPD).

Cuando actuamos como encargados, informamos al suscriptor que actúa como responsable sin dilación indebida tras tener conocimiento de la violación y le asistimos en sus propias obligaciones de notificación.

Ningún servicio en línea puede hacerse absolutamente seguro. Esta página describe medidas, no garantías, y los Términos y Condiciones no incluyen compromiso alguno de disponibilidad ni de nivel de servicio.

No contamos con certificación ISO/IEC 27001 ni con informe SOC 2, y el servicio no se ha sometido a una prueba de intrusión independiente. Si algo de esto cambia, se indicará en esta sección.

La autenticación de doble factor para las cuentas de usuario todavía no está disponible. La seguridad de la cuenta descansa por tanto en la solidez de la contraseña, el bloqueo de la cuenta y los límites descritos más arriba, y por eso pedimos una contraseña que no se utilice en ningún otro sitio.

El servicio funciona en una sola región, sin conmutación entre regiones: si esa región falla, el servicio no está disponible hasta que se restablezca. Lo indicamos porque una declaración de seguridad que solo enumera fortalezas no sirve para fundamentar una decisión.

Si encuentra una vulnerabilidad, escriba a info@ravsolutions.eu con la descripción, los pasos para reproducirla y la dirección afectada. Confirmamos la recepción y le decimos cómo pensamos tratarla.

Le pedimos que nos dé una oportunidad razonable de corregir el problema antes de hacerlo público. Durante las pruebas, no acceda a datos que no sean suyos, no los modifique ni los borre, no degrade el servicio para los demás y no emplee ingeniería social contra nuestro personal ni contra nuestros proveedores.

No mantenemos un programa retribuido de recompensas por errores. No emprenderemos acciones contra quien comunique de buena fe y dentro de los límites anteriores.

Mantenemos esta declaración actualizada junto con el servicio. El número de versión y la fecha de entrada en vigor de la parte superior de la página indican qué texto está vigente; las versiones anteriores están disponibles previa solicitud.

Cuando cambia una de las medidas descritas aquí, esta página cambia con ella. Las preguntas sobre su contenido pueden dirigirse a info@ravsolutions.eu.