En cuanto más de una persona o proyecto utiliza una cuenta de proxy, llegan las mismas preguntas. Cómo evitamos que todo el equipo comparta una credencial. Cómo distinguimos qué cliente ha consumido qué gigabytes. Cómo cortamos el acceso de un contratista sin romper el acceso de los demás. En este sector esas preguntas suelen responderse con la frase “sub-usuarios”, y esa frase significa cosas distintas según quién la venda.
A continuación se explica qué son realmente los sub-usuarios, qué ofrece y qué no ofrece el producto residencial, y cómo resolver los tres problemas subyacentes en cualquier caso.
Qué significan los sub-usuarios en este mercado
Un sub-usuario, cuando un proveedor lo ofrece, es un conjunto secundario de credenciales de proxy emitido bajo una cuenta principal. Normalmente puede tener su propio límite de ancho de banda, a veces sus propias restricciones de segmentación, y se puede revocar sin afectar a la cuenta principal. Es una función de control de acceso vinculada al propio tráfico.
Los equipos las quieren por tres motivos distintos, y conviene separarlos, porque tienen soluciones diferentes.
Aislamiento. Distintas personas o proyectos no deberían compartir una credencial, de modo que una filtración o una baja tenga un radio de impacto contenido.
Atribución. Alguien necesita saber qué cliente, equipo o proyecto usó qué parte del ancho de banda, normalmente para facturación o margen.
Límites. Un proyecto no debería poder consumir todo el plan, ya sea por accidente o por un proceso descontrolado.
Qué ofrece el producto residencial
Para ser directos: los proxies residenciales de Shifter no tienen credenciales de proxy por sub-usuario. La autenticación es un único nombre de usuario y contraseña, con opciones de segmentación y sesión expresadas dentro del nombre de usuario, tal como se documenta en gateway y autenticación. No existe ninguna función para generar una segunda credencial de proxy con su propio límite de ancho de banda.
Lo que sí existe se divide en dos mecanismos, y entre ambos cubren los tres problemas anteriores.
Team Workspaces gestionan el acceso a la cuenta. Se invita a personas por correo electrónico y se les asigna un rol: Viewer para visibilidad de solo lectura sobre miembros, tráfico y facturas, Billing para eso más financiación y compras, y Admin para gestión completa de miembros y equipo. Los roles tienen alcance por espacio de trabajo en lugar de global, la eliminación es inmediata y termina las sesiones existentes, y una persona puede pertenecer a varios espacios de trabajo y cambiar entre ellos con un único inicio de sesión. El comportamiento completo está en el anuncio de Team Workspaces.
Los identificadores de sesión gestionan la segmentación del tráfico. Cada solicitud puede llevar un ID de sesión elegido por el usuario, que es lo que hace posible la atribución por cliente y por proyecto sin credenciales separadas.
La distinción que hay que retener: los espacios de trabajo controlan quién puede administrar la cuenta, los identificadores de sesión organizan qué está haciendo el tráfico. Los sub-usuarios, donde existen en otros proveedores, difuminan esa distinción.
Resolver el aislamiento sin sub-usuarios
Dado que una sola credencial sirve para todo, el trabajo de aislamiento se traslada a cómo se almacena y se expone.
Guarde la credencial en un gestor de secretos en lugar de en código, configuración o un documento compartido, y permita que las aplicaciones la lean del entorno en tiempo de ejecución. Las personas no necesitan la credencial del proxy para hacer su trabajo; los sistemas sí. A un ingeniero que necesita hacer pruebas se le puede dar acceso a un servicio que la usa en lugar de al valor en sí.
Cuando realmente se necesitan radios de impacto separados, espacios de trabajo separados con sus propios planes le dan credenciales realmente separadas, ya que los planes no se cruzan entre espacios de trabajo. Eso es más pesado que un sub-usuario e implica facturación separada, así que se ajusta al caso en que un cliente o unidad de negocio debería tener su propia cuenta de todos modos, no al caso en que simplemente se busca orden.
Luego, planifique la rotación antes de necesitarla. Como la credencial es compartida, rotarla afecta a todo a la vez, así que trátelo como un despliegue: actualice el almacén de secretos, actualice cada cliente y después invalide el valor antiguo. Saltarse ese orden es la forma más común en que un equipo descubre en cuántos sitios vive la credencial, ya que todos ellos empiezan a devolver errores 407 simultáneamente.
Para personas en lugar de sistemas, la baja se gestiona a través de los roles de espacio de trabajo: se elimina al miembro y su acceso al panel termina de inmediato, incluida cualquier sesión abierta. Eso cubre el caso del contratista, que suele ser lo que realmente se pregunta.
Resolver la atribución sin sub-usuarios
Aquí es donde los identificadores de sesión hacen el trabajo, y conviene estructurarlos deliberadamente desde el principio.
Codifique el inquilino (tenant) en el ID de sesión para que cada solicitud sea trazable hasta quien correspondía. El ID es cualquier cadena que usted elija, así que una convención estructurada no cuesta nada y convierte la atribución en una cuestión de analizar sus propios registros:
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}Después, registre los bytes por solicitud asociados al cliente, porque la factura del proveedor es un único total para la cuenta y no puede indicarle el desglose. Sumar los tamaños de las respuestas por inquilino le da una cifra de uso sobre la que facturar o calcular el margen, y reconciliar periódicamente su total con la factura mantiene la honestidad de la cifra, ya que los reintentos, las solicitudes fallidas y la sobrecarga de conexión también consumen ancho de banda que un conteo ingenuo del tamaño del cuerpo no capta. La métrica que hay que vigilar por inquilino es bytes por registro, que se trata en KPIs de proxy y es el número que convierte la atribución en una conversación sobre costes.
Las sesiones también cumplen aquí su propósito original: identificadores distintos por cliente evitan que los flujos de dos clientes colisionen en la misma sesión, algo que importa en cuanto se ejecuta más de un trabajo a la vez. La semántica está en sticky frente a rotating.
Resolver los límites sin sub-usuarios
No hay un límite del lado del proveedor por inquilino, así que el límite tiene que residir en su propio planificador, y en realidad ahí es donde pertenece: su sistema sabe a qué tiene derecho un cliente, el proxy no.
Asigne a cada inquilino un presupuesto de ancho de banda para el periodo y hágalo cumplir contra el uso que ya está registrando, deteniendo o poniendo en cola los trabajos de ese inquilino cuando se agote en lugar de dejar que consuma la asignación compartida. Avise con antelación al límite en lugar de al llegar a él. Combine eso con cuotas de concurrencia por inquilino para que un gran proceso por lotes nocturno no deje sin recursos a cuatro trabajos pequeños sensibles al tiempo, y con presupuestos de reintentos por inquilino para que el objetivo fallido de un cliente no inunde el conjunto compartido, que es el argumento de contención en reintentos y backoff y limitación de tasa.
El lugar natural para todo esto es el componente que ya ve cada solicitud, por lo que un gestor de proxies es el sitio adecuado para colocar los presupuestos por inquilino, las cuotas de concurrencia y la atribución, en lugar de dispersarlos entre distintos trabajos.
Elegir entre una cuenta y varios espacios de trabajo
La decisión suele ser más sencilla de lo que parece, y depende de quién posea la relación comercial.
Use una cuenta con inquilinos lógicos cuando esté prestando un servicio y el proveedor sea su cadena de suministro: usted compra el ancho de banda, los clientes nunca ven al proveedor, y la segmentación es una convención de nombres en su propio código. Esta es la forma habitual de las agencias.
Use un espacio de trabajo por cliente cuando el cliente deba tener su propio plan y sus propias facturas, con su equipo añadido como Admins. La facturación es realmente separada, el tráfico no puede mezclarse porque los planes no se cruzan entre espacios de trabajo, y el cliente puede hacerse cargo limpiamente si termina la colaboración.
Diseñar en torno a un identificador de inquilino desde el primer día es lo que convierte el paso de uno a otro en un cambio de configuración en lugar de una reconstrucción.
La conclusión
Los sub-usuarios son una implementación de tres necesidades distintas, y no son la única implementación. En el producto residencial hay una única credencial de proxy, así que el aislamiento proviene de la gestión de secretos y, donde debe ser absoluto, de espacios de trabajo separados con sus propios planes; el control de acceso para las personas proviene de los roles de espacio de trabajo con revocación inmediata; la atribución proviene de identificadores de sesión estructurados junto con su propia contabilidad de bytes por inquilino, porque la factura es un único total; y los límites provienen de presupuestos en su planificador, que es el único lugar que sabe a qué tiene derecho cada inquilino. Si construye en torno a un identificador de inquilino desde el principio, obtiene las tres cosas, y conserva la opción de trasladar a un cliente a su propio espacio de trabajo más adelante sin tocar el código de recolección.
La capa que hay debajo son los proxies residenciales: un único gateway donde país, ciudad, sesión y TTL se expresan por solicitud, que es precisamente lo que convierte la segmentación por inquilino en una convención de nombres en lugar de una limitación del producto, con precios por GB para que el uso que usted atribuye internamente se mida en la misma unidad por la que se le factura.