Des concepts que vous utilisez sans même le savoir : Contrôle d'accès basé sur les rôles

Bienvenue dans notre nouvelle série consacrée aux concepts et fonctionnalités techniques que vous utilisez probablement tous les jours sans même le savoir. Cette série vous permettra de mieux comprendre l'impact de ces concepts sur vos opérations quotidiennes et de tirer le meilleur parti des outils à votre disposition.

Notre premier article porte sur le contrôle d'accès basé sur les rôles, un moyen couramment utilisé pour gérer les autorisations des applications et l'accès aux ressources du réseau en fonction du rôle attribué à un utilisateur. C'est également connu sous le nom de sécurité basée sur les rôles et c'est un concept que tout administrateur système devrait comprendre.

Qu'est-ce que le contrôle d'accès basé sur les rôles ?

Le contrôle d'accès basé sur les rôles est né de la nécessité de gérer des listes de contrôle d'accès de plus en plus complexes pour un grand nombre d'utilisateurs et de ressources. Prenons un peu de recul et examinons d'abord le contrôle d'accès.

Pourquoi nous avons besoin d'un contrôle d'accès

Pour des raisons assez évidentes, les administrateurs système voudront limiter la capacité des utilisateurs d'un système à effectuer des actions sur ce système. Lorsque nous utilisons le mot "utilisateurs", nous faisons référence à la fois aux utilisateurs humains et aux applications qui agissent en tant qu'utilisateurs de services.

Le contrôle d'accès agit comme une couche entre les utilisateurs et les systèmes, garantissant que les administrateurs de systèmes peuvent mettre en place des limites - sans restreindre complètement la fonctionnalité.

Le contrôle d'accès couvre un large éventail de systèmes - de l'accès au système d'exploitation et aux applications à l'accès à des réseaux spécifiques, tant internes qu'externes. Et oui, dans un premier temps, le contrôle d'accès nous indique si un utilisateur peut accéder à une application, un système ou un réseau - ou si l'accès lui est interdit.

Le contrôle d'accès concerne également le degré d'accès accordé. En d'autres termes, un utilisateur peut avoir un accès complet à un système - lecture et écriture, par exemple - alors qu'un autre utilisateur peut avoir un accès restreint - lecture seulement, par exemple.

