Assim que mais de uma pessoa ou projeto usa uma conta de proxy, as mesmas perguntas surgem. Como impedimos que toda a equipe compartilhe uma única credencial. Como sabemos qual cliente consumiu quantos gigabytes. Como cortamos o acesso de um contratado sem interromper o de todos os outros. Neste setor, essas perguntas costumam ser respondidas com a expressão “subusuários”, e essa expressão significa coisas diferentes dependendo de quem está vendendo.
A seguir, o que os subusuários realmente são, o que o produto residencial oferece e não oferece, e como resolver os três problemas subjacentes de qualquer forma.
O que subusuários significam neste mercado
Um subusuário, quando um provedor o oferece, é um conjunto secundário de credenciais de proxy emitido sob uma conta principal. Normalmente, pode ter seu próprio limite de banda, às vezes suas próprias restrições de segmentação, e pode ser revogado sem afetar a conta principal. É um recurso de controle de acesso vinculado ao próprio tráfego.
As equipes os desejam por três razões distintas, e vale a pena separá-las, pois têm soluções diferentes.
Isolamento. Pessoas ou projetos diferentes não devem compartilhar uma única credencial, para que um vazamento ou a saída de alguém tenha um raio de impacto contido.
Atribuição. Alguém precisa saber qual cliente, equipe ou projeto usou qual parte da largura de banda, geralmente para faturamento ou margem.
Limites. Um projeto não deve conseguir consumir todo o plano, seja por acidente ou por uma tarefa fora de controle.
O que o produto residencial oferece
Sendo direto: os proxies residenciais da Shifter não têm credenciais de proxy por subusuário. A autenticação é feita com um único nome de usuário e senha, com opções de segmentação e sessão expressas dentro do nome de usuário, conforme documentado em gateway e autenticação. Não há recurso para gerar uma segunda credencial de proxy com seu próprio limite de banda.
O que existe se divide em dois mecanismos, que juntos cobrem os três problemas acima.
Team Workspaces gerenciam o acesso à conta. Você convida pessoas por e-mail e atribui uma função: Viewer para visibilidade somente leitura de membros, tráfego e faturas, Billing para essas permissões além de financiamento e compras, e Admin para gerenciamento completo de membros e equipe. As funções têm escopo por workspace, e não global, a remoção é imediata e encerra as sessões existentes, e uma pessoa pode pertencer a vários workspaces e alternar entre eles com um único login. O comportamento completo está em o anúncio dos Team Workspaces.
Identificadores de sessão lidam com a segmentação do tráfego. Cada requisição pode carregar um ID de sessão de sua escolha, o que torna possível a atribuição por cliente e por projeto sem credenciais separadas.
A distinção a manter em mente: os workspaces controlam quem pode administrar a conta, os identificadores de sessão organizam o que o tráfego está fazendo. Os subusuários, onde existem em outros lugares, misturam essas duas coisas.
Resolvendo o isolamento sem subusuários
Como uma única credencial atende a tudo, o trabalho de isolamento passa a depender de como você a armazena e a expõe.
Mantenha a credencial em um gerenciador de segredos em vez de no código, na configuração ou em um documento compartilhado, e deixe que as aplicações a leiam a partir do ambiente em tempo de execução. As pessoas não precisam da credencial de proxy para fazer seu trabalho; os sistemas precisam. Um engenheiro que precise testar pode receber acesso a um serviço que a utiliza, em vez do valor propriamente dito.
Quando você realmente precisa de raios de impacto separados, workspaces separados com planos próprios fornecem credenciais genuinamente separadas, já que os planos não atravessam workspaces. Isso é mais pesado do que um subusuário e implica faturamento separado, então se encaixa no caso em que um cliente ou unidade de negócio deve ter sua própria conta de qualquer forma, e não no caso em que você só quer organização.
Depois, planeje a rotação antes de precisar dela. Como uma única credencial é compartilhada, sua rotação afeta tudo de uma vez, então trate isso como uma implantação: atualize o armazenamento de segredos, atualize cada cliente, e só então invalide o valor antigo. Pular essa ordem é a forma mais comum de uma equipe descobrir em quantos lugares a credencial está presente, já que todos eles começam a retornar erros 407 simultaneamente.
Para pessoas, em vez de sistemas, o desligamento passa pelas funções de workspace: remova o membro e o acesso dele ao painel termina imediatamente, incluindo qualquer sessão aberta. Isso cobre o caso do contratado, que geralmente é o que realmente está sendo perguntado.
Resolvendo a atribuição sem subusuários
É aqui que os identificadores de sessão fazem o trabalho, e vale a pena estruturá-los de forma deliberada desde o início.
Codifique o tenant no ID de sessão para que cada requisição seja rastreável até para quem ela foi feita. O ID é qualquer string que você escolher, então uma convenção estruturada não custa nada e transforma a atribuição em uma questão de analisar seus próprios 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}Em seguida, registre os bytes por requisição em relação ao cliente, porque a fatura do provedor é um total único para a conta e não revela a divisão. Somar o tamanho das respostas por tenant fornece um número de uso para cobrar ou para calcular a margem, e reconciliar periodicamente seu total com a fatura mantém a precisão, já que novas tentativas, requisições com falha e a sobrecarga de conexão consomem largura de banda que uma contagem simples do tamanho do corpo não captura. A métrica a acompanhar por tenant é bytes por registro, abordada em KPIs de proxy e é o número que transforma a atribuição em uma conversa sobre custo.
As sessões também cumprem aqui seu propósito original: identificadores distintos por cliente evitam que os fluxos de dois clientes colidam na mesma sessão, o que importa a partir do momento em que mais de uma tarefa é executada simultaneamente. A semântica está em sticky versus rotativo.
Resolvendo limites sem subusuários
Não existe um limite por tenant do lado do provedor, então o limite precisa residir no seu próprio agendador, e, honestamente, é onde ele deveria estar mesmo: seu sistema sabe a que um cliente tem direito, o proxy não sabe.
Dê a cada tenant um orçamento de largura de banda para o período e aplique-o em relação ao uso que você já está registrando, interrompendo ou colocando em fila as tarefas daquele tenant quando o orçamento se esgotar, em vez de deixá-lo consumir a alocação compartilhada. Alerte bem antes do limite, e não apenas quando ele for atingido. Combine isso com cotas de concorrência por tenant, para que um grande lote noturno não sufoque quatro tarefas pequenas e sensíveis ao tempo, e com orçamentos de novas tentativas por tenant, para que o alvo com falha de um cliente não inunde o pool compartilhado, o que é o argumento de contenção em novas tentativas e backoff e limitação de taxa.
O lugar natural para tudo isso é o componente que já vê cada requisição, e é por isso que um gerenciador de proxy é o local certo para colocar orçamentos por tenant, cotas de concorrência e atribuição, em vez de espalhá-los pelas tarefas.
Escolhendo entre uma conta e vários workspaces
A decisão geralmente é mais simples do que parece, e se resume a quem é o titular da relação comercial.
Use uma única conta com tenants lógicos quando você estiver prestando um serviço e o fornecedor for sua cadeia de suprimentos: você compra a largura de banda, os clientes nunca veem o provedor, e a segmentação é uma convenção de nomenclatura no seu próprio código. Esse é o formato comum de agência.
Use um workspace por cliente quando o cliente deve ser o titular do próprio plano e das próprias faturas, com sua equipe adicionada como Admins. O faturamento é genuinamente separado, o tráfego não pode se misturar porque os planos não atravessam workspaces, e o cliente pode assumir o controle de forma limpa se o contrato terminar.
Projetar em torno de um identificador de tenant desde o primeiro dia é o que transforma a mudança entre essas opções em uma alteração de configuração, e não em uma reconstrução.
Em resumo
Subusuários são uma implementação para três necessidades distintas, e não são a única implementação. No produto residencial há uma única credencial de proxy, então o isolamento vem do gerenciamento de segredos e, onde precisa ser absoluto, de workspaces separados com planos próprios; o controle de acesso para pessoas vem das funções de workspace com revogação imediata; a atribuição vem de identificadores de sessão estruturados somados à sua própria contabilidade de bytes por tenant, já que a fatura é um total único; e os limites vêm de orçamentos no seu agendador, que é o único lugar que sabe a que cada tenant tem direito. Se você construir em torno de um identificador de tenant desde o início, obtém os três, e mantém a opção de mover um cliente para o próprio workspace mais tarde sem tocar no código de coleta.
A camada subjacente são os proxies residenciais: um único gateway em que país, cidade, sessão e TTL são todos expressos por requisição, o que é exatamente o que faz da segmentação por tenant uma convenção de nomenclatura, e não uma limitação do produto, com preços por GB para que o uso que você atribui internamente seja medido na mesma unidade em que você é cobrado.