Seguridad
Seguridad que se puede auditar, no solo prometer
Aislamiento por colegio impuesto por el motor de base de datos y no por el código de la aplicación, contenido servido con enlaces firmados de sesenta segundos, y registro de auditoría de toda mutación relevante.
El principio
El control vive en el motor, no en el código
La forma habitual de aislar colegios en un producto multi-institución es que cada consulta filtre por el identificador de la institución. Funciona hasta que una consulta olvida el filtro, y entonces un colegio ve los datos de otro.
Aquí el filtro no lo escribe la aplicación: lo impone Postgres con seguridad a nivel de fila. Cada tabla de negocio tiene su política, la sesión de cada petición lleva el colegio y el usuario, y una consulta descuidada simplemente no recibe las filas ajenas. No es que la aplicación se porte bien: es que no puede portarse mal.
Las reglas
Seis decisiones que no se negocian
Sin prueba de aislamiento, no entra
Una tabla nueva necesita su política y una prueba que demuestre que el colegio A no ve al B. Es una regla de aceptación de código, no una recomendación.
El acceso a un libro nunca lo decide el cliente
Siempre lo resuelve una función del motor, libro por libro y persona por persona. El navegador no puede concederse acceso a nada.
Ninguna dirección de contenido es pública
Los enlaces al material van firmados, duran sesenta segundos y quedan ligados al usuario y a su dispositivo. Un enlace filtrado caduca antes de llegar a un grupo de WhatsApp.
Toda mutación relevante queda registrada
Quién, qué, cuándo y contra qué. La bitácora es de solo agregar: no se edita ni se borra, porque una auditoría que se puede reescribir no es una auditoría.
Los procesos automáticos también rinden cuentas
Las tareas que corren con privilegios elevados están confinadas a un solo paquete del código y cada una escribe su rastro. Fuera de ahí, ese privilegio no existe.
El PIN de un menor no se puede leer
Se guarda con función de derivación de clave y su tabla está cerrada a lectura. Un espacio de diez mil combinaciones que se pudiera consultar sería un PIN reversible sin intentar un solo ingreso.
Las pruebas de aislamiento se ejecutan contra un Postgres de verdad y conectadas como un usuario real, no con simulaciones. Una prueba que simula el aislamiento pasa siempre y no protege de nada.
Cómo se comprueba
Que falle por la razón correcta, no solo que falle
Una prueba que espera un error puede pasar por el motivo equivocado: un nombre de tabla mal escrito también lanza una excepción. Por eso, en las verificaciones de seguridad comprobamos qué error exactamente devuelve el motor.
En el módulo de inglés, por ejemplo, hay seis intentos de escritura que deben fracasar. Cuatro fracasan con «permiso denegado sobre la tabla» —el privilegio nunca se otorgó— y dos con «la fila viola la política de seguridad» —el privilegio existe pero la política la rechaza—. Las dos capas responden, y eso se verifica en vez de suponerse.
Preguntas de un área de sistemas
Lo técnico, sin rodeos
¿Qué pasa si un estudiante manipula el navegador?
¿Un alumno puede subirse el nivel de inglés?
¿Cómo se autentica un adulto?
¿Hay integración con el sistema académico del colegio?
¿Dónde corre y quién lo opera?
Abrimos pronto para su colegio
Todavía no se pueden crear cuentas ni agendar demostraciones. Mientras tanto, los libros y la forma de trabajar ya se pueden ver aquí.