Sobald mehr als eine Person oder ein Projekt ein Proxy-Konto nutzt, tauchen dieselben Fragen auf. Wie verhindern wir, dass das ganze Team sich ein Zugangsdaten-Set teilt. Wie erkennen wir, welcher Kunde welche Gigabytes verbraucht hat. Wie entziehen wir einem Auftragnehmer den Zugriff, ohne allen anderen die Nutzung zu unterbrechen. In dieser Branche werden diese Fragen üblicherweise mit dem Begriff “Sub-User” beantwortet, und der Begriff bedeutet je nach Anbieter etwas anderes.
Hier ist, was Sub-User tatsächlich sind, was das Residential-Produkt bietet und nicht bietet, und wie sich die drei zugrunde liegenden Probleme in jedem Fall lösen lassen.
Was Sub-User in diesem Markt bedeuten
Ein Sub-User ist, sofern ein Anbieter dies anbietet, ein zweiter Satz von Proxy-Zugangsdaten, der unter einem übergeordneten Konto ausgestellt wird. Typischerweise kann er ein eigenes Bandbreitenlimit tragen, manchmal eigene Targeting-Einschränkungen, und er kann widerrufen werden, ohne das übergeordnete Konto zu berühren. Es handelt sich um eine Zugriffskontrollfunktion, die direkt am Traffic selbst ansetzt.
Teams wollen dies aus drei unterschiedlichen Gründen, und es lohnt sich, diese zu trennen, da sie unterschiedliche Lösungen haben.
Isolation. Verschiedene Personen oder Projekte sollten sich nicht ein Zugangsdatenset teilen, damit ein Leak oder ein Weggang nur begrenzten Schaden anrichtet.
Attribution. Jemand muss wissen, welcher Kunde, welches Team oder welches Projekt welchen Teil der Bandbreite genutzt hat, meist für Abrechnung oder Margenberechnung.
Limits. Ein Projekt sollte nicht den gesamten Plan verbrauchen können, weder versehentlich noch durch einen außer Kontrolle geratenen Job.
Was das Residential-Produkt bietet
Um es direkt zu sagen: Shifters Residential-Proxys verfügen nicht über Proxy-Zugangsdaten pro Sub-User. Die Authentifizierung erfolgt über einen einzigen Benutzernamen und ein Passwort, wobei Targeting- und Session-Optionen im Benutzernamen ausgedrückt werden, wie in gateway and authentication dokumentiert. Es gibt keine Möglichkeit, ein zweites Proxy-Zugangsdatenset mit eigenem Bandbreitenlimit zu erstellen.
Was es gibt, verteilt sich auf zwei Mechanismen, und zusammen decken sie die drei oben genannten Probleme ab.
Team Workspaces regeln den Zugriff auf das Konto. Sie laden Personen per E-Mail ein und weisen eine Rolle zu: Viewer für Nur-Lese-Einblick in Mitgliedschaften, Traffic und Rechnungen, Billing für all dies plus Aufladen und Kauf, und Admin für vollständige Mitglieder- und Teamverwaltung. Rollen sind pro Workspace festgelegt statt global, ein Entzug erfolgt sofort und beendet bestehende Sitzungen, und eine Person kann mehreren Workspaces angehören und mit einem einzigen Login zwischen ihnen wechseln. Das vollständige Verhalten steht in the Team Workspaces announcement.
Session-Identifikatoren regeln die Segmentierung des Traffics. Jede Anfrage kann eine von Ihnen gewählte Session-ID tragen, was die Attribution pro Kunde und pro Projekt ohne separate Zugangsdaten ermöglicht.
Die Unterscheidung, die man sich merken sollte: Workspaces steuern, wer das Konto verwalten kann, Session-Identifikatoren organisieren, was der Traffic tut. Sub-User, wo es sie anderswo gibt, vermischen diese beiden Dinge.
Isolation ohne Sub-User lösen
Da ein einziges Zugangsdatenset allem dient, verlagert sich die Isolationsarbeit darauf, wie Sie es speichern und zugänglich machen.
Bewahren Sie das Zugangsdatenset in einem Secret Manager auf statt im Code, in der Konfiguration oder in einem geteilten Dokument, und lassen Sie Anwendungen es zur Laufzeit aus der Umgebung lesen. Personen brauchen die Proxy-Zugangsdaten nicht, um ihre Arbeit zu erledigen; die Systeme brauchen sie. Ein Ingenieur, der testen muss, kann Zugriff auf einen Dienst erhalten, der sie nutzt, statt auf den Wert selbst.
Wo Sie tatsächlich getrennte Risikobereiche benötigen, bieten separate Workspaces mit eigenen Plänen wirklich getrennte Zugangsdaten, da Pläne nicht workspace-übergreifend gelten. Das ist schwergewichtiger als ein Sub-User und bedeutet separate Abrechnung, weshalb es zu dem Fall passt, in dem ein Kunde oder eine Geschäftseinheit ohnehin ein eigenes Konto besitzen sollte, statt zu dem Fall, in dem Sie nur Ordnung wollen.
Planen Sie dann die Rotation, bevor Sie sie brauchen. Da ein Zugangsdatenset gemeinsam genutzt wird, betrifft dessen Rotation alles gleichzeitig, behandeln Sie es also wie ein Deployment: Aktualisieren Sie den Secret Store, führen Sie den Rollout bei jedem Client durch, und deaktivieren Sie dann den alten Wert. Diese Reihenfolge zu überspringen ist die häufigste Art, wie ein Team entdeckt, an wie vielen Stellen das Zugangsdatenset existiert, da dann alle gleichzeitig anfangen, 407 errors zurückzugeben.
Für Personen statt Systeme läuft das Offboarding über Workspace-Rollen: Entfernen Sie das Mitglied, und dessen Panel-Zugriff endet sofort, einschließlich jeder offenen Sitzung. Das deckt den Fall des Auftragnehmers ab, was meist die eigentliche Frage ist.
Attribution ohne Sub-User lösen
Hier leisten Session-Identifikatoren die Arbeit, und es lohnt sich, sie von Anfang an bewusst zu strukturieren.
Kodieren Sie den Tenant in der Session-ID, sodass jede Anfrage bis zu demjenigen zurückverfolgt werden kann, für den sie bestimmt war. Die ID ist ein beliebiger von Ihnen gewählter String, sodass eine strukturierte Konvention nichts kostet und Attribution zu einer Frage des Parsens Ihrer eigenen Logs macht:
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}Erfassen Sie dann Bytes pro Anfrage bezogen auf den Kunden, denn die Rechnung des Anbieters ist eine einzige Gesamtsumme für das Konto und kann Ihnen nicht die Aufteilung mitteilen. Die Summierung der Antwortgrößen pro Tenant liefert Ihnen eine Nutzungszahl, gegen die Sie abrechnen oder aus der Sie die Marge berechnen können, und der regelmäßige Abgleich Ihrer Gesamtsumme mit der Rechnung hält alles ehrlich, da Wiederholungsversuche, fehlgeschlagene Anfragen und Verbindungs-Overhead alle Bandbreite verbrauchen, die eine naive Body-Größen-Zählung übersieht. Die Kennzahl, die pro Tenant zu beobachten ist, sind Bytes pro Datensatz, die in proxy KPIs behandelt wird und die Zahl ist, die aus Attribution ein Kostengespräch macht.
Sessions erfüllen hier auch ihren ursprünglichen Zweck: Unterschiedliche Identifikatoren pro Kunde verhindern, dass die Abläufe zweier Kunden auf derselben Sitzung kollidieren, was relevant wird, sobald mehr als ein Job gleichzeitig läuft. Die Semantik steht in sticky versus rotating.
Limits ohne Sub-User lösen
Es gibt keine anbieterseitige Obergrenze pro Tenant, das Limit muss also in Ihrem eigenen Scheduler leben, und ehrlich gesagt gehört es ohnehin dorthin: Ihr System weiß, worauf ein Kunde Anspruch hat, der Proxy weiß es nicht.
Geben Sie jedem Tenant ein Bandbreitenbudget für den Zeitraum und setzen Sie es gegen die bereits erfassten Nutzungsdaten durch, indem Sie die Jobs dieses Tenants stoppen oder in eine Warteschlange stellen, wenn das Budget aufgebraucht ist, statt ihn die gemeinsame Zuteilung aufzehren zu lassen. Alarmieren Sie deutlich vor dem Limit statt erst dabei. Kombinieren Sie das mit Nebenläufigkeits-Anteilen pro Tenant, damit ein großer nächtlicher Batch nicht vier kleine zeitkritische Jobs aushungern kann, und mit Retry-Budgets pro Tenant, damit ein fehlschlagendes Ziel eines Kunden nicht den gemeinsamen Pool überflutet, was das Eindämmungsargument in retry and backoff und rate limiting ist.
Der natürliche Ort für all das ist die Komponente, die bereits jede Anfrage sieht, weshalb a proxy manager der richtige Ort ist, um Tenant-Budgets, Nebenläufigkeits-Anteile und Attribution unterzubringen, statt sie über einzelne Jobs zu verstreuen.
Wahl zwischen einem Konto und mehreren Workspaces
Die Entscheidung ist meist einfacher, als sie aussieht, und läuft darauf hinaus, wer die geschäftliche Beziehung besitzt.
Nutzen Sie ein Konto mit logischen Tenants, wenn Sie eine Dienstleistung erbringen und der Anbieter Teil Ihrer Lieferkette ist: Sie kaufen die Bandbreite, Kunden sehen den Anbieter nie, und Segmentierung ist eine Namenskonvention in Ihrem eigenen Code. Das ist die übliche Agentur-Struktur.
Nutzen Sie einen Workspace pro Kunde, wenn der Kunde seinen eigenen Plan und seine eigenen Rechnungen besitzen soll, wobei Ihr Team als Admins hinzugefügt wird. Die Abrechnung ist wirklich getrennt, Traffic kann nicht vermischt werden, da Pläne nicht workspace-übergreifend gelten, und der Kunde kann sauber übernehmen, wenn die Zusammenarbeit endet.
Die Gestaltung um einen Tenant-Identifikator von Anfang an ist das, was den Wechsel zwischen diesen beiden Optionen zu einer Konfigurationsänderung statt zu einem Neubau macht.
Das Fazit
Sub-User sind eine Umsetzung von drei getrennten Bedürfnissen, und sie sind nicht die einzige Umsetzung. Beim Residential-Produkt gibt es ein einziges Proxy-Zugangsdatenset, sodass Isolation aus Secret-Management kommt und, wo sie absolut sein muss, aus separaten Workspaces mit eigenen Plänen; Zugriffskontrolle für Personen kommt aus Workspace-Rollen mit sofortigem Entzug; Attribution kommt aus strukturierten Session-Identifikatoren plus Ihrer eigenen Byte-Buchhaltung pro Tenant, da die Rechnung eine einzige Gesamtsumme ist; und Limits kommen aus Budgets in Ihrem Scheduler, dem einzigen Ort, der weiß, worauf jeder Tenant Anspruch hat. Wenn Sie von Anfang an um einen Tenant-Identifikator herum bauen, erhalten Sie alle drei, und Sie behalten die Möglichkeit, einen Kunden später in einen eigenen Workspace zu verschieben, ohne den Erfassungscode anzufassen.
Die darunterliegende Schicht sind residential proxies: ein Gateway, bei dem Land, Stadt, Session und TTL alle pro Anfrage ausgedrückt werden, was genau das ist, was Segmentierung pro Tenant zu einer Namenskonvention statt zu einer Produktbeschränkung macht, mit per-GB pricing, sodass die intern zugeordnete Nutzung in derselben Einheit gemessen wird, in der abgerechnet wird.