Aller au contenu
Deepstack
Se connecter

Autorisation, du contrôle d'accès au multi-tenant

Qui a le droit de faire quoi, et comment le prouver

Comprendre pourquoi le contrôle d'accès est la faille la plus fréquente des applications, choisir un modèle de permissions, appliquer la décision au niveau de l'objet et du tenant, centraliser les politiques sans bloquer les équipes, et prouver par les tests et l'audit que les règles tiennent.

Pour les développeurs, architectes et responsables techniques qui maintiennent une application à plusieurs rôles ou plusieurs clients et veulent sortir des vérifications dispersées dans les contrôleurs.

Par Elias Varen11 chapitres2 h 35 de lectureMis à jour le

Commencer la lectureAcheter le dossier · 29,25 € au lieu de 39 €
Offre de lancement, jusqu'au 2 novembre

2 chapitres et annexes se lisent librement ; 2 de plus avec un compte gratuit.

Sommaire

  1. ·Avant-proposSavoir si ce dossier vous concerne : le problème qu'il traite, la position qu'il défend sur l'autorisation, et comment le lire.3 min

Pourquoi ça casse

Les mécanismes de faille et les modèles de permissions, avec leur coût.

  1. 1Pourquoi le contrôle d'accès casseReconnaître dans votre code les causes structurelles des failles d'autorisation (décisions dispersées, chemins secondaires, ouverture par défaut, règles orales) et savoir ce qu'une architecture d'autorisation doit garantir : un point de décision, un modèle écrit, une preuve.15 min
  2. 2RBAC, ABAC, ReBAC : modéliser les permissionsConstruire un modèle de permissions qui tienne dans un SaaS multi-tenant (permissions nommées, rôles par appartenance, conditions, relations limitées aux objets partagés), en connaissant son budget de requêtes, sa capacité à expliquer une décision et le chemin pour en changer.14 minMembres

Appliquer la décision

L'objet, le tenant et la base de données : là où la règle doit vraiment s'exécuter.

  1. 3Vérifier au niveau de l'objetPlacer la décision d'accès sur l'objet chargé plutôt que sur la route, avec des voters Symfony en refus par défaut, et l'étendre aux listes, aux compteurs, aux actions en masse, aux champs et aux fichiers, là où le contrôle par objet disparaît le plus souvent.13 minMembres
  2. 4Le tenant, première condition de toute décisionFaire du tenant la première condition évaluée par chaque décision d'autorisation, résoudre le rôle dans ce tenant et nulle part ailleurs, puis traiter comme des chemins nommés et tracés ce qui le traverse : changement de tenant actif, invitations, support en impersonation, administrateurs de la plateforme et opérations cross-tenant.14 minDossier complet
  3. 5Row-level security PostgreSQL : filet ou point d'applicationExploiter la row-level security sans qu'elle devienne une fuite : contexte posé par transaction, comportement derrière un pooler en mode transaction, rôles et propriétaires, politiques restrictives, plans mesurés sous le bon rôle, tests en SQL, puis le critère pour en faire un filet sous l'application ou le point d'application principal.12 minDossier complet

Centraliser les politiques

Moteurs de politiques, graphes de relations, tokens et délégation.

  1. 6Moteurs de politiques : sortir les règles du codeDécider si vos règles d'autorisation doivent quitter le code applicatif pour un moteur de politiques, embarqué ou en service, et savoir ce que cela coûte en latence, en filtrage de listes, en déploiement et en tests.13 minDossier complet
  2. 7Graphe de relations : l'autorisation par tuplesComprendre le modèle des tuples de relations, la réécriture d'ensembles et l'héritage, traiter la cohérence d'une révocation suivie d'un nouveau contenu, et décider entre une table PostgreSQL avec requêtes récursives et un service de relations dédié.13 minDossier complet
  3. 8Tokens, délégation et confused deputySavoir ce qu'un token d'accès doit porter et ce qui doit rester côté serveur, concevoir la délégation à des intégrations, des services et des agents qui agissent au nom d'un utilisateur, et repérer le confused deputy dans vos propres services.13 minDossier complet

Opérer et prouver

Événements et projections, audit et tests, puis la migration d'un existant.

  1. 9Événements et projections : quand la décision voyagePlacer la décision d'accès dans un système à événements : à quel moment juger une commande, ce qu'un événement a le droit de transporter, comment les droits eux-mêmes se projettent sans ouvrir de fenêtre, et ce qu'un rejeu, un saga ou un webhook fait de vos règles.14 minDossier complet
  2. 10Audit et tests : prouver que les règles tiennentConstruire les preuves qu'un auditeur ou un grand compte accepte : une matrice de décisions testée à la bonne couche, des tests de fuite, un inventaire des points d'entrée qui casse la CI, un journal des décisions exploitable, la détection d'énumération et une revue des accès qui se fait vraiment.13 minDossier complet
  3. 11Sortir des vérifications ad hoc : migrer un existantMigrer une application dont les contrôles d'accès sont dispersés vers un point d'application unique : inventorier ce qui décide, comparer l'ancienne et la nouvelle décision en mode shadow, basculer module par module, nettoyer, et fixer des critères vérifiables pour déclarer la migration terminée.14 minDossier complet
  1. ·Conclusion : jusqu'où allerChoisir, 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.3 minDossier complet

En version courte

Un point du dossier par article, à lire en quelques minutes.

Autorisation, du contrôle d'accès au multi-tenant : Qui a le droit de faire quoi, et comment le prouver · Deepstack