Deux portes VPN en série : ce que chacune décide réellement

Le chaînage de deux VPN est généralement vendu comme du chiffrement supplémentaire, ce qui est la chose la moins intéressante qu'il apporte. Le vrai produit est une seconde décision d'autorisation, prise par un autre propriétaire sur un autre ensemble de ressources. Si les deux étapes acceptent le même identifiant et atteignent les mêmes destinations, la porte intérieure est une décoration avec de la latence en plus. Décider si cette seconde décision vaut son coût d'exploitation commence par nommer ce que chaque porte vérifie réellement.

Un tunnel, puis une seconde décision

La porte extérieure répond à une question large : s'agit-il d'un appareil d'employé approuvé, et peut-il atteindre le réseau interne général. La porte intérieure répond à une question plus étroite : cette identité porte-t-elle le droit de maintenance, et peut-elle atteindre ces points de terminaison de gestion précis. Ce sont des questions différentes avec des propriétaires différents, et ni l'une ni l'autre n'implique l'autre. L'existence d'un chemin à travers les deux étapes n'est pas l'autorité d'utiliser ce qui se trouve derrière la seconde. Atteindre l'entrée lointaine prouve qu'une route fonctionne, et rien de plus.

Le principe est ancien et toujours ignoré : l'emplacement réseau ne plaide rien en soi. Résumé de l'architecture zéro confiance du NIST le dit clairement, en rejetant la confiance implicite qui découle de l'origine d'une connexion ou du propriétaire du réseau. Appliqué ici, arriver à l'entrée intérieure est une condition préalable à ses ressources, jamais l'autorisation de les utiliser.

Écrivez ce que chaque porte vérifie

Pour chaque étape, consignez l'identité qu'elle vérifie, les destinations qu'elle autorise et les conditions dans lesquelles elle peut être contournée. La porte extérieure peut légitimement autoriser les services internes ordinaires plus l'écouteur de la porte intérieure, et rien d'autre. La porte intérieure peut exiger une revendication de rôle et n'autoriser que les adresses de gestion nommées dans le registre des changements. L'application à l'extrémité lointaine garde le dernier mot sur les opérations que ce rôle peut effectuer, si bien que la chaîne ajoute une porte sans remplacer l'autorisation de l'application.

Deux omissions cassent le dispositif en silence. Si le domaine extérieur atteint déjà directement chaque destination sensible, la porte intérieure est facultative plutôt qu'obligatoire. Si un écouteur public ou une seconde route privée offre le même accès, le chemin prévu est une option parmi plusieurs. Attribuez aussi un propriétaire à chaque jeu de règles, et faites nommer par leur contrat les services de destination, les identités sources autorisées, le DNS privé, la traduction d'adresses et qui répond quand la transmission échoue. Une adresse de confiance sur le réseau extérieur ne doit jamais remplacer l'autorisation du domaine intérieur.

Testez les cas de refus, pas le chemin heureux

Une connexion réussie à travers les deux portes prouve très peu, car c'est le cas que tout le monde a testé lors du déploiement. Les cas intéressants sont ceux où une étape passe et l'autre refuse. Trois d'entre eux couvrent l'essentiel du risque, et chacun a un résultat attendu qui peut être vérifié plutôt que discuté.

Avec l'accès général approuvé et le rôle sensible absent, le travail ordinaire doit continuer pendant que la destination sensible est refusée. Approuvez les deux étapes et l'ensemble atteignable doit être les points de terminaison de maintenance nommés dans le registre des changements, rien de plus large. Avec le droit révoqué en cours de session, la politique de session convenue doit prendre effet sans démonter l'accès général non lié. Savoir si cette révocation met fin immédiatement à une session existante ou à la prochaine réauthentification est une décision de politique que le contrat devrait déjà contenir. Celui qui a écrit les cas d'acceptation n'est pas la personne qui devrait les interpréter lors d'un incident.

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

Comptez les dépendances ajoutées

Chaque étape supplémentaire ajoute un composant qui peut tomber en panne et une route qui doit s'imbriquer correctement dans le tunnel extérieur. Lors d'une panne partielle, le chemin extérieur reste debout tandis que l'intérieur est injoignable, si bien que l'utilisateur voit une icône VPN saine à côté d'un service qui ne répond jamais.

Vérifiez les routes et les règles de blocage en cas de panne, pas seulement dans le cas normal. Une route par défaut poussée par le tunnel extérieur peut capturer l'adresse de la porte intérieure elle-même, ce qui transforme la seconde étape en une connexion qui s'établit puis tombe. Consignez ce qui doit rester bloqué pendant que le tunnel intérieur est absent, car un repli accidentel autour de lui est pire qu'une coupure nette. Utilisez la même forme de sonde sur les deux sauts, afin que chacun soit mesuré plutôt que supposé. Deux indicateurs connectés n'établissent ni l'imbrication ni l'isolement.

Ce que la seconde porte ne peut pas vous acheter

Demandez si les deux portes partagent un identifiant, une autorité de certification ou un plan de gestion. Là où c'est le cas, elles partagent aussi leurs modes de défaillance les plus importants, et la seconde étape coûte plus que l'indépendance qu'elle semble ajouter. Des sessions cryptographiques séparées ne créent pas des contrôles administratifs séparés.

Gardez la porte intérieure tant qu'elle applique une exigence que vous pouvez énoncer et tester, comme un rôle que le domaine extérieur ne vérifie jamais. Supprimez-la quand son seul travail est de réauthentifier la même identité contre les mêmes destinations. Dans les deux cas, consignez ensemble l'exigence, le propriétaire et le comportement en cas de panne, afin que la prochaine revue débatte de l'exigence et non du schéma.