Les politiques de sécurité au niveau des lignes réduisent les fuites de données entre locataires par rapport au filtrage côté application

Hypothèse

La documentation sur la sécurité au niveau des lignes indique que, une fois cette sécurité activée sur une table, tout accès normal doit être autorisé par une politique, et qu'en l'absence de toute politique, une règle de refus par défaut s'applique, de sorte qu'aucune ligne n'est visible ni modifiable ; les superutilisateurs, les rôles dotés de BYPASSRLS et, normalement, le propriétaire de la table contournent cette règle. Une politique porte une expression USING pour les lignes pouvant être vues, et une expression WITH CHECK pour les lignes pouvant être écrites ; la page CREATE POLICY indique que les politiques permissives se combinent avec OR, les politiques restrictives avec AND, et qu'au moins une politique permissive est nécessaire avant que les politiques restrictives ne soient utiles. Un service qui se connecte avec un rôle non propriétaire, définit le locataire par transaction (SET LOCAL app.tenant_id = ...) et déclare USING (tenant_id = current_setting('app.tenant_id')::uuid) sur chaque table de locataire change les modes de défaillance : une requête à laquelle il manque le prédicat de locataire continue de ne renvoyer que les lignes du locataire courant, et une requête qui ne définit jamais app.tenant_id ne renvoie rien ou échoue lors de la conversion, au lieu de renvoyer les lignes de tous les locataires. L'hypothèse : sur toute la durée de vie d'une base de code, cette conception produit moins de bogues confirmés d'exposition entre locataires qu'un filtrage côté application soumis à la même discipline de test.

Prédiction

Dans les bases de code où des politiques existent sur toutes les tables de locataires, les rapports de bogues classés comme « données d'un autre locataire visibles » sont plus rares par point de terminaison que dans des bases de code comparables qui en sont dépourvues, et les fuites restantes proviennent d'un petit nombre de causes : des connexions s'exécutant en tant que propriétaire, superutilisateur ou rôle BYPASSRLS ; des tables où la politique a été oubliée ; et du code qui s'exécute avec les privilèges de son définisseur. Les requêtes individuelles auxquelles il manque un prédicat n'apparaîtront pas parmi les causes.

Test proposé

1. Sélectionner des services de taille comparable, avec et sans isolation fondée sur des politiques ; extraire de leurs outils de suivi les incidents étiquetés comme exposition entre locataires sur une période fixe, normalisés par le nombre de points de terminaison.
2. Vérification de type mutation : retirer le prédicat de locataire d'un échantillon de requêtes dans chaque base de code, et compter combien de requêtes mutées renvoient des lignes étrangères dans un environnement de test comportant deux locataires, ainsi que combien de tests les détectent.
3. Consigner les catégories de défaillance résiduelles pour voir si les connexions en tant que propriétaire et les politiques oubliées dominent, ce qui indiquerait où concentrer l'effort de relecture.

Statut

Aucun résultat n'est revendiqué. Les politiques déplacent le mode de défaillance mais en ajoutent un qui leur est propre : elles doivent être créées par table et testées, les rôles privilégiés les contournent, et les expressions de politique modifient les plans de requête. L'hypothèse ne porte que sur le nombre de fuites, pas sur la performance ni sur le coût opérationnel.