1. Objetivo y alcance

Esta Política describe cómo se protege la confidencialidad, integridad y disponibilidad de los datos tratados en MakerCycle, y cómo se actúa ante un incidente de seguridad, conforme a los artículos 32 a 34 del RGPD.

Alcance: la aplicación web (makercycle.es), las aplicaciones móviles Android e iOS, y la infraestructura de datos asociada.

2. Arquitectura y proveedores

Conocer la arquitectura es necesario para entender qué protege cada medida:

• Aplicación: sitio estático servido por Netlify. No hay servidor de aplicación propio ni código de MakerCycle ejecutándose en un servidor intermedio.
• Datos y autenticación: Supabase (PostgreSQL gestionado). La aplicación habla directamente con Supabase desde el navegador usando una clave pública, y el control de acceso se aplica en la propia base de datos.
• Funciones de servidor: un número reducido de Edge Functions en Supabase para las operaciones que no pueden ejecutarse en el navegador.

La consecuencia relevante en seguridad es que el aislamiento entre usuarios no depende de código de aplicación, sino de reglas aplicadas por la base de datos (sección 3.1). No hay una capa intermedia que se pueda saltar.

3. Medidas técnicas implantadas

3.1 Aislamiento de datos entre usuarios

Es la medida principal del sistema. Todas las tablas que contienen datos de negocio tienen activado Row Level Security (RLS) de PostgreSQL, con reglas que vinculan cada fila a su propietario:

• Cada fila lleva el identificador del usuario que la creó y, opcionalmente, el del equipo con el que se comparte.
• Toda consulta, sin excepción, se filtra por esas reglas en el servidor de base de datos. Una consulta que pidiera datos ajenos no devuelve un error: devuelve cero filas.
• Las reglas se aplican igual desde la web, desde las apps móviles y desde cualquier cliente que use la clave pública, porque viven en la base de datos y no en la aplicación.

3.2 Cifrado en tránsito

• Todo el tráfico usa HTTPS con TLS, tanto hacia la web como hacia la base de datos y las funciones de servidor.
• Los certificados los emiten y renuevan automáticamente Netlify y Supabase.

3.3 Cifrado en reposo

• Los datos almacenados y las copias de seguridad están cifrados en disco por Supabase como parte de su servicio gestionado.
• Las contraseñas no las gestiona MakerCycle. Las almacena Supabase Auth con función de derivación de clave y sal por usuario. La aplicación nunca ve, procesa ni guarda una contraseña.

No aplicamos cifrado adicional campo a campo dentro de la base de datos: no aportaría protección real frente a los riesgos que nos afectan —la aplicación necesita descifrar para funcionar— y degradaría búsquedas y cálculos.

3.4 Autenticación y control de acceso

• Autenticación por email y contraseña gestionada por Supabase Auth, con confirmación de correo en el alta.
• Sesiones basadas en tokens con caducidad y renovación automática.
• Dentro de un equipo existen roles (propietario y miembro) que determinan quién puede invitar o expulsar a otros miembros.
• Las operaciones sensibles se ejecutan mediante funciones de base de datos con permisos elevados y controlados, cuyo acceso está revocado por defecto y concedido solo a usuarios autenticados. Esas funciones comprueban la identidad y la pertenencia al equipo antes de escribir.

3.5 Gestión de credenciales

• La clave de administración de la base de datos no está presente en el código de la aplicación ni en lo que se descarga el navegador. Solo se usa, cuando es imprescindible, dentro de funciones de servidor.
• Las claves de los servicios externos (proveedor de IA, envío de correo) viven exclusivamente como variables de entorno del servidor y nunca llegan al cliente.
• Las funciones de servidor verifican la sesión del usuario antes de hacer nada.

3.6 Cabeceras de seguridad del navegador

Servidas en todas las páginas:

