Spotrak
Équipe produit
Un SaaS multi-entreprises, c'est une seule base de données qui contient les clients de tout le monde. La question qui devrait empêcher de dormir n'importe quel éditeur : qu'est-ce qui garantit qu'une requête d'une entreprise ne ramènera jamais, par bug ou par malveillance, la donnée d'un client d'une autre entreprise ?
La mauvaise réponse, la plus répandue, c'est « notre code filtre par compte ». Le code, ça s'oublie. Un développeur écrit une requête, oublie son filtre, et la fuite est là. Faire reposer l'isolation sur la discipline des développeurs, c'est une fuite qui attend son jour.
L'isolation vit dans la base, pas dans le code
Chez Spotrak, la séparation est imposée par Postgres lui-même, via le Row Level Security. Chaque table porte une règle : une session ne peut lire que les lignes de son compte, point. Même si une requête oublie son filtre, la base ne renvoie rien d'autre. L'isolation ne dépend plus de la mémoire du développeur, elle est structurelle.
Fermé par défaut, ouvert par exception
Le réflexe habituel est d'ouvrir les accès puis de restreindre. On fait l'inverse : tout est interdit par défaut, et on ouvre explicitement, table par table, le strict nécessaire. Une table qu'on oublie de configurer n'est pas une table grande ouverte. C'est une table à laquelle personne n'accède. L'erreur penche du côté sûr.
Les données sensibles ne sont pas exposées en direct
Les jetons de session, les codes à usage unique, les événements internes ne vivent pas dans des tables que le client interroge. Ils sont dans un schéma séparé, accessible uniquement par des fonctions au privilège contrôlé, qui valident avant de répondre. Le navigateur de l'utilisateur ne parle jamais directement à ces tables.
Rien de tout ça ne se voit dans l'interface, et c'est précisément le but. La sécurité qui se voit est une contrainte ; la sécurité bien faite est une absence de bruit. Quand on confie les données de ses clients à un logiciel, c'est cette couche invisible qu'on achète vraiment.