Matrice d'habilitations et gestion des droits dans le temps

Une matrice d'habilitations est un tableau qui croise les profils de l'organisation (les fonctions) avec ses ressources (applications, dossiers, données), et indique dans chaque case le niveau d'accès autorisé : aucun, lecture, modification, validation, administration. Elle traduit les décisions des responsables en une référence unique, que le service informatique transforme ensuite en groupes, en rôles et en droits techniques. Ce chapitre montre comment la construire, la traduire en SISR comme en SLAM, et la faire vivre : arrivées, mobilités, départs, accès temporaires et revues périodiques.

À quoi sert la matrice

Sans matrice, les droits s'accordent au fil des demandes (« donne-lui les mêmes droits que Karim ») et personne ne peut dire, six mois plus tard, pourquoi tel salarié accède à tel dossier. La matrice apporte :

• une décision documentée : chaque case a été validée par le responsable de la ressource ;
• un modèle pour les arrivées : un nouveau comptable reçoit le profil « comptable », rien de plus ;
• une référence pour les contrôles : on compare les droits réels à la matrice et on corrige les écarts ;
• une preuve de conformité : le RGPD impose de limiter l'accès aux données personnelles aux personnes qui en ont besoin (article 32), et la matrice montre comment c'est fait.

L'indicateur du référentiel, « les droits mis en place correspondent aux habilitations des acteurs », se vérifie exactement ainsi.

Construire la matrice en cinq étapes

1. Inventorier les ressources : applications, dossiers partagés, bases de données, équipements. L'outil de gestion de parc (le cours GLPI et gestion de parc) donne la liste des applications et des serveurs.
2. Inventorier les profils à partir de l'organigramme et des fiches de poste : on raisonne en fonctions, pas en personnes.
3. Définir l'échelle des niveaux : par exemple Aucun, Lecture (L), Modification (M), Validation (V), Administration (A). Pour une base de données, on raisonne souvent en opérations : sélection, ajout, modification, suppression.
4. Faire remplir et valider chaque colonne par le propriétaire de la ressource : le responsable comptable décide qui accède au logiciel comptable, la direction et le délégué à la protection des données sont consultés pour les données personnelles sensibles. Le service informatique conseille et applique, il ne décide pas seul.
5. Traduire, puis revoir : transformer la matrice en groupes et en droits, et la relire au moins une fois par an.

La matrice de Sorbier Logistique

L : lecture, M : modification, V : validation, A : administration, — : aucun accès.

Quelques choix de cette matrice méritent d'être justifiés, comme dans une copie :

• le technicien n'a pas accès aux données métier : réparer un poste ne demande pas de lire la paie (besoin d'en connaître) ;
• la validation dans le logiciel comptable est réservée au responsable : séparation des tâches avec la saisie ;
• la paie n'est accessible qu'au responsable comptable et en lecture à la direction : ce sont des données personnelles sensibles ;
• le stagiaire a une ligne à part, en lecture seule et avec une date de fin.

Côté SISR : traduire la matrice en groupes Active Directory

La matrice se traduit selon la méthode AGDLP du chapitre 7 : un groupe global par profil (une ligne), un groupe de domaine local par ressource et par niveau (une case non vide), et l'imbrication des premiers dans les seconds.

