El backend /Seguridad y RLS
Protegido por la base de datos.
No por el middleware.
La autorización en Rebase es la seguridad a nivel de fila de Postgres, aplicada por la propia base de datos — y falla en cerrado: una tabla sin RLS se rechaza, nunca se filtra. Eso vale hoy cuando autoalojas la pila de código abierto, y vale en Rebase Cloud, que ejecuta el mismo servidor.
Revisa la base de datos que ya tienes
No hace falta que te creas nada de esto. rls-check lee el catálogo de tu propia base de datos y reporta lo que está realmente expuesto: tablas servidas con la seguridad a nivel de fila desactivada, políticas que evalúan a verdadero para todo el mundo, vistas que leen esquivando la RLS de sus tablas base. Funciona en cualquier Postgres — Supabase, Neon, RDS o tu propio servidor.
De solo lectura por construcción: abre una transacción de solo lectura y ejecuta consultas al catálogo. No escribe nada, y ningún dato sale de tu máquina.
Seguridad a nivel de fila, escrita donde está la colección
Define quién puede leer, crear, actualizar y borrar cada fila — aplicado directamente por PostgreSQL. Las políticas se escriben como código en tu esquema, se versionan y se aplican vía migraciones. Sin middleware, sin trucos del ORM. Y falla en cerrado: una tabla sin RLS no tiene modelo de autorización, así que Rebase se niega a servirla — e imprime el SQL exacto para protegerla al arrancar. No hay comprobación de auth que olvidar.
El valor por defecto
Una tabla sin política no sirve ninguna fila
La mayoría de los sistemas de esta categoría son permisivos hasta que te acuerdas de cerrarlos. Rebase va al revés: las peticiones se ejecutan como un rol restringido de Postgres que no posee nada, así que una tabla para la que olvidaste escribir una política se rechaza en vez de filtrarse.
Eso vale para todas las entradas a la vez — la API REST, el SDK tipado, el panel de administración, la clave con alcance de un agente y una sesión de psql se encuentran con las mismas políticas, porque las políticas no están en el servidor.
Sin rol que lo salte todo
El tráfico de usuario nunca se ejecuta como propietario de la tabla. No hay ninguna clave de «servicio» que apague las políticas en silencio por comodidad.
Columnas privilegiadas protegidas por defecto
A las colecciones de auth se les inyectan políticas para que un usuario no pueda ascenderse escribiendo su propia columna de roles. Salirse de eso es explícito y con nombre.
Las tablas de unión heredan sus extremos
Las uniones muchos-a-muchos son el agujero clásico. Sus políticas se derivan de ambos lados de la relación en vez de dejarse a que te acuerdes tú.
Una base de datos, sin segunda copia
Rebase habla con tu Postgres directamente y nunca ingiere tus filas en un almacén propio. Hay un solo sitio donde las políticas tienen que aguantar, y es donde viven los datos.
Puedes leerlo entero
El servidor tiene licencia MIT de principio a fin. Audita el código, inspecciona el SQL que emite y vuelve a leer las políticas desde tu propia base de datos con
rls-check.La deriva se detecta
El editor de políticas compara lo que hay en tu código con lo que hay en la base de datos y señala todo lo que se ha movido — incluidas las reglas permisivas que parecen seguras y no lo son.
Roles que tus políticas pueden leer
Define roles en tu esquema — admin, editor, lector o el rol propio que necesites. Cada rol recibe permisos granulares por colección.
Permisos por colección — SELECT, INSERT, UPDATE, DELETE por rol y por colección.
Integración con RLS — Las políticas pueden referirse al rol del usuario actual para filtrar por fila.
Autenticación JWT — Auth sin estado basada en tokens, con caducidad y refresco configurables.
Tus datos, tu infraestructura
Esta sección describe el modelo autoalojado. A diferencia de las plataformas SaaS que ingieren y controlan tus datos, el servidor Rebase de código abierto se conecta directamente a tu propia base de datos PostgreSQL, sobre infraestructura que operas tú. Si prefieres que lo ejecutemos nosotros, salta a la sección Rebase Cloud de abajo.
Sin migración de datos
Rebase introspecciona y se adapta a tu esquema existente.
Cero cautiverio de proveedor
Deja de usar Rebase cuando quieras — tus datos se quedan exactamente donde están.
Acceso directo a la infraestructura
Control total sobre tu base de datos PostgreSQL, tus copias de seguridad y tu infraestructura.
Despliega en tus términos
Ejecuta Rebase donde quieras. Sin nube propietaria obligatoria.
Tu base de datos
Ejecuta PostgreSQL donde sea — AWS RDS, Supabase, Neon, un VPS o tu propio hardware. Rebase se conecta a él; el dueño eres tú.
Tu servidor
Despliega el backend de Rebase como proceso Node.js o contenedor Docker. Railway, Render, Fly.io o hierro desnudo — tú decides.
Tus reglas
La auth, las políticas RLS y los permisos de la API viven en tu código. Revísalos en PRs, versiónalos en Git, hazlos cumplir en CI.
Dos modelos de despliegue, dos historias de seguridad
Lee esto primero — casi toda afirmación de esta página depende de cuál ejecutes. Autoalojado, nunca vemos tus datos. En Rebase Cloud lo alojamos nosotros, lo que nos convierte en encargados del tratamiento. Rebase Cloud está en beta privada: hoy ejecuta clientes reales y se abre por tandas, y todo lo de abajo describe lo que funciona ahora.
Lo ejecutas todo tú
Instalas el servidor Rebase de código abierto y lo apuntas a una base de datos PostgreSQL que es tuya. Tus datos nunca tocan nuestros servidores, no hay ningún encargado externo en el camino y tú eres el único responsable del tratamiento.
Las secciones de Soberanía de datos y Despliega en tus términos de abajo describen este modelo.
Lo ejecutamos nosotros por ti
Rebase Cloud es nuestro hosting gestionado. Alojamos tu base de datos y tu aplicación en nuestra infraestructura, lo que significa que Rebase actúa como encargado del tratamiento por cuenta tuya, con Google Cloud como subencargado. Nada en esta página finge lo contrario.
La sección de Rebase Cloud de abajo describe exactamente dónde viven esos datos y cómo están aislados.
Cuando lo alojamos nosotros, esto es lo que significa
Esta es la arquitectura que funciona hoy: tu base de datos y tu aplicación sobre infraestructura que operamos nosotros, con Rebase como encargado del tratamiento de los datos que pones en ella y tú como responsable. Rebase Cloud está en beta privada — hoy ejecuta clientes reales y se abre por tandas. Solicita acceso.
Alojado en la UE
Rebase Cloud se ejecuta en un clúster de Google Kubernetes Engine Autopilot en Google Cloud europe-west1 (Bélgica). Tu base de datos y los contenedores de tu aplicación corren allí. Rebase Cloud no ofrece de momento elección de región.
Encargado y subencargado
Tú eres el responsable del tratamiento de los datos que tus usuarios ponen en tu proyecto. Rebase es el encargado, y Google Cloud es subencargado porque aporta el cómputo, el almacenamiento y la red sobre los que corre Rebase Cloud.
Una base de datos por cliente
Esto no es multi-tenancy de esquema compartido. Cada proyecto tiene su propia base de datos PostgreSQL — no hay una columna tenant_id que te separe de otro cliente, y una conexión está ligada a una sola base de datos, así que una lectura entre inquilinos es inalcanzable en vez de estar solo limitada por políticas. Esa base de datos es un clúster CloudNativePG propio, en su propio namespace de Kubernetes y con sus propias copias de seguridad — no una base de datos en un clúster compartido con otros clientes.
Aislamiento de red entre clientes
Cada namespace de cliente se crea con una NetworkPolicy de Kubernetes que cubre entrada y salida, así que los pods de un proyecto no pueden abrir conexiones a los pods o la base de datos de otro. Las aplicaciones de cliente se sirven desde *.rebase.website — un dominio registrable aparte, que a propósito nunca comparte con la consola, para que las fronteras de cookies y same-site del navegador caigan entre ellos.
Cifrado en tránsito y de los secretos
El tráfico a la consola y a cada dominio de cliente se sirve por TLS, con certificados emitidos automáticamente (Let's Encrypt vía cert-manager para los dominios de cliente). Los secretos que el plano de control guarda por ti — variables de entorno del proyecto, cadenas de conexión, credenciales del clúster, credenciales de copia de seguridad — se cifran en reposo con AES-256-GCM. El plano de control se niega a arrancar sin una clave de cifrado válida; no hay respaldo en texto plano.
Copias nocturnas, retención de 30 días
Las bases de datos gestionadas se aprovisionan con una copia base nocturna más archivado continuo del write-ahead log a almacenamiento de objetos, bajo una política de retención de 30 días — que es también lo que hace posible la recuperación a un punto en el tiempo. El estado de las copias se reporta por proyecto en la consola, para que veas si el archivado está funcionando de verdad en vez de suponerlo.
Rebase Cloud también podrá conectarse a una base de datos PostgreSQL que ya sea tuya en vez de aprovisionar una. En ese caso la base de datos queda enteramente bajo tu control y las notas de arriba sobre la base gestionada — aislamiento, copias, retención — no le aplican.
Dónde estás con el RGPD
La respuesta cambia según el modelo de despliegue, así que aquí están los dos.
Tú eres el responsable, y el único encargado
- Ningún encargado externo implicado. El software corre en tu infraestructura; no recibimos ningún dato de cliente.
- Acceso directo a los datos. Atiende las solicitudes de acceso y supresión desde tu propia base de datos — sin ticket de soporte, sin proveedor en medio.
- La residencia la eliges tú. Despliega PostgreSQL en la región que exijan tus obligaciones.
Tú eres el responsable, nosotros tu encargado
- Rebase trata los datos siguiendo tus instrucciones. Tú sigues siendo el responsable de los datos de tus usuarios finales.
- Google Cloud es subencargado, y aporta el cómputo, el almacenamiento y la red en europe-west1 (Bélgica).
- Los datos se quedan en la UE por defecto, porque es la única región en la que Rebase Cloud aprovisiona.
¿Necesitas un acuerdo de encargo de tratamiento firmado o una lista formal de subencargados antes de poder comprar? Escribe a sales@rebase.pro y te diremos honestamente por dónde va ese papeleo.
¿Has encontrado una vulnerabilidad?
Repórtalo en privado a security@rebase.pro. Por favor no abras una incidencia pública en GitHub por un problema de seguridad, y danos la oportunidad de publicar una corrección antes de divulgarlo. Aspiramos a acusar recibo en unos pocos días laborables.
Lee las políticas que escribe.
Genera un proyecto e inspecciona la seguridad a nivel de fila de Postgres generada desde tus definiciones de colección — antes de confiarle nada.