• Content-Security-Policy: restringe desde qué orígenes puede cargarse contenido y a qué servidores puede conectarse la página.
• X-Frame-Options: impide que la aplicación se incruste en sitios de terceros (protección frente a clickjacking).
• X-Content-Type-Options: evita la interpretación de un fichero como un tipo distinto del declarado.
• Referrer-Policy: limita la información de procedencia que se envía al navegar fuera del sitio.
• Permissions-Policy: deniega por defecto el acceso a cámara, micrófono y geolocalización.

3.7 Protección frente a ataques habituales

• Inyección SQL: no se construye SQL concatenando texto. El acceso se hace mediante una capa que genera consultas parametrizadas.
• Cross-Site Scripting (XSS): la interfaz está construida con React, que escapa por defecto el contenido que inserta, reforzado por la Content-Security-Policy.
• Autorización: cubierta por RLS (3.1), que actúa aunque una comprobación de la interfaz fallara.

3.8 Copias de seguridad

• Supabase realiza copias de seguridad automáticas de la base de datos, cifradas, con la periodicidad y el plazo de conservación correspondientes al plan contratado.
• La restauración se realiza a través de las herramientas del proveedor.

3.9 Minimización en las funciones de inteligencia artificial

Las funciones de IA (asistente y lectura de facturas) están diseñadas para no acumular datos:

• El documento que subes no se almacena. La imagen o el PDF de una factura viaja desde tu navegador, se procesa y se descarta. No se guarda en la base de datos ni en almacenamiento de ficheros, ni por nuestra parte ni de forma temporal.
• Las conversaciones con el asistente no se guardan. Existen en la memoria de tu navegador mientras la ventana está abierta y desaparecen al cerrarla.
• Ninguna escritura es automática. Lo que la IA extrae de una factura se te muestra para que lo revises y confirmes; nada llega a tus datos sin que lo apruebes.

Consulta la Política de Privacidad para saber qué proveedores intervienen y qué garantías se aplican.

3.10 Procesamiento local de los archivos de laminado

Los archivos que subes a la calculadora de costes (.gcode, .gcode.3mf, .bgcode, .goo, .ctb) se procesan íntegramente en tu navegador. No existe ninguna ruta de código que los transmita a un servidor: el analizador es una librería que se ejecuta en tu dispositivo y solo devuelve cifras.

• De todo el archivo, lo único que se persiste son nombre, peso, horas y cantidad, y solo cuando guardas el proyecto.
• Las miniaturas de vista previa se extraen en memoria para mostrarlas y no se guardan en ninguna tabla ni en almacenamiento de ficheros.
• La calculadora no admite archivos STL ni ningún formato de malla: el modelo 3D original nunca entra en el sistema.

Es una garantía estructural, no una promesa de intenciones: al no existir la transmisión, no hay nada que proteger, que retener ni que pueda filtrarse. Cualquiera puede comprobarlo desde su propio navegador, en la pestaña «Red» de las herramientas de desarrollo, mientras sube un archivo.

3.11 Ausencia de rastreo

MakerCycle no utiliza herramientas de analítica, publicidad, perfilado ni rastreo. No hay Google Analytics ni equivalentes. Reducir la superficie de tratamiento es también una medida de seguridad. Ver la Política de Cookies.

4. Medidas organizativas

• Acceso restringido: únicamente el responsable del tratamiento tiene acceso administrativo a los datos de producción. No hay empleados ni terceros con acceso.
• Deber de confidencialidad: asumido directamente por el responsable, sin intermediarios.
• Control de versiones: todo el código está versionado en Git con historial completo, lo que permite auditar cualquier cambio y revertirlo.
• Cambios en la base de datos: se aplican mediante ficheros de migración versionados y revisables, no mediante modificaciones manuales.
• Encargados de tratamiento: se seleccionan proveedores que ofrecen condiciones de tratamiento de datos conformes al RGPD. La relación con cada uno se detalla en la Política de Privacidad.

5. Gestión de vulnerabilidades

• Actualización de dependencias: las librerías de terceros se actualizan periódicamente, priorizando los avisos de seguridad.
• Corrección: una vulnerabilidad crítica confirmada se corrige y despliega con prioridad sobre cualquier otro trabajo.

