Migration des permissions : architecture de l'application
Définit une migration progressive d'un modèle de permission à un autre en utilisant l'évaluation en mode shadow, la détection de divergences, des cohortes explicites de basculement, le retour arrière et des limites d'application en mode fail-closed.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite quant à la réussite de leur passage par une implémentation adoptante.
Décision
Faire fonctionner les anciens et nouveaux moteurs de politique en parallèle, mais ne conserver qu'un seul résultat faisant autorité par cohorte. Enregistrer les divergences pseudonymisées, les corriger, puis basculer par cohortes limitées avec un commutateur de version de politique réversible.
Portée
- Traduction de politique, comparaison en shadow, basculement de cohorte, comportement des sessions, versionnage du cache et retour arrière.
- Application à travers les API synchrones, les jobs, les exports, la recherche, les caches et les outils administratifs.
- Preuves nécessaires pour retirer l'ancienne politique.
Hors de ce périmètre
- Changer les droits produits en même temps que la migration de leur représentation.
- Maintenir deux sources de vérité indépendantes après migration.
Contrat
- Chaque requête d'application porte le locataire, le sujet, l'action, la ressource et la version de politique sélectionnée.
- La sortie shadow ne peut ni autoriser ni refuser les actions utilisateur ; seul le moteur faisant autorité de la cohorte le peut.
- Les enregistrements de divergence classifient séparément les différences attendues de traduction des autorisations et refus inexpliqués.
- Les caches de permissions et de décisions incluent la version de politique et le périmètre du locataire dans leurs clés.
- Le basculement est monotone par cohorte sauf retour arrière explicite qui rétablit la cohorte.
- La mise hors service de l'ancienne politique nécessite zéro divergence à haut risque inexpliquée, un retour arrière testé et une couverture des chemins d'application non HTTP.
Guide d'implémentation
- Créer un vocabulaire canonique des permissions, puis des adaptateurs pour les deux modèles.
- Utiliser des fixtures de décision représentatives et réduites en termes de confidentialité ainsi que des échantillons shadow de production.
- Propager la version de politique dans les sessions ou réévaluer les sessions au niveau de l'application après basculement.
- Concevoir le retour arrière pour changer l'autorité sans réécrire à l'envers les affectations partiellement migrées.
Gestion des échecs et protections
- Si le nouveau moteur est indisponible pour une cohorte migrée, suivre la politique déclarée fail-closed ou de repli protégé ; ne jamais utiliser silencieusement un cache sans version.
- Si le volume de divergences perd en observabilité, arrêter l'expansion de la cohorte.
- Si la traduction d'affectation est ambiguë, mettre l'affectation en quarantaine pour révision plutôt que d'élargir l'accès.
Vérification et exploitation
- Mesurer les divergences par action/classe de risque, latence d'évaluation, échecs de cache, couverture de migration, temps de retour arrière et échecs d'autorisation inexpliqués.
- Valider chaque cohorte sur une fenêtre de preuves et un approbateur nommé.
- Maintenir l'ancien moteur en lecture seule durant la fenêtre de retour arrière, puis supprimer délibérément tous les chemins d'appel.
Les exemples à l'apparence exécutable dans ce package sont des fixtures et contrats d'acceptation. Lancez
python tools/validate.py depuis la racine de la collection pour vérifier la structure et les métadonnées du package ; puis
implémentez et exécutez les scénarios dans le dépôt cible.
Hypothèses d'adoption
- Les noms et valeurs numériques dans
example.yamlsont un profil d'adoption, pas des valeurs par défaut universelles. - L'équipe adoptante doit mapper les acteurs, classes de données, vocabulaire d'erreur et propriété à son système.