Conclusion : jusqu'où aller
Choisir, selon votre application, le niveau de mécanisme qui suffit, de la simple décision sur l'objet au service de relations dédié, et savoir ce qui ne se règle par aucun outil.
Par Elias Varen3 min de lectureDossier complet
À retenir
- Trois choses valent pour toute application à plusieurs rôles : refus par défaut, décision sur l'objet chargé dans le tenant, et un test qui échoue quand une entrée répond sans décision.
- Chaque mécanisme plus lourd (RLS comme point d'application, moteur de politiques, graphe de relations) répond à un déclencheur précis, pas à une taille d'équipe.
- La partie difficile reste humaine : écrire les règles avec le métier, les faire relire, et décider qui a le droit de les changer.
Onze chapitres décrivent des mécanismes de poids très différents. Un voter de vingt lignes et un service de relations répliqué ne répondent pas au même problème, et la plupart des applications n'auront jamais besoin du second. Cette conclusion sert à trouver votre niveau.
Le socle, quelle que soit l'application
Trois pratiques ne dépendent ni de la taille ni du modèle de permissions. Elles coûtent peu et rendent tout le reste possible.
La première est le refus par défaut, vérifié par un test. Une requête qui atteint un contrôleur, un handler ou un webhook sans qu'aucune décision n'ait été prise échoue en environnement de test. Le chapitre sur l'audit et les tests montre le listener qui le fait.
La deuxième est la décision prise sur l'objet, après un chargement borné au tenant actif. Le rôle seul ne suffit jamais, et la liste se filtre dans la requête avec le même périmètre que le compteur et l'export. C'est l'objet du chapitre sur la vérification au niveau de l'objet et de celui sur le tenant.
La troisième est une décision qui renvoie une raison, pas seulement un booléen. Elle coûte une classe. Elle rend possibles le support (« pourquoi je ne vois pas ce dossier ? »), le journal des refus et, plus tard, la comparaison en mode shadow quand vous voudrez changer de mécanisme.
Une application qui a ces trois pratiques est déjà mieux protégée que la plupart de celles que j'ai eu à reprendre. Beaucoup peuvent s'arrêter là.
Les déclencheurs
Les mécanismes plus lourds s'ajoutent chacun sur un signal précis. Le schéma suivant résume ceux que le dossier a détaillés.
flowchart TD
A["Socle : refus par défaut, décision sur l'objet, raison"] --> B{"Des clients lisent la base sans passer par vos repositories ?"}
B -->|oui| C["RLS comme point d'application pour ces clients"]
B -->|non| D["RLS comme filet, ou rien"]
A --> E{"Les clients écrivent leurs propres règles, ou plusieurs services partagent les mêmes ?"}
E -->|oui| F["Moteur de politiques, avec évaluation partielle pour les listes"]
E -->|non| G["Module PHP de règles testé"]
A --> H{"Le produit a un vrai partage objet par objet ?"}
H -->|oui, un seul service| I["Table de relations dans PostgreSQL, lue sur le primaire"]
H -->|oui, plusieurs services| J["Service de relations dédié, avec token de cohérence"]
H -->|non| K["Rôles et attributs suffisent"]Les branches sont indépendantes. Une application peut avoir besoin de la RLS comme point d'application pour un client qui branche son outil de BI sur une replica, tout en gardant ses règles dans un module PHP et ses permissions en rôles par tenant. C'est même le cas le plus fréquent.
Deux déclencheurs ne figurent pas sur le schéma parce qu'ils arrivent pour tout le monde. Le premier consommateur d'événements hors de la transaction qui les produit (une projection asynchrone, un webhook, un autre contexte) oblige à traiter la décision qui voyage. La première intégration qui agit au nom d'un utilisateur oblige à penser la délégation et le confused deputy. Ni l'un ni l'autre ne se reporte.