#BackToBasics : la gestion des habilitations, des principes fondamentaux à l’industrialisation de la démarche

Habiliter les utilisateurs du système d’information d’une organisation consiste à leur accorder les bons droits d’accès. Chaque acteur qui accède aux données de l’entreprise doit posséder un niveau d’habilitation adapté à ses missions ou sa situation. À noter qu’on parle également de permissions, de privilèges ou d’autorisations. Tous ces termes sont des synonymes qui désignent les habilitations.

Sur le papier, la tâche paraît simple, n’est-ce pas ? Mais si on transpose cela à la réalité de l’entreprise, il s’agit d’habiliter des centaines voire des milliers d’utilisateurs qui vont interagir avec un SI de plus en plus ouvert et hétérogène. On comprend alors bien pourquoi il existe des solutions pour en industrialiser la gestion !

À l’heure où les cyber-menaces explosent littéralement, la sécurité du SI et des ressources de l’entreprise est un enjeu prioritaire. Une gestion des habilitations défaillante représente une menace de sécurité sérieuse et peut être lourde de conséquences pour l’entreprise. En effet, le contrôle des droits d’accès est l’un des éléments indispensables qui protège le SI contre les dysfonctionnements liés au facteur humain, aux utilisations frauduleuses et à la perte ou au vol de données. 

Cela étant dit, les projets de gestion des identités et des habilitations sont malheureusement souvent perçus comme complexes, voire pénibles pour l’entreprise. Pourtant, en s’appuyant sur quelques principes de base, un outil de gestion des habilitations et une démarche itérative, c’est un projet qui apportera un ROI appréciable et des réponses immédiates à des enjeux clés pour l’entreprise.

Les principes fondamentaux en matière de droits d’accès au SI

Avant d’aborder la mise en œuvre d’un projet de gestion d’habilitations, il me semble important de rappeler quelques règles d’or qui définissent une bonne gestion des habilitations :

Le principe de moindre privilège

Le principe est simple : un utilisateur doit disposer uniquement des droits nécessaires à l’exécution de ses missions, ni plus ni moins. L’idée sous-jacente est de restreindre les droits d’accès des utilisateurs pour réduire les risques de sécurité. Selon ce même principe, chaque processus, appareil et application du système doit se voir attribuer la moindre autorité nécessaire pour éviter de compromettre des informations privilégiées. 

Pour appliquer ce principe du moindre privilège dans l’entreprise, on pourra notamment se baser sur les rôles métiers des organisations (RBAC, ORBAC) et les profils applicatifs.

C’est sur ce principe du moindre privilège que repose le modèle de sécurité Zero trust notamment. Pour en savoir plus, je vous conseille de consulter notre billet #BackToBasics : le Zero Trust Network Access (ZTNA) de quoi parle-t-on exactement ?

La séparation des tâches

La séparation des tâches (ou en anglais SOD – Segregation Of Duties) est un principe indispensable lorsqu’il s’agit d’attribuer des habilitations. Il consiste à éviter qu’un utilisateur cumule des droits incompatibles qui auraient un impact significatif sur le niveau de risque d’erreurs opérationnelles ou de fraude.

D’une manière générale, cela signifie qu’aucune personne ne doit avoir sous sa responsabilité toutes les étapes clés d’un processus. Un utilisateur ne doit donc pas cumuler des droits lui permettant d’initier, valider et contrôler une même tâche. Les responsabilités de ces différentes tâches doivent impérativement être réparties entre différents utilisateurs.

La séparation des tâches est une mesure fondamentale dans une démarche de contrôle continu et mise en conformité de l’entreprise (RGPD, BALE). C’est même une obligation dans certains secteurs comme le domaine bancaire où les conséquences peuvent être lourdes… On a tous en tête la tristement célèbre affaire Kerviel.

La gestion des comptes à privilèges

Certains utilisateurs se verront accorder plus de privilèges que d’autres, c’est notamment le cas des administrateurs qui sont habilités à créer, modifier et/ou supprimer des comptes utilisateurs, à modifier les configurations de certains systèmes ou encore accéder à des données confidentielles, etc.

Ces comptes à privilèges nécessitent un traitement spécifique car ils représentent un risque de sécurité élevé. Ils doivent faire l’objet d’un contrôle rigoureux et d’une surveillance accrue afin de limiter l’impact potentiel de leur compromission sur l’entreprise.

