Héritage des permissions : Architecture d'application
Les permissions effectives sont calculées de manière déterministe à partir des héritages de rôle, de groupe et de ressource avec des règles de refus prioritaire, des vues matérialisées pour l'audit, et une gestion explicite des superpositions de droits temporaires.
Statut du package : Package de référence assisté par IA. La validation statique du package a réussi ; les scénarios d'implémentation restent à exécuter et une revue humaine du domaine est requise avant adoption stable.
Décision
Calculer l'accès effectif en parcourant la hiérarchie des ressources jusqu'à une profondeur limitée, en unissant les autorisations des rôles et groupes, en superposant les droits temporaires actifs, puis en appliquant un refus explicite sur les ressources plus proches afin que le refus explicite l'emporte sur un droit actif sauf si une dérogation break-glass auditable distincte est enregistrée.
Portée
- Héritage le long des arbres locataire, dossier, projet ou objet.
- Assignations directes, rôles dérivés de groupes, et superpositions de droits temporaires.
- Explication/débogage du comportement de l'API et isolation inter-locataires lors de l'inspection.
- Instantanés matérialisés d'accès effectif pour la comparaison d'audit après modifications.
Hors de ce bloc
- Workflow d'émission des droits temporaires et balayages d'expiration (voir bloc accès temporaire).
- Authentification et validation des identifiants.
- Interface utilisateur pour la gestion des permissions.
Contrat
- Les permissions d'autorisation se propagent de l'ancêtre au descendant jusqu'à la limite de profondeur sauf blocage par un refus explicite sur une ressource intermédiaire ou feuille.
- L'ordre d'évaluation est fixe : union des autorisations de rôle et groupe, application des droits temporaires actifs, puis application des refus explicites. Le refus explicite sur une ressource annule les autorisations héritées et les droits actifs pour la même action sur cette ressource et ses descendants (par défaut : pas d'exception grant-wins).
- L'élévation break-glass, lorsqu'elle est activée, est une voie de dérogation auditable distincte avec son propre ticket et expiration ; elle n'est pas impliquée par les droits temporaires ordinaires.
- Les droits temporaires ajoutent des autorisations uniquement tant que leur statut est actif et dans la fenêtre temporelle ; les droits expirés ou révoqués sont ignorés avant l'évaluation des refus.
- Le calcul de l'accès effectif est déterministe : des entrées identiques produisent des hachages de décision identiques consignés dans les instantanés d'audit.
- Le middleware d'application et l'API d'explication utilisent la même version du moteur et le même ordre de règles ; les résultats divergents sont considérés comme des défauts.
- Les requêtes d'explication inter-locataires ne révèlent jamais les chemins de ressources ni les rôles d'autres locataires.
- Une profondeur dépassant le maximum du profil entraîne un refus avec le code raison
depth-exceeded, pas une autorisation partielle silencieuse. - Lorsqu'une entrée d'héritage change, le recalcul se termine dans la limite de lecture périmée du profil ou l'application échoue en mode fermé pour les ressources affectées.
Guide d'implémentation
- Représenter les ressources par des identifiants de chemin stables ; stocker les liaisons sous forme de tuples
(subject, role, scope_path). - Matérialiser les appartenances aux groupes de manière asynchrone mais bloquer les revendications d'administration UI de propagation jusqu'à la fin de la matérialisation.
- Utiliser
effective-access-cases.yamlcomme données de fixture pour des tests pilotés par table dans le dépôt adoptant. - Versionner le moteur et inclure la version dans les instantanés d'audit pour supporter les évolutions futures des règles.
Gestion des échecs et protections
- En cas d'échec partiel de matérialisation, refuser les actions élevées uniquement pour les sujets et ressources affectés dans le locataire concerné jusqu'à réussite du recalcul. Si la portée exacte de la ressource ne peut être établie en toute sécurité, échouer en mode fermé pour ces sujets sur ce locataire, jamais sur des locataires non liés.
- La détection de membership circulaire dans les groupes interrompt l'expansion et alerte au lieu de boucler indéfiniment.
- Si l'API d'explication est désactivée en production, fournir un outil break-glass en lecture seule avec audit renforcé.
- Ne pas mettre en cache l'accès effectif au-delà des frontières de locataires.
Vérification et opérations
- Comparer les décisions d'application aux échantillons de sortie d'explication à chaque déploiement via des tests smoke.
- Suivre la latence de recalcul, les incidents de lecture périmée, et les refus pour dépassement de profondeur.
- Alerter avec locataire, ensemble de sujets, et preuve de portée de ressource pour que la limite fail-closed soit revue sans l'élargir accidentellement.
- Examiner les conflits deny-wins lorsque les administrateurs se plaignent de refus inattendus ; exporter la différence d'instantanés.
Hypothèses d'adoption
- Les noms et structures dans
example.yamleteffective-access-cases.yamlconstituent un profil d'adoption, pas des valeurs par défaut universelles. - Les équipes cartographient explicitement leur arbre de ressources et catalogue de rôles au modèle d'héritage.