Matrice des rôles et permissions

Objectif

La matrice des rôles et permissions attribue à chaque rôle, pour chaque fonction d'une solution, l'autorité qu'il détient sur elle: créer, lire, modifier, supprimer, exécuter, approuver ou rien du tout. Une cellule remplie autorise, une cellule marquée refuse. La ligne porte, selon la convention retenue, l'activité elle-même ou l'objet sur lequel les autorités s'exercent. La technique répond à une question que tout système pose et que personne ne pose à voix haute: quelle fonction exige quel accès. Là où elle n'est pas posée, la réponse est produite au moment du paramétrage, par un développeur ou un intégrateur qui la déduit de ce qui lui semble commode.

La moitié utile de cette décision de conception est le refus. Autoriser un rôle à lire un dossier est une phrase banale; refuser cette lecture à quatre autres rôles est l'exigence que le système devra appliquer, tester et prouver. Ce que la grille décide en aval est considérable: le modèle de rôles qui sera configuré dans la solution cible, les contraintes de séparation des fonctions qu'il faudra tenir, l'étendue de la journalisation et les campagnes de recertification qui suivront pendant toute la vie du système.

Le livrable tient en quatre pièces indissociables. La grille remplie, une ligne par fonction, une colonne par rôle, une autorité par cellule. La liste de définition des rôles, une ligne par rôle: quelle famille de métiers il recouvre, qui en répond, qui l'attribue. Les contraintes qu'une grille ne sait pas dessiner, rôles mutuellement exclusifs, portées du type « son propre dossier seulement », règles d'héritage et de délégation. Et la légende, qui dit ce que vaut une cellule sans autorité: le silence signifie refus, la plateforme refuse par défaut, et cette phrase écrite une fois transforme un tableau en exigence.

Pour un traitement soumis au droit suisse, cette grille est la forme documentaire d'une obligation. La LPD impose au responsable du traitement la protection des données dès la conception (art. 7) et une sécurité adéquate par des mesures techniques et organisationnelles (art. 8). L'OPDo fixe les objectifs de la sécurité, dont la confidentialité (art. 2), et range le contrôle de l'accès aux données parmi les mesures qui assurent cette confidentialité: le responsable du traitement prend les mesures appropriées afin que « les personnes autorisées n'aient accès qu'aux données personnelles dont elles ont besoin pour accomplir leurs tâches » (art. 3 al. 1 let. a).

Usage

Quand l'utiliser

• Populations d'utilisateurs distinctes sur une même solution: des métiers dont les droits ne peuvent pas être identiques.
• Données sensibles ou réglementées: santé, ressources humaines, finances, où chaque lecture se justifie.
• Séparation des fonctions exigée: distinguer qui prépare et qui approuve, avant que le paramétrage ne les confonde.
• Audit ou certification annoncé: établir qui pouvait faire quoi, avant le premier contrôle.
• Paramétrage d'un progiciel ou d'un service en ligne: confronter le modèle de rôles du produit aux métiers réels.
• Droits d'un système existant devenus incohérents: reconstruire une cible, puis la comparer aux droits réellement attribués.
• Interfaces, traitements par lots et comptes de service: leur donner une colonne avant qu'ils ne reçoivent tous les droits.
• Externalisation ou reprise d'une activité: fixer ce que le prestataire voit, au moment où le contrat se négocie.

Quand ne pas l'utiliser

• Population unique aux mêmes droits: une grille à une colonne n'apprend rien, écrire l'unique jeu d'autorisations comme exigence non fonctionnelle.
• Droits dépendant de la donnée ou du contexte: écrire des règles d'attributs plutôt que multiplier les rôles, quand l'accès dépend du propriétaire du dossier, d'un seuil ou d'un horaire.
• Fonctions ou organisation encore instables: la grille sera refaite entièrement, établir d'abord la décomposition fonctionnelle ou le modèle de processus.

Description

Lignes, colonnes, cellules

