Suite au piratage d’Uber en 2022, où un cybercriminel a réussi à pénétrer dans le système interne de l’entreprise et à accéder à ses outils, le secteur a tiré une leçon importante : réagir aux failles de sécurité ne suffit pas, et leur prévention est une priorité. Une chose importante que les entreprises peuvent faire est de mettre en place des politiques de contrôle d’accès pour leurs logiciels et de surveiller régulièrement les accès et les opérations effectuées.

Aujourd’hui, il existe sur le marché de nombreux mécanismes de contrôle d’accès, dont le contrôle d’accès basé sur les rôles (RBAC). Dans cet article, nous allons explorer les nombreux avantages des systèmes RBAC en termes de facilité d’utilisation et de sécurité. Nous vous montrerons également comment les mettre en place en utilisant un schéma spécifique, et comment ils peuvent vous aider à rester en conformité avec les réglementations. Nous verrons également d’autres mécanismes de contrôle d’accès pour mieux comprendre comment ils fonctionnent.

Principes de base du contrôle d’accès basé sur les rôles (RBAC)

Le contrôle d’accès basé sur les rôles est un mécanisme qui permet aux utilisateurs d’accéder à certaines ressources en fonction des autorisations définies pour les rôles qui leur sont attribués. Le système RBAC repose sur trois éléments principaux :

• Rôles
• Permissions
• Utilisateurs

Chaque rôle est assorti d’autorisations spécifiques permettant d’accéder à certaines ressources, et un utilisateur se voit attribuer un rôle donné. Donc, quand l’utilisateur obtient un rôle, il peut voir et utiliser tout ce à quoi ce rôle a le droit d’accéder.

Schéma RBAC

Les entreprises mettent en œuvre le système RBAC à l’aide d’un schéma. Dans ce pseudo-schéma basé sur SQL, nous verrons comment associer les rôles, les utilisateurs et les autorisations. Le schéma de la base de données contient les tables et leurs relations. Cinq tables principales sont nécessaires pour mettre en œuvre un schéma RBAC :

• Users (utilisateurs) : permet de garder une trace de tous les utilisateurs et de leurs informations de base.
• Permissions (autorisations) : affiche les autorisations définies dans les systèmes, qui peuvent être divisées par ressource et par action autorisée sur cette ressource.
• Roles (rôles) : rôles définis dans le système
• User_Roles : mappage des rôles par utilisateur pour voir tous les rôles d’un utilisateur ; une relation de plusieurs à plusieurs.
• Role_Permissions : montre l’association entre les rôles et les autorisations

Dans certains cas particuliers, vous devrez attribuer directement certaines autorisations à un utilisateur. Nous vous le déconseillons fortement, car vous permettrez ainsi l’octroi de nombreuses autorisations à un seul utilisateur par votre équipe. Si vous vous retrouvez dans cette situation pour certains cas d’usage spécifiques, vous pouvez créer une autre table appelée User_Permissions pour associer les utilisateurs aux autorisations.

Avec ces cinq ou six tables, vous pourrez créer une fonction qui effectuera les contrôles d’autorisation pour vous. Vous trouverez ci-dessous une pseudo-fonction permettant de vérifier les autorisations :

function check_permissions(user, permissions):
    user_role = get_role(user)
    user_permissions = user_role.get_permissions()
    if permissions in user_permissions:
        Return “allowed”
    else:
        Return “Not allowed”

La définition des autorisations peut varier d’une implémentation à l’autre. Une application peut être une autorisation d’objet comme « profile-edit », qui signifie que l’utilisateur peut modifier le profil.

Vous pouvez également mettre en place une hiérarchie des rôles, ce qui signifie qu’un rôle peut avoir différents rôles et que les autorisations seront déterminées en fonction de ces rôles. Dans ces cas, l’implémentation peut s’avérer un peu délicate. Vous aurez besoin de deux champs : is_parent_role et child_roles. Vous pouvez également créer une autre table pour ce mappage.

Importance du contrôle d’accès basé sur les rôles

Le contrôle d’accès basé sur les rôles uniformise le processus d’octroi d’autorisations aux utilisateurs pour l’exécution ou la réalisation de tâches opérationnelles. Les avantages du RBAC sont les suivants :

• Moins de travail redondant : une fois les rôles définis, vous n’avez plus qu’à attribuer un rôle à un utilisateur pour qu’il obtienne les autorisations appropriées. Sinon, vous devrez ajouter manuellement chaque autorisation à chaque utilisateur.
• Sécurité améliorée : étant donné qu’une équipe centralisée définit ces rôles, le système RBAC est moins sujet aux erreurs et plus facile à gérer. Avoir des rôles bien définis réduit également les risques d’accorder accidentellement de mauvaises autorisations.
• Facilité d’audit : les rôles prédéfinis impliquent moins de changements dans la définition et l’attribution des rôles, ce qui simplifie les audits par rapport à l’attribution d’autorisations à chaque utilisateur.
• Exigences de conformité : la mise en place d’un contrôle d’accès vous aidera à respecter les réglementations en matière de conformité, ce qui est toujours un aspect majeur de la sécurité.

