Les besoins ou les demandes des utilisateurs vont vers plus de mobilité et plus de facilité pour accéder aux ressources nécessaires à leur fonction. Bill Gates expliquait dans une interview parue dans l’Express le concept de cloud computing qui consiste à stocker les données des utilisateurs sur des serveurs centraux afin de les rendre accessibles depuis différents terminaux. Le futur retraité de Microsoft expliquait que ce concept implique un changement fondamental sur l’informatique, autrefois centrée sur les ordinateurs, qui doit désormais être centrée sur l’utilisateur. La nécessité d’intégrer la sécurité dans ce concept semblait évidente pour Bill Gates, mais est-ce si trivial dans un environnement professionnel qui suppose un partage contrôlé des informations ?
Les responsables sécurité sont de plus en plus confrontés au problème de mise en œuvre d’un contrôle efficace des utilisateurs. La mise en œuvre de ce contrôle des utilisateurs n’est pas évidente car les solutions sont nombreuses et la recette universelle n’existe pas.
La théorie de la sécurité définit plusieurs types de contrôles, mais en pratique, les contrôles sont implémentés à deux niveaux : au niveau processus et au niveau technique.
Pour prendre un exemple simple, le contrôle d’accès à un bâtiment peut se résumer aux contrôles effectués lors du processus de délivrance d’un badge et par le contrôle (automatique) de validité effectué par le système de badge couplé aux différentes portes du bâtiment.
La force du contrôle réside dans la cohérence des contrôles procéduraux et techniques. Les contrôles appliqués dans les processus peuvent être rendus inefficaces si les solutions techniques sont trop faibles et peuvent être bypassées. Il en est de même lorsque les solutions techniques sont très (voir trop) strictes, si les processus encadrant sont trop lascifs.
Pour reprendre l’exemple précédant, un processus d’habilitation rigoureux appliqué pour attribuer un badge est inutile si les lecteurs de badge sont sur de simples portes qui permettent à plusieurs personnes de passer après que la première ait badgé. De même un système de sas onnéreux ne remplit pas sa fonction (laisser entrer uniquement des personnes habilitées) si le processus de gestion des badges ne contrôle pas rigoureusement la restitution des badges des personnes quittant l’entreprise. Cet exemple pris dans le contexte de sécurité physique peut parfaitement se décliner dans un contexte logique en considérant l’accès aux ressources informatiques.
Centrer les contrôles sur les utilisateurs suppose une gestion des identités et des habilitations rigoureuse. Il est important de comprendre que l’IAM (Identity and Access Management) est un ensemble de processus et de mécanismes techniques mis en oeuvre sur un SI qui sont nécessaires mais pas suffisants.
Le premier aspect de l’IAM concerne la gestion des identités et des mécanismes d’authentification. L’authentification des utilisateurs sur un SI moderne est rarement satisfaisante. Le mot de passe est encore le moyen le plus couramment utilisé pour s’authentifier alors que c’est le moyen le moins fiable pour le faire. Obliger les utilisateurs à choisir des mots de passe plus longs, plus complexes et à les changer plus souvent, donne une fausse impression de robustesse. Les solutions d’authentification “forte” existent depuis plusieurs années. Les éditeurs intègrent ces solutions dans leurs produits, dont Microsoft, mais la décision “politique” de renforcer l’authentification reste difficile à prendre, généralement pour une raison économique. La mise en oeuvre de la solution a non seulement un coût lié au projet et au déploiement, mais aussi un surcoût lié au support aux utilisateurs, qui doit être renforcé pour palier aux pertes d’authentifiant. La peur de ne pas pouvoir se connecter est le principal frein qui ne peut être levé que par un processus fiable (disponible lorsque cela est nécessaire et sécurisé pour éviter l’usurpation d’identité).
Le deuxième aspect de l’IAM est la gestion des habilitations ou des droits des utilisateurs à accéder à une ressource. La complexité de la gestion des droits est proportionnelle au nombre d’utilisateurs et de ressources auxquelles ils souhaitent accéder. Pour simplifier la gestion, il est nécessaire de définir des profils d’utilisateurs et des ensembles de ressources afin que la configuration des droits soit humainement gérable. Tout le problème revient à définir le bon niveau de granularité pour classifier les ressources et les utilisateurs. Si le niveau est trop macroscopique, les utilisateurs ont trop d’accès par rapport à leurs réels besoins, et si le niveau est trop fin, l’effort de gestion devient trop important par rapport aux enjeux de l’entreprise. De plus, le système doit pouvoir supporter les accès exceptionnels ou dérogatoires (exceptions qui durent). L’humain a aussi tendance à s’approprier les privilèges qu’on lui donne et il est souvent difficile de retirer des privilèges à quelqu’un, même si ces privilèges ne lui sont pas utiles. Sans système de gestion des habilitations formalisé, il est difficile de gérer les droits des utilisateurs et de les modifier lorsqu’ils changent de poste en supprimant les droits devenus inutiles.
Les privilèges ultimes sont ceux nécessaires aux administrateurs. La production informatique a trop souvent tendance à focaliser la disponibilité des accès des administrateurs au détriment du contrôle de leur activité. Il est (encore) difficile d’imposer l’abandon des comptes génériques et la généralisation de l’authentification forte. Le besoin de contrôle des administrateurs est d’autant plus important que leurs privilèges permettent de contourner la sécurité mise en place pour les utilisateurs standards. Cette capacité à contourner la sécurité est (malheureusement) à prendre au sérieux y compris à propos des utilisateurs non privilégiés. Un exemple simple: donner l’accès à l’annuaire de l’entreprise à un employé ou à un stagiaire est légitime. Lui permettre de le recopier dans sa totalité pour éventuellement le transférer à l’extérieur est plus discutable (l’exemple vaut pour toutes les données de l’entreprise). Dans ce cas le problème ne peut pas se résoudre par la mise en oeuvre d’un contrôle d’accès, mais par une analyse du comportement des utilisateurs et la détection d’une anomalie (lecture de l’intégralité de l’annuaire par une personne durant une courte période). Une bonne gestion des habilitations n’est pas suffisante pour assurer un contrôle efficace des utilisateurs.
Pour détecter une anomalie de comportement d’un utilisateur, il faut analyser les traces générées par les utilisateurs sur un SI. Cela suppose dans un premier temps que les différents composants génèrent des traces (des logs) et dans un deuxième temps que les logs soient traités. Pour que le traitement remonte des résultats liés aux utilisateurs, cela suppose que les logs intègrent des informations permettant l’identification des utilisateurs à l’origine des événements. Cette activité est (ou devrait être) l’objectif de la supervision de la sécurité. Les produits de supervision de la sécurité sont tous capables de centraliser les logs, en général dans une grosse base de données, d’aggréger les événements pour en diminuer le volume et de corréler des événements techniques pour en déduire des événements plus fonctionnels. Un projet de supervision de la sécurité ne doit pas se réduire au traitement des logs de firewalls ou autres composants d’infrastructures, car si le périmètre couvert est trop restreint, il est impossible d’interpréter les événements sous la forme d’actions humaines. La difficulté d’un tel projet est à la fois technique, aux vues de la volumétrie des logs à traiter et du nombre de composants différents à intégrer, et fonctionnelle, pour décrire sous forme de règles les comportements normaux (ou pas) des utilisateurs. Un autre problème est réglementaire car le droit à la vie privée doit être intégré dans le projet (Loi informatique et libertés – cf CNIL). Il est possible de dépersonnaliser les logs en limitant l’identification de l’utilisateur que lorsque cela est nécessaire (par un processus contrôlé).
Les services de contrôle interne devraient s’attacher à vérifier quel est le niveau de contrôle global des utilisateurs d’un SI (depuis les partenaires externes, en passant par les utilisateurs internes sans oublier les administrateurs). La cohérence des mécanismes de sécurité est très importante. La gestion des identités et des habilitations, et la supervision de la sécurité sont indispensables au contrôle efficace des utilisateurs. Au delà des outils, il est nécessaire d’identifier les tâches ou opérations qui ne sont pas correctement tracées ou qui ne peuvent pas être imputées à un utilisateur. Ce type d’audit de sécurité a une finalité différente des audits menés habituellement. En effet, il ne s’agit pas d’identifier les intrusions possibles sur un SI, ou de contrôler le respect de l’ISO27001, mais d’identifier les manques dans le processus d’habilitation ou de supervision, et dans les moyens techniques associés, qui peuvent impacter le contrôle des utilisateurs d’un SI.
(4 votes)
Loading ...