5.1 Comunicación responsable de vulnerabilidades

Si detectas una vulnerabilidad en MakerCycle, te agradecemos que nos lo comuniques antes de hacerla pública:

• Escribe a contacto@3dmstore.es con la descripción técnica y los pasos para reproducirla.
• Acusaremos recibo en un plazo de 5 días hábiles.
• Te pedimos que no divulgues públicamente el fallo hasta que esté corregido.
• Si lo deseas, reconoceremos tu contribución cuando se publique la corrección.

No realizamos pruebas de intrusión contratadas ni disponemos de programa de recompensas. Las comunicaciones responsables son, por tanto, una vía especialmente valiosa.

6. Medidas no implantadas

Por transparencia, y porque conocerlo puede influir en tu decisión de usar el servicio, estas medidas no están disponibles hoy:

• Autenticación de doble factor (2FA): no ofrecida actualmente. Recomendamos usar una contraseña única y robusta, preferiblemente con un gestor de contraseñas.
• Monitorización continua y alertas automáticas: no hay vigilancia 24/7 ni sistemas de detección de intrusiones. La detección de incidentes depende de la revisión periódica y de los avisos de usuarios y proveedores.
• Auditorías de seguridad externas y pruebas de intrusión: no realizadas.
• Certificaciones: MakerCycle no está certificado en ISO 27001, SOC 2 ni ningún esquema equivalente. Sí lo están algunos de nuestros proveedores de infraestructura, en su propio ámbito.
• Pruebas periódicas de restauración de copias: se confía en el mecanismo del proveedor; no ejecutamos un calendario propio de simulacros de restauración.
• Objetivos comprometidos de recuperación (RTO/RPO): no ofrecemos compromisos cuantificados de tiempo de recuperación.

Esta lista se revisa cuando cambia alguna de estas circunstancias.

7. Gestión de incidentes de seguridad

7.1 Qué se considera incidente

Cualquier evento que afecte a la confidencialidad, integridad o disponibilidad de los datos o de los sistemas: acceso no autorizado, pérdida o alteración de datos, exposición indebida por un error de configuración, o indisponibilidad prolongada del servicio.

7.2 Procedimiento

1. Detección. Por revisión propia, aviso de un usuario o comunicación de un proveedor.
2. Contención. Medidas inmediatas para detener la exposición: revocar credenciales, corregir la configuración o suspender la funcionalidad afectada.
3. Evaluación. Determinar qué datos y qué personas se han visto afectados, y qué riesgo supone para sus derechos y libertades.
4. Corrección. Resolver la causa raíz y desplegar la solución.
5. Notificación. Según los criterios de la sección 7.3.
6. Registro. Documentación interna del incidente: qué ocurrió, qué datos se vieron afectados, qué se hizo y qué se ha cambiado para evitar que se repita. Este registro se mantiene aunque el incidente no sea notificable, conforme al art. 33.5 RGPD.

7.3 Notificación

7.4 Contacto

Para comunicar un incidente o una vulnerabilidad: contacto@3dmstore.es. El correo se atiende en horario laboral; los asuntos marcados como críticos tienen prioridad sobre cualquier otra comunicación.

8. Tus derechos ante un incidente

Si te ves afectado por una violación de seguridad, tienes derecho a:

• Recibir información clara sobre qué ha ocurrido y qué datos tuyos se han visto afectados.
• Recibir recomendaciones concretas para protegerte.
• Ejercer tus derechos de acceso, rectificación, supresión y portabilidad, según se detalla en la Política de Privacidad.
• Presentar una reclamación ante la Agencia Española de Protección de Datos (www.aepd.es).

9. Actualización de esta Política

Esta Política se actualiza cuando cambian las medidas implantadas, la arquitectura o los proveedores. El criterio que la rige es que toda afirmación aquí contenida debe corresponderse con una medida verificable; cuando una medida deja de estar implantada, se retira del documento.

Última actualización: agosto de 2026.