Une fois que plus d’une personne ou d’un projet utilise un compte proxy, les mêmes questions surgissent. Comment empêcher toute l’équipe de partager un seul identifiant. Comment savoir quel client a consommé quels gigaoctets. Comment couper l’accès d’un prestataire externe sans casser celui de tous les autres. Dans ce secteur, ces questions trouvent généralement une réponse dans l’expression “sub-users”, et cette expression signifie des choses différentes selon qui la vend.
Voici ce que sont réellement les sub-users, ce que le produit résidentiel fournit ou non, et comment résoudre les trois problèmes sous-jacents dans un cas comme dans l’autre.
Ce que signifient les sub-users sur ce marché
Un sub-user, lorsqu’un fournisseur en propose, est un second jeu d’identifiants proxy émis sous un compte parent. Typiquement, il peut porter son propre plafond de bande passante, parfois ses propres restrictions de ciblage, et il peut être révoqué sans toucher au compte parent. C’est une fonctionnalité de contrôle d’accès rattachée au trafic lui-même.
Les équipes le veulent pour trois raisons distinctes, et il vaut la peine de les séparer, car elles appellent des solutions différentes.
L’isolation. Différentes personnes ou différents projets ne doivent pas partager un seul identifiant, afin qu’une fuite ou un départ ait un impact contenu.
L’attribution. Quelqu’un doit savoir quel client, quelle équipe ou quel projet a utilisé quelle part de la bande passante, généralement à des fins de facturation ou de marge.
Les limites. Un projet ne doit pas pouvoir consommer l’intégralité du forfait, que ce soit par accident ou à cause d’une tâche qui s’emballe.
Ce que fournit le produit résidentiel
Autant être direct : les proxies résidentiels de Shifter n’ont pas d’identifiants proxy par sub-user. L’authentification repose sur un seul nom d’utilisateur et mot de passe, avec les options de ciblage et de session exprimées dans le nom d’utilisateur, comme documenté dans gateway and authentication. Il n’existe aucune fonctionnalité permettant de créer un second identifiant proxy avec son propre plafond de bande passante.
Ce qui existe se répartit entre deux mécanismes, et à eux deux ils couvrent les trois problèmes évoqués plus haut.
Team Workspaces gère l’accès au compte. Vous invitez des personnes par e-mail et leur attribuez un rôle : Viewer pour une visibilité en lecture seule sur les membres, le trafic et les factures, Billing pour ces mêmes droits plus le financement et les achats, et Admin pour la gestion complète des membres et de l’équipe. Les rôles sont définis par espace de travail plutôt que globalement, la suppression est immédiate et met fin aux sessions existantes, et une même personne peut appartenir à plusieurs espaces de travail et passer de l’un à l’autre avec une seule connexion. Le comportement complet est décrit dans the Team Workspaces announcement.
Les identifiants de session gèrent la segmentation du trafic. Chaque requête peut porter un identifiant de session de votre choix, ce qui rend possible l’attribution par client et par projet sans identifiants séparés.
La distinction à retenir : les espaces de travail contrôlent qui peut administrer le compte, les identifiants de session organisent ce que fait le trafic. Les sub-users, là où ils existent ailleurs, brouillent ces deux notions.
Résoudre l’isolation sans sub-users
Puisqu’un seul identifiant sert à tout, le travail d’isolation se déplace vers la façon dont vous le stockez et l’exposez.
Conservez l’identifiant dans un gestionnaire de secrets plutôt que dans du code, une configuration ou un document partagé, et laissez les applications le lire depuis l’environnement au moment de l’exécution. Les personnes n’ont pas besoin de l’identifiant proxy pour faire leur travail ; ce sont les systèmes qui en ont besoin. Un ingénieur qui doit tester peut recevoir un accès à un service qui l’utilise plutôt qu’à la valeur elle-même.
Là où vous avez véritablement besoin de zones d’impact séparées, des espaces de travail distincts avec leurs propres forfaits vous donnent des identifiants réellement séparés, puisque les forfaits ne traversent pas les espaces de travail. C’est plus lourd qu’un sub-user et cela implique une facturation séparée, ce qui convient au cas où un client ou une unité d’affaires devrait de toute façon posséder son propre compte, plutôt qu’au cas où vous cherchez simplement de l’ordre.
Ensuite, planifiez la rotation avant d’en avoir besoin. Puisqu’un seul identifiant est partagé, sa rotation affecte tout d’un coup, donc traitez-la comme un déploiement : mettez à jour le coffre de secrets, déployez sur chaque client, puis invalidez l’ancienne valeur. Sauter cet ordre est la manière la plus courante pour une équipe de découvrir le nombre d’endroits où vit l’identifiant, chacun d’eux se mettant à renvoyer des erreurs 407 simultanément.
Pour les personnes plutôt que pour les systèmes, le départ passe par les rôles d’espace de travail : retirez le membre et son accès au panneau s’arrête immédiatement, y compris toute session ouverte. Cela couvre le cas du prestataire externe, qui est généralement ce qu’on cherche vraiment à demander.
Résoudre l’attribution sans sub-users
C’est ici que les identifiants de session font le travail, et il vaut la peine de les structurer délibérément dès le départ.
Encodez le locataire (tenant) dans l’identifiant de session afin que chaque requête soit traçable jusqu’à celui pour qui elle a été effectuée. L’identifiant est une chaîne de caractères de votre choix, donc une convention structurée ne coûte rien et fait de l’attribution une simple question d’analyse de vos propres logs :
def proxy_for(client, job, country, ttl=600):
sid = f"{client}-{job}" # e.g. acme-prices-0827
user = f"customer-USERNAME-country-{country}-sid-{sid}-ttl-{ttl}"
url = f"http://{user}:PASSWORD@p.shifter.io:443"
return {"http": url, "https": url}Ensuite, enregistrez les octets par requête pour chaque client, car la facture du fournisseur est un total unique pour l’ensemble du compte et ne peut pas vous indiquer la répartition. Additionner la taille des réponses par locataire vous donne un chiffre d’usage à facturer ou à partir duquel calculer une marge, et rapprocher périodiquement votre total de la facture garde le tout honnête, car les nouvelles tentatives, les requêtes échouées et la surcharge de connexion consomment tous de la bande passante qu’un simple comptage de la taille du corps ne capte pas. La métrique à surveiller par locataire est les octets par enregistrement, traitée dans proxy KPIs, et c’est le chiffre qui transforme l’attribution en conversation sur les coûts.
Les sessions remplissent aussi leur rôle d’origine ici : des identifiants distincts par client empêchent les flux de deux clients de se percuter sur la même session, ce qui compte dès que plus d’une tâche s’exécute à la fois. La sémantique est expliquée dans sticky versus rotating.
Résoudre les limites sans sub-users
Il n’existe pas de plafond côté fournisseur par locataire, donc le plafond doit vivre dans votre propre planificateur, et honnêtement c’est là qu’il a de toute façon sa place : votre système sait à quoi un client a droit, le proxy ne le sait pas.
Attribuez à chaque locataire un budget de bande passante pour la période et faites-le respecter par rapport à l’usage que vous enregistrez déjà, en arrêtant ou en mettant en file d’attente les tâches de ce locataire lorsqu’il est épuisé plutôt que de le laisser consommer l’allocation partagée. Alertez bien avant d’atteindre la limite plutôt qu’au moment où elle est atteinte. Associez cela à des parts de concurrence par locataire afin qu’un gros traitement de nuit ne puisse pas priver quatre petites tâches urgentes, ainsi qu’à des budgets de nouvelles tentatives par locataire afin que la cible défaillante d’un client ne puisse pas inonder le pool partagé, ce qui constitue l’argument de contention développé dans retry and backoff et rate limiting.
L’endroit naturel pour tout cela est le composant qui voit déjà chaque requête, c’est pourquoi a proxy manager est le bon endroit pour placer les budgets par locataire, les parts de concurrence et l’attribution, plutôt que de les disperser à travers les différentes tâches.
Choisir entre un seul compte et plusieurs espaces de travail
La décision est généralement plus simple qu’il n’y paraît, et elle se résume à qui possède la relation commerciale.
Optez pour un seul compte avec des locataires logiques lorsque vous fournissez un service et que le fournisseur fait partie de votre chaîne d’approvisionnement : vous achetez la bande passante, les clients ne voient jamais le fournisseur, et la segmentation est une convention de nommage dans votre propre code. C’est la configuration courante pour une agence.
Optez pour un espace de travail par client lorsque le client doit posséder son propre forfait et ses propres factures, votre équipe étant ajoutée en tant qu’Admins. La facturation est réellement séparée, le trafic ne peut pas être mélangé puisque les forfaits ne traversent pas les espaces de travail, et le client peut reprendre la main proprement si la collaboration se termine.
Concevoir dès le premier jour autour d’un identifiant de locataire est ce qui transforme le passage de l’un à l’autre en un simple changement de configuration plutôt qu’en une reconstruction.
En résumé
Les sub-users sont une seule mise en œuvre pour trois besoins distincts, et ce n’est pas la seule mise en œuvre possible. Sur le produit résidentiel, il n’existe qu’un seul identifiant proxy, donc l’isolation vient de la gestion des secrets et, là où elle doit être absolue, d’espaces de travail séparés avec leurs propres forfaits ; le contrôle d’accès pour les personnes vient des rôles d’espace de travail avec révocation immédiate ; l’attribution vient d’identifiants de session structurés associés à votre propre comptabilité d’octets par locataire, car la facture est un total unique ; et les limites viennent de budgets dans votre planificateur, qui est le seul endroit sachant à quoi chaque locataire a droit. Si vous construisez dès le départ autour d’un identifiant de locataire, vous obtenez les trois, et vous conservez la possibilité de faire basculer plus tard un client vers son propre espace de travail sans toucher au code de collecte.
La couche sous-jacente est celle des residential proxies : une passerelle unique où le pays, la ville, la session et le TTL sont tous exprimés par requête, ce qui est exactement ce qui fait de la segmentation par locataire une convention de nommage plutôt qu’une limitation du produit, avec une tarification au GB afin que l’usage que vous attribuez en interne soit mesuré dans la même unité que celle qui vous est facturée.