SQL Academy · Lección

Políticas de seguridad a nivel de fila

Filtre automáticamente las filas por usuario

Políticas de seguridad a nivel de fila es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Academy incluye 4 lecciones en total.

¿Qué es la seguridad a nivel de fila?

La seguridad a nivel de fila (RLS) es una función de PostgreSQL que permite controlar qué filas de una tabla puede ver o modificar un usuario o rol de la base de datos determinado. En lugar de filtrar las filas en cada consulta, puede definir una política una sola vez y PostgreSQL la aplica automáticamente en cada operación SELECT, INSERT, UPDATE y DELETE.

Puede imaginarla como una cláusula WHERE invisible vinculada a la propia tabla, en lugar de a una consulta específica.

Habilitar RLS en una tabla

RLS está deshabilitada de forma predeterminada. Debe activarla explícitamente en cada tabla mediante ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Una vez habilitada, cualquier rol que no sea el propietario de la tabla no verá ninguna fila hasta que se cree al menos una política.

-- Create a sample table
CREATE TABLE orders (
  id        SERIAL PRIMARY KEY,
  owner     TEXT NOT NULL,
  amount    NUMERIC(10,2)
);

-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

Crear su primera política

Una política se crea con CREATE POLICY. Debe asignarle un nombre, especificar la tabla y proporcionar una expresión USING. La cláusula USING es una expresión booleana que se evalúa para cada fila; solo serán visibles para el usuario las filas cuya expresión devuelva TRUE.

-- Allow each user to see only their own orders
CREATE POLICY orders_owner_policy
  ON orders
  FOR SELECT
  USING (owner = current_user);

Las cláusulas USING frente a WITH CHECK

Las políticas tienen dos cláusulas de filtrado que cumplen funciones diferentes:

USING — filtra filas en operaciones de lectura (SELECT, UPDATE, DELETE). Una fila solo es visible si USING devuelve TRUE.
WITH CHECK — valida filas en operaciones de escritura (INSERT, UPDATE). Una escritura solo se permite si WITH CHECK devuelve TRUE. Si se omite, USING se reutiliza para las comprobaciones de escritura.

-- Allow users to select and insert only their own rows
CREATE POLICY orders_isolation
  ON orders
  FOR ALL
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Ámbito de las políticas: FOR SELECT, INSERT, UPDATE, DELETE

Una sola política puede abarcar todos los comandos (FOR ALL) o uno específico. Separar las políticas por comando le proporciona un control detallado; por ejemplo, permitir que todos los usuarios lean todas las filas, pero que solo puedan modificar las suyas.

-- Everyone can read all orders
CREATE POLICY read_all_orders
  ON orders
  FOR SELECT
  USING (true);

-- But each user can only update their own orders
CREATE POLICY update_own_orders
  ON orders
  FOR UPDATE
  USING       (owner = current_user)
  WITH CHECK  (owner = current_user);

Uso de session_user y current_user

PostgreSQL proporciona funciones integradas para identificar al usuario activo dentro de una expresión de política:

current_user — el rol cuyos privilegios están activos en ese momento (puede cambiar después de SET ROLE).
session_user — el rol que abrió la conexión (no cambia durante la sesión).

La mayoría de las políticas de RLS se basan en current_user porque refleja el rol efectivo después de cambiar de rol.

-- Inspect the current identity inside a query
SELECT current_user, session_user;

Aplicación de RLS a roles específicos

De forma predeterminada, una política se aplica a PUBLIC (todos los roles). Puede restringirla a un rol específico mediante la cláusula TO. Esto resulta útil cuando desea una política para los usuarios normales y otra diferente para un rol de administrador.

-- Policy only for the 'app_user' role
CREATE POLICY app_user_policy
  ON orders
  FOR SELECT
  TO app_user
  USING (owner = current_user);

-- Separate permissive policy for 'admin' role
CREATE POLICY admin_full_access
  ON orders
  FOR ALL
  TO admin
  USING (true)
  WITH CHECK (true);

Políticas permisivas frente a restrictivas

Varias políticas de la misma tabla pueden interactuar de dos maneras:

PERMISSIVE (predeterminada) — todas las políticas permisivas se combinan con OR. Una fila es accesible si cualquiera de las políticas permisivas lo permite.
RESTRICTIVE — las políticas restrictivas se combinan mediante AND con el resultado de las políticas permisivas. Una fila es accesible solo si supera la política restrictiva y al menos una política permisiva.