Les lignes sont les fonctions que la solution exécute. Elles se récoltent dans la décomposition fonctionnelle, le modèle de processus et les cas d'utilisation existants, ce qui garantit qu'aucune fonction n'est oubliée et que chacune est située dans un scénario réel. La maille est le seul vrai jugement de cet axe: une ligne par écran est trop fine, une ligne par module est trop grossière. L'unité exploitable est une action qu'un utilisateur peut se voir autoriser ou refuser, ce qui correspond le plus souvent à un cas d'utilisation ou à une user story.

Deux conventions d'écriture coexistent, et les confondre produit une grille incohérente. Le BABOK marque ses cellules d'une croix: la ligne y est une activité complète, « créer un compte », « consulter les rapports », et la cellule dit seulement permis ou non permis. La pratique écrit plutôt les verbes créer, lire, modifier et supprimer, que le guide situe lui-même au niveau du système d'information, dans la matrice CRUD. Avec les verbes, la ligne devient l'objet sur lequel ils portent, le dossier, la facture, le paramètre, et les lettres fournissent les actions. Une même grille tient l'une ou l'autre convention, jamais les deux, sous peine de cellules dont le sens change d'une ligne à l'autre.

Les colonnes sont les rôles. Elles se dérivent des modèles d'organisation, des cahiers des charges, des manuels de procédure et des guides utilisateur du système, puis se complètent en séance avec chaque domaine métier, parce que les documents décrivent l'organisation telle qu'elle a été décidée, alors que la séance montre comment elle travaille. Le critère de regroupement est la communauté des fonctions exercées: deux rattachements hiérarchiques distincts peuvent tenir le même rôle. Les rôles non humains sont des colonnes à part entière: interfaces avec des systèmes partenaires, traitements par lots, comptes techniques, agents logiciels. Ils reçoivent en général les droits les plus étendus du système, précisément parce que personne ne leur a donné de colonne.

Les cellules portent les autorités. Le vocabulaire dépasse vite les quatre verbes, et chaque ajout correspond à une décision réelle: exécuter pour lancer un traitement ou produire un rapport, approuver pour la décision de flux de travail qui porte l'essentiel des contraintes de séparation des fonctions, exporter ou imprimer pour l'action qui fait sortir la donnée du système contrôlé, ce qui en fait un droit distinct de la lecture, déléguer pour l'autorité qu'un titulaire peut transmettre à un autre, temporairement ou durablement. S'y ajoutent les qualificatifs de portée, lire son propre dossier plutôt que tous les dossiers, lire dans sa propre unité plutôt que dans toute l'entreprise. Le guide traite explicitement l'héritage et la délégation comme des raffinements de la grille, c'est-à-dire comme des décisions à prendre.

Le rôle est une étiquette de groupe

Un rôle désigne un groupe d'individus qui partagent des fonctions communes. Deux personnes portant le même intitulé de poste peuvent tenir des rôles différents; deux intitulés différents peuvent recouvrir le même rôle. C'est la règle de conception dont dépend la grille entière: une colonne nommée d'après la personne qui occupe aujourd'hui le poste encode une carrière, et elle devient un jeu de droits que plus personne ne sait justifier le jour où cette personne s'en va.

L'indirection que la grille dessine est celle du contrôle d'accès fondé sur les rôles, formalisé par Ferraiolo et Kuhn au NIST en 1992 puis normalisé sous ANSI/INCITS 359. Les personnes sont rattachées à des rôles, les rôles sont rattachés à des permissions, et aucune permission n'est jamais attribuée directement à une personne. Sandhu, Ferraiolo et Kuhn en décrivent quatre niveaux cumulatifs, dont chacun ajoute exactement une exigence: le RBAC plat, où les utilisateurs acquièrent leurs permissions par leurs rôles et où l'on peut savoir quels rôles une personne détient et quelles personnes détiennent un rôle; le RBAC hiérarchique, qui autorise l'héritage entre rôles; le RBAC contraint, qui ajoute les contraintes de séparation des fonctions; le RBAC symétrique, qui ajoute la revue inverse, savoir pour une permission donnée quels rôles la détiennent. Ce dernier niveau est celui que réclame tout auditeur. Il est aussi le plus rarement atteint.

