Que sont les comptes de rôle ?
Les comptes de rôle sont des comptes liés à un rôle particulier dans votre organisation (c.-à-d. un groupe d’employés ou un système automatisé) plutôt qu’à une personne. Ils sont souvent utilisés pour automatiser les tâches et fluidifier les flux de données.
Par exemple, si votre système RH doit communiquer avec le système de paie, vous pouvez configurer un utilisateur « hr » pour automatiser la gestion des identifiants. Vous pouvez ensuite consulter les journaux pour voir quand le compte de rôle ”hr” accède au système de paie, offrant ainsi une meilleure visibilité sur les modèles d’accès. De plus, vous savez que le trafic provoqué par « hr » n’est pas du trafic d’utilisateur individuel, vous pouvez donc l’exclure lors de l’analyse des comportements de connexion irréguliers. Cela peut à la fois faire gagner du temps dans vos workflows et renforcer la sécurité.
Cependant, il y a quelques inconvénients. Des problèmes surviennent lorsque vous commencez à utiliser des comptes de rôle de manière inappropriée avec des systèmes qui nécessitent une identité. Partager un compte de rôle entre plusieurs employés comme identifiant multi-usage pour un fournisseur (par ex. vendor-name@mystartup.com), utiliser l’utilisateur « ubuntu » sur un hôte Linux hébergé dans le cloud, ou utiliser le compte « Administrator » sur nos serveurs Windows, seraient autant d’exemples d’utilisation de comptes de rôle contraires aux bonnes pratiques. Il s’agit de systèmes pour lesquels l’utilisation d’une identité unique est importante et le partage d’un compte de rôle compromet la sécurité.
Quelques exemples de comptes de rôle
Lorsque vous utilisez un compte de rôle dans ces systèmes, vous perdez la capacité de séparer le trafic. Par conséquent, les journaux d’accès deviennent confus et opaques.
À titre d’exemple :
Vos journaux indiquent que l’utilisateur « ubuntu » s’est connecté à 04:32:15 et a exécuté la commande rm -rf */command. Cependant, vous n’avez aucune visibilité sur l’ingénieur qui a réellement exécuté la commande, car ils utilisaient un compte de rôle partagé !
Un autre exemple :
Tous vos responsables de comptes se connectent à votre CRM (Customer Relationship Manager) hébergé avec l’identifiant « vendor-name@mystartup.com », car il est bien moins cher de n’avoir qu’un seul compte et cela permet une meilleure transparence au sein de l’équipe. Cependant, vous ne pouvez pas voir qui a fait quoi, seulement que cela a été fait.
Ce ne sont là que des problèmes potentiels d’administration et de responsabilité. Le véritable danger lié à la mauvaise utilisation des comptes de rôle vient de l’affaiblissement de la sécurité.
Lorsque vous utilisez ce type de comptes de rôle partagés, les identifiants doivent être changés chaque fois qu’une personne quitte l’équipe, et ces nouveaux identifiants doivent être redistribués à toutes les personnes qui ont besoin d’y accéder. Il s’agit d’un processus manuel, très exigeant en main-d’œuvre, et sujet aux erreurs.
Pièges courants
Bien que vous puissiez atténuer les problèmes liés aux comptes de rôle partagés en appliquant de bonnes pratiques d’hygiène et en utilisant des ressources uniques pour accéder au compte de rôle, au final, vous continuez malgré tout à masquer les identités. Configurer les comptes « ec2-user » et « Administrator » pour utiliser des clés ou des certificats uniques accordant un accès individuel aux comptes de rôle est une meilleure approche, mais cela ne reste qu’une solution partielle.
Faire confiance à vos employés et collègues est un élément important de tout système de sécurité. Cependant, chaque fois que vous ajoutez quelqu’un à l’équipe, vous ajoutez de multiples vecteurs d’attaque aux ressources auxquelles cette personne a accès. Lorsque vous utilisez des comptes de rôle, tous ces vecteurs sont concentrés sur une seule cible, de sorte qu’un attaquant dispose désormais de plusieurs façons d’attaquer le même ensemble d’identifiants.
De plus, cela limite vos options de remédiation lorsqu’une attaque réussit. Vous ne pouvez pas simplement désactiver le compte de rôle, car cela couperait l’accès à toute l’équipe.
Un autre problème se pose lorsque des membres de votre équipe quittent votre organisation. Quand votre stagiaire commercial termine sa mission tout en conservant l’accès à l’ensemble de votre CRM, c’est bien plus que partir avec son propre carnet d’adresses : c’est partir avec le carnet d’adresses de tout le monde. Si votre ingénieur principal quitte l’équipe, il a toujours la clé privée de votre compte de rôle utilisateur « ubuntu » sur son ordinateur portable personnel. Si cet ancien employé part travailler chez un concurrent, il peut conserver un accès continu à votre infrastructure sans être détecté.
La bonne voie à suivre
Heureusement, tous ces problèmes peuvent être résolus en attribuant des identités spécifiques à chaque personne qui accède à vos outils. Vos journaux deviendront plus clairs, et votre capacité à savoir qui a ou n’a pas accès aux systèmes sera bien définie.
L’attribution et la révocation des privilèges deviennent une tâche simple et sont faciles à auditer. En plus, votre PDG et votre équipe de sécurité dormiront plus tranquillement, sachant que personne en dehors de l’entreprise ne sème le chaos dans vos systèmes.
Traditionnellement, vous aviez besoin d’une identité unique sur chaque système que vous vouliez utiliser pour éviter d’utiliser des comptes de rôle. Ainsi, chaque hôte auquel vous vouliez vous connecter et chaque fournisseur auquel vous vouliez accéder nécessiterait des comptes uniques pour chaque employé. Cependant, cela ne fait qu’ajouter une étape au processus d’onboarding et d’offboarding, et peut facilement être oublié.
C’est là que les solutions de gestion des identités viennent à la rescousse. En disposant d’une source d’identité centrale à laquelle tous les autres systèmes peuvent s’intégrer, vous accordez ou révoquez les autorisations en un clic. Avec des protocoles comme OAuth et SAML combinés à des outils comme LDAP et AD, vous pouvez obtenir une identité complète sur plusieurs plateformes. Vous pouvez le créer vous-même ou utiliser des solutions fournies par le fournisseur, et laisser les membres de votre équipe se démarquer en donnant à chacun sa propre identité.
Chez Foxpass, nous vous aidons à maintenir la sécurité et les meilleures pratiques opérationnelles en facilitant la gestion de comptes utilisateurs distincts. Nous automatisons même la création et la suppression des comptes en les synchronisant avec votre fournisseur d’identité (comme Google, Office365, Okta, OneLogin ou Bitium). Nous proposons également des fonctionnalités d’accès temporaire qui révoquent automatiquement l’accès après une période définie. De plus, nos serveurs hébergés dans le cloud vous évitent d’avoir à gérer vous-même un serveur LDAP ou RADIUS.
Vous voulez découvrir par vous-même la simplicité et l’efficacité de Foxpass ? Qu’attendez-vous ? Démarrez dès aujourd’hui un essai gratuit de 30 jours :
