Stratégies d'Autorisation

Choisir la bonne stratégie d’autorisation est une décision architecturale qui a des conséquences durables sur la sécurité, la maintenabilité et l’expérience utilisateur. Ce chapitre explore les stratégies d’autorisation pour les architectures modernes, des plus simples aux plus sophistiquées.

Spectre des Modèles d’Autorisation

DAC ──> RBAC ──> RBAC+ABAC hybride ──> ABAC ──> ReBAC ──> PBAC
 │         │            │                │        │         │
 Simple                                           Complexe
 Faible                                            Forte
 contrôlabilité                                  contrôlabilité

Hybrides RBAC+ABAC

L’approche la plus pragmatique pour la plupart des organisations : utiliser RBAC comme modèle de base avec des règles ABAC pour les cas complexes.

Architecture Hybride

1. Évaluation RBAC (base) :
   L'utilisateur a-t-il un rôle qui permet l'action demandée ?
   │
   ├── NON  → REFUSER (fin de l'évaluation)
   │
   └── OUI  → Continuer vers l'évaluation ABAC

2. Évaluation ABAC (contexte) :
   Les attributs (temps, lieu, appareil, classification) sont-ils valides ?
   │
   ├── NON  → REFUSER ou demander élévation
   │
   └── OUI  → PERMETTRE

Exemples d’Implémentation

Autorisation dans les Microservices

Défis Spécifiques

Modèles d’Autorisation pour Microservices

Modèles d’Authentification API

Comparaison Détaillée des Modèles API

Cadre Décisionnel pour le Choix du Modèle

Questions à se Poser

1. Combien d’utilisateurs ? (< 100 → DAC/RBAC simple, > 10 000 → RBAC+ABAC)
2. Quelle granularité de permissions ? (Fonction métier → RBAC, Attribut/contexte → ABAC)
3. Les relations entre entités sont-elles importantes ? (Oui → ReBAC)
4. Quelle est la maturité opérationnelle ? (Faible → RBAC, Élevée → PBAC/policy-as-code)
5. L’application est-elle réglementée ? (Oui → RBAC+ABAC avec audit complet)
6. Architecture monolithique ou microservices ? (Monolithe → RBAC classique, Microservices → Sidecar/PDP centralisé)
7. Quelle est la fréquence des changements de politiques ? (Faible → RBAC, Élevée → ABAC/PBAC)
8. Avez-vous besoin d’autorisation déléguée ? (Oui → OAuth 2.0)

Arbre de Décision Simplifié

Besoin de granularité fine ?
├── NON → RBAC
└── OUI → Besoin de contexte (temps, lieu, classification) ?
         ├── NON → RBAC avec rôles supplémentaires
         └── OUI → Relations entre entités importantes ?
                   ├── OUI → ReBAC (Zanzibar)
                   └── NON → ABAC ou RBAC+ABAC hybride

Points Clés à Retenir

• Le spectre des modèles d’autorisation va de DAC (le plus simple) à PBAC (le plus sophistiqué) — le choix du bon modèle dépend du nombre d’utilisateurs, de la granularité requise, des relations entre entités et de la maturité opérationnelle
• L’approche hybride RBAC+ABAC est la plus pragmatique pour la plupart des organisations : RBAC pour le contrôle d’accès de base basé sur les rôles, avec des règles ABAC pour les décisions contextuelles (temps, lieu, classification de la ressource)
• L’autorisation dans les microservices présente des défis spécifiques : décentralisation, latence, consistance et traçabilité — les solutions incluent API Gateway, sidecar OPA, JWT avec claims, service mesh et PDP centralisé
• Les modèles d’authentification API vont de la clé API (faible sécurité, facile) à mTLS et HMAC (haute sécurité, complexe) — OAuth 2.0 Client Credentials est le meilleur équilibre pour les communications M2M
• Le cadre décisionnel pour choisir le modèle d’autorisation repose sur 8 questions clés — l’arbre de décision simplifié guide le choix : RBAC pour les besoins simples, ABAC ou RBAC+ABAC pour la granularité contextuelle, ReBAC pour les relations entre entités