Donnez aux utilisateurs VPN accès à un seul service, pas au sous-réseau

Un prestataire a besoin d’une application web interne et de rien d’autre, et la réponse facile est de lui donner un tunnel vers le sous-réseau des serveurs. Cela fonctionne jusqu’au jour où il l’analyse. La conception plus étroite demande plus de réflexion, car l’accessibilité, le routage et la permission applicative sont trois contrôles distincts qui doivent s’accorder.

Écrivez l’exigence comme un service, pas comme un sous-réseau

Commencez par l’hôte de destination, le protocole et le port, puis ajoutez le groupe d’utilisateurs ou d’appareils qui doit l’atteindre. N’incluez la zone DNS privée que si l’application résout un nom, et un fournisseur d’identité que si le flux de connexion en a besoin. Tout le reste est une dépendance que vous n’avez pas encore justifiée.

Un sous-réseau est un détail d’implémentation de l’équipe réseau, tandis qu’un service est ce que l’entreprise a demandé et l’unité qui peut être revue et retirée.

Si la liste des dépendances dépasse trois éléments, l’application a probablement besoin de sa propre discussion de conception.

Routez étroitement, mais appliquez ailleurs

Une route ou un sélecteur étroit indique au tunnel quels paquets transporter ; ce n’est pas une politique d’autorisation. Le filtre de la passerelle, le pare-feu de l’hôte de destination et le modèle de permissions de l’application elle-même sont là où l’accès se décide. Une route couvrant une seule adresse est un bon début, et ce n’est pas le contrôle qui arrête un utilisateur déterminé. C’est cette séparation qui vous permet de changer le filtre sans reconcevoir le tunnel.

À l’inverse, une route large avec un filtre strict peut être légitime, mais seulement si toutes les personnes impliquées savent laquelle des deux fait l’application de la règle.

Documentez explicitement le point d’application, sinon la prochaine modification le déplacera par accident.

Vérifiez la source que le service voit réellement

La cible voit soit l’adresse du pool du client, soit l’adresse de la passerelle, selon que vous traduisez ou non. Les règles de pare-feu de l’hôte et les journaux doivent correspondre à la source réelle. Si plusieurs utilisateurs partagent une source traduite, aucune règle par utilisateur sur cet hôte ne peut les distinguer, et c’est une contrainte de conception, pas un bug.

Choisissez la traduction délibérément : elle simplifie le routage et détruit l’identité de la source, ce qui compte pour l’audit et pour les règles par utilisateur.

Notez laquelle des deux vous avez choisie, à côté de la règle qui en dépend.

L’autorisation applicative n’est pas facultative

Atteindre un port ne donne pas de rôle. L’application a toujours besoin de sa propre connexion et de ses propres permissions, car la couche réseau ne peut pas exprimer quels enregistrements un utilisateur peut modifier. Un service qui fait confiance à toute requête venant du sous-réseau interne transforme un tunnel étroit en accès complet pour un identifiant compromis. Le tunnel décide qui peut ouvrir la socket, et l’application décide ce qu’on peut en faire.

C’est ici que la conception étroite paie deux fois, car moins d’hôtes joignables signifie moins d’endroits où une erreur applicative peut être exploitée.

Gardez la règle réseau et le rôle applicatif dans des systèmes séparés, et retirez-les séparément.

Prouvez à la fois le chemin autorisé et le chemin refusé

Connectez-vous en tant qu’utilisateur autorisé et effectuez une opération représentative inoffensive, puis essayez une destination qui devrait être inaccessible. Une conception qui ne teste que la première moitié n’est pas testée, et c’est le test refusé qui prouve la conception. Testez une session neuve après chaque changement de règle, et regardez le chemin de retour si les requêtes arrivent mais pas les réponses.

Ne désactivez pas les filtres de transfert pour faire passer le test d’acceptation, car cela change la chose testée.

Lorsque l’utilisateur n’a plus besoin du service, retirez l’identité distante et le rôle applicatif dans leurs systèmes respectifs, et consignez les deux. Le guide de transfert strongSwan couvre le côté passerelle du chemin.