Maksim Kabakou - Fotolia
Sudo, cet outil méconnu si riche de fonctionnalités
Il faut manipuler la ligne de commande sur un système Unix/Linux pour connaître ce dispositif utilisé afin d’accéder ponctuellement aux niveaux de privilèges les plus élevés. Mais il peut être intégré dans une véritable stratégie PAM.
Aujourd’hui chez Quest Software, à travailler sur la plateforme One Identity, Todd Miller est l’un principaux développeurs de Sudo, cet incontournable utilitaire d’élévation de privilège des systèmes Unix/Linux. Nous revenons avec lui, et Tyler Reese, chef de produit senior chez One Identity, sur la version 1.9 de Sudo, lancée au printemps.
LeMagIT : La principale nouveauté de Sudo 1.9 est l’enregistrement centralisé des sessions. Comment cela fonctionne-t-il ?
Todd Miller : Sudo supporte l’enregistrement de sessions depuis sa version 1.8. Mais les enregistrements étaient stockés localement sur la machine. Il était donc possible de déplacer ou modifier ces traces d’activité. Désormais, les enregistrements peuvent être stockés sur un système centralisé, sécurisé, pour empêcher un utilisateur local de les modifier.
Todd MillerDéveloppeur, Quest Software
Cela ne passe pas par un mécanisme comme syslog. Les sessions sont streamées en temps réel [la transmission peut-être chiffrée]. Il est possible de configurer plusieurs systèmes qui seront contactés par sudo. Mais si la connexion à ces systèmes est impossible, en raison d’un problème réseau par exemple, suivant la configuration, la commande va être autorisée à s’exécuter ou pas. Il est complètement possible de configurer la manière dont seront traités les échecs.
Seul le texte, en ligne de commande, est enregistré – que ce soit en saisie ou en sortie.
LeMagIT : À cela s’ajoute également une API d’audit et d’approbation. Cela vaut-il pour des cas d’usage tels que l’attribution de droits d’administration en mode à la volée, en just-in-time, de manière intégrée à ses processus de PAM ?
Todd Miller : C’est effectivement l’un des cas d’usage. Vous pouvez ainsi avoir une politique [de sécurité par défaut] sudoers qui autorise l’exécution directe de commandes, mais vous pouvez également avoir un plug-in qui permet de gérer l’attribution des droits en JIT.
Au début de notre réflexion sur ce sujet, nous avons décidé d’avoir un mécanisme de plug-in, pour éviter que de multiples politiques de sécurité n’interagissent les unes avec les autres. Car lorsque c’est le cas, il devient difficile d’obtenir des résultats vraiment prévisibles. Mais certaines personnes veulent aussi des politiques au-dessus de tout cela. En fait la plupart des gens ne vont pas remplacer leur fichier de sudoers ; ils veulent seulement ajouter là de nouveaux contrôles. D’où l’approche plug-in.
Il y a une tendance de fond en faveur d’une gestion zero-trust des privilèges, avec des approbations à la volée. Et cela en tenant compte de contraintes temporelles ou en s’intégrant à un ServiceNow – un ticket est alors nécessaire pour obtenir les privilèges.
LeMagIT : Quels langages sont supportés pour l’écriture des plug-ins ?
Todd Miller : Sudo est écrit en C. Nous avons donc commencé par là. Mais avec la version 1.9, nous supportons également les plug-ins écrits en Python. C’est l’un des langages les plus populaires actuellement. Et probablement plus important encore, bon nombre de services cloud ont des librairies Python pour faciliter l’intégration.
Todd MillerQuest Software
Tyler Reese : Et la prévalence de Python dans le monde de la sécurité est encore plus marquée : toutes les red et blue teams utilisent Python. Nous voulions prendre une orientation écosystème pour disposer d’une offre plus diverse. Python permet d’abaisser la barre à l’entrée.
Vous devez penser à des cas d’usage d’entreprise. Par exemple, l’un des plug-ins permet d’assurer l’évaluation des règles sur notre serveur Privilege Manager, suivant sa grammaire. Le plug-in Audit permet de travailler sur les données et la manière dont elles sont structurées – si quelque chose comme syslog ne convient pas, par exemple. Et un autre permet de gérer des scénarios d’authentification spécifiques, par exemple pour des actifs particulièrement critiques, et demander au passage la validation d’une carte à puce.
LeMagIT : J’ai l’impression que beaucoup de gens méconnaissent largement Sudo…
Todd Miller : C’est effectivement très répandu. La plupart des gens ne connaissent Sudo que comme le moyen d’exécuter des commandes à privilèges. Leur expérience de Sudo se limite probablement à leur poste de travail ou leur ordinateur portable.
Il faut dire que Sudo a grandi dans un environnement pédagogique, avec des niveaux de droits d’administration différents. Il y avait une vraie nécessité à fournir des accès limités. Mais les cas d’usage de Sudo sont en fait très variés, depuis l’utilisateur individuel jusqu’à la grande entreprise. Et en environnement professionnel, si vous arrivez au bureau le lundi et que tout est cassé ; vous avez besoin d’un moyen de savoir ce qui s’est passé.
L’éventail est tellement large que nous avons écrit un livre intitulé « maîtrise de sudo ». Et lorsqu’on parle de ce livre, souvent, la réaction est « mais c’est dingue ! ». C’est parce que chacun ne l’utilise que suivant ses cas d’usage.
Tyler Reese : Nous l’observons aussi chez One Identity, avec les entreprises qui adoptent de plus en plus l’open source, mais qui ont besoin de fonctionnalités de classe entreprise, comme l’audit centralisé et personnalisé, la gestion centralisée des accès à privilèges, etc. L’embauche de Todd s’inscrit dans cette perspective, pour s’assurer que les fonctionnalités attendues par nos clients entreprises arrivent dans Sudo.