Remplir la grille

1. Fixer le périmètre et le niveau d'abstraction
   Fonctions du système ou activités de processus, jamais les deux dans la même grille. Le niveau de détail est la limite que le guide reconnaît lui-même à la technique.
2. Récolter les fonctions
   Dans la décomposition fonctionnelle, le modèle de processus et les cas d'utilisation. Si aucun de ces artefacts n'existe, la technique est prématurée.
3. Dériver les rôles
   Des documents d'organisation, puis tenir une courte séance par domaine métier pour trouver les rôles manquants et fusionner les doublons. Écrire la définition d'une ligne de chaque rôle immédiatement.
4. Remplir ligne par ligne
   Jamais colonne par colonne: la lecture par ligne oblige à demander « qui d'autre touche à cette fonction », et c'est ainsi que les rôles oubliés apparaissent, ce que le guide compte parmi les finalités mêmes de la technique.
5. Passer les deux règles sur la grille remplie
   Moindre privilège: ce rôle peut-il faire son travail sans cette autorité. Séparation des fonctions: un rôle initie-t-il et approuve-t-il la même transaction. Les deux règles produisent des modifications de cellules.
6. Faire relire séparément par le métier et par la révision
   Le responsable métier valide que le travail reste faisable, la révision interne et le conseiller à la protection des données valident qu'il ne peut pas être détourné. Les deux relectures trouvent des défauts différents.
7. Confronter à la réalité
   Si le système existe, extraire les droits réellement attribués et les comparer à la grille. Les écarts sont soit des défauts de la matrice, soit des accès non autorisés.
8. Fixer la cadence d'entretien avant de conclure
   Un propriétaire nommé par rôle, un intervalle de recertification et les événements déclencheurs, arrivée, mutation, départ, nouvelle fonction livrée.

Le moindre privilège et la séparation des fonctions

Le moindre privilège vient de Saltzer et Schroeder, dont la formulation de 1975 tient encore: « Every program and every user of the system should operate using the least set of privileges necessary to complete the job. », soit le plus petit jeu de privilèges nécessaire à l'accomplissement de la tâche. Le même article donne la séparation des privilèges, selon laquelle un mécanisme de protection exigeant deux clés est plus robuste que celui qui s'ouvre à une seule. Le NIST en donne la version opérationnelle dans la famille AC de la SP 800-53: chaque entité reçoit le minimum de ressources et d'autorisations nécessaires à sa fonction. En droit suisse, cette règle d'ingénierie est devenue une obligation, à l'article 3 alinéa 1 lettre a OPDo.

La séparation des fonctions interdit qu'un utilisateur détienne à lui seul assez de privilèges pour détourner le système, l'exemple canonique étant que celui qui autorise un salaire ne doit pas pouvoir le préparer. Elle s'applique statiquement, par des rôles mutuellement exclusifs qu'une même personne ne peut pas cumuler, ou dynamiquement, par une règle de double intervention au moment de la transaction. La SP 800-192 énonce la contrainte que la grille doit exprimer: si un rôle demande une dépense et qu'un autre l'approuve, l'organisation peut interdire l'attribution des deux rôles au même utilisateur. Cette contrainte ne se dessine pas dans une grille à deux axes, et c'est pourquoi la liste des contraintes est une pièce du livrable.

La journalisation est le pendant du refus. Le droit suisse la règle. Lors de traitements automatisés de données sensibles à grande échelle ou de profilage à risque élevé, et lorsque les mesures préventives ne suffisent pas à garantir la protection des données, l'OPDo art. 4 impose de journaliser au moins l'enregistrement, la modification, la lecture, la communication, l'effacement et la destruction des données. La lecture est donc un événement journalisé, ce qui fait d'une cellule de lecture une décision de sécurité à part entière. Le même seuil déclenche un règlement de traitement (art. 5), dont la matrice est l'annexe naturelle. Côté certification, les mesures que citera l'auditeur sont celles de l'annexe A d'ISO/IEC 27001:2022: 5.15 contrôle d'accès, 5.16 gestion des identités, 5.18 droits d'accès, 8.2 droits d'accès privilégiés, 5.3 séparation des tâches, qui est la séparation des fonctions sous le nom que la norme lui donne.

