Les en­tre­prises et les or­ga­ni­sa­tions at­tri­buent des au­to­ri­sa­tions d’accès à leur système in­for­ma­tique seulement aux uti­li­sa­teurs qui en ont ef­fec­ti­ve­ment besoin, dans le cadre de leur activité. Les données sensibles sont ainsi protégées des accès non autorisés et des mo­di­fi­ca­tions non désirées. Afin d’assurer la sécurité au sein des grandes or­ga­ni­sa­tions, les au­to­ri­sa­tions d’accès in­di­vi­duelles sont définies dans ce que l’on appelle une Access Control List (liste de contrôle des accès) ou ACL. L’in­con­vé­nient : plus le nombre d’uti­li­sa­teurs est élevé, plus l’at­tri­bu­tion des au­to­ri­sa­tions in­di­vi­duelles nécessite de main­te­nance et s’avère sujette aux erreurs. Une al­ter­na­tive flexible et efficace à la fois est le contrôle d’accès à base de rôles : Role Based Access Control, abrégé RBAC.

Qu’est-ce que le RBAC ?

Le Role Based Access Control, abrégé RBAC, signifie « contrôle d’accès à base de rôles ». Ce concept de sécurité et d’au­to­ri­sa­tion permet l’at­tri­bu­tion de rôles et d’au­to­ri­sa­tions dans l’in­fras­truc­ture in­for­ma­tique d’une or­ga­ni­sa­tion. Le principe « à base de rôles » est ce qui distingue le RBAC des autres concepts de sécurité, par exemple du contrôle d’accès obli­ga­toire. Avec ce modèle, un ad­mi­nis­tra­teur système attribue à chaque uti­li­sa­teur et objet un niveau de sécurité et une catégorie. Le système d’ex­ploi­ta­tion compare au­to­ma­ti­que­ment les deux niveaux et attribue ou non l’accès.

Dans le RBAC, les droits d’accès sont attribués à l’aide d’un modèle de rôles défini. Les rôles d’uti­li­sa­teur établis séparent les processus de travail dans une or­ga­ni­sa­tion et varient donc d’une en­tre­prise à une autre. Les repères possibles pour une ré­par­ti­tion adéquate sont les services, les sites, les centres de coûts ou les fonctions d’un col­la­bo­ra­teur.

Le fonc­tion­ne­ment du Role Based Access Control

Avant de pouvoir appliquer le concept d’au­to­ri­sa­tion RBAC dans une en­tre­prise, il faut spécifier les droits d’un rôle de manière aussi détaillée que possible. Cela inclut l’éta­blis­se­ment précis des au­to­ri­sa­tions dans les domaines suivants :

  • Droits de mo­di­fi­ca­tion des données (lecture, lecture et écriture, accès complet)
  • Droits d’accès aux ap­pli­ca­tions de l’en­tre­prise
  • Au­to­ri­sa­tions dans les ap­pli­ca­tions

Afin d’exploiter plei­ne­ment les avantages du modèle RBAC, l’éla­bo­ra­tion du concept de rôles et d’au­to­ri­sa­tions passe toujours au premier plan. L’or­ga­ni­sa­tion transfère toutes les fonctions des col­la­bo­ra­teurs aux rôles qui dé­fi­nis­sent les droits d’accès cor­res­pon­dants. Dans une deuxième étape, les rôles sont attribués aux col­la­bo­ra­teurs selon les tâches. Le Role Based Access Control permet d’attribuer un ou plusieurs rôles par uti­li­sa­teur. Il est ainsi possible d’attribuer in­di­vi­duel­le­ment des au­to­ri­sa­tions d’accès dans le modèle de rôles. Ainsi un uti­li­sa­teur peut obtenir un accès pour effectuer ses tâches sans engendrer d’autres mo­di­fi­ca­tions.

