Liste d'IP autorisées ou portable approuvé : deux contrôles différents

Les demandes d'une règle n'autorisant que le portable approuvé finissent souvent par une entrée de pare-feu pour l'adresse publique du bureau. Cette règle admet désormais tout appareil derrière l'adresse. L'exigence et la mise en œuvre ne sont pas la même chose. Séparez ce que veut la politique de ce que l'adresse peut prouver.

Trois questions dans une seule demande de politique

Découpez la demande en trois parties : d'où vient la connexion, quel service elle peut atteindre et quel ordinateur présente l'identité. Une règle d'adresse source répond à la première, une règle de service de destination à la seconde. Ni l'une ni l'autre n'identifie la machine physique, car toutes deux portent sur des champs réseau que partagent de nombreux appareils. La troisième exige une identité émise pour cet appareil et non réutilisable en silence.

Écrivez les trois réponses séparément. Une seule ligne de pare-feu ne peut pas satisfaire une exigence qui en nomme trois.

Ce que l'adresse source peut vous dire

La traduction d'adresses est la raison habituelle pour laquelle une règle d'origine réseau admet trop. Tout ce qui se trouve derrière une sortie de bureau apparaît comme la même adresse publique, la règle accorde donc l'accès à tout le groupe. Une adresse fixe à l'intérieur du VPN présente la même faiblesse ailleurs : c'est une affectation liée à une session, non une propriété du matériel. Tout appareil doté d'une identité acceptée peut ouvrir cette session. Traitez l'adresse comme une restriction réseau et décrivez-la ainsi.

Cela reste utile pour limiter l'exposition, et ce n'est pas une authentification d'appareil.

Liez l'accès à une identité enrôlée

Si l'exigence est une restriction d'appareil, utilisez l'enrôlement par appareil pris en charge par le VPN et donnez à chaque ordinateur une identité distincte.

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

La liste du magasin montre le certificat et la présence d'une clé privée, et la vérification montre si la chaîne mène à l'ancre prévue. Un certificat prouve la possession de la clé privée acceptée selon la politique configurée ; il ne prouve pas quelle machine physique la détenait lorsque cette clé peut être exportée et copiée. Nommer le profil d'après le portable laisse le secret tout aussi transportable qu'avant. Là où la plateforme le permet, des clés protégées par le matériel avec une politique d'attestation offrent une liaison plus forte, et l'enrôlement doit encore décider qui peut recevoir l'identité.

Testez la frontière, puis planifiez le retrait

Évaluez deux cas : le portable approuvé et l'utilisateur doivent se connecter, et un autre appareil ne détenant que le compte de l'utilisateur ne doit pas le faire. Si la conception exige une vérification de l'utilisateur et de l'appareil, vérifiez que la méthode choisie impose les deux dans la même session au lieu de supposer que deux réglages indépendants se combinent.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

La révocation doit retirer l'identité d'appareil acceptée, et le traitement des sessions actives mérite son propre test. Un TPM ou un indicateur d'appareil géré n'est pas un certificat de bonne santé pour chaque processus de la machine.

Consignez la restriction réseau, l'identité de l'appareil et la décision d'enrôlement comme trois contrôles avec trois responsables. Cela rend la frontière vérifiable, et c'est ce qu'une adresse seule ne peut jamais fournir.