Contrôle d'accès : RBAC, ABAC et principe du moindre privilège

Le contrôle d'accès décide, à chaque demande, si un utilisateur authentifié peut effectuer une action sur une ressource. Le modèle le plus utilisé en entreprise est le RBAC (Role-Based Access Control), où les droits sont attribués à des rôles et les rôles aux personnes ; l'ABAC (Attribute-Based Access Control) affine la décision avec des attributs et le contexte. Quel que soit le modèle, le principe du moindre privilège s'applique : chaque compte ne reçoit que les droits strictement nécessaires à sa mission.

Les modèles de contrôle d'accès

Le RBAC en détail

Dans le RBAC, on ne donne jamais un droit directement à une personne. On définit des rôles qui correspondent à des fonctions (comptable, technicien, responsable de service), on attribue des permissions aux rôles, puis on affecte les utilisateurs aux rôles.

Les avantages sont immédiats : une arrivée ou un départ se traite en ajoutant ou en retirant un rôle ; un audit consiste à relire une dizaine de rôles plutôt que des centaines de droits individuels ; la matrice d'habilitations se traduit directement en rôles (chapitre 11).

Deux dérives à surveiller :

• l'explosion des rôles : à force de créer un rôle pour chaque exception (« comptable mais qui voit aussi les notes de frais du commercial »), on finit avec plus de rôles que de salariés ;
• le rôle fourre-tout : un rôle « utilisateur avancé » qui cumule des droits sans rapport, donné à tout le monde pour éviter les demandes.

L'ABAC : quand le rôle ne suffit pas

Certaines règles ne s'expriment pas avec des rôles :

• un commercial ne voit que les clients de sa région ;
• un responsable valide les notes de frais de son équipe, pas celles des autres ;
• l'accès à la paie n'est possible que depuis un poste géré, en heures ouvrées.

L'ABAC évalue une règle sur des attributs : de la personne (service, région, niveau), de la ressource (propriétaire, classification), de l'action (lecture, suppression) et du contexte (heure, adresse IP, état du poste). Il est plus fin, mais plus difficile à auditer. En pratique, on combine les deux : le RBAC donne les droits de base, des règles ABAC les restreignent.

Les principes à citer dans une copie

Côté SLAM : le contrôle d'accès défaillant

Le contrôle d'accès défaillant (Broken Access Control) est en tête du Top 10 de l'OWASP, édition 2025 comme édition 2021. Il prend trois formes :

• l'élévation verticale : un utilisateur ordinaire accède à une fonction d'administration (/admin/utilisateurs répond sans vérifier le rôle) ;
• l'élévation horizontale : un utilisateur accède aux données d'un autre utilisateur de même niveau ;
• la référence directe non sécurisée (IDOR, Insecure Direct Object Reference) : l'application utilise un identifiant fourni par le client sans vérifier qu'il appartient bien à l'utilisateur. GET /api/notes-de-frais/1043 renvoie la note 1043, quel que soit son propriétaire ; il suffit de changer le nombre.

Le sujet SLAM de 2024 (U6) en donnait un exemple : dans l'API d'une application de formations, aucune route ne vérifiait l'utilisateur appelant, seul le code de l'application cliente le faisait avant d'appeler l'API. Conséquence : quiconque connaît l'adresse de l'API peut l'appeler directement, avec Postman ou curl, et lire ou modifier les données sans aucun contrôle.

La correction se fait côté serveur, en deux étages. D'abord le rôle, avec un middleware (ici en Express, après le middleware proteger du chapitre 5 qui a vérifié le jeton) :

// Fabrique de middleware : n'autorise que les rôles listés
export const autoriser = (...rolesAutorises) => (req, res, next) => {
  if (!req.utilisateur) {
    return res.status(401).json({ erreur: 'Non authentifié' });
  }
  if (!rolesAutorises.includes(req.utilisateur.role)) {
    return res.status(403).json({ erreur: 'Accès interdit' });
  }
  next();
};

// Seul un comptable valide une note de frais
app.post('/api/notes-de-frais/:id/validation', proteger, autoriser('comptable'), validerNote);

Ensuite la propriété de la donnée, que le rôle ne suffit pas à garantir : la requête SQL filtre sur l'utilisateur connecté, pris dans le jeton vérifié, jamais dans la requête du client.