De la cellule à l'exigence

Chaque cellule non vide se réécrit en une phrase testable: le rôle R détient l'autorité A sur la fonction ou l'objet O, dans la portée S. Cette phrase entre dans le référentiel d'exigences, se trace au cas d'utilisation dont elle provient et engendre deux cas de test: le positif, où le rôle réussit, et le négatif, où tous les autres rôles échouent. Le second est celui que les équipes sautent. Il est pourtant le seul à démontrer que le contrôle d'accès fonctionne: un système qui autorise correctement et refuse mal passe tous les tests fonctionnels.

L'héritage et la délégation s'écrivent hors de la grille, sous une forme fixe. Une règle d'héritage tient en une ligne de la liste des contraintes: l'autorité concernée, le niveau hiérarchique depuis lequel elle s'applique, les unités subordonnées qu'elle atteint. Une délégation en tient une autre: l'autorité délégable, le rôle qui la détient, le rôle ou la portée qui peut la recevoir, la durée, l'événement qui la révoque. Chacune engendre son propre test négatif, celui qui vérifie qu'un responsable ne reçoit pas par héritage une autorité que la grille refuse à son équipe, celui qui vérifie qu'une délégation échue ne laisse aucun droit derrière elle.

À côté des cellules, la grille engendre des exigences d'administration que l'on oublie parce qu'elles ne sont écrites nulle part dans le tableau: qui attribue un rôle, quelle approbation cette attribution demande, à quelle fréquence les attributions sont recertifiées, comment elles sont révoquées et ce qui se passe lors d'une mutation interne. Ces exigences décident si la matrice reste vraie six mois après la mise en service.

La frontière avec les deux autres matrices

Trois grilles se ressemblent et se confondent sur le terrain: celle-ci, la matrice RACI et la matrice CRUD de complétude. Ce qui les sépare est le sens d'une cellule. La raison pour laquelle la RACI ne peut pas être fondue dans celle-ci est que consulté et informé sont des états de communication entre personnes: une fonction ne se consulte pas, et un système ne sait pas appliquer ces deux lettres.

Les pièges

L'explosion des rôles

Un rôle par combinaison de permissions. Le symptôme est visible: plus de rôles que de familles de métiers, des rôles qui diffèrent d'une seule cellule, des noms qui portent un qualificatif comme Gestionnaire_VD_lecture_seule. La cause est constante, encoder le contexte, la portée, le seuil ou la propriété dans le nom du rôle. Kuhn, Coyne et Weil chiffrent la limite: implémenter n conditions d'attributs dans un modèle de rôles peut demander jusqu'à 2ⁿ rôles, et le RBAC soutient mal les attributs dynamiques tels que l'heure de la journée. Leur conclusion est le partage à retenir: le modèle de rôles échange un effort de structuration initial contre une administration et une revue faciles, l'approche par attributs fait le troc inverse, facile à mettre en place et pénible à analyser. La matrice reste l'artefact juste pour la couche stable, celle des familles de métiers; la couche contextuelle s'écrit en règles, et les deux cohabitent.

La matrice jamais rejouée

Écrite pendant le projet, exacte le jour de la mise en service, jamais rouverte ensuite. Rien ne se périme plus vite: chaque livraison apporte des fonctions nouvelles, et chacune arrive sans ligne.

Les droits accumulés

La même dérive s'aggrave par accumulation. Le départ se voit et se traite; la mutation interne est silencieuse, parce qu'elle ajoute le nouveau rôle sans retirer l'ancien. Après trois mouvements, une personne détient une combinaison que personne n'a jamais approuvée et qui rompt la séparation des fonctions.

