El aislamiento lo impone la base de datos, no el código de la aplicación.
Cada petición que cambia algo se autoriza tres veces, en tres sitios que fallan de forma independiente. Detrás de ellos hay 868 políticas de seguridad a nivel de fila, así que un error en un manejador es un fallo y no una fuga de datos. Esta página está escrita para quien tiene que dar su visto bueno.
Cómo protege Lurno los datos de una organización frente a los de otra
Lurno autoriza cada petición que modifica datos en tres sitios independientes. La interfaz comprueba un permiso antes de dibujar un control. El servidor exige ese mismo permiso antes de tocar los datos, y rechaza la petición si la respuesta es no. La base de datos aplica una política de seguridad a nivel de fila que decide qué filas puede devolver la consulta. Las tres tienen que pasar. Hay 868 políticas de ese tipo repartidas en 676 migraciones, y las tablas de la aplicación viven en 14 esquemas de dominio en lugar del esquema público por defecto, de modo que las filas de una organización siguen siendo inalcanzables desde la sesión de otra incluso cuando el código que hay encima está mal. Los cambios administrativos se escriben en un registro de auditoría de solo adición cuyas filas se encadenan con SHA-256 y pueden verificarse con una consulta. Augmental Learning Inc. está alineada con las prácticas de ISO 27001; no tiene certificado ISO 27001 ni informe SOC 2, y lo decimos en el cuestionario en lugar de dejar que un comprador suponga otra cosa.
- Autorización en tres puertas
- Un modelo en el que una misma petición se autoriza tres veces, mediante tres mecanismos que fallan de forma independiente. La primera puerta es la interfaz: oculta un control para el que la persona conectada no tiene permiso. La segunda es el servidor: el manejador exige el permiso antes de tocar los datos y lanza un error si la respuesta es no. La tercera es la base de datos: una política de seguridad a nivel de fila sobre la tabla restringe qué filas puede devolver la consulta. La primera puerta es comodidad, la segunda es el límite principal y la tercera es lo que sigue aguantando cuando la segunda se salta.
Tres puertas, y qué hay detrás de cada una
Una petición, autorizada tres veces
Un control de la interfaz pregunta si la persona conectada tiene un permiso antes de dibujarse. El manejador del servidor exige ese mismo permiso antes de hacer ningún trabajo. Después la base de datos aplica una política que decide qué filas puede ver la consulta. Tres mecanismos, tres sitios distintos en los que acertar, y basta con que uno diga no para que la petición termine.
- La comprobación de la interfaz es comodidad, no un límite. Oculta un botón; no protege una tabla.
- Todas las comprobaciones se resuelven a través de un solo catálogo de permisos y una sola función. Ningún manejador lee el nombre de un rol y decide por su cuenta qué significa ese rol.
- Un rol concedido en una rama del árbol de una organización desciende por esa rama, y las políticas de la base de datos leen el mismo árbol que la interfaz, de modo que las dos no pueden discrepar.
868 políticas repartidas en 676 migraciones
El aislamiento es esquema, no convención. Las tablas se crean con la seguridad a nivel de fila activada y con políticas que delegan en la misma función de permisos que llama el servidor, y una comprobación de migraciones busca tablas a las que se concedió acceso sin una política detrás. La cifra no es un dato de marketing: es lo que devuelve la base de datos cuando se le pregunta cuántas políticas está aplicando.
- Las políticas no incrustan su propia lógica. Llaman a la función de permisos, así que la respuesta no puede desviarse de lo que el servidor decidió un momento antes.
- Las políticas de escritura llevan una cláusula de comprobación además de la de lectura, de modo que una inserción no puede colocar una fila en una organización para la que quien escribe no tiene permiso.
- Cuando una vista expone datos personales, el acceso se concede columna por columna. Una concesión sobre toda la tabla anularía en silencio la protección a nivel de columna, así que no se usa.
Catorce esquemas de dominio, nunca el público
Las tablas de la aplicación viven en catorce esquemas con nombre propio: uno para identidad y accesos, uno para organizaciones, uno para medios, y así sucesivamente. Nada que importe está en el esquema público por defecto, que es el sitio donde una concesión accidental o un valor por defecto permisivo tienen más probabilidades de exponer datos. Los medios privados no tienen ninguna política de almacenamiento para navegadores autenticados: cada lectura la firma un servidor que ha comprobado antes la fila propietaria, y cada subida se emite del mismo modo.
- Los tokens de un solo uso —invitaciones, restablecimientos de contraseña, recuperación de cuenta— se guardan como hashes con sal. El token en claro se muestra una vez, en el correo, y nunca más.
- Solo la marca es pública. El logotipo y el favicon de una organización tienen que dibujarse antes de que nadie inicie sesión; los avatares y los medios de las lecciones no, así que siguen firmados.
Demostrar después qué ocurrió
Un registro de auditoría que nadie puede comprobar es un archivo de log con mejor marketing. Este es de solo adición y detecta manipulaciones, y comprobarlo es una consulta.
Un registro de solo adición
Los cambios administrativos se escriben como eventos con actor, acción, recurso, organización y una carga con el antes y el después. Nada actualiza una fila de auditoría. La ruta de escritura solo añade.
Una cadena de hashes SHA-256
Cada evento guarda el hash del anterior y un hash de sí mismo, ambos asignados por un disparador de la base de datos y no por el código que registró el evento. Cambie una fila y todos los hashes posteriores dejan de cuadrar.
Una verificación que puede ver ejecutarse
Una función de verificación recorre la cadena y señala la primera fila donde se rompe. La ejecutaremos delante de usted durante una revisión.
Revisiones de acceso
Quién tiene qué rol y en qué organización, revisado según un calendario en lugar de en el momento de la auditoría. Una retirada de acceso es un evento de auditoría como cualquier otro.
Dos personas para lo destructivo
Anonimizar o borrar a una persona es una solicitud y después una aprobación aparte. Quien solicita no puede aprobar su propia solicitud, y nadie puede tomarse a sí mismo como objetivo.
Sesiones que puede cerrar
Una persona conectada puede revocar sus otras sesiones, y una sesión revocada queda bloqueada en la siguiente comprobación de permisos, no cuando su token caduca por su cuenta.
Del consentimiento al borrado, con un reloj en cada paso
Cada inquilino es el responsable del tratamiento de los datos de sus estudiantes y Lurno es el encargado del tratamiento. La maquinaria de abajo es lo que hace que esa división sea real y no solo contractual.
- 01
Consentimiento, con una versión
Cada política a la que una persona da su consentimiento lleva una versión. Cambie la política y el consentimiento antiguo deja de contar: se vuelve a preguntar a la persona, y queda registrado a qué accedió y cuándo. El tratamiento con IA es un consentimiento aparte: retírelo y no se envía nada a ningún proveedor.
- 02
Una solicitud de acceso del interesado, como un asistente
Un administrador recorre la solicitud paso a paso en lugar de improvisarla: identificar al interesado, reunir lo que se conserva en toda la plataforma y generar la exportación. Portabilidad significa legible por máquina: JSON y CSV, no un PDF con una captura de pantalla.
- 03
Conservación con fecha de fin
Los datos personales llevan un plazo de conservación por categoría en lugar de vivir para siempre por defecto. Las cuentas inactivas, las invitaciones caducadas y las sesiones obsoletas tienen todas una fecha a partir de la cual dejan de existir.
- 04
Borrado con regla de dos personas
Un administrador lo solicita, un segundo lo aprueba y solo entonces se ejecuta. Quien solicita no puede aprobar nunca, y ninguno de los dos puede tomarse a sí mismo como objetivo. El borrado alcanza las tablas que hacen referencia a la persona, no solo la fila de su perfil.
- 05
Un registro de brechas con un reloj de 72 horas
Un incidente es una fila con un plazo calculado como 72 horas desde su descubrimiento, y recordatorios que siguen disparándose hasta que se cierra. El reloj arranca en el descubrimiento, no en el momento en que alguien se acuerda del artículo 33.
Dónde están realmente los datos
Almacenamiento de medios que puede apuntar a otro sitio
Los archivos se escriben a través de una interfaz de almacenamiento con cuatro implementaciones: Supabase Storage, Amazon S3, Azure Blob Storage y Google Cloud Storage. Esa suele ser la respuesta honesta a un requisito de ubicación: un despliegue puede escribir los archivos en un bucket de la región que usted tenga que usar, en lugar de esperar a que un proveedor abra una. Cuéntenos el requisito pronto y le diremos con claridad si hoy se cumple.
- La base de datos, la autenticación y las funciones sobre las que corre la API están alojadas en Supabase. Esa es la única dependencia que no se puede configurar de otra manera, y está nombrada en el DPA.
- Los dominios propios por organización se sirven a través de Cloudflare con certificados emitidos automáticamente, así que un estudiante en Beirut o en Milán ve su dominio, no el nuestro.
Analítica de producto en la UE, y sin los estudiantes
La analítica de la plataforma pasa por PostHog en su región de la UE, detrás de una abstracción para que el proveedor pueda sustituirse sin tocar el producto. La repetición de sesión está enmascarada y nunca graba a los estudiantes: la superficie del estudiante no está instrumentada para repetición en absoluto.
- Los campos de texto y todo lo marcado como dato personal se enmascaran en el navegador, antes de que una repetición se envíe a ningún sitio.
- La analítica está sujeta a consentimiento y desactivada salvo que una organización la active. No se perfila nada sobre un menor, en ninguna superficie.
Qué le pasa al texto antes de llegar a un proveedor de IA
El mensaje de un estudiante, un PDF subido, una pregunta escrita en el copiloto: todo eso es contenido, nada de eso es instrucción. Esa distinción se impone, no se pide en un prompt.
Clasificación de inyecciones
La entrada no confiable se clasifica antes de ejecutar la llamada real. El texto que intenta redirigir al modelo se marca en lugar de ejecutarse.
Una valla aleatorizada
El texto no confiable se envuelve en una etiqueta por petición que no puede adivinar, y esa etiqueta se elimina del propio contenido. Al truncar, la valla se vuelve a cerrar en lugar de quedar abierta.
Anonimización antes de la llamada
Los nombres, los correos y los identificadores se sustituyen antes de que nada salga hacia un proveedor. La corrección se ejecuta sobre una entrega anonimizada; la correspondencia con el estudiante se queda en nuestro servidor.
Validación del esquema de salida
Cada respuesta se valida contra un esquema. Una respuesta malformada tiene un intento de reparación y después falla, en lugar de acabar dentro de un curso.
Un rastro de la propuesta al cambio
Las peticiones, los borradores aceptados y los borradores rechazados son entradas separadas en el mismo registro encadenado por hash. Lo que sugirió el modelo queda al lado de lo que aplicó una persona.
Cómo inician sesión las personas
Escrito como lo necesita un revisor de seguridad: qué está disponible hoy y qué no.
Cuentas por invitación
Las cuentas las crea un administrador o una invitación: no hay registro de autoservicio. Los enlaces de restablecimiento y recuperación son de un solo uso y se guardan con hash.
Inicio de sesión de partner (SSO silencioso)
Un sistema partner que ya ha autenticado a alguien puede traspasarlo con una aserción firmada, de modo que el estudiante no ve nunca un segundo inicio de sesión. Se configura por organización, con clave propia y revocable.
Inicio de sesión único SAML y OIDC
En la hoja de rutaNo está construido. Si su despliegue depende de Entra ID o de Okta, dígalo en la primera llamada y le diremos en qué punto está en lugar de insinuar que ya existe.
MFA y passkeys
En la hoja de rutaTambién en la hoja de ruta. Hoy el proveedor de identidad gestiona la contraseña, las sesiones puede revocarlas su propietario y la revocación surte efecto en la siguiente comprobación de permisos.
Todos los que tocan sus datos
Cinco, y cada uno está nombrado en el acuerdo de tratamiento de datos en lugar de descubrirse después.
| Capability | De qué se encarga | Dónde se aplica |
|---|---|---|
| Supabase | Base de datos, autenticación, almacenamiento de archivos y las funciones sobre las que corre la API | El encargado principal. El almacenamiento de medios puede apuntarse a S3, Azure o GCS en su lugar. |
| Cloudflare | DNS, TLS y el dominio propio en el que se sirve cada organización | Termina el TLS de los dominios por organización; los certificados se emiten automáticamente. |
| OpenAI | Generación con IA, tutoría y borradores de corrección | Se llama solo cuando una petición lo necesita, después de anonimizar. Se pueden configurar Anthropic y Google en su lugar, y una organización puede conectar su propia clave. |
| Resend | Correo transaccional: invitaciones, notificaciones, restablecimientos | Una organización puede enviar desde su propio subdominio, con su propia clave. |
| PostHog | Analítica de producto y repetición de sesión enmascarada | Región de la UE. Las superficies de estudiante no se graban. |
La lista que rige es la del acuerdo de tratamiento de datos, junto con el anexo FERPA de privacidad de datos del alumnado para colegios. Enviamos ambos antes de una llamada, no después.
WCAG 2.1 AA, y lo que no tenemos
Lurno está construido conforme a WCAG 2.1 AA. Las comprobaciones automáticas de axe se ejecutan en integración continua, así que un fallo de contraste o una etiqueta que falta rompen una compilación en lugar de llegar a una publicación. Las rutas de teclado, el foco visible y las preferencias de movimiento reducido viven en la biblioteca de componentes, en vez de añadirse pantalla por pantalla. El producto se publica en inglés, francés, árabe e italiano, y el árabe es de derecha a izquierda de principio a fin, no un diseño de izquierda a derecha traducido.
Lo que no tenemos es un VPAT ni una auditoría de accesibilidad de un tercero, y preferimos escribirlo aquí antes que enterrarlo en la respuesta a la pregunta 47. Si un informe formal de conformidad es una condición de compra, plantéelo pronto: es una conversación de alcance, no una casilla.
Respondidas antes de que tenga que enviar el cuestionario
Las páginas a las que esta no deja de apuntar
Envíenos el cuestionario.
Casi todo está respondido arriba. Traiga el resto —ubicación de los datos, conservación, subencargados, el DPA— a una llamada, y responderemos con las mismas palabras llanas que hemos usado aquí.