Toutes ces préoccupations sont transversales au système d'exploitation et à l'espace applicatif. Une application individuelle qui prend en charge plusieurs utilisateurs nécessitera probablement une certaine forme de contrôle pour déterminer quels utilisateurs peuvent effectuer quelles activités (sinon elle cessera d'être utile très rapidement).

La nécessité d'une gestion avancée des accès

Dans les systèmes simples, une simple liste de contrôle d'accès fera l'affaire - en indiquant quels utilisateurs ont quel type d'accès et où. Mais dans l'environnement informatique complexe des entreprises d'aujourd'hui, les longues listes de critères de contrôle d'accès ne fonctionnent pas, notamment en raison de la nature intégrée des systèmes et de la manière dont les autorisations accordées à un endroit doivent également se propager ailleurs.

À la base, RBAC est une couche d'abstraction qui sépare les autorisations des utilisateurs en introduisant le concept de "rôles", également connus sous le nom de "groupes". Ce changement apparemment mineur permet une plus grande flexibilité et un contrôle granulaire des autorisations. D'une certaine manière, le contrôle d'accès basé sur les rôles ajoute une certaine surcharge administrative, mais si l'on considère la situation dans son ensemble, le RBAC simplifie considérablement la gestion des accès, en particulier dans les environnements plus complexes.

Qu'est-ce qu'un rôle ?

Les rôles sont au cœur de RBAC. Tout comme les utilisateurs, un rôle peut faire référence au rôle d'une personne dans l'organisation et, par conséquent, aux autorisations de systèmes requises pour remplir ce rôle. Les rôles peuvent également être attribués à des objets inanimés tels que des applications ou des services fonctionnant sur un serveur.

En ce qui concerne le contrôle d'accès, un rôle spécifique définira un ensemble spécifique d'autorisations. Par exemple, un "éditeur" pourra lire et modifier les articles d'un site Web, mais ne pourra pas modifier les paramètres du site ou supprimer des articles - cela nécessiterait un rôle d'"administrateur".

En utilisant les rôles, les administrateurs système peuvent s'assurer que les personnes qui ont besoin de droits d'accès spécifiques pour faire leur travail disposent de ces droits selon un modèle défini - tel que défini par le rôle. Lorsqu'un nouveau rédacteur rejoint l'entreprise, par exemple, un administrateur système peut simplement lui attribuer le rôle de rédacteur standard sans avoir à configurer manuellement les autorisations du nouveau membre du personnel.

D'un autre point de vue, les employés juniors - y compris, par exemple, les administrateurs de systèmes juniors - auront moins de droits d'accès aux systèmes d'une entreprise. Les employés juniors n'auront accès qu'à un sous-ensemble des informations de l'entreprise, et les administrateurs de systèmes juniors auront la permission d'apporter certaines modifications aux systèmes, mais pas toutes.

En outre, les rôles relient les autorisations aux ressources. Ainsi, un rôle peut lier certaines autorisations à des ressources spécifiques. Par exemple, une personne travaillant dans le bureau de New York peut accéder aux ressources en nuage liées au bureau de New York en fonction de son rôle NYC. Cette même personne ne peut pas accéder aux ressources de San Francisco, sauf si son rôle est élargi en raison de sa participation à un projet à San Francisco.

Les rôles peuvent être utilisés de manière incroyablement flexible. Par exemple, la composition des rôles consiste à attribuer plusieurs rôles à une même personne, qui hérite des autorisations pour tous les rôles. La composition peut se faire tout naturellement, les utilisateurs se voyant attribuer des rôles correspondant à leur position parfois complexe au sein d'une organisation.

RBAC : contrôle d'accès à l'aide de rôles

Ainsi, comme le suggère l'acronyme, le RBAC applique un contrôle d'accès basé sur le rôle ou les multiples rôles attribués à un utilisateur. Il s'agit d'une amélioration des listes de contrôle d'accès standard et, bien entendu, le RBAC n'est qu'un modèle de contrôle d'accès parmi d'autres.

Il existe une alternative dans ce qu'on appelle le contrôle d'accès basé sur les attributs (ABAC) qui a évolué à partir du RBAC. L'ABAC accorde l'accès en fonction des attributs du sujet (utilisateur) et de la ressource à laquelle on accède - ainsi que de quelques autres éléments, notamment l'action requise et l'environnement dans lequel la demande est faite.

Comment déterminer si votre système utilise RBAC ?

La plupart des applications qui prennent en charge plusieurs utilisateurs auront une forme de contrôle pour spécifier quels utilisateurs peuvent faire quoi. Si une application ou un système fait référence à des groupes et si les utilisateurs sont ajoutés à un groupe plutôt que de se voir attribuer des autorisations individuellement, alors cette application ou ce système utilise la technologie RBAC. En fait, si vous cherchez des mots comme groupes et rôles, vous êtes probablement en présence d'une technologie RBAC.

Exemples de contrôle d'accès basé sur les rôles dans la pratique

Le contrôle d'accès basé sur les rôles est incroyablement courant. Il est facile à utiliser et à mettre en œuvre, et vous le trouverez intégré dans vos solutions technologiques, depuis le système d'exploitation jusqu'aux applications et services quotidiens que vous utilisez. Dans cette section, nous allons examiner quelques exemples courants de RBAC.

À un niveau simple, considérons un système de gestion de contenu. Ici, les utilisateurs doivent être en mesure de gérer le contenu - créer et modifier des articles, supprimer des articles et modifier la structure du site. Le rôle d'auteur, par exemple, pourrait inclure la capacité de créer et de modifier des articles, mais pas de les supprimer.

Les travailleurs ayant un rôle d'éditeur peuvent être en mesure de modifier et de supprimer des articles, mais pas de modifier la structure du site. Le rôle d'administrateur, quant à lui, disposerait de toutes les autorisations - création, modification, suppression d'articles ainsi que la possibilité de modifier la structure et les paramètres du site.

Le RBAC est aussi couramment utilisé comme garde-barrière pour les données. Prenons l'exemple des données médicales, où certains membres du personnel médical ayant des rôles spécifiques ont accès aux données des patients, tandis que d'autres membres du personnel ne peuvent voir qu'un sous-ensemble des données ou uniquement les données des patients qu'ils consultent.

Dans le monde de la technologie, Kubernetes, la solution de conteneurisation la plus utilisée, utilise RBAC pour garantir que les utilisateurs humains et les applications disposent du bon niveau d'accès aux conteneurs individuels et aux groupes de conteneurs.

RBAC joue également un rôle très important dans les plates-formes en nuage telles qu'Azure de Microsoft, où RBAC régit l'accès aux ressources Azure et aux applications fonctionnant sur ces ressources.

Avantages de l'utilisation de RBAC

Pourquoi vouloir utiliser RBAC au lieu d'une simple ACL ? Nous avons évoqué certains de ces avantages, mais examinons de plus près ceux qui font de RBAC un moyen si courant d'appliquer les permissions.

Efficacité opérationnelle

Bien que les ACL puissent techniquement faire le travail, elles deviennent rapidement encombrantes et finissent par être inapplicables lorsque la complexité des permissions augmente. Cependant, même avec des charges de travail plus simples, le système RBAC permet de mieux gérer les autorisations car les règles ne doivent pas être définies pour chaque utilisateur.

Par exemple, avec une liste de contrôle d'accès, si vous souhaitez autoriser tous les utilisateurs à imprimer sur une imprimante spécifique, cette modification doit être effectuée pour chaque utilisateur individuel. Avec RBAC, il suffit d'ajouter l'imprimante au groupe concerné.

Ce qui précède n'est qu'un simple exemple. Lorsque le RBAC est déployé dans de grands systèmes complexes, les gains d'efficacité opérationnelle se multiplient véritablement. En fait, les très grandes organisations ne peuvent tout simplement pas fonctionner sans RBAC - il serait tout simplement impossible de s'appuyer sur les ACL.

Intégration avec d'autres services

RBAC, avec son catalogue d'utilisateurs, de rôles et d'autorisations, peut également servir de plate-forme pour une base de données d'autorisations ou un service d'annuaire. Cela signifie qu'un système de contrôle d'accès basé sur RBAC peut facilement s'intégrer à différents services.

En d'autres termes, les rôles et les autorisations des utilisateurs peuvent être récupérés un par un ou même exportés en gros pour être ensuite appliqués à un système complètement distinct, ce qui signifie que le RBAC offre de nombreuses possibilités d'intégration entre systèmes.

Amélioration du contrôle et de la conformité

Lorsque RBAC est utilisé, l'administrateur peut appliquer un contrôle plus granulaire et plus fréquent sur les permissions. Les autorisations peuvent également être gérées de manière plus souple, ce qui signifie que l'administration peut exercer un contrôle plus strict sur les autorisations.

En particulier dans les déploiements à grande échelle, les autorisations peuvent devenir assez "lâches" et "excessives" avec le temps. Le RBAC permet donc de resserrer l'accès, ce qui améliore la conformité aux règles et aux politiques de l'organisation, ainsi qu'à l'environnement de conformité au sens large. Les règles peuvent être étroitement alignées sur les exigences de conformité et sont plus faciles à modifier en cas de changement de réglementation.

Audit et visibilité

Dans le cas d'applications à l'échelle de l'entreprise, RBAC conservera très probablement aussi des journaux d'accès sophistiqués pour aider les administrateurs à comprendre quel accès a été accordé à qui, par qui et quand il a été accordé.

Il offre une visibilité beaucoup plus grande sur la façon dont les systèmes sont accessibles et par qui ils le sont. En outre, les solutions qui utilisent le RBAC devraient également être en mesure d'exporter des rapports donnant aux administrateurs système un aperçu clair de quels utilisateurs ont quel type de permissions.

Inconvénients de l'utilisation de RBAC

Comme pour toute approche en matière de technologie de l'information, l'utilisation de RBAC présente certains inconvénients. Tout d'abord, il y a le "coût" initial de la nécessité de sélectionner des rôles pour les utilisateurs lorsqu'un utilisateur est ajouté. Cependant, étant donné la facilité avec laquelle RBAC permet de propager les permissions basées sur les rôles pour cet utilisateur à l'avenir, cela peut être considéré comme un coût relativement minime. Ce problème est généralement résolu par une forme d'intégration avec un fichier d'entreprise déjà établi ou un service de gestion d'identité centralisé.

L'un des problèmes de RBAC peut être ce que l'on appelle l'explosion des rôles : de plus en plus de rôles sont créés pour s'adapter à un nombre croissant de rôles dans l'organisation et pour tenir compte de rôles de plus en plus complexes au sein de l'organisation. Cela peut conduire à une grande complexité qui peut être difficile à gérer.

La mise en place de structures de rôles RBAC peut également être assez longue et complexe. De plus, au fur et à mesure qu'une organisation évolue, cette structure changera également - ce qui peut signifier que la structure des rôles doit être revue tous les quelques années.

Pour ces raisons, certaines personnes considèrent l'ABAC comme une alternative améliorée, mieux adaptée aux environnements d'accès et de permissions très complexes.

Configuration de RBAC

Une façon de contourner certains des inconvénients de RBAC est de commencer par une configuration RBAC bien structurée. Voici quelques conseils pour vous aider dans votre démarche :

• Commencez par un catalogage complet. Avant de commencer à penser aux rôles, assurez-vous de connaître exactement les systèmes pour lesquels vous essayez de définir des autorisations. Pensez aux réseaux jusqu'aux différentes bases de données de votre organisation. Il est important de savoir ce à quoi vous essayez de contrôler l'accès avant de concevoir votre système de contrôle d'accès.
• Analysez votre personnel. Examinez votre personnel de près et essayez d'identifier des rôles clairs - et même des rôles qui se chevauchent. Ce faisant, vous devez trouver le juste équilibre entre la création d'un nombre suffisant de rôles pour que votre structure d'autorisations soit suffisamment granulaire, mais pas trop, au point d'annuler les avantages de RBAC en utilisant trop de rôles.
• Obtenez l'adhésion de vos collègues. Ensuite, définissez l'accès de vos employés en fonction de leurs responsabilités quotidiennes en faisant correspondre ces responsabilités aux rôles. Il est également utile de mettre en place un certain niveau de formation pour vos collègues - en particulier ceux qui occupent des fonctions technologiques - afin qu'ils comprennent les principes de base de RBAC.
• Gérer le changement. La gestion des changements de rôles est l'un des aspects les plus difficiles de RBAC. Lors de la planification de votre système RBAC, prévoyez la manière dont les rôles peuvent changer à l'avenir et effectuez des audits réguliers pour vous assurer que les rôles et les autorisations que vous avez configurés correspondent toujours à la réalité sur le terrain.

En substance, un peu de réflexion prospective vous aidera à tirer le meilleur parti de RBAC et à minimiser les changements et la maintenance que vous devrez effectuer à l'avenir.

Conclusion

RBAC est l'un des moyens par lesquels vous pouvez gérer les utilisateurs et les autorisations dans vos applications et vos systèmes. Les concepts de haut niveau impliqués dans RBAC, y compris les utilisateurs et les groupes ainsi que les règles et les politiques, sont transversaux aux sujets technologiques.

Il est utile de comprendre à quoi sert chacun de ces concepts transversaux et comment ils fonctionnent dans d'autres domaines de l'informatique. En tant que professionnels de l'informatique, la compréhension des principes fondamentaux nous aide à aborder avec plus de compétence les sujets plus complexes.