L'écart entre la matrice et les droits réellement attribués

La matrice est une exigence, la table des habilitations du système est un fait, et les deux divergent dès le premier accès d'urgence accordé un vendredi soir. Sans confrontation périodique, le document devient une décoration, plus dangereuse que rien puisqu'il sera présenté à un auditeur comme une preuve.

Les cellules vides sans légende

Un vide lu comme « pas encore décidé » par l'analyste et comme « aucun accès » par le développeur ou l'inverse. Une phrase dans la légende et une plateforme qui refuse par défaut suffisent à fermer le sujet.

L'accès fonctionnel confondu avec l'accès aux données

Pouvoir ouvrir l'écran des factures et pouvoir voir les montants de toutes les factures sont deux droits distincts, et une grille qui s'arrête à l'écran laisse le second à l'appréciation du développeur.

L'héritage implicite

Un responsable d'équipe détient-il automatiquement tout ce que son équipe détient. Tant que la réponse n'est pas écrite, elle est prise par défaut, et elle double les droits de toute une ligne hiérarchique.

Le rôle sans propriétaire nommé

La campagne de recertification n'a alors personne à qui poser la question, et la réponse devient « tout approuver ». Un rôle sans propriétaire est un rôle que personne ne retirera jamais.

Considérations IA

La fouille de rôles est l'application la plus mûre de l'IA à cette technique. Son mode de défaillance est précis. Des algorithmes de regroupement appliqués aux habilitations existantes proposent des rôles construits par le bas, à partir de ce que les gens détiennent réellement. C'est une contre-épreuve utile de la matrice construite par le haut, où les écarts sont les découvertes. Employée comme point de départ, la même technique blanchit les droits excédentaires existants: ce que les gens détiennent aujourd'hui devient la définition officielle du rôle de demain. On fouille pour contredire la grille, jamais pour la produire.

Un modèle de langage rédige la grille; il ne répond d'aucune cellule. Nourri des cas d'utilisation et de la liste des rôles, il produit en quelques secondes une matrice complète et plausible, et une permission fausse mais plausible est une vulnérabilité qui part en production. L'économie de la technique est inhabituelle: le remplissage n'a jamais été la partie coûteuse, et la relecture, un propriétaire métier nommé qui confirme chaque ligne, ne diminue pas d'une minute. L'usage rentable est double, produire la grille candidate et produire les cas de test négatifs, ligne par ligne, qui sont fastidieux et que personne n'écrit à la main.

La détection d'anomalies sur les habilitations mérite d'être nommée séparément, parce qu'elle attaque la vraie cause d'échec des recertifications, la fatigue du relecteur. Le repérage d'écarts par rapport au groupe de pairs, cette personne détient une permission que personne d'autre de sa famille de métiers ne détient, transforme une campagne de plusieurs centaines de lignes à tamponner en une revue des vingt lignes qui diffèrent.

Les agents logiciels posent une question de conception que la matrice doit trancher explicitement. Un assistant qui agit pour le compte d'un utilisateur est un sujet du modèle d'accès, et la grille doit dire s'il agit avec ses propres permissions ou avec les permissions déléguées de la personne qui l'a invoqué. Le raffinement de la délégation est exactement le bon endroit pour cette décision. Le sujet voisin est la recherche documentaire: un assistant qui indexe une base avec un unique compte technique capable de tout lire reproduit les accès de ce compte pour chaque utilisateur qui l'interroge. Le filtrage des permissions doit se faire au moment de la requête, contre la même matrice, faute de quoi le composant le plus récent de l'architecture contourne le contrôle d'accès que tout le reste applique.

Exemples

Le concept que la grille rend visible est le refus: elle écrit ce qu'un rôle ne peut pas faire avec la même précision que ce qu'il peut faire. Le cas est le module de traitement des remboursements d'une caisse maladie, écrit à la convention des verbes, donc une ligne par objet traité. Selon l'art. 57 al. 7 LAMal, le médecin-conseil ne transmet aux organes compétents de l'assureur que les indications dont ceux-ci ont besoin pour décider de la prise en charge d'une prestation, pour fixer la rémunération, pour calculer la compensation des risques ou pour motiver une décision. La ligne des indications médicales traduit cette restriction en autorités: une seule colonne lit, les cinq autres sont refusées.

