Le mot de passe n'a jamais été le seul problème : PAM traditionnel contre PAM moderne

Partie 1 sur 3 de notre série Rethinking Privileged Access.

La discussion autour de la gestion des accès privilégiés (PAM) tournait à l'origine autour d'une seule question : comment protéger le mot de passe ? Le mettre sous coffre. Le faire tourner. L'injecter dans les sessions pour que personne ne le voie jamais. Le protéger par des approbations et la MFA pour que seule la bonne personne puisse le récupérer. Le PAM traditionnel est l'une des réponses les plus matures et les plus répandues à cette question.

Résoudre le problème des mots de passe est essentiel, mais c'est loin d'être le seul. Le zero trust, l'absence de privilège permanent et l'accès juste-à-temps ont mûri depuis la conception du PAM traditionnel, qui n'a pas suivi.

C'est la croisée des chemins entre le PAM traditionnel et le PAM moderne avec Netwrix Privilege Secure (NPS). Le PAM traditionnel a été excellent dans ce pour quoi il a été conçu, mais arrêter les attaques modernes exige un outil conçu pour autre chose.

PAM traditionnel : protéger le mot de passe

Le PAM traditionnel part d'une hypothèse : les comptes privilégiés existent en permanence, et votre rôle est de les protéger au mieux. Si un compte est membre de Domain Admins aujourd'hui, il le sera encore demain, la semaine prochaine et l'année suivante, que quelqu'un utilise ce privilège ou non. Le PAM traditionnel joue le rôle de gardien rigoureux devant ce privilège permanent.

En pratique, ce contrôle ressemble à ceci :

• Un utilisateur a besoin d'accéder à un compte privilégié. Il doit d'abord disposer des bonnes autorisations dans l'outil PAM lui-même, via des attributions de rôles ou un accès au secret au niveau du dossier.
• Selon la politique, il peut devoir satisfaire à la MFA avant d'aller plus loin.
• Il demande l'accès au secret (un check-out), ce qui peut nécessiter l'approbation d'un ou plusieurs approbateurs désignés.
• Une fois approuvé, l'utilisateur ne voit généralement jamais le mot de passe. L'outil lance une session RDP ou SSH et y injecte directement l'identifiant.
• Le check-out a une durée limitée. Lorsque l'utilisateur a terminé ou que le temps est écoulé, l'outil effectue le check-in du secret.
• Après le check-in, l'outil fait tourner le mot de passe, de sorte qu'un identifiant exposé pendant l'utilisation n'est plus valide.

Ce modèle supprime l'exposition des identifiants, crée une piste d'audit claire et impose des contrôles d'approbation avant que quiconque n'accède à un compte sensible. Mais quelle que soit la rigueur du processus, le compte sous-jacent reste un Domain Admin (ou un administrateur local, ou un sudoer) entre les sessions. Le privilège est permanent. Seul l'accès au mot de passe est temporaire. Un administrateur peut aussi récupérer un mot de passe pour une tâche « rapide » en dehors de l'outil, contournant ainsi l'ensemble de ces contrôles.

Le PAM traditionnel a aussi une limite stricte dans Active Directory. Il lit l'appartenance aux groupes pour décider qui accède aux secrets, mais il ne crée, ne supprime ni ne modifie les groupes AD. L'appartenance aux groupes, et le privilège permanent qui va avec, échappe entièrement à son contrôle.

La partie 2 de cette série couvre les attaques qui contournent l'accès au mot de passe ou qui n'en ont pas besoin, et explique pourquoi le juste-à-temps et le zero standing privilege sont si puissants.

Lorsque les éditeurs de PAM traditionnel parlent de « juste-à-temps » ou de « zero standing privilege », ils désignent l'accès au mot de passe, pas le privilège du compte. Ils vous diront aussi qu'un véritable juste-à-temps exige un produit distinct de gestion des privilèges sur les postes de travail. Ce produit contrôle les droits d'administrateur local sur les ordinateurs des employés. C'est une forme de juste-à-temps, mais il ne couvre pas les comptes qui font tourner votre infrastructure critique, ce qui est le rôle du PAM. Netwrix propose aussi un produit dans cette catégorie : Netwrix PolicyPak.

PAM moderne : Netwrix Privilege Secure élimine le privilège permanent

Netwrix Privilege Secure part d'une prémisse différente. Au lieu de demander « comment protéger un compte puissant ? », il demande « pourquoi un compte puissant doit-il être puissant en permanence ? »

NPS s'articule autour de la session et des Activities, qui s'exécutent avant, pendant et après cette session pour accorder le privilège exactement quand il est nécessaire, puis le retirer dès qu'il ne l'est plus. NPS prend en charge trois approches de compte, chacune gérant ce cycle de vie différemment.

1. Comptes demandeurs

