Recomendaciones de seguridad a nivel de fila

La seguridad a nivel de fila (RLS) es necesaria para mantener el aislamiento de los datos de los inquilinos en un modelo agrupado con PostgreSQL. El RLS centraliza la aplicación de las políticas de aislamiento a nivel de base de datos y elimina la carga que supone mantener este aislamiento para los desarrolladores de software. La forma más común de implementar RLS es habilitar esta función en el DBMS de PostgreSQL. El RLS implica filtrar el acceso a las filas de datos en función de un valor de una columna específica. Puede utilizar dos métodos para filtrar el acceso a los datos:

• Una columna de datos específica de una tabla se compara con el valor del usuario actual de PostgreSQL. Los valores de la columna que son equivalentes a los del usuario de PostgreSQL que ha iniciado sesión son accesibles para ese usuario.

• Una columna de datos específica de una tabla se compara con el valor de una variable de tiempo de ejecución establecida por la aplicación. Durante esa sesión, se puede acceder a los valores de la columna que son equivalentes a la variable de tiempo de ejecución.

Se prefiere la segunda opción, ya que la primera requiere la creación de un nuevo usuario de PostgreSQL para cada inquilino. En cambio, una aplicación SaaS que utilice PostgreSQL debería ser responsable de establecer un contexto específico del inquilino en tiempo de ejecución cuando consulte PostgreSQL. Esto tendrá el efecto de aplicar el RLS. También puede habilitar el RLS de forma periódica. table-by-table Como práctica recomendada, debe habilitar el RLS en todas las tablas que contengan datos de inquilinos.

En el siguiente ejemplo, se crean dos tablas y se habilita el RLS. En este ejemplo, se compara una columna de datos con el valor de la variable app.current_tenant de tiempo de ejecución.

-- Create a table for our tenants with indexes on the primary key and the tenant’s name
CREATE TABLE tenant (
    tenant_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name VARCHAR(255) UNIQUE,
    status VARCHAR(64) CHECK (status IN ('active', 'suspended', 'disabled')),
    tier VARCHAR(64) CHECK (tier IN ('gold', 'silver', 'bronze'))
);
 
-- Create a table for users of a tenant
CREATE TABLE tenant_user (
    user_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenant (tenant_id) ON DELETE RESTRICT,
    email VARCHAR(255) NOT NULL UNIQUE,
    given_name VARCHAR(255) NOT NULL CHECK (given_name <> ''),
    family_name VARCHAR(255) NOT NULL CHECK (family_name <> '')
);
 
-- Turn on RLS
ALTER TABLE tenant ENABLE ROW LEVEL SECURITY;
 
-- Restrict read and write actions so tenants can only see their rows
-- Cast the UUID value in tenant_id to match the type current_setting
-- This policy implies a WITH CHECK that matches the USING clause
CREATE POLICY tenant_isolation_policy ON tenant
USING (tenant_id = current_setting('app.current_tenant')::UUID);
 
-- And do the same for the tenant users
ALTER TABLE tenant_user ENABLE ROW LEVEL SECURITY;
 
CREATE POLICY tenant_user_isolation_policy ON tenant_user
USING (tenant_id = current_setting('app.current_tenant')::UUID);

Para obtener más información, consulte la entrada del blog Aislamiento de datos de múltiples inquilinos con seguridad a nivel de fila de PostgreSQL. El equipo de AWS SaaS Factory también tiene algunos ejemplos GitHub para ayudar a implementar el RLS.