La mise en place et la sur­veil­lance du RBAC s’ef­fec­tuent via un Identity Access Ma­na­ge­ment System, abrégé IAM (système de gestion des identités). Ce système aide es­sen­tiel­le­ment les en­tre­prises avec un nombre élevé de col­la­bo­ra­teurs lors de l’at­tri­bu­tion, du contrôle et de l’ac­tua­li­sa­tion de toutes les identités et droits d’accès. L’at­tri­bu­tion d’au­to­ri­sa­tions est appelée « Pro­vi­sio­ning », le retrait « De-Pro­vi­sio­ning ». La condition requise à l’uti­li­sa­tion d’un tel système est l’éta­blis­se­ment d’un concept de rôles uniforme et stan­dar­disé.

Conseil

Les self-service portal (portails libre-service) per­met­tent aux uti­li­sa­teurs de modifier eux-mêmes leurs au­to­ri­sa­tions. Le système informe au­to­ma­ti­que­ment les ad­mi­nis­tra­teurs en cas de mo­di­fi­ca­tion. Ces derniers ont la pos­si­bi­lité d’annuler im­mé­dia­te­ment les mo­di­fi­ca­tions.

Comment fonc­tionne l’éla­bo­ra­tion d’un RBAC ?

Le Role Based Access Control se base sur une structure à trois niveaux d’uti­li­sa­teurs, de rôles et de groupes. Dans ce que l’on appelle le « role mining », les or­ga­ni­sa­tions dé­fi­nis­sent les rôles qui dépendent gé­né­ra­le­ment de la structure or­ga­ni­sa­tion­nelle de l’en­tre­prise. Enfin, chaque col­la­bo­ra­teur se voit attribuer un ou plusieurs rôles incluant une ou plusieurs au­to­ri­sa­tions d’accès. Un ou plusieurs groupes sont liés à un rôle sans être né­ces­sai­re­ment mis au même niveau.

Pour élaborer un concept de rôles, la plupart du temps l’approche py­ra­mi­dale s’impose :

Le sommet : au­to­ri­sa­tions pour tous les col­la­bo­ra­teurs

Au sommet sont définies les au­to­ri­sa­tions dont tous les col­la­bo­ra­teurs de l’or­ga­ni­sa­tion ont besoin, comme l’accès à l’Intranet, la suite Office, l’e-mail client, l’ensemble du registre du réseau ou l’ins­crip­tion dans Active Directory.

Le deuxième niveau : ap­par­te­nance à un service

Au sein d’une or­ga­ni­sa­tion, les col­la­bo­ra­teurs d’un service se chargent d’activités d’un même domaine. Ainsi le service financier a besoin d’accéder au système ERP et au disque dur du service, le service des RH en revanche a besoin d’accéder à toutes les données des col­la­bo­ra­teurs. Les au­to­ri­sa­tions cor­res­pon­dantes sont at­tri­buées à tous les col­la­bo­ra­teurs d’un service.

Le troisième niveau : les fonctions

Selon la fonction des col­la­bo­ra­teurs et les tâches qui leur incombent, d’autres au­to­ri­sa­tions sont définies.

Conseil

Ce sont les chefs d’équipes qui con­nais­sent le mieux les tâches de leurs col­la­bo­ra­teurs. Il est donc conseillé de les inclure dans la dé­fi­ni­tion des rôles. Les au­to­ri­sa­tions sont au­to­ma­ti­que­ment extraites et con­fir­mées auprès des chefs d’équipes à l’aide d’un système IAM.

L’élément fon­da­men­tal : les rôles

Dans de nombreux cas, les col­la­bo­ra­teurs s’occupent d’activités qui jusqu’à présent n’étaient pas prises en charge par la requête du service et de la fonction. L’or­ga­ni­sa­tion attribue donc à chaque col­la­bo­ra­teur les rôles com­plé­men­taires dont il a besoin en fonction de ses activités réelles.

Sources de données pour le RBAC

Afin de définir et d’attribuer les rôles, une or­ga­ni­sa­tion a besoin de données complètes et actuelles sur les col­la­bo­ra­teurs. Dans les grandes en­tre­prises, ces données sont en­re­gis­trées en détail dans le système des res­sources humaines. À l’éla­bo­ra­tion d’un concept de rôles et d’au­to­ri­sa­tion, il est re­com­mandé de tenir compte également des rôles qui éven­tuel­le­ment ne sont pas ac­tuel­le­ment occupés. Il s’agit en général des sta­giaires d’un service ou des postes vacants depuis longtemps.