Bonnes pratiques en matière de contrôle d’accès basé sur les rôles (RBAC)

Une seule erreur dans la mise en œuvre peut compromettre même le système le plus sécurisé. Par conséquent, le respect des bonnes pratiques est primordial.

Rédigez des informations détaillées pour chaque rôle et ses responsabilités. Ajoutez une colonne de notes dans la table des rôles pour définir l’utilisation de chaque rôle et le motif de sa création. Abstenez-vous de créer aveuglément des rôles ; essayez plutôt de trouver les rôles les mieux adaptés qui existent déjà et attribuez-les.

Évitez les autorisations explicites au niveau de l’utilisateur, car cela peut prêter à confusion et entraîner l’octroi d’autorisations inappropriées.

Assurez-vous que toutes les tables ont une colonne created_by, updated_by, updated_at et created_at.. En outre, chaque modification apportée aux tables doit être transmise à un système d’audit centralisé afin de déterminer si des autorisations ont été attribuées de manière incorrecte ou si quelqu’un a reçu une autorisation de niveau supérieur qui n’était pas nécessaire.

Les décisions concernant les changements de rôles doivent appartenir à des utilisateurs spécifiques. Cette opération est extrêmement importante, chaque modification doit donc être soumise à un processus d’approbation rigoureux.

En outre, l’équipe qui gère le contrôle d’accès doit publier des lignes directrices sur la manière de créer des autorisations pour les rôles.

Autres mécanismes de contrôle d’accès

De nombreux mécanismes de contrôle d’accès sont utilisés aujourd’hui. Voici quelques-uns des principaux d’entre eux que nous vous présentons ci-dessous.

Contrôle d’accès basé sur les attributs

Dans ce mécanisme de contrôle d’accès, les autorisations sont accordées aux ressources en fonction de leurs attributs. L’un des principaux exemples est AWS, qui permet de donner accès à des ressources à l’aide de balises.

Avantages : cette méthode est très souple. Vous pouvez facilement modifier les attributs permettant à un utilisateur de recevoir une autorisation.

Inconvénients : des autorisations non souhaitées peuvent se propager si l’attribut est associé à une autre entité. La mise en œuvre prend également plus de temps, car vous devez associer chaque ressource à un attribut, ce qui nécessite que l’équipe définisse ces attributs et les planifie.

Contrôle d’accès au niveau de l’utilisateur

Dans ce mécanisme, un utilisateur est autorisé à accéder aux ressources en fonction de l’autorisation qui lui est directement attribuée.

Avantages : semble simpliste à première vue et constitue le mécanisme le plus facile à mettre en œuvre.

Inconvénients : il est difficile à gérer parce qu’il peut devenir très complexe au fur et à mesure que les utilisateurs et les autorisations augmentent.

Contrôle d’accès basé sur des politiques

Dans ce cas, les utilisateurs se voient accorder un accès sur la base d’une politique définie pour l’utilisateur au niveau de l’entreprise. La politique évalue ensuite le sujet, l’objet, l’action et le contexte. Le sujet peut être un service tel que le service ingénierie ; l’objet peut être un outil tel que SonarQube ; l’action peut être l’activité que vous essayez d’effectuer, par exemple la consultation de rapports ; et le contexte est l’environnement donné, tel que l’étape ou la production.

Avantages : les politiques lisibles par un humain sont plus logiques et permettent un contrôle au niveau du contexte.

Inconvénients : la mise en œuvre est complexe, car elle peut impliquer différents secteurs verticaux et leurs outils.

Conclusion

Vous pouvez mettre en œuvre le contrôle d’accès de plusieurs façons différentes. Une méthode très courante consiste à combiner le contrôle de l’accès basé sur les rôles (RBAC) et le contrôle de l’accès basé sur mes attributs (ABAC). AWS a mis en œuvre ce qui semble être l’une des meilleures combinaisons de ces deux éléments.

Outre le choix des mécanismes de contrôle, vous devez vous assurer que chaque événement est contrôlé et que des alertes seront déclenchées en cas de création d’autorisations incorrectes.

Répondre à toutes ces exigences sans heurts représente un véritable défi, car vous allez rencontrer plusieurs obstacles en cours de route. Par exemple, l’outil centralisé que vous utilisez doit pouvoir se connecter à plusieurs autres outils internes. Certains de ces outils peuvent être limités et ne prendre en charge qu’un petit nombre de protocoles.

Outre ces problèmes, nous vous conseillons de mettre en place un contrôle d’accès pour tous vos systèmes. Vous pourrez ainsi garder l’esprit tranquille, même dans les situations où vos systèmes sont compromis.