Row-Level Security n’est pas une suggestion

Petit exercice de pensée. Vous utilisez une plateforme SaaS. Votre concurrent utilise la même plateforme. Vous stockez tous deux inventaire, résultats de grading, prix et informations client. La question : qu'est-ce qui empêche votre concurrent de voir vos données ?

Si la réponse est "le code applicatif vérifie quel tenant vous êtes et n'affiche que vos données" — félicitations, vous avez de la sécurité au niveau applicatif. Cela signifie qu'un bug dans le code, un endpoint API mal configuré, une injection SQL ou un développeur trop serviable avec accès base de données pourrait potentiellement exposer les données du tenant A au tenant B.

Si la réponse est "la base de données elle-même impose l'isolation, et aucune requête ne peut retourner les données d'un autre tenant quelle que soit sa forme" — vous avez de la row-level security. Ce sont deux choses très différentes.

Le problème de la couche applicative

L'isolation tenant au niveau applicatif fonctionne ainsi : chaque requête inclut un filtre. WHERE tenant_id = 'your-tenant'. L'application ajoute ce filtre à chaque appel base de données. Si le filtre est présent, vous voyez vos données. S'il est absent — à cause d'un bug, d'un oubli, d'un nouvel endpoint qui a oublié le check ou d'un développeur qui lance vite une requête en production — la base retourne gentiment tout.

La base de données ne connaît pas les tenants. Elle stocke des lignes. C'est à l'application de demander les bonnes. Et l'application, étant du logiciel écrit par des humains, peut faire des erreurs.

Ce n'est pas théorique. Les fuites de données multi-tenant font partie des incidents de sécurité les plus courants dans les plateformes SaaS. Un développeur écrit un nouvel endpoint API et oublie le filtre tenant. Un script de migration tourne sans clause WHERE. Une session de debug se connecte directement à la base et lance un SELECT * qui retourne les enregistrements de tous les tenants. Chacune de ces erreurs est simple. Chacune peut exposer votre inventaire, vos prix, vos données client.

La sécurité applicative met le verrou sur la porte. La row-level security construit les murs en béton. Les portes peuvent rester ouvertes. Le béton non.

Row-level security : la base comme arbitre

Postgres Row Level Security (RLS) fonctionne différemment. Au lieu de compter sur l'application pour filtrer les données, la base elle-même impose les règles. Chaque table a une policy qui dit : "ce tenant ne peut voir que les lignes dont tenant_id correspond à sa session." La policy est appliquée au niveau base de données. Aucun code applicatif ne peut la contourner. Aucune requête ne peut l'éviter. Un SELECT * retourne seulement vos lignes, non pas parce que l'application les a filtrées, mais parce que la base refuse de montrer autre chose.

Si un développeur écrit un endpoint buggué qui oublie le filtre tenant, la base retourne quand même uniquement les données du bon tenant. Si quelqu'un lance une requête brute, la policy s'applique. Si une nouvelle feature est ajoutée dans l'urgence avec un contrôle d'accès incomplet, la base s'en moque — la policy est là, permanente et inoubliable.

RLS ne remplace pas la sécurité applicative. Il faut toujours authentification, autorisation et bon design API. Mais RLS est le filet de sécurité — la garantie que même quand l'application se trompe, les données tenant ne fuient pas. C'est la différence entre "nous faisons confiance au code" et "l'architecture ne le permet pas".

Pourquoi c'est important pour l'ITAD

Les plateformes ITAD manipulent par nature des données sensibles. L'inventaire contient des numéros de série et des historiques d'assets. Les prix révèlent la stratégie commerciale. Les listes clients sont du renseignement concurrentiel. Les enregistrements d'effacement contiennent des métadonnées sur ce qui se trouvait sur l'appareil avant effacement — et même si les données elles-mêmes ont disparu, les métadonnées (quels clients avaient quels appareils avec quelles classifications de données) sont précieuses et sensibles.

Si vous êtes une entreprise ITAD qui évalue une plateforme multi-tenant, la question "comment mes données sont-elles isolées des autres tenants ?" devrait figurer dans votre premier e-mail. Et la réponse devrait être : "au niveau base de données, avec des policies RLS sur chaque table." Pas "notre code applicatif s'en charge." Pas "nous avons des contrôles d'accès." Pas "nos développeurs sont très prudents." La prudence n'est pas une architecture de sécurité. La prudence est un espoir.

La row-level security n'est pas une fonctionnalité à activer ou désactiver selon préférence. C'est une décision architecturale fondatrice qui détermine si votre plateforme multi-tenant a une vraie isolation ou une isolation simulée. La différence est invisible quand tout fonctionne. Elle est tout quand quelque chose se passe mal.

Votre concurrent utilise la même plateforme. Peut-il voir vos données ? Si la réponse dépend du fait que l'application ne fasse jamais d'erreur, la réponse est "pas encore".