Fondation de la plateforme

Isolation des tenants

Sécurité au niveau des lignes (RLS) PostgreSQL applique les frontières de tenant à chaque requête. Ni un filtre, ni une étiquette — une garantie au niveau du schéma.

Pourquoi cela compte pour les acheteurs d'entreprise

La plupart des SaaS multi-tenant isolent les tenants avec des filtres `WHERE tenant_id = ?` dans le code applicatif. Un filtre manquant, un bogue, et les données fuient. FrontLine déplace l'isolation dans la base de données : les politiques de sécurité au niveau des lignes rejettent les requêtes sans revendication de tenant, donc les bogues applicatifs ne peuvent pas causer d'exposition de données inter-tenant.

Comment c'est implémenté

Isolation imposée au schéma, non rapiécée dans le code applicatif

Chaque table portant des données par tenant a une politique RLS liée à la variable de session `app.tenant_id`. L'API définit cette variable depuis la revendication tenant du JWT authentifié avant l'exécution de toute requête. Les politiques sont RESTRICTIVE (refus par défaut), donc une variable manquante ou non concordante retourne zéro ligne plutôt que de fuiter. La RLS est activée au niveau du rôle de base de données — même un accès BD direct via un pool de connexions ne peut pas la contourner. Les politiques sont versionnées avec le schéma.

Capacités

Ce qui est couvert dès le départ

RLS sur chaque table portée par tenant (130+ tables)

Politiques RESTRICTIVE de refus par défaut

Revendication tenant fixée depuis le JWT, jamais l'entrée utilisateur

Sous-politiques par client et par LOB sur les tables pertinentes

Le pool de connexions impose la même appartenance au rôle

Les migrations de schéma vérifient que les nouvelles tables ont la RLS activée

La suite de tests affirme le rejet d'accès inter-tenant pour chaque point d'accès

La piste d'audit capture toute requête rejetée par politique

Standards et conformité

Artefacts prêts pour l'audit sur lesquels vos évaluateurs peuvent s'appuyer

SOC 2 Type II — contrôles de séparation logique
LPRPDE — mesures de sécurité raisonnables pour les renseignements personnels
RGPD Article 32 — sécurité du traitement
Preuves prêtes pour l'audit : DDL des politiques RLS sur demande

FAQ des achats

Ce que les évaluateurs sécurité et conformité demandent vraiment

L'application peut-elle accidentellement faire fuiter des données inter-tenant ?+

Non. Même si le code applicatif oublie de filtrer, la base de données rejette la requête parce que la variable de session tenant ne correspond pas. L'application recevrait un ensemble de résultats vide.

Comment la revendication tenant est-elle vérifiée ?+

Elle vient d'un JWT signé, défini au début de la session par l'intergiciel d'authentification de l'API. Les utilisateurs ne peuvent ni définir ni altérer leur propre revendication tenant.

Qu'en est-il des administrateurs de base de données ?+

Les rôles applicatifs s'exécutent avec la RLS activée. Les rôles privilégiés nécessaires pour contourner la RLS ne sont pas dans le chemin de l'application — ils sont derrière une procédure de récupération séparée et auditée.

Comment testez-vous que l'isolation fonctionne ?+

Les tests d'intégration pour chaque point d'accès incluent un cas « essayer d'accéder aux données d'un autre tenant » qui doit retourner zéro ligne ou 404. Les tests font échouer la compilation si l'isolation régresse.

Présentez ceci à votre équipe sécurité

Nous partageons les aperçus de sécurité, le DDL des politiques RLS, les schémas d'événements d'audit, et l'avancement SOC 2 sur demande. Réservez une revue de sécurité de 30 minutes avec les fondateurs.

Réserver une revue de sécurité Retour à Atlas