Dessinez le chemin déchiffré : où une appliance VPN applique la politique
Un schéma qui s'arrête à l'écouteur chiffré ne montre pas la politique qui compte. Dessinez le chemin déchiffré, puis comparez les emplacements selon ce que la requête traverse.
Les schémas des fournisseurs s'arrêtent généralement à l'écouteur chiffré, parce que c'est la partie qui possède une adresse publique. La question qui décide de la posture de sécurité est ce qui se passe après le déchiffrement, quand le paquet devient de l'IP ordinaire et peut atteindre tout ce que la table de routage autorise. Si personne n'a dessiné ce tronçon, personne ne le possède. Le runbook ci-dessous le dessine d'abord, puis compare les emplacements selon ce que la requête déchiffrée traverse réellement.
Dessinez le paquet après le déchiffrement, pas avant
Le chemin externe est la partie que les fournisseurs documentent : un point de terminaison public, une politique de transport qui admet la connexion et un service qui la termine. Le chemin interne commence à l'instant où le paquet perd son en-tête de tunnel, et à partir de là il est régi par des règles de routage et de filtrage qui n'ont rien à voir avec le tunnel. Mettez les deux sur la même page, car un schéma qui ne montre que le premier suggère que l'admission et l'autorisation sont une seule décision. Elles ne le sont pas, et l'écart entre les deux est là où la plupart des emplacements se trompent.
Écrivez le tronçon interne comme une séquence numérotée avec des types d'équipement nommés, et non comme une flèche. Une flèche cache si la requête traverse un filtre, et traverser ou non est toute la question. Chaque saut ci-dessous nomme l'équipement et le jeu de règles qui y agit, de sorte qu'un filtre manquant apparaît comme un trou au lieu d'être suggéré par une ligne.
- Client distant : l'équipement de l'utilisateur qui crée le tunnel.
- Politique de bord : le jeu de règles qui admet le transport externe vers l'écouteur public.
- Appliance de terminaison : le point de terminaison VPN qui décapsule et remet le paquet à l'IP ordinaire.
- Filtre interne : le jeu de règles de transfert ou de groupes de sécurité qui limite le trafic du client vers le service.
- Hôte d'application : le service qui reçoit la requête déchiffrée.
Deux politiques, deux propriétaires
La politique externe répond à qui peut établir un tunnel, et elle s'exprime dans les règles qui admettent le transport vers le service de terminaison. La politique interne répond à quel service un utilisateur authentifié peut atteindre, et elle vit dans les règles de transfert, les groupes de sécurité ou l'application elle-même. Un seul équipement peut héberger les deux, et une conception à plusieurs équipements possède toujours les deux. C'est les nommer séparément qui vous permet de dire laquelle a échoué quand un utilisateur n'atteint pas une application.
Les contrôles d'admission comme les certificats et l'authentification multifacteur répondent à l'identité et à rien d'autre. Ils ne décident pas de l'emplacement et n'accordent pas de permission par ressource une fois l'utilisateur à l'intérieur.
L'emplacement décide quelle frontière la requête traverse
Trois emplacements sont courants, et chacun change quelle frontière la requête déchiffrée traverse. Comparez-les selon ce qui y termine, ce qui peut voir le texte clair, quel contrôle peut encore refuser la requête et ce qui tombe avec l'appliance. Le tableau ci-dessous utilise ces quatre colonnes au lieu d'une question générique, parce que chaque réponse est une décision de conception distincte.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
Le troisième emplacement est celui qui supprime discrètement l'application, parce qu'un tronçon sur le segment protégé donne à l'appliance un chemin direct que le schéma ne montre peut-être pas. Inspectez les interfaces et les routes plutôt que l'image : ip route get 10.20.5.10 indique par quelle interface le paquet sortirait, et la réponse n'est souvent pas celle que la conception supposait. Le rôle classique du pare-feu de contrôler le trafic entre postures, comme décrit dansNIST SP 800-41, est un test utile ici, car un équipement doté d'un tronçon sans restriction vers le réseau protégé ne contrôle pas grand-chose. Une consultation de route est un schéma plus honnête que celui de la présentation.
L'administration relève de son propre chemin explicitement autorisé. Permettre aux utilisateurs d'atteindre une application n'exige jamais de leur permettre d'atteindre l'interface de contrôle de l'appliance, et les deux permissions doivent être accordées par des règles différentes. Auditez les deux chemins séparément, car une règle partagée cache laquelle a été ouverte.
La traduction change ce que les règles en aval peuvent voir
La traduction de source est pratique et elle détruit de l'information. Après le masquerade, chaque client ressemble à l'appliance, si bien qu'une règle en aval écrite pour distinguer les utilisateurs ne le peut plus. Ce n'est pas seulement un problème de journalisation, c'est un problème de politique : une règle fondée sur l'adresse du client devient silencieusement une règle fondée sur la passerelle. Si la politique par utilisateur compte, préservez la source ou appliquez la politique avant la traduction.
Le chemin de retour mérite le même examen. Notez quelle route la destination choisit pour le paquet retour, car un retour asymétrique contourne l'inspection avec état et produit une connexion qui s'établit puis se bloque. Les deux directions doivent traverser la frontière que vous avez dessinée, sinon la frontière est décorative.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGAcceptez une opération autorisée et une refusée
Testez depuis le vrai client distant plutôt que depuis un hôte d'administration, car l'hôte d'administration se trouve généralement là où l'utilisateur ne sera jamais. Une opération autorisée prouve que le chemin fonctionne, et une opération refusée prouve que la politique fait quelque chose. Exécutez les deux après chaque changement d'emplacement et notez l'identité de source et la destination utilisées. Un test qui ne prouve que le succès ne peut pas distinguer une règle correcte d'une règle absente.
Testez ensuite les cas qui changent d'état : une reconnexion, une session qui survit à une rotation de clés et une panne de l'appliance elle-même. Comparez les mises à jour, la capacité et la reprise dans le cadre du même schéma, car une appliance qui porte plusieurs contrôles logiques est un seul domaine de panne portant plusieurs étiquettes. Une seconde boîte n'est pas indépendante non plus quand un identifiant administratif partagé ou une route sans restriction défait la frontière qu'elle était censée créer.
Documentez le point de terminaison, le chemin déchiffré et le contrôle qui le restreint. Ces trois lignes restent significatives quel que soit le nom de l'implémentation.