Sécurité au niveau des lignes

AiHummer est multi-locataire, et sa frontière d’isolation la plus forte se trouve dans la base de données elle-même : Sécurité au niveau des lignes PostgreSQL (RLS). Avec RLS activé, la base de données — pas seulement le code de l’application — veille à ce qu’une requête ne voie que les lignes appartenant au locataire actuel.

Niveau : La sécurité au niveau des lignes est limitée par le paiement Entreprise niveau — il ne fait pas partie de la plateforme gratuite/Communautaire.

Pourquoi RLS

Filtrage au niveau de l’application (WHERE tenant_id = ...) est nécessaire mais fragile : une seule clause oubliée peut laisser fuiter des données entre les locataires. RLS transfère la garantie dans PostgreSQL, de sorte que même une requête non filtrée ne renvoie que les lignes du locataire actuel. C’est une couche de défense en profondeur sous le propre filtrage de l’application. Pour le modèle de multi-location plus large — et comment il s’associe aux effets secondaires idempotents — voir Multilocativité et idempotence.

Le rôle restreint (optionnel)

RLS est s’inscrire et est activé en donnant à la passerelle une seconde connexion à la base de données qui utilise un rôle restreint plutôt que celui du propriétaire :

# /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

Le aihummer_app rôle est pas le propriétaire de la table, donc PostgreSQL applique des politiques RLS à celle-ci. Les requêtes de l’application passent par ce pool restreint. Activer RLS consiste à définir AIHUMMER_DB_APP_URL — et Les installations locales/standard (natives de l’hôte) configurent cette variable automatiquement, donc RLS est actif dès le départ. Il est « sur option » seulement dans le sens où un déploiement personnalisé ou manuel doit le configurer AIHUMMER_DB_APP_URL lui-même.

[!NOTE] Sans AIHUMMER_DB_APP_URL, la passerelle utilise le pool de propriétaires pour tout et le RLS n’est effectivement pas appliqué. Configurez le pool restreint (qui le ce que fait l’installateur standard pour vous) pour activer l’isolation au niveau de la base de données.

[!IMPORTANT] RLS ne dépend pas de la formule. Il fonctionne à l’identique sur toutes les formules, Community comprise. Si l’écran de licence affiche « Sécurité au niveau des lignes » comme indisponible, c’est une imprécision de cet écran, pas l’état de votre base de données.

Où RLS est déjà actif et où vous devez l’activer

Comment vous avez installé	État de RLS après l’installation
Installation standard, l’installateur met en place PostgreSQL	Actif. Le rôle restreint et `AIHUMMER_DB_APP_URL` sont créés pour vous
PostgreSQL personnel ou managé (adresse de base fournie)	Inactif. Vous créez le rôle et définissez `AIHUMMER_DB_APP_URL`
Installation sans droits administrateur (rootless)	Inactif. Idem

[!WARNING] Deux erreurs qui laissent RLS « activé » sans rien protéger. Première : AIHUMMER_DB_APP_URL pointe vers le propriétaire des tables ou un superutilisateur — PostgreSQL exempte ces rôles des politiques, et la passerelle signalera quand même RLS comme actif. Utilisez un rôle restreint distinct. Seconde : sur votre propre PostgreSQL, le rôle restreint peut être créé automatiquement avec un mot de passe prévisible — donnez-lui votre propre mot de passe avant que la base ne soit joignable sur le réseau.

Portée par locataire

Dans une requête, l’application établit le locataire actuel sur la connexion avant d’exécuter des requêtes limitées au locataire — conceptuellement db.WithTenant. Une fois défini, les politiques RLS sur le rôle restreint limitent chaque lecture et écriture aux lignes de ce locataire. La portée est liée à l’unité de travail, donc elle ne se propage pas entre les requêtes simultanées.

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

Mode système / contournement pour les travailleurs

Certain travail est légitimement inter-locataire ou indépendant du locataire — travailleurs en arrière-plan, planificateurs, récupération de livraison et maintenance similaire. Pour ceux-ci, la passerelle utilise un mode système (contournement) qui fonctionne sur le pool du propriétaire, en dehors des politiques RLS par locataire, afin que les tâches d’infrastructure puissent fonctionner à travers l’ensemble de données.

[!WARNING] Le mode contournement est réservé aux travailleurs internes de confiance. Chemins de code de traitement des requêtes cet acte au nom d’un utilisateur doit toujours passer par la restriction, pool à l’échelle du locataire — jamais le chemin de contournement.

Les migrations s’exécutent sur le pool de propriétaires

Les modifications de schéma nécessitent des privilèges que le rôle restreint n’a pas, donc les migrations s’exécutent toujours sur le pool propriétaire (AIHUMMER_DATABASE_URL), sous un verrou consultatif, au démarrage. Le restreint aihummer_app Le rôle est utilisé uniquement pour le trafic applicatif ordinaire. Cela maintient la séparation des privilèges propre : les opérations de modification du schéma utilisent le propriétaire ; l’accès aux données des locataires utilise le rôle restreint avec RLS appliqué.

Où aller ensuite

Multilocativité et idempotence — le modèle complet du locataire et comment les effets secondaires restent sûrs en cas de récupération.
Coffre-fort des secrets — les DEK par locataire renforcent la même chose isolation à la couche des secrets.
RBAC et clés API à portée — autorisation au-dessus de couche de données.