-- Restrictive policy: block access to archived orders for everyone
CREATE POLICY no_archived_rows
  ON orders
  AS RESTRICTIVE
  FOR SELECT
  USING (amount > 0);

Cómo omitir RLS: BYPASSRLS y propietarios de tablas

De forma predeterminada, el propietario de la tabla y los superusuarios omiten RLS y siempre ven todas las filas. Puede conceder el atributo BYPASSRLS a un rol si necesita acceso sin restricciones sin ser superusuario. Por el contrario, puede obligar al propietario a respetar RLS mediante FORCE ROW LEVEL SECURITY.

-- Force the table owner to also obey RLS policies
ALTER TABLE orders FORCE ROW LEVEL SECURITY;

-- Grant BYPASSRLS to a trusted service account
ALTER ROLE service_account BYPASSRLS;

Modificación y eliminación de políticas

Puede actualizar una política existente con ALTER POLICY o eliminarla por completo con DROP POLICY. Eliminar todas las políticas mientras RLS sigue habilitado significa que ningún rol que no sea el propietario podrá acceder a las filas. Para eliminar RLS por completo, deshabilítelo con ALTER TABLE.

-- Rename a policy
ALTER POLICY orders_owner_policy ON orders
  RENAME TO user_isolation_policy;

-- Update the USING expression
ALTER POLICY user_isolation_policy ON orders
  USING (owner = current_user AND amount >= 0);

-- Remove a policy
DROP POLICY admin_full_access ON orders;

-- Disable RLS entirely on the table
ALTER TABLE orders DISABLE ROW LEVEL SECURITY;

Patrón del mundo real: aislamiento de datos multiinquilino

Un patrón común de RLS en aplicaciones SaaS multiinquilino consiste en almacenar una columna tenant_id en cada tabla y utilizar una variable de sesión (set_config) para pasar el identificador del inquilino al establecer la conexión. A continuación, la política compara el tenant_id de cada fila con ese valor.

-- Table with tenant isolation column
CREATE TABLE documents (
  id         SERIAL PRIMARY KEY,
  tenant_id  TEXT NOT NULL,
  title      TEXT
);

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Policy reads the tenant from a session variable
CREATE POLICY tenant_isolation
  ON documents
  FOR ALL
  USING       (tenant_id = current_setting('app.tenant_id'))
  WITH CHECK  (tenant_id = current_setting('app.tenant_id'));

-- Application sets the variable before running queries
SELECT set_config('app.tenant_id', 'tenant_42', true);

-- Now only tenant_42 documents are visible
SELECT * FROM documents;

Comprobación de conocimientos

Compruebe su comprensión de las políticas de Row-Level Security en PostgreSQL.

Resumen de la lección

En esta lección ha aprendido cómo Row-Level Security proporciona un filtrado automático de filas basado en políticas directamente en el nivel de la base de datos:

Habilitar RLS en una tabla con ALTER TABLE ... ENABLE ROW LEVEL SECURITY.
Usar CREATE POLICY con una cláusula USING para filtrar las filas legibles y una cláusula WITH CHECK para validar las filas escritas.
Limitar las políticas a comandos específicos (SELECT, INSERT, UPDATE, DELETE, ALL) y roles específicos mediante la cláusula TO.
Combinar políticas PERMISSIVE (lógica OR) y RESTRICTIVE (lógica AND) para implementar un control de acceso por capas.
Los propietarios de tablas y los superusuarios omiten RLS de forma predeterminada; use FORCE ROW LEVEL SECURITY para anular este comportamiento.
El patrón multiinquilino que utiliza current_setting() es una aplicación práctica y potente de RLS.

RLS es la forma estándar de imponer el aislamiento de datos de manera limpia y coherente, sin dispersar cláusulas WHERE por todas las consultas de la aplicación.

Preguntas frecuentes

¿La lección «Políticas de seguridad a nivel de fila» es gratis?

Sí — el texto completo de «Políticas de seguridad a nivel de fila» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Academy, actualiza a CoddyKit PRO. El curso de SQL Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Políticas de seguridad a nivel de fila»?

Filtre automáticamente las filas por usuario Practicas SQL Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar SQL Academy?

No se requiere experiencia previa. SQL Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Políticas de seguridad a nivel de fila»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de SQL Academy?

Sí. Cada lección de SQL Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

← Volver a SQL Academy