Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Mettre en place un projet de sécurité des identités : Des a priori « technologiques » à déconstruire

juin 2023 par Sébastien Lelarge, Solutions Engineering Manager, SailPoint

Au sein des entreprises, les impératifs de sécurité tant physiques que cyber ne font plus débat. En revanche, nombreux sont les a priori qui persistent lorsqu’on parle, plus précisément, de gestion des accès et de gouvernance des identités. Ce sont pourtant bien des éléments phares de l’aspect cybersécurité des entreprises, quels que soient leurs tailles ou le nombre de collaborateurs ou de prestataires avec lesquels elles travaillent.
Revenons sur six a priori technologiques à déconstruire pour s’assurer non seulement du succès d’un projet de sécurité des identités, mais aussi réduire le cyber risque dans les organisations.

1 – « Seules les entreprises soumises à des règlementations spécifiques (types banques, assurances, santé…) sont concernées. »

En réalité l’ensemble des entreprises, dès lors qu’elles ont des salariés, sont concernées. Selon une étude IDSA et dimensional research, 84 % des entreprises, quel que soit leur domaine d’activité, ont subi une faille relative à l’identité, et 96 % d’entre elles confessent que cela aurait pu être minimisé voire empêché, en mettant simplement en œuvre un programme de sécurité des identités. En matière de sécurité, l’automatisation et l’accélération de ce type de processus sont des atouts majeurs pour garantir, par exemple, que chaque identité a les bons accès aux bonnes ressources, et, à tout moment de leur cycle de vie, du onboarding de l’utilisateur à son offboarding, en passant par ses éventuels changements de poste. Ce qui prenait auparavant plusieurs heures, voire plusieurs jours ne prend désormais plus que quelques minutes avec un outil de gestion des identités.

2 – « La revue des accès et la SoD (Segregation of Duties), ce n’est pas pour moi. »

La revue des accès et la SoD peuvent être vues comme des fonctionnalités de gouvernance avancées, pourtant elles ne sont pas dédiées qu’au monde de la banque ou de l’assurance. Ce sont des fonctionnalités particulièrement efficaces pour vérifier la légitimité des accès des collaborateurs grâce à la mobilisation des responsables applicatifs et des propriétaires de ressources. Il est même très souvent plus judicieux d’aborder un projet IAM (gestion des identités et des accès) par la mise en place de ces fonctionnalités, car cela permet de remettre rapidement l’entreprise dans une situation de risque minimal du point de vue des accès.

3 – « Nous avons une démarche “cloud first” et heureusement, tous les éditeurs proposent des solutions SaaS. »

Sous l’acronyme SaaS (Software as a Service) se cache un nombre incroyable de solutions qui n’ont rien à voir avec du SaaS. S’il est vrai que beaucoup d’éditeurs proposent des solutions cloud, ce ne sont pas pour autant des solutions SaaS, à savoir : un service auquel on souscrit et dont on n’aura pas besoin de gérer les mises à jour à la différence d’un logiciel.
La majorité des solutions cloud sont des logiciels en services managés. En souscrivant à de telles offres, les entreprises n’ont plus d’infrastructures à gérer, en revanche elles seront toujours soumises aux montées de version, aux plages de maintenance et elles prennent le risque de se retrouver bloquées dans une version. Les questions à se poser dès lors sont : quel est l’objectif de la démarche « cloud first » ? S’agit-il de s’affranchir de l’hébergement de la solution ? Ou souhaite-t-on un service sur étagère, toujours à jour, sans besoin de maintenance ou montée de version ? Quand on migre sur Office365, on ne veut pas d’un serveur Exchange dans le cloud mais on souscrit à un service – en l’occurrence Exchange online. En matière de sécurité des identités, peu d’acteurs proposent réellement une solution SaaS, et c’est sur ce point qu’il faut être vigilant.

4 – « Ce sont des projets longs à mettre en place »

Historiquement et dans un contexte logiciel, cet a priori était compréhensible. Mais ce n’est plus vrai aujourd’hui, surtout lorsqu’on choisit de travailler avec un intégrateur qui propose ses projets sous la forme de MVP (Minimum Viable Product) avec un engagement de livraison de la première version en moins d’un an. Avec la version standard d’une véritable solution SaaS, le délai de livraison du MVP peut même être de quatre mois. La version standard regroupe généralement les bonnes pratiques adoptées par des centaines d’autres entreprises qui ont réussi leur projet IAM. Le SaaS est un catalyseur et l’utilisation d’une telle plateforme permet de s’absoudre des délais de montée de version, des charges induites par la mise en place d’une architecture technique en interne ainsi que des coûts de maintenance.

5 – « Avant de lancer un projet IAM, je vais commencer par sécuriser l’accès au SI avec de la MFA (Authentification multi-facteur) et mettre sous contrôle les comptes à privilèges »

C’est une démarche rassurante de prime abord, toutefois à quelques exceptions près, c’est généralement une mauvaise idée de lancer son projet de sécurité des identités après l’AM (Access Management) et le PAM (Privileged Access Management). Pour être vraiment efficace, ces types de solutions ont besoin des données d’identités précises. C’est l’IAM qui permet d’avoir ces informations les plus à jour possible et permet par exemple, de savoir avec certitude si un utilisateur est actif pour lui autoriser les accès ou les lui refuser. Ou encore de réagir rapidement à un changement dans le cycle de vie de l’utilisateur et désactiver ces accès aux applications. L’AM va consommer le fait que l’utilisateur est inactif en faisant confiance à l’IAM. Ce dernier est la pierre angulaire de l’identité et ce, pour toutes les solutions de sécurité qui vont graviter autour.

6 – « Se faire accompagner est trop onéreux, nous allons le faire nous-même pour économiser »

Les coûts liés à un projet qui n’a pas été mené par des professionnels sont souvent difficiles à anticiper voire décuplés, sans compter le temps de mise en œuvre qui s’en trouve forcément rallongé. Même dans un projet basé sur une solution SaaS avec les fonctionnalités standard, la phase d’implémentation est importante. Si cela représente effectivement un coût, il faut surtout regarder le ROI attendu. Un intégrateur s’engage sur un budget / forfait, une durée pour les différents livrables (l’approche MVP, par lots) et va mobiliser les ressources humaines ayant l’expérience nécessaire à la réussite du projet dans les temps. Si cela représente une part importante du budget global d’un projet IAM, se lancer seul dans un tel chantier est plus risqué financièrement, même lorsqu’on pense avoir les compétences en interne.


Voir les articles précédents

    

Voir les articles suivants