Seguridad, backups y estado
Una revisión interna estática del 2026-10-18 (sin ejecutar código) concluyó que Plurabase no está listo para clientes, ni siquiera para los datos reales del propio dueño. Las razones principales: el piloto no tiene backups, ninguna alerta llega a una persona cuando algo falla, el piloto no está abierto al público, así que el operador sigue admitiendo cada cuenta, y corre en una máquina virtual KVM en un servidor dedicado. No guardes en el piloto datos que no puedas perder. La página de datos tiene el estado de cada capacidad.
Lo que ya existe
- Solo red privada. El piloto solo es accesible por Tailscale desde dispositivos que admite el operador. Nada está expuesto a Internet.
- Cuentas de la plataforma en el piloto. El registro con verificación de correo, MFA TOTP, restablecimiento de contraseña y códigos de recuperación corre sobre los endpoints nativos de GoTrue con sesiones guardadas en el servidor (ADR-0018). Su correo sale por el proveedor del operador. El piloto no está abierto al público, así que el operador admite cada cuenta.
- Roles comprobados en cada petición. La consola, la API de administración, el acceso a Studio, el servidor MCP y Sites comprueban el rol actual de quien llama en la organización y el proyecto. Esa revisión leyó el código y no encontró ningún camino para que un miembro
developeroread_onlyobtenga claves service-role, SQL privilegiado o secretos. No intentó explotar el proxy de API de cada proyecto, los handlers de Git ni la autorización del SQL compartido. - Tokens de agente ligados a un proyecto. Los tokens MCP nombran un proyecto, vencen en 24 horas o 7 días, se pueden restringir o revocar desde la consola y se comparan con el rol actual del miembro en cada llamada. Las herramientas de escritura exigen un
operation_id, y un resultado incierto detiene nuevas escrituras hasta que el operador lo concilia. - Aislamiento por proyecto. Cada proyecto tiene sus propias credenciales de PostgreSQL, su red interna de contenedores y límites de memoria, CPU y procesos. Los puertos de la base de datos no se publican.
- Los frontends no alcanzan secretos. Un Site recibe solo la clave publicable. Los ZIP los decodifica un proceso sin privilegios que rechaza path traversal, enlaces, archivos especiales y tamaños falsificados. El código del Site corre en un origen opaco y no puede leer cookies de la consola.
Lo que falta
Backups
Estado: En desarrollo (ops.backups)
Hoy no se hace ningún backup. Los backups lógicos diarios cifrados hacia un almacenamiento fuera del host, con simulacro de restauración en otra máquina y alertas de hombre muerto (ADR-0020), están escritos y esperan su primera ejecución nativa, igual que un observador de salud de la operación que informa servicios caídos, poco disco o memoria, un certificado por vencer y backups atrasados a su propia comprobación externa (ADR-0031).
Recuperación a un punto en el tiempo
Estado: En desarrollo (database.pitr)
El archivado continuo de WAL en el mismo repositorio fuera del host, un backup base semanal y un simulacro que restaura un proyecto a un momento elegido en otra máquina (ADR-0031) están escritos y esperan su primera ejecución nativa. Requieren que antes estén activados los backups diarios. Hasta que se ejecuten, una base de datos perdida o dañada no se puede devolver a un momento anterior.
Rotación de claves
Estado: En desarrollo (projects.key-rotation)
En el host del piloto, los owners y admins pueden ver la clave secreta de un proyecto y su credencial de Studio, y nada las rota. Alguien a quien se retira de un equipo puede conservar secretos que ya vio. Los cambios de rol se aplican a las peticiones nuevas en segundos, no a secretos ya copiados.
La rotación de claves está escrita y no desplegada (ADR-0030). Un owner o admin rota la clave secreta, los JWT de servicio y la credencial de Studio de un proyecto desde la consola, y retirar o degradar a un owner o admin rota los proyectos que perdió, como mucho una vez cada 5 minutos por proyecto. Una rotación termina solo cuando el gateway, PostgREST, GoTrue y Storage rechazan cada uno las claves antiguas. También retira el JWT anon heredado, así que las versiones publicadas de Sites y los builds que lo incluyen dejan de responder hasta que se vuelven a publicar; los clientes que usan la clave publicable siguen funcionando. El mismo código deja de mostrar la credencial de Studio en la consola. Las contraseñas de la base de datos no se rotan, y lo que creó un admin retirado se queda.
Clientes hostiles
El aislamiento entre proyectos se ha revisado y probado en parte, pero no se ha atacado con cargas hostiles. El código de build no confiable debe correr en una máquina virtual aislada; ese camino no está activo. Un perfil de contenedor más estricto para los servicios de cada proyecto (sin capacidades de Linux innecesarias, sin archivos core, un directorio temporal acotado para las funciones) y una tabla de firewall del host que aleja las redes de los proyectos del host, del servicio de metadatos de la nube y entre sí están escritos pero apagados: el piloto no habilita ninguno hasta que pase una prueba con cargas hostiles en una máquina desechable.
Cumplimiento
Plurabase no tiene certificación SOC 2, HIPAA ni ninguna otra, y no ofrece SLA.
Recuperar un frontend
Revertir un Site cambia de inmediato la versión publicada. Nunca modifica tablas, usuarios de Auth ni migraciones, y no es un backup de la base de datos.