Eléments à prendre en considération pour la réussite d’un projet RBAC

De plus en plus d’articles publiés sur le net laissent à penser que la gestion des accès basée sur des Rôles (Role Based Access Control ou RBAC en anglais) est un concept dépassé.

Avec plus de dix années d’expérience dans le secteur de l’Identity Management, Tools4ever a il est vrai, souvent, voire très souvent même, été le témoin de projets touchant à la gestion des accès basée sur des rôles ne tenant effectivement pas la route.
Quelles sont les raisons d’un tel constat d’échec ? Et quelles sont les bonnes pratiques garantissant la réussite de votre projet ?

Voici quelques éléments de réponse :

1/ Ne pas chercher à créer à tout prix une matrice des accès et des rôles complète

Lors de l’implémentation de projets de RBAC, les organisations recourent généralement aux services de sociétés de conseil qui consacrent énormément de temps – voire parfois même des années – à effectuer des interviews et d’autres actions nécessitant pas mal d’efforts dans le but de construire une matrice parfaite contenant tous les rôles et accès existant dans l’organisation. Très coûteuse, cette approche aboutit rarement au résultat escompté. En effet, le monde de l’entreprise n’étant par essence pas statique, se focaliser sur une matrice des rôles ‘complète’ a toutes les chances de déboucher sur une entreprise sans fin.

2/ Notre conseil : Axez votre travail préparatoire sur un modèle pyramidale

Si une organisation souhaite réellement obtenir de bons résultats et à moindre coûts, la méthode pyramidale est recommandée. L’idée principale est que l’ensemble des accès peut être appréhendé comme une pyramide comportant des accès fondamentaux et secondaires. Exemple des échelles de niveaux :

• Niveau organisation (OS, login + e-mail)
• Niveau département/service (dossier(s) de partage, applications métier)
• Niveau fonction / intitulé de poste (plus détaillées)
• Niveaux des autorisations / rôles les plus détaillés (exemple rôles dans SAP)

Cette méthode a pour avantage principal de générer des des résultats immédiats et applique ainsi de la règle des 80/20 (80% de résultats avec 20% d’efforts).

3/ Faire la différence entre les autorisations et accès structurés et ad-hoc :

Un des risques inhérents aux projets relatifs à la gestion des accès basée sur des rôles est de se perdre dans la « jungle » des autorisations. En effet, il n’est pas concevable d’extraire un modèle type de rôles à partir des autorisations et des  accès secondaires de la pyramide, car bien souvent ils ont été attribués arbitrairement ou à titre exceptionnel et sont de ce fait pas structurés. En revanche, certains accès et autorisations sont structurés et peuvent très bien représenter un rôle précis s’inscrivant parfaitement dans la définition du modèle. Il faut donc impérativement différencier ces deux types d’autorisation dès la conception du projet, car le processus de gestion et la collecte des informations se rapportant à ces deux types d’autorisations sont différents.

Au départ, les accès et autorisations non-structurés peuvent très bien être gérés par un système de demande par workflow  avec traçabilité pour alimenter par la suite la matrice de façon plus exhaustive.

Autres éléments importants à prendre en compte :

• Les prérequis de conformité (exemple ‘segregation of duty’ dans SOX),
• Gestion de l’existant par rapport au futur (as is – to be),
• La description des rôles /accès fonctionnels et techniques (demande fonctionnelle vs. réalité technique)

Pour en savoir plus sur la gestion des rôles et la gestion des accès, n’hésitez pas à prendre contact avec nous.

• et marquée avec gestion des identités et des accès
• Gestion des Identités
• matrice des accès et des rôles
• rbac
• sox
• workflow