Modèles d’autorisation : RBAC, MAC et DAC

Les modèles de contrôle d’accès définissent les règles et les politiques qui déterminent quels sujets (utilisateurs, processus) peuvent accéder à quels objets (fichiers, systèmes, données). Le modèle choisi détermine qui peut accorder l’accès, comment les permissions sont attribuées et comment leur application fonctionne. L’examen Security+ couvre quatre modèles principaux : le contrôle d’accès discrétionnaire (DAC), le contrôle d’accès obligatoire (MAC), le contrôle d’accès fondé sur les rôles (RBAC) et le contrôle d’accès fondé sur des règles. Il est essentiel de comprendre les atouts de chaque modèle et les cas d’utilisation auxquels il convient pour concevoir des systèmes d’autorisation efficaces.

Dans le contrôle d’accès discrétionnaire (DAC), le propriétaire de la ressource décide qui peut accéder à ses ressources et peut accorder ou révoquer l’accès d’autres utilisateurs. L’aspect « discrétionnaire » signifie que les propriétaires prennent les décisions : le système applique leurs décisions, mais ne les impose pas. C’est le modèle utilisé dans la plupart des environnements informatiques personnels (permissions de fichiers Windows NTFS, permissions de fichiers Linux/Unix). La limite de sécurité du DAC est qu’il exige de chaque propriétaire de ressource qu’il prenne les bonnes décisions en matière d’accès : un utilisateur qui reçoit l’accès à un fichier peut accorder cet accès à d’autres personnes sans intervention d’un administrateur, ce qui risque de diffuser des données sensibles au-delà du public prévu.

Le DAC comporte deux risques de sécurité inhérents. Accès transitif : l’utilisateur A accorde l’accès à l’utilisateur B, qui l’accorde à son tour à l’utilisateur C — le propriétaire initial peut même ignorer que C a accès à sa ressource. Le problème du député confus : un programme privilégié agissant au nom d’un utilisateur moins privilégié peut utiliser involontairement ses privilèges d’une manière que l’utilisateur ne pourrait pas employer directement. Dans les environnements DAC, un seul compte compromis peut potentiellement accéder à toutes les ressources auxquelles cet utilisateur a reçu accès et peut accorder à d’autres personnes un accès avant que la compromission ne soit détectée. Le DAC est pratique, mais complique le confinement strict de l’information.

Dans le contrôle d’accès obligatoire (MAC), le système d’exploitation applique des politiques d’accès fondées sur des étiquettes de sécurité attribuées aux sujets (utilisateurs) et aux objets (données). Les utilisateurs ne peuvent ni remplacer ni modifier ces politiques ; seul l’administrateur système ou la politique de sécurité peut les modifier. Le MAC est utilisé dans les environnements gouvernementaux et militaires où les informations classifiées doivent être strictement compartimentées. Un utilisateur disposant d’une habilitation « Secret » ne peut pas accéder à des données portant l’étiquette « Top Secret », même si le propriétaire des données souhaite lui en accorder l’accès. Le modèle Bell-LaPadula (pas de lecture vers un niveau supérieur, pas d’écriture vers un niveau inférieur) et le modèle Biba (pas d’écriture vers un niveau supérieur, pas de lecture depuis un niveau inférieur) sont des implémentations formelles du MAC.

Deux modèles MAC formels expriment les objectifs de sécurité sous forme de règles mathématiques. Bell-LaPadula se concentre sur la confidentialité : les sujets ne peuvent pas lire des données d’un niveau de classification supérieur au leur (pas de lecture vers un niveau supérieur) et ne peuvent pas écrire de données à un niveau de classification inférieur (pas d’écriture vers un niveau inférieur). Cela empêche les informations sensibles de parvenir à des utilisateurs non autorisés. Biba se concentre sur l’intégrité : les sujets ne peuvent pas écrire vers un niveau d’intégrité supérieur (pas d’écriture vers un niveau supérieur) ni lire depuis un niveau d’intégrité inférieur (pas de lecture depuis un niveau inférieur). Biba empêche que des données à haute intégrité soient contaminées par des entrées à faible intégrité. Les systèmes MAC réels (comme SELinux) combinent des aspects des deux modèles.

Le contrôle d’accès fondé sur les rôles (RBAC) attribue des permissions à des rôles plutôt qu’aux utilisateurs individuels, puis affecte les utilisateurs à ces rôles. Cela résout la difficulté de gérer l’attribution de permissions individuelles à grande échelle. Parmi les rôles courants dans les environnements d’entreprise figurent : admin, auditeur, développeur, responsable_RH et analyste_financier. Lorsqu’un nouvel employé arrive, il est ajouté au rôle approprié et hérite immédiatement de toutes les permissions requises par ce rôle. Lorsqu’un employé change de poste, son rôle change et ses permissions s’ajustent automatiquement. Le RBAC est le modèle dominant dans les systèmes IAM d’entreprise.