Les avantages et les in­con­vé­nients du RBAC

Selon certaines con­di­tions, le Role Based Access Control s’est établi comme un modèle de bonnes pratiques. Si le concept de rôles et d’au­to­ri­sa­tion est défini et appliqué de manière obli­ga­toire dans toute l’en­tre­prise, le RBAC présente de nombreux avantages :

  • Flexi­bi­lité : l’en­tre­prise attribue seulement un ou plusieurs rôles à un col­la­bo­ra­teur selon les besoins. Les mo­di­fi­ca­tions au sein de la structure de l’or­ga­ni­sa­tion ou des au­to­ri­sa­tions sont ra­pi­de­ment trans­mises à tous les col­la­bo­ra­teurs tandis que l’en­tre­prise adapte les rôles cor­res­pon­dants.
  • Faible charge ad­mi­nis­tra­tive : le RBAC rend obsolète l’at­tri­bu­tion coûteuse d’au­to­ri­sa­tions in­di­vi­duelles.
  • Risque d’erreurs réduit : les au­to­ri­sa­tions in­di­vi­duelles sont plus coûteuses et aussi plus sujettes aux erreurs que l’at­tri­bu­tion d’au­to­ri­sa­tions d’accès à base de rôles.
  • Aug­men­ta­tion de l’ef­fi­ca­cité : en réduisant la charge et le risque d’erreurs, l’ef­fi­ca­cité du système in­for­ma­tique et des autres col­la­bo­ra­teurs augmente. Les mo­di­fi­ca­tions manuelles, le trai­te­ment des erreurs, les délais d’attente ainsi que les demandes in­di­vi­duelles de droits dis­pa­rais­sent.
  • Sécurité : les droits d’accès sont définis ex­clu­si­ve­ment selon le concept de rôles, ce qui évite la sur-au­to­ri­sa­tion de col­la­bo­ra­teurs in­di­vi­duels. Ceci cor­res­pond au principe du PoLP, c’est-à-dire le principe du moindre privilège.
  • Trans­pa­rence : la dé­sig­na­tion des rôles est le plus souvent aisément com­pré­hen­sible, ce qui renforce la trans­pa­rence et la com­pré­hen­sion par les uti­li­sa­teurs.

Les in­con­vé­nients du Role Based Access Control :

  • Éla­bo­ra­tion complexe : le transfert des struc­tures de l’or­ga­ni­sa­tion dans le modèle RBAC requiert beaucoup de travail.
  • At­tri­bu­tion tem­po­raire : si un uti­li­sa­teur a besoin tem­po­rai­re­ment de droits d’accès étendus, il est plus facile d’oublier l’at­tri­bu­tion avec le RBAC qu’avec une at­tri­bu­tion in­di­vi­duelle de droits.
  • Uti­li­sa­tion : pour les petites en­tre­prises, l’éla­bo­ra­tion et la main­te­nance des rôles né­ces­si­tent davantage de travail que la ré­par­ti­tion des droits in­di­vi­duels. Par con­sé­quent, le modèle RBAC est utilisé seulement à partir d’un certain nombre de rôles et de col­la­bo­ra­teurs. Et pourtant, même pour les grandes en­tre­prises, le Role Based Access Control a pour in­con­vé­nient de mul­ti­plier les rôles. Si une en­tre­prise a dix services et dix rôles, il en résulte déjà 100 groupes dif­fé­rents.

Quand est utilisé le RBAC ?

Dans de nom­breuses or­ga­ni­sa­tions, le Role Based Access Control s’est révélé la meilleure procédure d’ad­mi­nis­tra­tion des au­to­ri­sa­tions d’accès. Cependant, le modèle RBAC peut être utilisé même dans les systèmes d’ex­ploi­ta­tion et les autres logiciels, notamment pour le service de ré­per­toire Microsoft Windows Server Active Directory, pour le système d’ex­ploi­ta­tion Linux SELinux optimisé dans le domaine de la sécurité ou le système d’ex­ploi­ta­tion Unix Solaris.

Aller au menu principal