Deux autres lignes portent une contrainte qui ne se négocie pas. La décision de remboursement sépare le C et le U du gestionnaire de l'approbation du responsable d'équipe, de sorte qu'aucun rôle ne prépare et n'approuve la même décision. Le journal des accès porte une seule autorité, la lecture par la révision interne, sans modification et sans suppression pour quiconque: la journalisation des lectures que l'OPDo impose sur des données de santé traitées à grande échelle ne prouve rien si un rôle peut la retoucher.

Trois contraintes de ce module ne se dessinent pas dans la grille et appartiennent au livrable au même titre qu'elle.

• Rôles mutuellement exclusifs: une même personne ne peut pas détenir à la fois Gestionnaire de prestations et Responsable d'équipe, faute de quoi la séparation lisible sur la ligne de la décision se reconstitue dans une seule tête.
• Le journal est écrit par le système: aucun rôle ne détient C sur cette ligne, ce qui en fait un contrôle.
• Le refus vise une fonction, le droit d'accès reste entier: l'assuré ne lit pas les indications médicales dans le portail, et son droit d'accès aux données le concernant s'exerce par la procédure que prévoit la LPD.

Visualisations

Le livrable est un tableau exploitable. L'usage réel de l'artefact tient dans ses deux sens de lecture: la ligne pour préparer une exigence, « qui touche à cette fonction », la colonne pour préparer une attribution de rôle, « voici tout ce que ce rôle détient ». Une image de grille perd les deux, ainsi que le tri, le filtre et les contrôles par formule qui font la valeur d'entretien de l'artefact.

Quatre conventions séparent une grille exploitable d'un dessin. La légende définit chaque lettre pour ce système-ci, y compris la lettre du refus. Le refus est écrit, par un signe visible, puisqu'une case vide se lit de deux manières. La portée figure dans la cellule, parce qu'une autorité limitée à son propre dossier n'est pas la même autorité. L'approbation se distingue visuellement des verbes d'écriture, car c'est elle que l'on contrôle du regard pour vérifier la séparation des fonctions.

Coût

Le coût dominant est la relecture récurrente. Recertifier les attributions et rouvrir la grille à chaque livraison qui ajoute une fonction dépasse, sur la durée de vie de la solution, tout ce qu'a coûté la construction initiale. Une matrice budgétée comme un livrable de projet est une matrice qui cessera d'être vraie.

Outils

Le tableur reste le bon outil pour l'artefact d'analyse, plus longtemps qu'on ne le croit: jusqu'à une quinzaine de rôles et une soixantaine de fonctions, avec une mise en forme conditionnelle qui fait ressortir les lignes sans aucune autorité et les rôles qui détiennent tout. Au-delà, il cesse d'être relu. Quand la matrice doit vivre à côté des exigences qu'elle trace et porter un historique des modifications, elle se tient dans l'outil d'exigences ou l'espace collaboratif de l'équipe, Confluence, Jira ou Azure DevOps.

Les ateliers de modélisation changent la nature de l'objet. Là où les rôles, les fonctions et les objets de données existent déjà comme éléments de modèle, les vues matricielles de Sparx Enterprise Architect ou les relations d'accès d'ArchiMate dans Archi produisent la grille comme une vue sur le modèle, qui suit chaque changement de celui-ci.

La plateforme cible mérite d'être ouverte avant de figer la maille des lignes, car sa plus petite unité attribuable est le plancher réel d'une ligne: rôles et groupes de Microsoft Entra ID, profils et jeux de permissions de Salesforce, rôles et objets d'autorisation de SAP, listes de contrôle d'accès de ServiceNow, Keycloak, Okta. Une grille plus fine que la plateforme produit des exigences qu'aucun paramétrage ne peut satisfaire.

