Role Based Access Control (RBAC) : comment fonctionne le contrôle d’accès à base de rôles ?

Les entreprises et les organisations attribuent des autorisations d’accès à leur système informatique seulement aux utilisateurs qui en ont effectivement besoin, dans le cadre de leur activité. Les données sensibles sont ainsi protégées des accès non autorisés et des modifications non désirées. Afin d’assurer la sécurité au sein des grandes organisations, les autorisations d’accès individuelles sont définies dans ce que l’on appelle une Access Control List (liste de contrôle des accès) ou ACL. L’inconvénient : plus le nombre d’utilisateurs est élevé, plus l’attribution des autorisations individuelles nécessite de maintenance et s’avère sujette aux erreurs. Une alternative flexible et efficace à la fois est le contrôle d’accès à base de rôles : Role Based Access Control, abrégé 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’autorisation permet l’attribution de rôles et d’autorisations dans l’infrastructure informatique d’une organisation. 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 obligatoire. Avec ce modèle, un administrateur système attribue à chaque utilisateur et objet un niveau de sécurité et une catégorie. Le système d’exploitation compare automatiquement 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’utilisateur établis séparent les processus de travail dans une organisation et varient donc d’une entreprise à une autre. Les repères possibles pour une répartition adéquate sont les services, les sites, les centres de coûts ou les fonctions d’un collaborateur.

Avant de pouvoir appliquer le concept d’autorisation RBAC dans une entreprise, il faut spécifier les droits d’un rôle de manière aussi détaillée que possible. Cela inclut l’établissement précis des autorisations dans les domaines suivants :

• Droits de modification des données (lecture, lecture et écriture, accès complet)
• Droits d’accès aux applications de l’entreprise
• Autorisations dans les applications

Afin d’exploiter pleinement les avantages du modèle RBAC, l’élaboration du concept de rôles et d’autorisations passe toujours au premier plan. L’organisation transfère toutes les fonctions des collaborateurs aux rôles qui définissent les droits d’accès correspondants. Dans une deuxième étape, les rôles sont attribués aux collaborateurs selon les tâches. Le Role Based Access Control permet d’attribuer un ou plusieurs rôles par utilisateur. Il est ainsi possible d’attribuer individuellement des autorisations d’accès dans le modèle de rôles. Ainsi un utilisateur peut obtenir un accès pour effectuer ses tâches sans engendrer d’autres modifications.

La mise en place et la surveillance du RBAC s’effectuent via un Identity Access Management System, abrégé IAM (système de gestion des identités). Ce système aide essentiellement les entreprises avec un nombre élevé de collaborateurs lors de l’attribution, du contrôle et de l’actualisation de toutes les identités et droits d’accès. L’attribution d’autorisations est appelée « Provisioning », le retrait « De-Provisioning ». La condition requise à l’utilisation d’un tel système est l’établissement d’un concept de rôles uniforme et standardisé.

Le Role Based Access Control se base sur une structure à trois niveaux d’utilisateurs, de rôles et de groupes. Dans ce que l’on appelle le « role mining », les organisations définissent les rôles qui dépendent généralement de la structure organisationnelle de l’entreprise. Enfin, chaque collaborateur se voit attribuer un ou plusieurs rôles incluant une ou plusieurs autorisations d’accès. Un ou plusieurs groupes sont liés à un rôle sans être nécessairement mis au même niveau.

Pour élaborer un concept de rôles, la plupart du temps l’approche pyramidale s’impose :

Au sommet sont définies les autorisations dont tous les collaborateurs de l’organisation ont besoin, comme l’accès à l’Intranet, la suite Office, l’e-mail client, l’ensemble du registre du réseau ou l’inscription dans Active Directory.

Au sein d’une organisation, les collaborateurs 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 collaborateurs. Les autorisations correspondantes sont attribuées à tous les collaborateurs d’un service.

Selon la fonction des collaborateurs et les tâches qui leur incombent, d’autres autorisations sont définies.

Dans de nombreux cas, les collaborateurs 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’organisation attribue donc à chaque collaborateur les rôles complémentaires dont il a besoin en fonction de ses activités réelles.

Afin de définir et d’attribuer les rôles, une organisation a besoin de données complètes et actuelles sur les collaborateurs. Dans les grandes entreprises, ces données sont enregistrées en détail dans le système des ressources humaines. À l’élaboration d’un concept de rôles et d’autorisation, il est recommandé de tenir compte également des rôles qui éventuellement ne sont pas actuellement occupés. Il s’agit en général des stagiaires d’un service ou des postes vacants depuis longtemps.

Selon certaines conditions, le Role Based Access Control s’est établi comme un modèle de bonnes pratiques. Si le concept de rôles et d’autorisation est défini et appliqué de manière obligatoire dans toute l’entreprise, le RBAC présente de nombreux avantages :

• Flexibilité : l’entreprise attribue seulement un ou plusieurs rôles à un collaborateur selon les besoins. Les modifications au sein de la structure de l’organisation ou des autorisations sont rapidement transmises à tous les collaborateurs tandis que l’entreprise adapte les rôles correspondants.
• Faible charge administrative : le RBAC rend obsolète l’attribution coûteuse d’autorisations individuelles.
• Risque d’erreurs réduit : les autorisations individuelles sont plus coûteuses et aussi plus sujettes aux erreurs que l’attribution d’autorisations d’accès à base de rôles.
• Augmentation de l’efficacité : en réduisant la charge et le risque d’erreurs, l’efficacité du système informatique et des autres collaborateurs augmente. Les modifications manuelles, le traitement des erreurs, les délais d’attente ainsi que les demandes individuelles de droits disparaissent.
• Sécurité : les droits d’accès sont définis exclusivement selon le concept de rôles, ce qui évite la sur-autorisation de collaborateurs individuels. Ceci correspond au principe du PoLP, c’est-à-dire le principe du moindre privilège.
• Transparence : la désignation des rôles est le plus souvent aisément compréhensible, ce qui renforce la transparence et la compréhension par les utilisateurs.

Les inconvénients du Role Based Access Control :

• Élaboration complexe : le transfert des structures de l’organisation dans le modèle RBAC requiert beaucoup de travail.
• Attribution temporaire : si un utilisateur a besoin temporairement de droits d’accès étendus, il est plus facile d’oublier l’attribution avec le RBAC qu’avec une attribution individuelle de droits.
• Utilisation : pour les petites entreprises, l’élaboration et la maintenance des rôles nécessitent davantage de travail que la répartition des droits individuels. Par conséquent, le modèle RBAC est utilisé seulement à partir d’un certain nombre de rôles et de collaborateurs. Et pourtant, même pour les grandes entreprises, le Role Based Access Control a pour inconvénient de multiplier les rôles. Si une entreprise a dix services et dix rôles, il en résulte déjà 100 groupes différents.

Dans de nombreuses organisations, le Role Based Access Control s’est révélé la meilleure procédure d’administration des autorisations d’accès. Cependant, le modèle RBAC peut être utilisé même dans les systèmes d’exploitation et les autres logiciels, notamment pour le service de répertoire Microsoft Windows Server Active Directory, pour le système d’exploitation Linux SELinux optimisé dans le domaine de la sécurité ou le système d’exploitation Unix Solaris.