Recommandations de sécurité au niveau des lignes - AWS Conseils prescriptifs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Recommandations de sécurité au niveau des lignes

La sécurité au niveau des lignes (RLS) est requise pour maintenir l'isolation des données des locataires dans un modèle groupé avec PostgreSQL. RLS centralise l'application des politiques d'isolation au niveau de la base de données et décharge les développeurs de logiciels de la charge que représente le maintien de cette isolation. La méthode la plus courante pour implémenter RLS consiste à activer cette fonctionnalité dans le SGBD PostgreSQL. Le RLS consiste à filtrer l'accès aux lignes de données en fonction d'une valeur dans une colonne spécifiée. Vous pouvez utiliser deux méthodes pour filtrer l'accès aux données :

  • Une colonne de données spécifiée dans une table est comparée à la valeur de l'utilisateur PostgreSQL actuel. Les valeurs de la colonne équivalentes à celles de l'utilisateur PostgreSQL connecté sont accessibles à cet utilisateur.

  • Une colonne de données spécifiée dans une table est comparée à la valeur d'une variable d'exécution définie par l'application. Les valeurs de la colonne équivalentes à la variable d'exécution sont accessibles pendant cette session.

La deuxième option est préférable, car la première nécessite la création d'un nouvel utilisateur PostgreSQL pour chaque locataire. Au lieu de cela, une application SaaS qui utilise PostgreSQL doit être chargée de définir un contexte spécifique au locataire lors de l'exécution lorsqu'elle interroge PostgreSQL. Cela aura pour effet de faire appliquer le RLS. Vous pouvez également activer le RLS sur une table-by-table base. Il est recommandé d'activer le protocole RLS sur toutes les tables contenant des données relatives aux locataires.

L'exemple suivant crée deux tables et active le protocole RLS. Cet exemple compare une colonne de données à la valeur de la variable d'exécutionapp.current_tenant.

-- 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);

Pour plus d'informations, consultez le billet de blog Isolation des données multi-locataires avec PostgreSQL Row Level Security. L'équipe de AWS SaaS Factory a également quelques exemples GitHub pour vous aider à mettre en œuvre le RLS.