Le contrôle de posture VPN ne bloque pas ? Suivez d’abord le rapport

Si un ordinateur portable dont les signatures antivirus ont cessé de se mettre à jour il y a des semaines peut encore ouvrir votre application interne, le document de politique est rarement ce qui ne va pas. Trois systèmes distincts doivent s’accorder avant que l’accès soit refusé : quelque chose mesure le point de terminaison, quelque chose convertit cette mesure en verdict d’autorisation ou de refus, et quelque chose abandonne réellement le trafic. Quand un appareil non conforme entre malgré tout, exactement un de ces maillons manque ou fait confiance à des preuves qu’il ne devrait pas. Les contrôles ci-dessous suivent cet ordre, et chacun a un point d’arrêt.

Le blocage est la dernière étape, pas la première

L’authentification et la posture répondent à des questions différentes. Une connexion réussie prouve qu’un justificatif a été présenté ; elle ne dit rien du logiciel qui tourne sur la machine qui l’a présenté. C’est précisément cet écart qui permet à un profil client copié de transporter une session d’apparence saine vers un hôte malsain.

Le travail de conformité des points de terminaison dispose déjà d’un vocabulaire pour cette chaîne. Le modèle de référence NEA de la RFC 5209 découpe la tâche en un collecteur, une étape d’évaluation et un point d’application, et dit clairement qu’un client qui ment sur son propre état sort du modèle. Cette réserve compte plus que le schéma : un module de plateforme de confiance ne transforme pas une mesure déclarée par l’appareil en fait.

Gardez le collecteur honnête sur la portée. Il doit rapporter les attributs que votre politique nomme, sur l’appareil qui demande l’accès, et peu d’autre chose. Un agent d’inventaire qui liste chaque paquet installé est un autre outil qu’un collecteur de posture, et la différence est à la fois un problème de conservation et de précision. Si le rapport ne peut pas être rattaché à une identité d’appareil, l’évaluateur devine quelle machine il vient d’autoriser.

Un tableau de bord affichant un état rouge n’est pas un contrôle. Demandez ce qu’un utilisateur refusé peut encore atteindre : le wiki, le partage de fichiers, le port de la base de données ? La remédiation a besoin d’une seule surface étroite, et tout le reste appartient derrière le blocage.

Lisez le rapport avant de lire la règle

Partez de la source plutôt que de la coche verte du client. Sous Windows, la mesure locale vient de Defender ou du produit qui s’est enregistré auprès du Security Center, et les deux se lisent sans console d’éditeur :

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

La seconde commande renvoie un entier nommé productState. Ses bits sont documentés de façon lâche et les éditeurs empaquettent différemment les indicateurs d’activation et de mise à jour, alors corroborez-le au lieu de l’analyser. Les suites tierces laissent aussi l’entrée du Security Center après la désinstallation, et celle-ci signale un logiciel qui n’est plus sur le disque.

L’âge est le champ que les gens sautent. Un horodatage de signature n’a de sens que par rapport à l’horloge de la machine qui fait l’évaluation, alors convertissez-le en intervalle au lieu de l’estimer à l’œil :

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

Désormais la politique a un nombre à lire. Si votre règle dit 72 heures, c’est le nombre qu’elle utilise, et un portable qui dort une semaine échoue sans que personne n’interprète une étiquette. Notez le seuil à côté de la commande, car les deux divergent quand l’outil de point de terminaison est remplacé.

Transformez chaque état d’appareil en verdict écrit

La plupart des litiges sur la posture sont en réalité des litiges sur la ligne inconnue. Décidez-la avant le premier incident, dans un tableau qui nomme la preuve, le verdict et le propriétaire, pour que personne n’improvise à la console de la passerelle.

La ligne du bas est là où les produits diffèrent. Certaines passerelles refusent la connexion et expliquent pourquoi ; d’autres laissent le tunnel monter et appliquent une politique restreinte ; quelques-unes retombent sur le dernier bon rapport connu. Seules les deux premières sont défendables, et il vaut la peine de tester laquelle fait la vôtre.

Gardez aussi l’identité et la permission dans leurs propres voies. Un portable qui passe tous les tests de posture a toujours besoin de l’autorisation humaine correcte pour l’application, et un certificat d’appareil prouve la possession d’une clé, pas l’état du système de fichiers. Écraser les trois dans un seul booléen, c’est ainsi qu’un compte d’assistance finit avec un accès permanent à la production.

Vérifiez le chemin d’application avec une requête, pas un tableau de bord

L’application est une propriété d’une requête, alors mesurez-la avec une. Placez une machine non conforme sur le tunnel et faites l’appel qu’un vrai utilisateur ferait :

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Un 200 venant d’un appareil qui devrait être bloqué signifie que la décision n’a jamais atteint le chemin des données. Deux causes habituelles : la politique est attachée à un groupe auquel le compte de test ne s’est jamais joint, ou l’application est joignable par une route que le VPN ne possède pas.

Vérifiez d’abord l’hypothèse de routage. Si le nom interne se résout vers une adresse que le client atteint déjà par le LAN local, le tunnel est hors sujet et aucune politique ne s’appliquera. Comparez cette adresse avec la route que la passerelle pousse. Sur OpenVPN, la politique par client vit dans des fichiers indexés par le nom commun, il est donc facile de l’inspecter :

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Un fichier contenant disable déconnecte ce client d’emblée, tandis qu’une ligne push "route ..." resserre ce qu’il peut atteindre. Les deux relèvent de l’application, et les deux sont visibles pour quiconque débogue le rapport.

Testez les quatre cas sur un seul compte d’essai

Le contrôle final est une petite matrice, pas un chemin heureux. Faites passer un compte de test par quatre états : à jour, signature expirée, protection désactivée, agent non installé. Pour chacun, notez le verdict dans le journal d’évaluation, le statut HTTP que l’application renvoie et si la page de remédiation s’est chargée.

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

Deux détails sont faciles à manquer. D’abord la relecture : un rapport capturé alors que la machine était saine ne doit pas être accepté pour une session ultérieure sur le même appareil, alors cherchez un horodatage lié à la connexion en cours. Ensuite le retrait : désinstaller l’agent doit produire le même refus qu’un rapport périmé, pas un passage propre, et c’est le cas que l’on ne teste le plus souvent jamais.

Quand la matrice correspond au tableau, remettez trois éléments à qui exploitera la passerelle ensuite : les commandes, le seuil et les quatre résultats attendus. C’est cette remise qui est le vrai livrable, car une conception de posture qui ne vit que dans un document de politique dérive la première fois que l’outil de point de terminaison change son champ de rapport.