Les plateformes de gouvernance des identités, SailPoint, Saviynt, Omada, One Identity ou Microsoft Entra ID Governance, servent le moment où il faut prouver que les accès sont corrects: campagnes de recertification, moteurs de règles de séparation des fonctions, automatisation des arrivées, mutations et départs et l'extraction des habilitations que l'on confronte à la matrice. Leur coût se justifie dès que cette confrontation est manuelle et annuelle. Leurs fonctions de fouille de rôles servent la contre-épreuve, jamais la construction. Quand les règles deviennent contextuelles, un moteur de politiques, Open Policy Agent avec Rego, AWS Cedar ou une implémentation XACML, porte la couche que la grille ne peut pas porter, celle-ci gardant les rôles stables. Enfin, là où un catalogue de conflits de séparation des fonctions existe déjà pour les processus métier, les suites de contrôle d'accès des progiciels de gestion intégrés, SAP GRC Access Control et ses équivalents, évitent de le redériver à la main.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.39 Roles and Permissions Matrix: la définition du rôle comme étiquette d'un groupe partageant des fonctions communes, la figure dont les cellules portent une croix, les trois éléments (identification des rôles, identification des activités, autorités), les raffinements que sont la délégation et l'héritage, les sources de dérivation des lignes et des colonnes, ainsi que la limite reconnue du niveau de détail.
• Ferraiolo, D. F. et Kuhn, D. R., Role-Based Access Controls, 15th National Computer Security Conference, NIST, 1992: l'article fondateur du contrôle d'accès fondé sur les rôles et de l'indirection entre utilisateurs, rôles et permissions.
• Sandhu, R., Ferraiolo, D. et Kuhn, R., The NIST Model for Role-Based Access Control: Towards a Unified Standard, 5th ACM Workshop on Role-Based Access Control, 2000: les quatre niveaux cumulatifs, plat, hiérarchique, contraint et symétrique, dont chacun ajoute une exigence unique.
• NIST, Role Based Access Control (page de projet): la normalisation du modèle sous ANSI/INCITS 359-2004, révisée en INCITS 359-2012.
• Saltzer, J. H. et Schroeder, M. D., The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975: la source primaire du moindre privilège et de la séparation des privilèges.
• Kuhn, D. R., Coyne, E. J. et Weil, T. R., Adding Attributes to Role-Based Access Control, IEEE Computer 43(6), 2010, p. 79-81: l'explosion des rôles, la borne de 2ⁿ rôles pour n conditions d'attributs et le partage entre modèle de rôles et modèle d'attributs.
• NIST, SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations: la définition du contrôle d'accès fondé sur les attributs, pour la couche contextuelle que la grille ne porte pas.
• NIST, SP 800-192, Verification and Test Methods for Access Control Policies/Models: la séparation des fonctions comme contrainte formelle, statique ou dynamique, et son expression sur des rôles mutuellement exclusifs.
• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, famille AC: le moindre privilège et la séparation des fonctions comme mesures applicables et vérifiables.
• ISO/IEC, ISO/IEC 27001:2022, annexe A: les mesures 5.15 contrôle d'accès, 5.16 gestion des identités, 5.18 droits d'accès, 8.2 droits d'accès privilégiés et 5.3 séparation des tâches, citées par leur désignation.
• Confédération suisse, Loi fédérale sur la protection des données (LPD), RS 235.1: art. 7, protection des données dès la conception, et art. 8, sécurité des données par des mesures techniques et organisationnelles appropriées.
• Confédération suisse, Ordonnance sur la protection des données (OPDo), RS 235.11: art. 2 objectifs, art. 3 al. 1 let. a contrôle de l'accès aux données, art. 4 journalisation incluant la lecture, art. 5 règlement pour les traitements automatisés.
• Confédération suisse, Loi fédérale sur l'assurance-maladie (LAMal), RS 832.10: art. 57 al. 7, les seules indications que le médecin-conseil transmet aux organes compétents de l'assureur.