Il s'agit du compte que l'utilisateur utilise déjà pour se connecter à son ordinateur et à sa messagerie, sans compte privilégié distinct. Au démarrage d'une session, une Activity accorde le privilège à la volée, par exemple en ajoutant l'utilisateur à Domain Admins ou à un autre groupe AD privilégié. Comme il s'agit du compte propre de l'utilisateur, le mot de passe n'est pas placé sous coffre et l'utilisateur le saisit pendant la session. À la fin de la session, NPS retire automatiquement le privilège accordé au départ.

C'est souvent l'approche la plus pratique des trois, mais elle offre la plus faible protection des identifiants, puisque le mot de passe n'est ni renouvelé ni injecté. Elle supprime tout de même le privilège permanent, car le compte ne détient des droits élevés que pendant la durée de la session.

2. Comptes gérés

C'est l'analogue le plus proche du fonctionnement du PAM traditionnel. Au démarrage d'une session, NPS fait tourner le mot de passe du compte et l'active. Les Activities accordent le privilège pour cette session, par exemple en ajoutant le compte à Domain Admins, aux administrateurs locaux ou à un groupe sudo. Le mot de passe est injecté dans la session, de sorte que l'utilisateur ne le voit jamais.

La différence apparaît à la fin : NPS fait de nouveau tourner le mot de passe et le place sous coffre, annule le privilège accordé et désactive le compte. Le compte existe toujours, mais entre les sessions il ne détient aucun privilège et ne peut pas s'authentifier, ce qui rend un mot de passe volé inutile à un attaquant.

3. Comptes éphémères

Ce modèle va plus loin en créant un compte entièrement neuf au début de chaque session. Pendant la session, il se comporte comme un compte géré : le privilège est accordé et le mot de passe injecté. À la fin de la session, NPS supprime entièrement le compte, sans rien laisser à attaquer.

Au-delà du privilège : ce que les Activities peuvent faire d'autre

Accorder et révoquer l'appartenance aux groupes est la fonction phare, mais les Activities ferment aussi des chemins d'attaque que les modèles à accès permanent laissent généralement ouverts :

• Purge des tickets Kerberos. Lorsqu'une session RDP se termine, NPS peut purger les tickets Kerberos de la ressource, coupant un chemin de mouvement latéral qui ne nécessite pas le mot de passe d'un compte.
• Activation/désactivation de RDP. La plupart des serveurs Windows laissent RDP actif par défaut. NPS peut ne l'activer qu'au démarrage d'une session et le désactiver immédiatement après, supprimant une surface d'attaque importante et constamment disponible.
• Mode protection. NPS peut analyser les ressources Windows ou Linux à la recherche de comptes locaux non approuvés. Un initié malveillant qui utilise correctement votre outil PAM pourrait discrètement créer des administrateurs locaux pour un usage ultérieur non autorisé.
• Synchronisation de la réplication des DC. Un changement de privilège sur un contrôleur de domaine ne se propage pas toujours instantanément au DC qui gère l'authentification de la session. NPS peut forcer une synchronisation ciblée afin que le privilège accordé soit disponible immédiatement, au lieu d'attendre les délais normaux de réplication AD.

Comparatif

Le PAM traditionnel a réduit le risque lié aux identifiants. Le PAM moderne supprime la cible.

Le modèle check-out/check-in du PAM traditionnel est une façon mature et éprouvée de réduire l'exposition des identifiants et d'ajouter de la responsabilisation à l'accès privilégié. Pour de nombreuses organisations, il a représenté un progrès important par rapport aux mots de passe partagés non gérés.

Netwrix Privilege Secure est conçu pour les attaques d'aujourd'hui. Il considère le privilège permanent lui-même, ainsi que le mot de passe qui le protège, comme la surface d'attaque à éliminer. Qu'il s'agisse du compte propre d'un utilisateur élevé seulement pour la durée d'une session, d'un compte géré rendu inutile entre deux usages ou d'un compte éphémère qui cesse d'exister une fois le travail terminé, la logique est la même : s'il n'existe aucun privilège en attente d'être utilisé, il n'y a rien qu'un attaquant puisse voler.

À suivre dans cette série

Supprimer le privilège permanent interrompt bien plus que le flux de check-out/check-in que le PAM traditionnel a été conçu pour sécuriser. Partie 2, Au-delà du coffre : comment NPS neutralise plus que les attaques sur les mots de passe, passe en revue la surface d'attaque plus large des identifiants Windows et Active Directory (hachages NTLM, tickets Kerberos, Kerberoasting, identifiants de domaine en cache, et plus) et indique lesquelles de ces attaques le modèle de session de NPS ferme et lesquelles il ne ferme pas.

Enfin, Partie 3 explique comment Bring Your Own Vault vous permet d'obtenir ces protections au niveau de la session par-dessus le coffre que vous utilisez déjà, sans migration de type rip-and-replace.