// Un salarié ne lit que SES notes de frais : le filtre porte sur l'identifiant du jeton
app.get('/api/notes-de-frais/:id', proteger, async (req, res) => {
  const [lignes] = await db.execute(
    'SELECT * FROM note_frais WHERE id = ? AND id_salarie = ?',
    [req.params.id, req.utilisateur.id],
  );
  if (lignes.length === 0) {
    return res.status(404).json({ erreur: 'Note introuvable' });   // ne révèle pas qu'elle existe
  }
  res.json(lignes[0]);
});

Dans le sujet de 2025 (cas Casterman), les droits étaient stockés par fonction, table par table et opération par opération (sélection, ajout, modification, suppression), et il fallait écrire en Java la méthode possedeDroit(uneTable, uneOperation) de la classe Utilisateur. Une écriture possible, en supposant que la fonction de l'utilisateur expose sa liste de droits :

/** Vrai si la fonction de l'utilisateur autorise l'opération sur la table. */
public boolean possedeDroit(String uneTable, String uneOperation) {
    for (Droit d : saFonction.getLesDroits()) {
        if (d.getTable().equals(uneTable) && d.getOperation().equals(uneOperation)) {
            return true;
        }
    }
    return false;   // refus par défaut : aucun droit trouvé
}

Le return false final est le refus par défaut : une table ou une opération oubliée dans la configuration est interdite, pas autorisée. Les droits du compte de base de données utilisé par l'application complètent ce contrôle (GRANT et les rôles MySQL).

Côté SISR : les droits sur les fichiers et les serveurs

Sur un serveur de fichiers Windows, deux couches de droits s'appliquent à un dossier partagé :

• les autorisations de partage, vérifiées quand on accède par le réseau (\\srv-fichiers\Compta) ;
• les autorisations NTFS, vérifiées dans tous les cas, en local comme par le réseau.

Le droit effectif par le réseau est le plus restrictif des deux. Au sein de NTFS, les autorisations des différents groupes d'un utilisateur s'additionnent, mais un refus explicite l'emporte sur une autorisation. Une pratique courante : des autorisations de partage larges (Modification pour les utilisateurs authentifiés) et tous les réglages fins en NTFS, donnés à des groupes de domaine local selon AGDLP (chapitre 7). On évite les refus explicites, difficiles à suivre, et on désactive l'héritage seulement quand c'est nécessaire.

Sur un serveur Linux, les droits rwx du propriétaire, du groupe et des autres (chmod 750 /srv/compta : tout pour le propriétaire, lecture et accès pour le groupe, rien pour les autres), les ACL pour les cas plus fins (setfacl -m g:compta:rx /srv/archives), et sudo pour les privilèges : on autorise une commande précise à un groupe précis plutôt que de donner le mot de passe de root.

# /etc/sudoers.d/techniciens : les techniciens redémarrent le serveur web, rien d'autre
%techniciens ALL=(root) /usr/bin/systemctl restart apache2

Le cours Administration Linux détaille les droits et sudo.

Comment l'E7 l'interroge

• SLAM : identifier un contrôle d'accès défaillant dans un extrait de code (IDOR, rôle lu dans la requête, route sans contrôle) ; écrire une méthode qui vérifie un droit (possedeDroit, sujet 2025) ; expliquer l'intérêt de rôles applicatifs différents au niveau de la connexion à la base (sujet 2023) ; écrire des tests unitaires qui vérifient qu'un rôle ne peut pas faire une action.
• SISR : calculer un droit effectif (partage et NTFS) ; proposer une organisation des groupes ; restreindre les privilèges d'un compte de service ; configurer sudo pour une tâche précise.
• Tronc commun : définir le moindre privilège, le besoin d'en connaître, la séparation des tâches, et les appliquer au contexte.

Pour aller plus loin. Le contrôle d'accès défaillant est la première catégorie de l'OWASP Top 10 : le chapitre Contrôle d'accès défaillant (A01) du cours Sécurité applicative détaille les IDOR et leurs corrections.

Exercices

CREATE USER 'app_tickets'@'10.0.1.20' IDENTIFIED BY 'Phrase-de-passe-longue-et-unique-2026';
GRANT SELECT ON parc.* TO 'app_tickets'@'10.0.1.20';
GRANT INSERT, UPDATE ON parc.ticket TO 'app_tickets'@'10.0.1.20';
GRANT INSERT ON parc.intervention TO 'app_tickets'@'10.0.1.20';