Accès du prestataire au dépôt : entrée publique ou chemin VPN ?

Un prestataire a besoin d’un dépôt privé pour un projet limité, et la demande arrive soit comme « rendez le dépôt public », soit comme « donnez-leur un accès VPN ». Les deux réponses contournent la vraie question. L’autorisation du dépôt et l’entrée réseau sont deux couches distinctes, et la permission qui compte est celle qui permet à cette personne de lire ou de pousser vers ce seul dépôt. Tout le reste, dans l’un ou l’autre paquet, est un risque supplémentaire. Concevez d’abord la couche d’autorisation, puis décidez de la faible quantité de chemin réseau dont elle a besoin.

Une mission illustrative rend cela concret : un développeur externe, un dépôt, aucun hôte de production, aucune interface d’administration. Gardez ce périmètre fixe pendant que vous comparez les entrées.

Deux entrées, deux frontières différentes

Un service de dépôt accessible publiquement applique toujours une authentification HTTPS ou SSH et une autorisation applicative. L’accessibilité publique ne signifie pas une lisibilité anonyme. Le coût est un écouteur qu’il faut maintenir, surveiller et corriger.

Une entrée VPN peut garder cet écouteur hors du chemin public, mais un compte VPN large peut exposer des services sans rapport. Un nom d’hôte public oublié, un écouteur SSH ou une famille d’adresses que vous avez oubliée peuvent anéantir la frontière « VPN uniquement » que vous croyiez avoir. C’est pourquoi une conception « VPN uniquement » exige un inventaire des écouteurs, pas seulement une règle de pare-feu.

Comparez les chemins autorisés, pas les étiquettes. Dans tous les cas, conservez l’authentification applicative et la validation normale de l’identité du serveur.

Les rôles du dépôt sont l’unité de permission

Donnez au prestataire une identité individuelle avec le plus petit rôle qui accomplisse la tâche. Consulter, pousser, maintenir et administrer sont des rôles différents, et un groupe qui accorde tous les projets internes n’équivaut pas à l’accès à un seul dépôt. Vérifiez les noms réels des rôles dans votre plateforme au lieu de supposer qu’un nom de groupe correspond à un seul rôle.

Listez chaque opération dont la mission a réellement besoin. L’accès par navigateur et le transport Git peuvent utiliser des identifiants ou des écouteurs différents. Les builds automatisés, les téléchargements de paquets et les webhooks peuvent tourner comme des identités séparées avec leurs propres chemins de livraison, et un VPN sur l’ordinateur portable ne les relie pas.

Protéger le contenu du dépôt est un travail distinct. Changer le chemin d’entrée ne supprime pas un secret déjà présent dans l’historique, ne restreint pas un clone autorisé et ne sécurise pas le poste de travail d’un contributeur.

Des identifiants qui survivent à la personne

La sortie est le moment où l’accès au dépôt et l’accès au réseau divergent de nouveau. Retirez l’autorisation du dépôt et le droit VPN via leurs propriétaires respectifs, puis vérifiez les jetons personnels, les clés SSH, les identifiants d’automatisation et les sessions actives. Une clé de déploiement est le survivant classique : elle peut conserver son accès configuré en lecture ou en écriture après le départ de la personne de l’organisation. La suppression d’une liste de membres n’est pas une sortie complète.

Inventoriez les identifiants machine par propriétaire et par objet avant la fin de la mission, pas après. Un jeton créé pour un build d’une semaine peut survivre au projet d’un an si personne n’a écrit pourquoi il existe.

Vérifiez l’opération, le refus et la sortie

Avant la remise, testez trois choses : l’opération autorisée sur le dépôt réussit, un dépôt sans rapport est refusé et l’identité retirée échoue. Si la conception est « VPN uniquement », confirmez que l’ancienne route publique directe ne peut plus effectuer l’opération.

Conservez le code et les enregistrements de revue, mais ne laissez pas un accès oublié devenir le plan de reprise. Une liste écrite des identités, des rôles et des dates d’expiration est ce qui fait de la prochaine demande de prestataire un processus reproductible.