Seguridad en Inmoly

La plataforma se ejecuta sobre infraestructura europea, contratada exclusivamente con proveedores que cuentan con sus propias certificaciones de seguridad reconocidas:

• Neon — PostgreSQL en la nube (EU-West).
• OVH — servidores virtuales (data centers UE).
• Cloudflare — túnel cifrado, sin puertos TCP públicos expuestos en el servidor (ver ADR-0006).
• Vercel — hosting del frontend con CDN global y edge security.
• Cloudflare R2 — almacenamiento de imágenes y documentos en EEE.

Sin servidores en oficinas físicas ni dependencia de infraestructura on-premise. Todo el tráfico entrante atraviesa Cloudflare; el servidor de producción no acepta conexiones directas desde Internet (solo el puerto 22 está abierto, restringido por UFW).

Inmoly es una plataforma multi-tenant: muchas agencias comparten la misma infraestructura lógica, pero cada agencia ve y opera estrictamente sus propios datos.

• Cada agencia tiene un identificador único (tenantId) presente en cada tabla con datos de cliente.
• Todas las consultas a la base de datos están filtradas por tenantId. No es posible que una agencia consulte, modifique o elimine datos de otra.
• La resolución de tenant ocurre en la capa de autenticación: el JWT firmado del usuario vincula su sesión al tenantId de su agencia, validado en cada petición.
• Suites de tests automatizados verifican el aislamiento (cross-tenant isolation tests) en cada despliegue.

Los datos se cifran tanto en tránsito como en reposo:

• En tránsito: HTTPS obligatorio (TLS 1.2+), sin posibilidad de conexión en HTTP. Certificados emitidos automáticamente y rotados por Cloudflare.
• En reposo: cifrado AES-256 gestionado por el proveedor de base de datos (Neon). Las copias de seguridad heredan el mismo cifrado.
• Contraseñas: nunca se almacenan en claro. Se aplican algoritmos de hash con salt (bcrypt, factor 12).
• Tokens de sesión: firmados (JWT) y transportados exclusivamente en cookies HttpOnly / Secure para mitigar XSS.

• Autenticación obligatoria en todos los endpoints que tratan datos personales.
• Tokens JWT de corta duración con renovación automática. En la plataforma (área del agente), tokens de muy corta vida regenerados a partir de refresh tokens. En el portal de cliente, cookies HttpOnly firmadas con expiración de 24 horas por defecto, ampliable a 30 días si el usuario activa la opción «Recuérdame».
• Roles dentro de cada agencia: ADMIN (acceso total), AGENT (acceso operativo a propiedades y leads), VIEWER (solo lectura). Cada permiso se valida en el servidor en cada petición, no solo en la interfaz.
• Cookies seguras con flags HttpOnly, Secure y SameSite=Strict en producción.
• Protección anti-CSRF en todos los formularios autenticados.
• Rate limiting en endpoints de autenticación y formularios públicos para prevenir abuso.
• Política de contraseñas con longitud mínima y verificación contra listas comunes.

Cada acción que modifica datos se registra en un log de auditoría inmutable. Esto nos permite responder a preguntas como "quién modificó esta ficha y cuándo", y es la base sobre la que cumplimos las obligaciones de Art. 30 y Art. 33 del RGPD.

• Identidad del actor (userId) y de la agencia (tenantId).
• Tipo de entidad y identificador.
• Estado anterior y posterior (diff before / after).
• Marca temporal y dirección IP.

El log de auditoría es accesible para el cliente desde el panel de administración para las acciones de su agencia. La política de retención del log se publica en la Política de Privacidad.

• Snapshots automáticos de la base de datos PostgreSQL gestionados por el proveedor (Neon), con la ventana de retención asociada al plan vigente.
• Point-in-Time Recovery (PITR): capacidad de restaurar la base de datos al estado de cualquier instante dentro de la ventana de retención del plan contratado.
• Almacenamiento de objetos (imágenes, documentos) en Cloudflare R2 con redundancia gestionada por el proveedor.
• Procedimientos documentados de restauración en caso de incidente, con pruebas planificadas a medida que la organización escala.
• Despliegues con estrategia expand/contract: las migraciones de base de datos son aditivas, las destructivas se separan en deploys posteriores cuando todos los nodos ya han adoptado el nuevo modelo.

La lista completa de subencargados (Neon, Vercel, Cloudflare, Stripe, Resend, Google Vertex AI, Google Maps Platform, Sentry, Google Analytics) y su rol se publica en la Política de Privacidad y en el Anexo II del DPA.

Los cambios en la lista de subencargados se notifican a las agencias clientes con al menos 30 días de antelación. Si la agencia se opone a un nuevo subencargado, dispone de plazos contractuales para terminar el servicio sin penalización.

Aplicamos los plazos del RGPD ante incidentes de seguridad que afecten a datos personales:

• Notificación a la AEPD (Art. 33): máximo 72 horas desde el momento en que tenemos conocimiento de la brecha.
• Notificación a las personas afectadas (Art. 34): sin dilación indebida cuando la brecha entrañe un alto riesgo.
• Notificación al responsable (la agencia, en relación de Encargado de Tratamiento): 72 horas conforme al DPA §3.9.
• Registro interno de todas las brechas conforme al Art. 33.5 RGPD, aunque no requieran notificación.

Si detectas una vulnerabilidad de seguridad en Inmoly, contacta con security@inmoly.es. Agradecemos la divulgación responsable y respondemos en plazo razonable.

• RGPD (Reglamento UE 2016/679) — aplicable como responsable y como encargado del tratamiento, según corresponda.
• LOPDGDD (Ley Orgánica 3/2018) — desarrollo español del RGPD.
• LSSI-CE (Ley 34/2002) — cookies, comunicaciones comerciales, identificación del prestador.
• DPA firmado en el registro — todos los clientes aceptan el Acuerdo de Encargado de Tratamiento al crear su cuenta; queda registro inmutable con marca temporal e IP de la aceptación.
• Sin certificación ISO 27001 ni SOC 2 a fecha de hoy — son certificaciones que valoraremos cuando la escala lo justifique. Si necesitas equivalencia contractual ahora, contacta con nosotros para revisar el ámbito.