La gestion des accès à privilège sur des serveurs est généralement réalisée par une application dédiée. Ce service pourra proposer la mise à disposition de comptes administrateurs pour les serveurs protégés (le contenu d’un bastion par exemple). Un administrateur qui se connecte sur cette application se verra proposer des autorisations administrateurs pour réaliser des actions. Les accès à ce type d’application devront être particulièrement surveillés et seules les personnes pour lesquelles ces privilèges sont indispensables à l’accomplissement de leurs missions doivent posséder ces droits sensibles. Leurs droits d’accès doivent être révoqués lorsque cela n’est plus le cas.

La politique de gestion des habilitations

La politique de gestion des habilitations est une mesure organisationnelle interne faisant partie intégrante du référentiel de sécurité des entreprises. Elle répond à plusieurs impératifs identifiés par la CNIL et ce sont les responsables de traitements qui en ont la charge.

La politique de contrôle des accès et des habilitations doit être documentée et réexaminée régulièrement. Elle doit, entre autres, lister :

• Les personnes autorisées à accorder des ressources et comment ces personnes y sont autorisées.
• Les workflows à appliquer à l’arrivée, au départ ou lors de la mutation d’un collaborateur. Cela est d’autant plus important lorsque ces utilisateurs ont accès à des données sensibles.
• Les sanctions prévues pour les utilisateurs ayant un accès légitime aux données en cas de non-respect des mesures de sécurité.

Les pratiques à proscrire

• Donner des droits d’administrateurs à des utilisateurs n’en ayant pas besoin.
• Fournir des privilèges d’administration sur des périodes plus importantes que nécessaire.
• Oublier de retirer des autorisations temporaires accordées à un utilisateur (pour un remplacement, par exemple).
• Accorder à un utilisateur plus de privilèges que nécessaire.
• Créer ou utiliser des comptes partagés.
• Oublier de supprimer les comptes utilisateurs des personnes ayant quitté l’organisation.
• Ne pas réviser les habilitations des personnes ayant changé de fonction ou de statut dans l’organisation.
• Ne jamais revoir sa politique d’accès et d’habilitations.

Les prérequis à l’industrialisation de la gestion des habilitations

Vous avez pour projet d’automatiser la gestion de vos habilitations au sein de votre organisation ? Le déploiement d’un logiciel de gestion des identités nécessite d’appliquer une démarche projet incrémentale afin de voir rapidement des premiers bénéfices. Quelques prérequis sont cependant indispensables à la mise en œuvre initiale.

Disposer d’un référentiel unique des identités

Automatiser la gestion des habilitations au sein de votre organisation imposera de disposer d’un référentiel central, unique et fiable des identités.

Dresser un état des lieux de l’existant est un prérequis indispensable pour pouvoir construire une infrastructure de gestion des identités et des habilitations sur des bases solides. Ainsi, la première étape du projet consistera à cartographier, rationaliser et consolider les différents référentiels existants au sein du SI.

Ces référentiels permettront de créer une identité unique pour chaque personne et de définir ses attributs, afin de lui délivrer des habilitations correspondant à ses besoins. Attention donc à la donnée, qui doit être de qualité, fiable et cohérente. D’expérience, un nettoyage est souvent nécessaire pour corriger les erreurs des identités, nettoyer les comptes orphelins et les doublons, etc. C’est un travail qu’il ne faut absolument pas sous-estimer, mais il faut prendre ce temps pour en gagner ensuite.

Une bonne pratique est de travailler en synergie avec les ressources humaines sur les données de référence du SIRH et les processus métier (entrée – mobilité – sortie) de l’entreprise.

Modéliser les droits d’accès

Les solutions d’IAM s’appuient sur un modèle de droits afin d’industrialiser la gestion des habilitations notamment. Il conviendra donc de modéliser ses habilitations, c’est-à-dire de définir le lien entre un utilisateur et ses droits d’accès au SI. On peut ainsi se baser sur les rôles métier, profils applicatifs, une notion de périmètre ou portée (pays, région, un site, un bâtiment, un service, etc.).

Il existe de nombreux modèles d’habilitation qui ne doivent pas s’exclure les uns les autres (ABAC, RBAC, ORBAC, ACL, DAC, MAC, etc.). Je ne vais pas tous les détailler ici (je vous invite à consulter cet article de notre partenaire IDento qui brosse très bien le sujet), mais ce qu’il faut retenir c’est que le choix d’un modèle s’effectue en fonction de la structure, de l’organisation et du contexte de sécurité dans lequel évolue l’entreprise. Ce choix n’est pas figé et évoluera avec les besoins futurs de l’entreprise.

