- À propos de l'autorisation en cybersécurité
- Différences entre identification, authentification et autorisation
- Les principaux modèles de contrôle d'accès
- Fonctionnement et mécanismes d'autorisation
- Implémentation de l'autorisation avec Python et Django
- Vulnérabilités et bonnes pratiques de sécurisation
- À retenir
En cybersécurité, l'autorisation est un mécanisme fondamental permettant de déterminer les ressources auxquelles un utilisateur, une application ou un système peut accéder et les opérations qu'il est autorisé à effectuer. Elle intervient généralement après l'authentification et constitue un élément essentiel du contrôle d'accès, de la protection des données et de la sécurité des applications informatiques.
1. À propos de l'autorisation en cybersécurité
L'autorisation, appelée Authorization en anglais, est le processus qui consiste à déterminer si une entité possède les permissions nécessaires pour effectuer une action sur une ressource donnée.
Une entité peut être un utilisateur, une application, un service ou un équipement informatique. La ressource concernée peut être un fichier, une base de données, une page Web, une API ou une fonctionnalité d'administration.
Objectifs de l'autorisation
Les mécanismes d'autorisation permettent notamment de :
- Limiter les accès aux seules ressources nécessaires.
- Empêcher les opérations non autorisées sur les données sensibles.
- Protéger l'intégrité des informations contre les modifications injustifiées.
- Renforcer la confidentialité des ressources protégées.
- Définir les responsabilités des utilisateurs et des services.
- Appliquer le principe du moindre privilège dans les systèmes informatiques.
Exemple simple
Considérons une plateforme pédagogique utilisée par des étudiants, des enseignants et des administrateurs.
Un étudiant authentifié peut consulter ses notes, mais il ne doit pas pouvoir les modifier. Un enseignant peut saisir les notes des étudiants relevant de ses classes. Un administrateur peut gérer les comptes et certaines configurations de la plateforme.
Ces différences sont définies par les règles d'autorisation.
Les éléments fondamentaux
| Élément | Définition | Exemple |
|---|---|---|
| Sujet | Entité demandant une opération. | Enseignant connecté. |
| Ressource | Objet auquel l'accès est demandé. | Fichier de notes. |
| Action | Opération demandée. | Lire, modifier, supprimer. |
| Permission | Droit accordé à une entité. | Modifier les notes d'une classe. |
| Politique d'accès | Ensemble de règles définissant les autorisations. | Seul l'enseignant responsable peut modifier une note. |
| Décision | Résultat de l'évaluation de la demande. | Accès autorisé ou refusé. |
Le principe du moindre privilège
Le principe du moindre privilège, ou Least Privilege, consiste à accorder à chaque utilisateur ou service uniquement les permissions nécessaires à ses tâches.
Par exemple, une application qui doit uniquement consulter une base de données ne devrait pas disposer d'une permission générale de suppression.
2. Différences entre identification, authentification et autorisation
Les notions d'identification, d'authentification et d'autorisation sont complémentaires, mais elles ne remplissent pas la même fonction.
Identification
L'identification consiste à déclarer une identité.
Par exemple, un utilisateur saisit son identifiant ou son adresse électronique pour indiquer le compte auquel il souhaite accéder.
Authentification
L'authentification consiste à vérifier les preuves associées à l'identité déclarée.
Elle peut reposer sur un mot de passe, une clé cryptographique ou un mécanisme d'authentification multifacteur.
Autorisation
L'autorisation détermine les opérations qu'une entité est autorisée à réaliser sur une ressource.
Une authentification réussie ne signifie donc pas que l'utilisateur peut accéder à toutes les fonctionnalités de l'application.
Tableau comparatif
| Concept | Question | Exemple |
|---|---|---|
| Identification | Qui prétendez-vous être ? | Saisie d'un identifiant. |
| Authentification | Pouvez-vous prouver cette identité ? | Vérification d'un mot de passe. |
| Autorisation | Qu'avez-vous le droit de faire ? | Permission de modifier un document. |
| Traçabilité | Quelles opérations ont été effectuées ? | Journal des modifications. |
Le modèle AAA
Dans les infrastructures informatiques et les réseaux, le modèle AAA regroupe trois fonctions :
- Authentication : vérification de l'identité.
- Authorization : détermination des permissions.
- Accounting : enregistrement ou comptabilisation des activités.
Exemple d'une application bancaire
Lorsqu'un client se connecte à son application bancaire, le système vérifie son identité. Une fois authentifié, il peut consulter les comptes qui lui appartiennent et effectuer uniquement les opérations autorisées.
Il ne doit pas pouvoir consulter les comptes d'autres clients en modifiant simplement un identifiant dans une adresse Web.
Cette protection nécessite un contrôle d'autorisation sur chaque ressource concernée.
3. Les principaux modèles de contrôle d'accès
Les systèmes informatiques utilisent différents modèles pour organiser et appliquer les permissions. Les plus connus sont DAC, MAC, RBAC et ABAC.
DAC : Discretionary Access Control
Le DAC, ou contrôle d'accès discrétionnaire, permet généralement au propriétaire d'une ressource de définir ou de déléguer certaines permissions d'accès.
Par exemple, le propriétaire d'un document peut autoriser un autre utilisateur à le lire ou à le modifier.
MAC : Mandatory Access Control
Le MAC, ou contrôle d'accès obligatoire, repose sur des règles de sécurité définies et imposées par une autorité centrale.
Les utilisateurs ordinaires ne peuvent généralement pas modifier librement ces règles.
Ce modèle est notamment utilisé dans certains environnements exigeant un contrôle strict de l'accès aux informations.
RBAC : Role-Based Access Control
Le RBAC, ou contrôle d'accès basé sur les rôles, associe des permissions à des rôles attribués aux utilisateurs.
Par exemple :
- Étudiant : consulter ses notes.
- Enseignant : consulter et modifier les notes de ses classes.
- Administrateur : gérer les utilisateurs et les paramètres autorisés.
Ce modèle facilite l'administration des permissions dans les applications comportant plusieurs catégories d'utilisateurs.
ABAC : Attribute-Based Access Control
Le ABAC, ou contrôle d'accès basé sur les attributs, utilise des caractéristiques du sujet, de la ressource, de l'action et du contexte pour déterminer les permissions.
Par exemple, un enseignant peut modifier les notes uniquement si :
- son compte est authentifié ;
- il est responsable de la classe concernée ;
- la période de saisie des notes est ouverte ;
- l'opération demandée est autorisée.
ACL : Access Control List
Une ACL, ou liste de contrôle d'accès, associe à une ressource une liste d'entités et de permissions.
Par exemple, un fichier peut posséder les permissions suivantes :
| Utilisateur | Lecture | Écriture | Suppression |
|---|---|---|---|
| alice | Oui | Oui | Non |
| bob | Oui | Non | Non |
| charles | Non | Non | Non |
Comparaison des modèles
| Modèle | Principe | Exemple |
|---|---|---|
| DAC | Permissions contrôlées par le propriétaire. | Partage d'un fichier. |
| MAC | Politique imposée par une autorité. | Système à classification de sécurité. |
| RBAC | Permissions associées aux rôles. | Gestion des utilisateurs d'une plateforme. |
| ABAC | Décision fondée sur des attributs. | Accès selon le rôle, la classe et le contexte. |
| ACL | Liste de permissions associées à une ressource. | Droits d'accès à un document. |
4. Fonctionnement et mécanismes d'autorisation
Un mécanisme d'autorisation doit évaluer chaque demande d'accès en fonction des règles de sécurité définies pour la ressource concernée.
Étape 1 : identification du sujet
Le système détermine l'entité qui souhaite accéder à une ressource.
Dans une application Web, cette identité peut être associée à une session authentifiée ou à un jeton d'accès valide.
Étape 2 : identification de la ressource
Le système détermine l'objet ciblé par la demande : document, fichier, compte, enregistrement ou fonctionnalité.
Étape 3 : identification de l'action
L'opération demandée peut être une lecture, une modification, une création, une suppression ou une opération administrative.
Étape 4 : évaluation des règles
Le système examine les permissions et les conditions applicables.
Une règle peut notamment dépendre du rôle, de l'appartenance à une organisation, du propriétaire de la ressource ou du contexte de la demande.
Étape 5 : décision
Le mécanisme d'autorisation produit une décision : autoriser ou refuser l'opération.
Une politique de sécurité robuste applique généralement le principe Deny by Default, selon lequel une opération est refusée lorsqu'aucune règle explicite ne l'autorise.
Étape 6 : application de la décision
La décision doit être appliquée par le composant chargé de protéger la ressource, notamment côté serveur pour une application Web.
Le simple masquage d'un bouton dans l'interface ne constitue pas un contrôle d'autorisation suffisant.
Étape 7 : journalisation
Les opérations sensibles et les refus importants peuvent être enregistrés dans des journaux afin de faciliter les audits et les investigations.
Policy Enforcement Point et Policy Decision Point
Dans certaines architectures de contrôle d'accès, on distingue :
- PEP, pour Policy Enforcement Point : composant qui applique la décision d'accès.
- PDP, pour Policy Decision Point : composant qui évalue la politique et détermine si l'accès est autorisé.
- PIP, pour Policy Information Point : source d'informations utilisées pour évaluer les règles.
- PAP, pour Policy Administration Point : composant permettant de gérer les politiques.
Autorisation dans les API
Une API doit vérifier les permissions de chaque demande sensible, même lorsque l'utilisateur est déjà authentifié.
Par exemple, une requête destinée à consulter une facture doit vérifier que le demandeur est autorisé à accéder à cette facture précise.
Les contrôles doivent être réalisés sur le serveur, indépendamment des informations affichées dans le navigateur.
5. Implémentation de l'autorisation avec Python et Django
Python permet d'illustrer les principaux mécanismes d'autorisation. Les exemples suivants utilisent des données fictives et présentent des contrôles simples pouvant servir de base à l'apprentissage du contrôle d'accès.
Exemple 1 : autorisation basée sur un rôle
Le programme suivant vérifie si un utilisateur possède le rôle administrateur avant de lui accorder l'accès à une fonctionnalité sensible. Il illustre le principe du RBAC.
1 2 3 4 5 6 7 8 9 | utilisateur = { "nom": "alice", "authentifie": True, "role": "enseignant" } if utilisateur["authentifie"] and utilisateur["role"] == "administrateur": print("Accès administratif autorisé") else: print("Accès administratif refusé") |
Output :
1 | Accès administratif refusé |
Exemple 2 : associer des permissions à des rôles
Le programme suivant définit un dictionnaire de permissions pour plusieurs rôles. Il vérifie ensuite si un utilisateur peut réaliser l'opération demandée.
1 2 3 4 5 6 7 8 9 10 11 | permissions = { "etudiant": ["lecture"], "enseignant": ["lecture", "ecriture"], "administrateur": ["lecture", "ecriture", "suppression"] } role = "enseignant" action = "ecriture" if action in permissions.get(role, []): print("Action autorisée") else: print("Action refusée") |
Output :
1 | Action autorisée |
Exemple 3 : contrôle d'accès par liste ACL
Le programme suivant utilise un dictionnaire représentant une liste de contrôle d'accès. Chaque utilisateur possède un ensemble de permissions sur une ressource fictive.
1 2 3 4 5 6 7 8 9 10 11 | acl = { "alice": ["lecture", "ecriture"], "bob": ["lecture"], "charles": [] } utilisateur = "bob" action = "ecriture" if action in acl.get(utilisateur, []): print("Permission accordée") else: print("Permission refusée") |
Output :
1 | Permission refusée |
Exemple 4 : autorisation basée sur les attributs
Le programme suivant illustre une politique ABAC. Un enseignant peut modifier les notes uniquement s'il est authentifié, s'il est responsable de la classe et si la période de saisie est ouverte.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | utilisateur = { "authentifie": True, "role": "enseignant", "classe": "2BAC-SM" } classe_demandee = "2BAC-SM" periode_ouverte = True autorise = ( utilisateur["authentifie"] and utilisateur["role"] == "enseignant" and utilisateur["classe"] == classe_demandee and periode_ouverte ) if autorise: print("Modification des notes autorisée") else: print("Modification des notes refusée") |
Output :
1 | Modification des notes autorisée |
Exemple 5 : vérifier le propriétaire d'une ressource
Le programme suivant illustre un contrôle d'autorisation au niveau d'un objet. Un utilisateur ne peut modifier un document que s'il en est le propriétaire et s'il est authentifié.
1 2 3 4 5 6 7 8 9 10 11 12 13 | document = { "id": 15, "titre": "Cours de Python", "proprietaire": "alice" } utilisateur = { "nom": "bob", "authentifie": True } if utilisateur["authentifie"] and document["proprietaire"] == utilisateur["nom"]: print("Modification autorisée") else: print("Modification refusée") |
Output :
1 | Modification refusée |
Exemple 6 : appliquer le principe du moindre privilège
Le programme suivant vérifie qu'un utilisateur possède une permission précise avant de réaliser une opération. L'absence de permission entraîne automatiquement un refus.
1 2 3 4 5 6 | permissions_utilisateur = ["lecture", "commentaire"] action_demandee = "suppression" if action_demandee in permissions_utilisateur: print("Opération autorisée") else: print("Opération refusée : permission insuffisante") |
Output :
1 | Opération refusée : permission insuffisante |
Exemple 7 : vérifier une permission avec Django
Le framework Django possède un système intégré de permissions permettant de contrôler certaines opérations sur les modèles de données.
Le programme suivant suppose qu'un modèle nommé Article appartient à une application Django appelée blog. Il vérifie si l'utilisateur courant possède la permission de modifier les articles.
1 2 3 4 5 | def modifier_article(request): if request.user.is_authenticated and request.user.has_perm("blog.change_article"): print("Modification autorisée") else: print("Modification refusée") |
Output :
1 | Modification autorisée |
Cette sortie correspond au cas où l'utilisateur est authentifié et possède effectivement la permission blog.change_article. Dans une application Django réelle, une vue doit retourner une réponse HTTP appropriée.
Il faut également vérifier les droits sur l'article précis. La permission standard change_article ne garantit pas, à elle seule, qu'un utilisateur peut modifier n'importe quel article particulier.
Exemple 8 : protéger une vue Django avec une permission
Le programme suivant utilise le décorateur permission_required de Django. Il exige que l'utilisateur possède la permission blog.change_article avant d'exécuter la vue.
1 2 3 4 5 | from django.contrib.auth.decorators import permission_required from django.http import HttpResponse @permission_required("blog.change_article", raise_exception=True) def modifier_article(request): return HttpResponse("Accès autorisé à la modification") |
Output :
1 | Accès autorisé à la modification |
Cette sortie représente le contenu de la réponse HTTP lorsque l'utilisateur possède la permission requise. Dans le cas contraire, Django refuse l'accès selon le comportement configuré.
Pour une modification réelle, il faut compléter ce contrôle par une vérification de propriété ou de permission sur l'objet concerné, ainsi que par les protections habituelles des formulaires et des requêtes HTTP.
6. Vulnérabilités et bonnes pratiques de sécurisation
Les défauts d'autorisation constituent une catégorie importante de vulnérabilités dans les applications Web, les API et les infrastructures informatiques.
Broken Access Control
Le Broken Access Control désigne les vulnérabilités permettant à un utilisateur d'effectuer des opérations ou d'accéder à des ressources pour lesquelles il ne possède pas les permissions nécessaires.
Ces vulnérabilités peuvent permettre la consultation, la modification ou la suppression non autorisée de données.
IDOR : Insecure Direct Object Reference
Une vulnérabilité IDOR peut apparaître lorsqu'une application utilise un identifiant de ressource fourni par le client sans vérifier correctement que l'utilisateur est autorisé à accéder à l'objet correspondant.
Par exemple, une application qui affiche une facture à partir de son identifiant doit vérifier que le demandeur possède les droits nécessaires sur cette facture.
Le simple fait d'utiliser un identifiant difficile à deviner ne remplace pas un contrôle d'autorisation.
BOLA : Broken Object Level Authorization
La vulnérabilité BOLA concerne les défauts d'autorisation au niveau des objets, notamment dans les API.
Elle peut permettre à un utilisateur d'accéder à des objets appartenant à d'autres utilisateurs lorsque les vérifications nécessaires sont absentes.
Élévation de privilèges
L'élévation de privilèges consiste à obtenir des permissions supérieures à celles normalement accordées.
Elle peut notamment résulter de défauts de configuration, de vulnérabilités logicielles ou de contrôles d'accès insuffisants.
Contrôle d'accès côté client
Une application ne doit jamais considérer qu'un bouton masqué ou un champ désactivé suffit à empêcher une opération.
Les vérifications d'autorisation doivent être appliquées côté serveur, au niveau des ressources et des opérations protégées.
Appliquer le principe Deny by Default
Le principe Deny by Default consiste à refuser une opération lorsqu'aucune règle explicite ne permet de l'autoriser.
Appliquer le moindre privilège
Les utilisateurs et les services doivent disposer uniquement des permissions nécessaires à leurs activités.
Vérifier les autorisations à chaque requête
Une application doit contrôler les permissions pour chaque opération sensible et pour chaque ressource concernée.
Il ne faut pas supposer qu'une authentification préalable suffit à autoriser toutes les opérations suivantes.
Centraliser les politiques d'accès
Lorsque cela est possible, les règles d'autorisation doivent être regroupées dans des composants cohérents afin de réduire les incohérences et les oublis.
Protéger les API
Les API doivent vérifier les permissions associées aux identités, aux jetons et aux ressources demandées.
Un jeton d'accès valide ne signifie pas automatiquement que toutes les opérations sont autorisées.
Journaliser les opérations sensibles
Les tentatives d'accès refusées, les changements de permissions et les opérations administratives importantes doivent être surveillés.
Tester les différents rôles
Les tests de sécurité doivent vérifier les comportements de l'application pour plusieurs catégories d'utilisateurs, notamment les utilisateurs anonymes, ordinaires et administrateurs.
Éviter les permissions excessives
Les permissions générales, notamment les accès administratifs permanents, doivent être limitées et régulièrement réévaluées.
Réviser régulièrement les droits
Les permissions doivent être mises à jour lorsqu'un utilisateur change de fonction ou quitte une organisation.
Défense en profondeur
Une stratégie de défense en profondeur combine l'autorisation avec l'authentification forte, le chiffrement, la surveillance, les mises à jour et les audits de sécurité.
7. À retenir
L'autorisation est le mécanisme permettant de déterminer les actions qu'un utilisateur, une application ou un système peut effectuer sur une ressource.
Elle se distingue de l'authentification, qui vérifie l'identité, et de l'identification, qui consiste à déclarer cette identité.
Les principaux modèles de contrôle d'accès comprennent DAC, MAC, RBAC et ABAC. Les ACL permettent également d'organiser les permissions associées aux ressources.
Le RBAC repose sur les rôles, tandis que l'ABAC utilise des attributs du sujet, de la ressource et du contexte.
Les mécanismes d'autorisation doivent appliquer le principe du moindre privilège et privilégier le refus par défaut lorsque les conditions d'accès ne sont pas satisfaites.
Les contrôles doivent être réalisés côté serveur et vérifier les permissions sur chaque ressource sensible.
Les vulnérabilités Broken Access Control, IDOR et BOLA illustrent les risques associés à une mauvaise gestion des autorisations.
Python permet de simuler les modèles RBAC, ABAC et ACL. Django fournit également des mécanismes intégrés pour gérer les utilisateurs, les groupes et les permissions.
Enfin, une politique d'autorisation efficace constitue une composante essentielle d'une stratégie de défense en profondeur visant à protéger les systèmes et les données contre les accès non autorisés.
Auteur : Younes Derfoufi
Lieu de travail : CRMEF OUJDA
Site Web : www.tresfacile.net
Chaine YouTube : https://www.youtube.com/user/InformatiquesFacile
Me contacter : https://www.tresfacile.net/me-contacter/