Puis les permissions NTFS : DL_Compta_M en Modification sur D:\Partages\Compta, DL_Compta_L en Lecture, et ainsi de suite. Les applications qui s'appuient sur l'annuaire (directement ou par un fournisseur d'identité) associent de la même façon leurs rôles aux groupes globaux.

# Créer les groupes d'une ressource et les imbriquer selon la matrice
New-ADGroup -Name "DL_Compta_M" -GroupScope DomainLocal -GroupCategory Security `
  -Path "OU=Groupes,DC=ad,DC=sorbier,DC=example"
New-ADGroup -Name "DL_Compta_L" -GroupScope DomainLocal -GroupCategory Security `
  -Path "OU=Groupes,DC=ad,DC=sorbier,DC=example"
Add-ADGroupMember -Identity "DL_Compta_M" -Members "GG_Comptables", "GG_Resp_Comptable"
Add-ADGroupMember -Identity "DL_Compta_L" -Members "GG_Direction"

# Vérifier : qui a réellement accès en modification à la compta ?
Get-ADGroupMember -Identity "DL_Compta_M" -Recursive | Select-Object Name, SamAccountName

Côté SLAM : traduire la matrice dans l'application et dans la base

Dans une application, la matrice devient des données : des tables de rôles et de droits, que le code consulte (la méthode possedeDroit du chapitre 9). Au niveau du SGBD, elle peut aussi devenir des rôles SQL et des GRANT : le cours SQL montre la traduction case par case.

Le sujet SLAM de 2023 (U6, cas Lama Zoo) décrivait un système d'habilitation centralisé : une base BdAuthentification attribue à chaque membre du personnel un rôle par application ; chaque rôle applicatif correspond à un compte du SGBD qui n'a des droits que sur les tables et les vues utiles. Quand l'utilisateur se connecte, l'application lit son rôle, s'en sert pour autoriser les fonctionnalités dans ses contrôleurs, et se connecte à la base métier avec le compte SGBD de ce rôle. L'intérêt, que demandait la question A.3 : même si un contrôle est oublié dans le code, le SGBD refuse les opérations que le rôle n'a pas le droit de faire (défense en profondeur), et une injection SQL ne dispose que des droits de ce rôle.

Des habilitations qui ont une durée de vie

Le même sujet relevait deux défauts dans la première version de la base : les habilitations n'avaient pas de durée de vie, et un même employé pouvait avoir plusieurs rôles pour la même application. Les deux sont des vulnérabilités : un stagiaire parti garde ses droits indéfiniment, et des rôles cumulés donnent des droits que personne n'a décidés.

Une structure qui corrige les deux, en MySQL :

CREATE TABLE Personnel (
  numMatricule INT PRIMARY KEY,
  nom          VARCHAR(50) NOT NULL,
  prenom       VARCHAR(50) NOT NULL
);

CREATE TABLE Application (
  idAppli INT PRIMARY KEY,
  libelle VARCHAR(60) NOT NULL
);

CREATE TABLE RoleApplicatif (
  idRole  VARCHAR(40) PRIMARY KEY,         -- correspond à un compte du SGBD
  idAppli INT NOT NULL,
  UNIQUE (idRole, idAppli),                -- cible de la clé étrangère composée ci-dessous
  FOREIGN KEY (idAppli) REFERENCES Application(idAppli)
);

CREATE TABLE EstHabilite (
  numMatricule INT NOT NULL,
  idAppli      INT NOT NULL,
  idRole       VARCHAR(40) NOT NULL,
  dateDebut    DATE NOT NULL,
  dateFin      DATE NULL,                    -- NULL : pas de fin prévue
  PRIMARY KEY (numMatricule, idAppli),       -- un seul rôle par personne et par application
  FOREIGN KEY (numMatricule) REFERENCES Personnel(numMatricule),
  FOREIGN KEY (idAppli) REFERENCES Application(idAppli),
  -- le rôle appartient bien à cette application
  FOREIGN KEY (idRole, idAppli) REFERENCES RoleApplicatif(idRole, idAppli),
  CHECK (dateFin IS NULL OR dateFin >= dateDebut)
);

La clé primaire sur le couple (personne, application) interdit le second rôle. La clé étrangère composée (rôle, application) empêche d'attribuer, pour l'application 3, un rôle qui appartient à l'application 5 : la base n'accepte que les couples qui existent dans RoleApplicatif. Les colonnes dateDebut et dateFin donnent une durée de vie ; l'application ne retient que les habilitations en cours :

SELECT idRole
FROM EstHabilite
WHERE numMatricule = ? AND idAppli = ?
  AND dateDebut <= CURRENT_DATE
  AND (dateFin IS NULL OR dateFin >= CURRENT_DATE);

Et un événement planifié supprime chaque nuit les habilitations échues, pour que la base reflète la réalité :

CREATE EVENT purger_habilitations_echues
ON SCHEDULE EVERY 1 DAY STARTS '2026-11-02 00:05:00'
DO
  DELETE FROM EstHabilite WHERE dateFin < CURRENT_DATE;

Une ligne dont dateFin est NULL n'est pas supprimée : la comparaison NULL < CURRENT_DATE n'est pas vraie (logique à trois valeurs du SQL).

Tracer chaque changement d'habilitation

Pour pouvoir répondre à la question « qui avait accès à la paie le 15 mars, et qui le lui avait donné ? », chaque attribution, chaque modification et chaque suppression d'habilitation est historisée, automatiquement, par des triggers :

CREATE TABLE HistoHabilitation (
  dateHeure    DATETIME(6) NOT NULL,
  numMatricule INT NOT NULL,
  idAppli      INT NOT NULL,
  action       VARCHAR(255) NOT NULL,
  compteSql    VARCHAR(100) NOT NULL,
  PRIMARY KEY (dateHeure, numMatricule, idAppli)
);

DELIMITER //
CREATE TRIGGER after_insert_habilitation
AFTER INSERT ON EstHabilite
FOR EACH ROW
BEGIN
  INSERT INTO HistoHabilitation (dateHeure, numMatricule, idAppli, action, compteSql)
  VALUES (NOW(6), NEW.numMatricule, NEW.idAppli,
          CONCAT('Attribution du rôle ', NEW.idRole), USER());
END //

CREATE TRIGGER after_update_habilitation
AFTER UPDATE ON EstHabilite
FOR EACH ROW
BEGIN
  IF OLD.idRole <> NEW.idRole OR NOT (OLD.dateFin <=> NEW.dateFin) THEN
    INSERT INTO HistoHabilitation (dateHeure, numMatricule, idAppli, action, compteSql)
    VALUES (NOW(6), OLD.numMatricule, OLD.idAppli,
            CONCAT('Modification : rôle ', OLD.idRole, ' à ', NEW.idRole,
                   ', fin ', IFNULL(OLD.dateFin, 'aucune'), ' à ', IFNULL(NEW.dateFin, 'aucune')),
            USER());
  END IF;
END //

CREATE TRIGGER after_delete_habilitation
AFTER DELETE ON EstHabilite
FOR EACH ROW
BEGIN
  INSERT INTO HistoHabilitation (dateHeure, numMatricule, idAppli, action, compteSql)
  VALUES (NOW(6), OLD.numMatricule, OLD.idAppli,
          CONCAT('Suppression du rôle ', OLD.idRole), USER());
END //
DELIMITER ;

Dans un trigger, OLD désigne la ligne avant la modification et NEW la ligne après (un trigger INSERT n'a que NEW, un trigger DELETE que OLD). L'opérateur <=> compare en tenant compte de NULL : NOT (OLD.dateFin <=> NEW.dateFin) détecte aussi le passage de « pas de fin » à une date, que <> laisserait passer, et IFNULL évite qu'un CONCAT avec NULL renvoie NULL. USER() renvoie le compte qui a envoyé la requête (alors que CURRENT_USER() renverrait, dans un trigger, le compte qui l'a créé). DATETIME(6) garde les microsecondes, pour que deux changements dans la même seconde ne violent pas la clé primaire. Le cours Procédures stockées et triggers détaille la syntaxe.

Le cycle de vie : arrivée, mobilité, départ, accès temporaire

Dans l'annuaire, la date de fin d'un compte temporaire se pose ainsi :

# Le compte de la stagiaire expire automatiquement à la fin de son stage
Set-ADAccountExpiration -Identity "nlopez.stage" -DateTime "2027-06-30"

La revue périodique des habilitations

Même avec une bonne procédure, les écarts s'accumulent. Une revue des habilitations (ou recertification) consiste à présenter à chaque responsable la liste des personnes qui ont accès à ses ressources, et à lui faire confirmer ou retirer chaque accès. Elle a lieu au moins une fois par an, plus souvent pour les accès sensibles et les comptes à privilèges.

Les contrôles techniques qui l'accompagnent :

# Comptes utilisateurs sans connexion depuis 90 jours : à vérifier, puis désactiver
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Select-Object Name, SamAccountName, LastLogonDate

# Comptes dont le mot de passe n'expire jamais : souvent des comptes de service oubliés
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' -Properties PasswordNeverExpires |
  Select-Object Name, SamAccountName

# Membres du groupe le plus sensible
Get-ADGroupMember -Identity "Admins du domaine" -Recursive | Select-Object Name

Les écarts typiques : comptes d'anciens salariés encore actifs, stagiaires sans date de fin, membres d'un groupe qui n'appartiennent plus au service, comptes génériques sans propriétaire, droits accordés « temporairement » il y a deux ans. Chaque correction est tracée dans un ticket.

Comment l'E7 l'interroge

• SLAM (sujet 2023, dossier A, 30 points sur 80) : expliquer l'intérêt des rôles applicatifs au niveau de la connexion à la base ; dire pourquoi l'absence de durée de vie et le cumul de rôles sont des vulnérabilités, puis modifier la base ; écrire le trigger d'historisation des modifications ; expliquer l'intérêt d'une transaction et compléter une fonction de suppression de rôle. Le sujet de 2025 donnait les droits par fonction sous forme de tableau, à traduire en code. Écrire les GRANT correspondant à une matrice est aussi un classique.
• SISR : construire une matrice à partir d'un organigramme ; la traduire en groupes et en permissions ; proposer une procédure d'arrivée et de départ ; analyser le résultat d'une revue (comptes inactifs, groupes trop larges).
• Tronc commun : justifier une case de la matrice par le moindre privilège, le besoin d'en connaître ou la séparation des tâches.

Exercices