Aujourd’hui, le principal modèle d’habilitation utilisé en entreprise est le modèle RBAC (Role-Based Access Control) qui repose sur la définition de rôles (ou profils). Les rôles sont définis au niveau de l’organisation et prennent en considération différents critères tels que le métier, le rôle managérial, la position hiérarchique, les accréditations, etc.

Pour dresser les matrices de rôles, les managers métier de votre organisation devront être sollicités car ils sont les plus à même d’exprimer les besoins d’accès aux applications pour leurs équipes. Les responsables applicatifs devront également être consultés pour limiter/encadrer les choix des managers qui pourraient être tentés d’accorder plus de droits que nécessaire ou de répéter les droits déjà accordés à d’autres membres de leur équipe sans vérifier que l’ensemble de ces droits sont ou restent pertinents.

Attention, les rôles définis devront tenir compte du principe de séparation des tâches SOD (Segregation Of Duties). Il faudra alors réunir un panel plus large de responsables métier et responsables applicatifs pour détecter les combinaisons de rôles interdites/dangereuses.

À noter qu’une bonne pratique consiste à limiter fortement par défaut le nombre de rôles associés à une identité pour en simplifier la gestion.

Maîtriser le cycle de vie des utilisateurs du SI

Attention à ne pas confondre la gestion des habilitations et la gestion du cycle de vie des utilisateurs. La gestion du cycle de vie des utilisateurs consiste à modéliser et outiller la gestion des événements de la vie d’une identité au sein de l’entreprise. Elle concerne toutes les populations devant se connecter au SI (employés, prestataires, fournisseurs, partenaires, clients, etc.) et couvre tous les événements pouvant varier selon les populations et les activités : arrivée, changement de poste, départ, absence longue durée, etc.

L’identité numérique étant une notion centrale, maîtriser son cycle de vie est un préalable indispensable. En effet, la gestion de l’identité est au service de la gestion des habilitations et des accès au travers du provisioning. Les processus techniques de provisioning des comptes et des droits sur le SI garantissent que chaque utilisateur du SI ait les bons droits au bon moment.

Définir les processus liés à la gestion des droits

Qui dit outillage dit formalisation vous l’aurez compris, voici donc quelques points à garder en tête lorsque vous formaliserez les processus autour de vos habilitations.

• L’attribution d’une ressource doit se faire sous la responsabilité conjointe du propriétaire de la ressource et du responsable métier. Le responsable métier doit disposer des moyens d’attribuer les droits à ses équipes, puis de les contrôler. Le propriétaire de la ressource lui sera en charge de définir sa sensibilité et ses modalités d’attribution et d’accès.
• Pour les ressources sensibles, plusieurs niveaux de validation pourront être nécessaires et un délai de traitement long sera tout à fait acceptable. Pour des ressources non sensibles, l’attribution pourra être plus rapide en permettant aux collaborateurs de se les auto-attribuer, via un self-service qui mettra à disposition un catalogue de rôles.
• Même si en pratique le self-service permet aux utilisateurs de s’accorder eux-mêmes un droit sur une ressource, il s’agit en réalité d’une délégation du manager ou du propriétaire de la ressource. La responsabilité de fournir cette habilitation reste l’apanage du manager ou du propriétaire. Le self-service ne désengage pas de cette responsabilité. Le self-service peut d’ailleurs maintenir une validation managériale pour tout ou partie des services proposés.
• Une analyse de risque devra être réalisée pour la mise en place d’un processus d’habilitation pour une ressource sensible.
• La gestion des personnels externes et de leurs habilitations doit être sous la responsabilité d’un collaborateur interne. Ces habilitations ne peuvent avoir une durée de vie plus longue que la mission en cours. La vérification de ces délais devra être introduite dans la revue des habilitations.
• Une réconciliation périodique des habilitations, à minima sensibles, doit être réalisée à intervalles réguliers afin de s’assurer que les droits réels dans les applications sont toujours alignés avec le modèle de droits (comptes orphelins, comptes non conformes au modèle, etc.).
• Une revue des droits doit être réalisée, à minima annuellement, afin d’identifier et de supprimer les comptes non utilisés, réaligner les droits accordés sur les fonctions de chaque utilisateur et vérifier l’absence de droits incompatibles. L’automatisation de cette tâche évitera le côté extrêmement fastidieux pour les responsables hiérarchiques, les propriétaires des ressources et le responsable du SI. Elle permettra également de faciliter le reporting et de fournir des traces en cas d’audit.