Service MFA indisponible : décidez l’accès VPN avant la panne

L’accès VPN s’arrête, et l’alerte indique que le service de second facteur est injoignable. Savoir si quelqu’un peut encore se connecter est une question de politique qui aurait dû être tranchée avant la panne, pas pendant. Un vérificateur indisponible n’est pas la preuve qu’un facteur a réussi, et un défi rejeté n’est pas le même événement qu’un défi injoignable. Le runbook ci-dessous transforme cette distinction en règle écrite que vous pouvez tester.

Étape 1 : nommez les trois issues séparément

Écrivez trois états et refusez de les fusionner : l’authentification primaire a échoué, le défi de second facteur a été refusé ou a expiré, et le service MFA n’a jamais répondu. Chacun a un propriétaire différent, une ligne de journal différente et une réponse correcte différente. Un seul message générique de délai dépassé masque dans lequel vous êtes, et c’est cette ambiguïté qui transforme une panne en discussion. Nommez les états dans le runbook avant d’en avoir besoin.

Un refus signifie que le vérificateur a répondu et a dit non, ce qui est une issue de politique et non un problème de disponibilité. Une tentative expirée signifie que le défi existait et que personne ne l’a terminé à temps. Un service injoignable signifie que la question n’a jamais reçu de réponse. Seul le troisième est une panne.

Étape 2 : lisez le mode de défaillance que le proxy utilise réellement

Trouvez le réglage qui régit le comportement lorsque le service ne peut pas être contacté, et lisez-le depuis la configuration en cours plutôt que depuis un modèle. Dans le proxy RADIUS de Duo, les valeurs documentées de failmode sont safe et secure, safe n’autorisant une tentative que lorsque l’authentification primaire réussit et secure rejetant la tentative dans cette condition.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

Le nom safe décrit un choix de disponibilité, non la garantie que chaque session admise ait eu un second facteur récent. Cette phrase appartient au registre des risques, car c’est exactement le compromis que fait le réglage. Ne généralisez pas la valeur à un autre fournisseur, une autre intégration ou un autre mode de proxy ; lisez la documentation de ce produit pour son propre équivalent. Une configuration copiée d’un exemple de fournisseur sans cette compréhension est une surprise qui attend la prochaine panne.

Arrêtez-vous si personne ne peut dire quel mode est actif. Le reste du runbook dépend de cette réponse.

Étape 3 : alignez les réessais sur le flux

Alignez le délai d’attente et le comportement de réessai de la passerelle sur le flux d’authentification qu’elle pilote. Des réessais non coordonnés créent plusieurs invites, brouillent l’appariement des tentatives et laissent le journal incapable de dire quel résultat correspond à quelle connexion. Un délai très long n’est pas une conception de disponibilité ; c’est une attente plus longue pour la même réponse.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Le délai d’attente propre à la requête du proxy est une limite distincte : une requête d’authentification émise et jamais terminée est rejetée, et ce rejet n’est pas une panne dont on se retire. Traitez un refus, un défi inachevé et un service injoignable comme trois entrées différentes de votre table de décision. Rendez ensuite la table explicite : quel état admet, quel état retient et quel état escalade vers un humain.

Si deux composants réessaient tous les deux, corrigez d’abord la propriété des réessais. Des invites en double sont le symptôme de deux propriétaires, pas d’un service lent.

Étape 4 : gouvernez l’accès d’urgence séparément

Si un accès d’urgence est nécessaire, donnez-lui sa propre portée, identité, autorisation et piste d’audit. Désactiver MFA en silence pour tous les utilisateurs n’est pas une procédure d’urgence ; c’est un affaiblissement permanent avec un incident attaché. Le propriétaire de la sécurité approuve à l’avance la règle d’admission, la visibilité et le chemin d’escalade.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

Testez toute la matrice dans un environnement hors production : échec primaire, rejet délibéré, expiration du défi et indisponibilité du service. Pour chacun, consignez le résultat d’admission et la raison journalisée. Ne créez pas de panne de production pour découvrir le comportement configuré, et ne testez pas le chemin d’urgence pour la première fois pendant l’incident pour lequel il a été écrit. Une procédure de rétablissement qui n’a jamais tourné est un document, pas un contrôle.

Le runbook se termine lorsque les trois états sont nommés, que le mode de défaillance est lu depuis le système en cours, que les réessais ont un seul propriétaire et que l’accès d’urgence a sa propre approbation et revue. Une application prévisible plus un chemin de rétablissement connu est le résultat qui mérite d’être documenté.