Le principal avantage du RBAC est son évolutivité administrative. Modifier les permissions d’un rôle affecte instantanément tous les utilisateurs de ce rôle : il n’est pas nécessaire de mettre à jour les fiches individuelles des utilisateurs dans des centaines de systèmes. Le RBAC prend naturellement en charge la séparation des tâches en veillant à ce qu’aucun rôle unique ne dispose de permissions incompatibles (par exemple, un rôle pouvant à la fois créer et approuver des transactions financières). Le RBAC simplifie également la conformité : les auditeurs peuvent examiner les rôles et leurs permissions plutôt que de contrôler des milliers d’affectations individuelles. Sa limite est la multiplication des rôles : les organisations créent parfois trop de rôles précis, ce qui engendre une complexité de gestion qui réduit l’avantage d’évolutivité.

Le contrôle d’accès fondé sur des règles (à ne pas confondre avec le RBAC) accorde ou refuse l’accès en fonction d’un ensemble de règles conditionnelles, plutôt que de l’identité ou du rôle seuls. Les règles de pare-feu en sont l’exemple classique : « Autoriser TCP de 192.168.1.0/24 vers n’importe quelle destination sur le port 443. Refuser tout autre trafic. » L’accès est évalué par rapport aux règles dans l’ordre jusqu’à ce qu’une correspondance soit trouvée. Le contrôle fondé sur des règles est souvent combiné à d’autres modèles : le MAC utilise les étiquettes de sécurité comme règles, et le contrôle d’accès fondé sur les attributs (ABAC) étend la logique fondée sur des règles pour évaluer simultanément plusieurs attributs (user.department, device.type, heure de la journée, resource.classification) afin de prendre des décisions précises.

ABAC (contrôle d’accès fondé sur les attributs) est le modèle de contrôle d’accès le plus flexible et le plus précis. Les décisions d’accès évaluent simultanément plusieurs attributs : les attributs du sujet (user.department, niveau d’habilitation, emplacement), les attributs de l’objet (classification des données, service du propriétaire, étiquette de conservation), les attributs environnementaux (heure de la journée, device.type, emplacement réseau) et les attributs de l’action (lecture, écriture, suppression). Une politique peut stipuler : « Autoriser l’accès si user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18. » ABAC permet de prendre des décisions de politique Zero Trust et est implémenté par des produits comme XACML et les moteurs de politiques IAM des services cloud.

Le modèle de contrôle d’accès approprié dépend des exigences de sécurité et du contexte organisationnel. DAC : adapté à l’informatique personnelle et aux petites équipes qui privilégient la commodité au contrôle strict. MAC : requis dans les environnements gouvernementaux et militaires classifiés avec une compartimentation stricte des informations. RBAC : idéal pour les entreprises où l’évolutivité administrative est essentielle et où les rôles correspondent clairement aux fonctions professionnelles. ABAC : adapté aux environnements cloud et aux architectures Zero Trust nécessitant des politiques précises tenant compte du contexte. En pratique, la plupart des organisations utilisent une combinaison de modèles : RBAC comme fondation, avec ABAC pour les décisions d’accès sensibles au contexte.

Quel que soit le modèle de contrôle d'accès, les listes de contrôle d'accès (ACLs) constituent le mécanisme d'implémentation technique le plus courant. Une ACL associée à une ressource indique quels sujets peuvent effectuer quelles actions. Les ACL de système de fichiers (Windows NTFS, ACL POSIX Linux) contrôlent l'accès aux fichiers et aux répertoires. Les ACL réseau contrôlent le flux du trafic au niveau du routeur ou du réseau cloud. Les ACL de base de données contrôlent l'accès aux tables et aux lignes. Les ACL peuvent mettre en œuvre chacun des modèles étudiés : l'ACL d'un fichier met en œuvre le DAC lorsque le propriétaire la contrôle ; l'ACL d'un système de sécurité met en œuvre le MAC lorsque des étiquettes déterminent les entrées ; l'ACL d'une application met en œuvre le RBAC lorsque les entrées font référence à des rôles.

Testez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : le DAC permet aux propriétaires des ressources de contrôler l'accès (ce qui est flexible, mais risqué) ; le MAC utilise des étiquettes de sécurité imposées par le système (modèle strict, utilisé dans les environnements classifiés) ; le RBAC attribue des autorisations à des rôles afin de faciliter la mise à l'échelle en entreprise ; et l'ABAC évalue plusieurs attributs pour prendre des décisions Zero Trust précises. Nous allons maintenant étudier la fédération des identités : SAML, OAuth et OpenID Connect.