Centralisez l’accès VPN des partenaires sans réunir les partenaires

La proposition est raisonnable : cinq tunnels partenaires répartis sur une dizaine d’ordinateurs portables, cinq jeux de versions client, cinq scripts de support et un ingénieur qui sait comment tout s’emboîte. Les déplacer vers un niveau d’accès maîtrisé règle la dispersion des points terminaux. Cela crée aussi un nouvel objet dans votre architecture, un service d’accès partagé qui a désormais besoin de son propre modèle d’autorisation, et la défaillance que tout le monde sous-estime, c’est un appareil central avec tous les tunnels activés qui devient discrètement un réseau de transit entre des organisations qui n’ont jamais accepté d’être voisines. Ce risque est un choix de conception, pas quelque chose que le matériel fait de lui-même. Le travail ci-dessous montre comment je garde le confort sans accepter l’effet secondaire accidentel.

Partez du contrat que chaque partenaire a déjà signé

Avant toute configuration, confirmez que le partenaire autorise ne serait-ce qu’une passerelle partagée ou une connexion de site. Un compte d’accès distant personnel, une exigence de posture d’appareil ou un flux MFA interactif peuvent ne pas être transférables vers un tunnel partagé sans surveillance, et regrouper des employés derrière une identité client copiée est le raccourci qui survit jusqu’à ce que le partenaire audite ses journaux. Pour chaque connexion autorisée, consignez les plages de destination, les domaines DNS privés, les sources internes autorisées, le responsable de l’authentification et ce qui doit se passer en cas de panne du tunnel. Demandez au partenaire de confirmer par écrit la connexion partagée, y compris les plages source qu’il acceptera. Une approbation verbale change souvent de sens la semaine où leur équipe sécurité tourne.

Ce registre est le livrable. Si vous ne pouvez pas l’écrire pour un partenaire, ce partenaire n’est pas prêt à être centralisé.

Routez selon le contexte, pas seulement selon la destination

Deux partenaires finiront par utiliser la même plage privée, parce que chaque organisation choisit dans le même espace RFC 1918. Une seule table de routage ordinaire ne peut pas choisir le bon partenaire à partir d’une adresse de destination seule, donc les plages qui se chevauchent ont besoin de contextes de routage séparés ou d’une autre conception convenue. Le modèle de domaine de transfert décrit dans RFC 4364 explique pourquoi cette séparation compte, et un déploiement n’a pas besoin d’exploiter MPLS pour exiger la même propriété de sa plateforme de passerelle.

Posez à la plateforme une question directe : deux partenaires peuvent-ils partager un même préfixe de destination et rester distinguables par le contexte employé d’où vient la session ? Si la réponse est non, cette contrainte façonne la conception plus que n’importe quelle liste de fonctions d’un fournisseur.

Là où la réponse est oui, le contexte de routage devient ce que vous documentez et testez, parce qu’il est invisible dans un traceroute.

Décidez ce que l’employé saisit et ce que le partenaire journalise

Certains travaux partenaires relèvent d’un proxy d’applications ou d’un espace de travail distant ouvert dans le contexte de ce partenaire. D’autres travaux exigent un accès réseau routé depuis un segment d’employés approuvé, et les deux produisent des adresses source et des pistes d’audit différentes à l’autre bout. Une adresse source traduite partagée peut satisfaire une liste d’autorisations tout en masquant quel appareil a fait quoi, donc conservez une trace fiable de l’employé vers la session et maintenez l’authentification applicative plutôt que de traiter l’adresse de la passerelle comme une identité, ce qui est commode jusqu’au moment où le partenaire demande qui l’a fait.

Parcourez ensuite une tâche réelle du côté de l’employé : ce qu’il clique, ce qui lui est demandé et ce que le partenaire verrait s’il demandait une entrée de journal. Si ce parcours n’est pas reproductible, la conception n’est pas terminée.

Refusez explicitement le transit entre partenaires

Du matériel partagé ne devrait jamais impliquer une confiance partagée. Ajoutez le refus comme une règle délibérée avec un responsable nommé, non comme un accident de configuration manquante, et testez-le dans les deux sens avec une requête qui réussirait autrement. Le test compte parce qu’une autorisation simplement absente peut être rétablie par l’ingénieur suivant qui ajoute une route pour régler une plainte sans rapport.

Écrivez le refus dans le registre du partenaire à côté des autorisations, pour que l’intention survive aux changements de personnel.

Exploitez-le comme un service partagé, pas comme un portable plus gros

Le renouvellement des tunnels, la rotation des identifiants, la capacité et le remplacement de la passerelle deviennent tous des changements de service partagé, ce qui signifie qu’ils ont besoin d’un calendrier et d’un canal de communication que les portables individuels n’exigeaient jamais. Un certificat partenaire qui expire un samedi n’est plus la panne d’un utilisateur ; ce sont toutes les sessions de ce partenaire à la fois.

N’acceptez le niveau que lorsqu’une requête refusée entre partenaires échoue exactement comme prévu et qu’une requête employé autorisée atteint la bonne destination avec la bonne source. Supprimer le conflit de portables en gardant intacte la frontière de chaque partenaire est tout l’enjeu ; une conception où chaque préfixe distant est joignable depuis chaque bureau a simplement déplacé le problème.

Tenez un petit tableau partenaire, contexte, plages autorisées et responsable. Ce sera la première chose que quiconque demandera pendant un incident.