Steven LafortuneLes comptes privilégiés ne sont pas compromis à l’écran de connexion. Ils le sont après la connexion : quand une session est détournée, qu’un appareil reste déverrouillé ou que des identifiants sont partagés un peu trop librement. C’est exactement l’écart que l’AMF à la réservation PAM vient combler : plutôt que de faire confiance à quiconque se trouve déjà à l’intérieur du périmètre, Devolutions vérifie maintenant l’identité une seconde fois, au moment précis où quelqu’un demande l’accès à un compte privilégié.
Le problème que l’AMF à la réservation résout
L’AMF standard à la connexion prouve qui s’est authentifié en début de journée. Elle ne prouve pas qui se trouve au clavier une heure plus tard, au moment où une demande de réservation privilégiée arrive. Pour les comptes sensibles — administrateurs de domaine, comptes de service, tout ce qui a des droits élevés — cet écart compte. Exiger un nouveau défi AMF au moment précis de la réservation vient combler cet écart : la vérification suit maintenant la demande d’accès elle-même, pas seulement la connexion initiale.
Activer l’AMF à la réservation
Dans Devolutions Server :
- Assurez-vous que les utilisateurs ont une méthode d’AMF configurée, soit par utilisateur (
Administration – Utilisateurs – Multifacteur), soit imposée globalement parAdministration – Configuration – Paramètres du serveur – Sécurité – Politiques d'accès conditionnel(réglez la cible AMF à Requise, Facultative par utilisateur ou Ignorée). - Ouvrez les propriétés du fournisseur PAM ou de l’entrée, puis allez à l’onglet Politique de réservation.
- Activez l’option qui exige l’AMF à la réservation.
- Enregistrez. L’exigence s’applique la prochaine fois que cette entrée est réservée.
Dans Devolutions Cloud : la même logique s’applique par Administration – Configuration – Sécurité – Authentification, où la vérification AMF peut être activée pour le lancement d’entrées sensibles. Les méthodes prises en charge incluent le courriel et le TOTP, avec d’autres fournisseurs d’identité couverts par les options AMF plus larges de la plateforme (Yubikey, Duo, Radius et d’autres, selon votre configuration).
Ce qui se passe quand un utilisateur réserve un compte
En surface, le processus de réservation ne change pas : l’utilisateur choisit l’entrée, sélectionne une durée et soumet une raison ou un numéro de billet si c’est requis. La nouveauté se passe exactement là, avant même que la demande parte quelque part. Si l’AMF est exigée pour cette entrée, l’utilisateur doit se vérifier — un code TOTP, un code envoyé par courriel ou par message texte — dans le cadre de la soumission de la demande. Sans AMF valide, la demande n’atteint jamais l’approbateur : l’identité est confirmée à la source, pas ajoutée après coup.
Ce que voit l’approbateur
Les approbateurs n’ont pas à deviner si l’identité a été confirmée. Au moment où une demande de réservation leur parvient pour révision, la vérification AMF a déjà eu lieu — le demandeur n’aurait pas pu soumettre la demande autrement. L’écran d’approbation reflète cette réalité, ce qui retire une inconnue de la décision de l’approbateur et ajoute un point de données de plus dans la piste de vérification, si cette réservation est un jour révisée.
Pourquoi ça compte
L’AMF à la réservation ne remplace pas les approbations, l’enregistrement de session ni vos politiques de réservation existantes ; elle s’ajoute à celles-ci comme point de contrôle supplémentaire, placé exactement là où le risque est le plus élevé : au moment où quelqu’un obtient l’accès à un compte privilégié. Pour les équipes qui utilisent déjà Devolutions PAM, il s’agit d’une simple bascule dans les politiques, pas d’un nouveau système à déployer.
Si vous utilisez Devolutions PAM, ça vaut la peine de l’activer. Consultez la documentation ci-dessous pour la configuration complète, et dites-nous comment ça fonctionne pour votre équipe.
Ressources :
Adam Listek
