Seguridad a nivel de fila — AiHummer Documentos

AiHummer es multitenant, y su límite de aislamiento más fuerte se encuentra en la propia base de datos: Seguridad a Nivel de Fila (RLS) en PostgreSQL. Con RLS habilitado, la base de datos —no solo el código de la aplicación— hace cumplir que una consulta únicamente vea las filas que pertenecen al inquilino actual.

Nivel: La seguridad a nivel de fila está limitada por el pago Empresa nivel — no forma parte de la plataforma gratuita/Comunidad.

Por qué RLS

Filtrado a nivel de aplicación (WHERE tenant_id = ...) es necesario pero frágil: una sola cláusula olvidada puede filtrar datos entre inquilinos. RLS traslada la garantía a PostgreSQL, de modo que incluso una consulta sin filtrar devuelve solo las filas del inquilino actual. Es una capa de defensa en profundidad debajo del propio alcance de la aplicación. Para el modelo de multitenencia más amplio —y cómo se combina con efectos secundarios idempotentes— vea Multialojamiento e idempotencia.

El rol restringido (opción de suscripción)

RLS es optar por participar y se activa al dar al gateway una segunda conexión de base de datos que utiliza un rol restringido en lugar del propietario:

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

la aihummer_app rol es no el propietario de la tabla, por lo que PostgreSQL aplica políticas RLS a ella. Las consultas de la aplicación pasan por este conjunto restringido. Habilitar RLS es cuestión de configurar AIHUMMER_DB_APP_URL — y las instalaciones locales/estándar (nativas del host) configuran esa variable automáticamente, por lo que RLS está activo desde el principio. Es “de opción” solo en el sentido de que una implementación personalizada o manual debe configurarlo AIHUMMER_DB_APP_URL sí mismo.

[!NOTE] Sin AIHUMMER_DB_APP_URL, la puerta de enlace utiliza la reserva del propietario para todo y la RLS no se aplica efectivamente. Configure el grupo restringido (que el instalador estándar hace por ti) para activar el aislamiento a nivel de base de datos.

[!IMPORTANT] RLS no depende del plan. Funciona igual en todos los planes, incluido Community. Si la pantalla de licencia muestra «Seguridad a nivel de fila» como no disponible, es una imprecisión de esa pantalla y no el estado de su base de datos.

Dónde RLS ya está activo y dónde hay que activarlo

Cómo instaló	Estado de RLS tras la instalación
Instalación estándar, el instalador despliega PostgreSQL	Activo. El rol restringido y `AIHUMMER_DB_APP_URL` se crean solos
PostgreSQL propio o gestionado (dirección de la base indicada)	Inactivo. Usted crea el rol y define `AIHUMMER_DB_APP_URL`
Instalación sin permisos de administrador (rootless)	Inactivo. Lo mismo

[!WARNING] Dos errores que dejan RLS «activado» sin proteger nada. Primero: AIHUMMER_DB_APP_URL apunta al propietario de las tablas o a un superusuario — PostgreSQL exime a esos roles de las políticas y la pasarela seguirá informando de que RLS está activo. Use un rol restringido aparte. Segundo: en su propio PostgreSQL el rol restringido puede crearse automáticamente con una contraseña previsible — asígnele una contraseña propia antes de que la base sea accesible por la red.

Alcance por inquilino

Dentro de una solicitud, la aplicación establece el inquilino actual en la conexión antes de ejecutar consultas con alcance de inquilino, conceptualmente db.WithTenant. Una vez delimitadas, las políticas RLS sobre el rol restringido limitan cada lectura y escritura a las filas de ese inquilino. El alcance está vinculado a la unidad de trabajo, por lo que no se filtra entre solicitudes concurrentes.

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

Modo de sistema / bypass para trabajadores

Parte del trabajo es legítimamente interinquilino o independiente del inquilino: trabajadores en segundo plano, planificadores, recuperación de entregas y mantenimiento similar. Para estos, la puerta de enlace utiliza un modo de sistema (omitir) que se ejecuta en el grupo de propietarios, fuera de las políticas RLS por inquilino, para que las tareas de infraestructura puedan operar en todo el conjunto de datos.

[!WARNING] El modo de omisión es solo para trabajadores internos de confianza. Rutas de código de manejo de solicitudes ese acto en nombre de un usuario siempre debe ejecutarse a través del restringido, piscina con alcance de inquilino — nunca el camino de bypass.

Las migraciones se ejecutan en el grupo del propietario

Los cambios en el esquema requieren privilegios que el rol restringido no tiene, por lo que las migraciones siempre se ejecutan en el grupo propietario (AIHUMMER_DATABASE_URL), bajo un bloqueo consultivo, al iniciar. El restringido aihummer_app El rol se utiliza solo para el tráfico de aplicaciones ordinario. Esto mantiene la separación de privilegios limpia: las operaciones que cambian el esquema usan el propietario; el acceso a los datos del inquilino usa el rol restringido con RLS aplicado.

¿A dónde vamos ahora?

Multialojamiento e idempotencia — el modelo completo de inquilino y cómo los efectos secundarios permanecen seguros durante la recuperación.
Bóveda de secretos — los DEK por inquilino refuerzan lo mismo aislamiento en la capa de secretos.
RBAC y claves API con alcance — autorización por encima de la capa de datos.