Capítulo 7 — Redes y protocolos
Mapa de la lección
Lección 07 publicada. Mapa, ejemplo, EX019.
flowchart TD
N0["Resultados de aprendizaje"]
N1["7.1 El camino de una petición"]
N2["7.2 Qué hace TLS y qué no"]
N3["7.3 Autenticación de API y limitación de frecuencia"]
N4["7.4 Amenazas a la IA a nivel de red"]
N5["7.6b Tiempos de espera y reintentos en las llamadas"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX019"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["7.1 El camino de una petición"]
N2["7.2 Qué hace TLS y qué no"]
N3["7.3 Autenticación de API y limitación de frecuencia"]
N4["7.4 Amenazas a la IA a nivel de red"]
N5["7.6b Tiempos de espera y reintentos en las llamadas"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[Resultados de aprendizaje]
|
v
[7.1 El camino de una petición]
|
v
[7.2 Qué hace TLS y qué no]
|
v
[7.3 Autenticación de API y limitación de frecuencia]
|
v
[7.4 Amenazas a la IA a nivel de red]
|
v
[7.6b Tiempos de espera y reintentos en las llamadas]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX019]
Resultados de aprendizaje
Usted podrá (1) explicar cómo viaja por internet una petición a un chatbot (DNS, TCP, TLS, HTTP); (2) describir qué protege TLS y qué no; (3) explicar la autenticación de API y la limitación de frecuencia; y (4) relacionar los controles de red con amenazas de la IA como la extracción y el agotamiento de recursos.
7.1 El camino de una petición
El navegador busca el dominio del chatbot (DNS), se conecta (TCP), establece un canal cifrado y autenticado (TLS) y envía una petición HTTP que contiene el mensaje. El servidor de aplicaciones puede a su vez llamar a una API de modelo por otra conexión TLS. Cada paso deja un registro que puede ayudar en una investigación: la consulta DNS, el establecimiento de la conexión TLS en el balanceador de carga, la petición HTTP en el servidor de aplicaciones y la llamada saliente al proveedor del modelo. En Ask Lumen, por tanto, un solo mensaje de un paciente atraviesa dos conexiones cifradas, y el servidor de aplicaciones es el único lugar donde LCH ve el texto en claro. Ahí es donde corresponden las comprobaciones de la entrada, el registro y las decisiones de política.
7.2 Qué hace TLS y qué no
TLS protege los datos en tránsito contra la escucha y la manipulación, y autentica al servidor. No protege contra un mensaje malicioso de un usuario autenticado, contra la inyección de instrucciones dentro del contenido ni contra el mal uso de los datos una vez que llegan. En Ask Lumen, TLS garantiza que el mensaje de un paciente llega al servidor de LCH sin ser leído ni modificado y que el paciente habla con el sitio real de LCH. No hace nada respecto a un paciente que escribe una instrucción diseñada para manipular el modelo, ni respecto a un documento de un asociado que lleva texto oculto. Esos problemas están dentro del canal protegido y necesitan controles en la aplicación.
7.3 Autenticación de API y limitación de frecuencia
Las API autentican a quienes las llaman con claves o tokens. Los límites de frecuencia y las cuotas acotan cuánto puede usar cada cliente. En las API de IA, los costes crecen con los tokens, así que los límites deben contar tokens, no solo peticiones. OWASP LLM10 (unbounded consumption, consumo ilimitado) cubre los ataques que agotan recursos o presupuestos.
"""Lab R: token-bucket limits against unbounded consumption (synthetic).
Simulates 60 seconds of requests from a normal client and a flooding client
against a model endpoint with a per-client token bucket."""
import random
rng = random.Random(4)
def simulate(rate_per_s, burst, reqs):
tokens, last, ok = burst, 0.0, 0
for t in reqs:
tokens = min(burst, tokens + (t - last) * rate_per_s); last = t
if tokens >= 1: tokens -= 1; ok += 1
return ok
normal = sorted(rng.uniform(0, 60) for _ in range(90))
flood = sorted(rng.uniform(0, 60) for _ in range(3000))
for rate, burst in ((5, 20), (2, 10), (1, 5)):
print(f"limit={rate}/s burst={burst:2d} normal_served={simulate(rate, burst, normal):3d}/90 "
f"flood_served={simulate(rate, burst, flood):4d}/3000")
Salida esperada:
limit=5/s burst=20 normal_served= 90/90 flood_served= 319/3000
limit=2/s burst=10 normal_served= 90/90 flood_served= 129/3000
limit=1/s burst= 5 normal_served= 62/90 flood_served= 64/3000
El Laboratorio R muestra el compromiso. Con 5 peticiones por segundo y una ráfaga de 20, se atienden todas las peticiones normales y la avalancha obtiene 319 de 3.000. Con 1 por segundo y una ráfaga de 5, la avalancha baja a 64, pero el cliente normal pierde 28 de sus 90 peticiones. Un límite debe fijarse a partir del uso normal medido, no elegirse solo para detener ataques.
7.4 Amenazas a la IA a nivel de red
Las consultas sistemáticas pueden copiar un modelo (Tramèr et al., arXiv:1609.02943). Las avalanchas de instrucciones largas pueden agotar la capacidad. Los controles de red —autenticación, cuotas, supervisión, segmentación y filtrado de salida— reducen estos riesgos y limitan lo que puede alcanzar un componente comprometido. La extracción necesita muchas consultas, así que las cuotas por cliente y la vigilancia de patrones de consulta inusuales aumentan su coste. El filtrado de salida importa si un componente se ve comprometido: un servidor de inferencia que solo puede alcanzar al proveedor del modelo no puede enviar datos a otro sitio. La segmentación mantiene los servidores del chatbot separados de la base de datos de citas, salvo a través de la interfaz estrecha de la herramienta de reservas.
7.5 Ejemplo resuelto (caso sintético de LCH)
El punto de acceso público del chat de Ask Lumen no tenía límites por sesión. Una prueba de carga sintética que enviaba instrucciones largas multiplicó por diez los costes del modelo en una hora. LCH añadió cuotas de tokens por sesión, una longitud máxima de mensaje y una alerta cuando el gasto supera el 150 % de la mediana diaria. Contar tokens en lugar de peticiones fue el cambio clave: unas pocas instrucciones muy largas habían costado más que miles de mensajes normales. El umbral de alerta del 150 % de la mediana diaria detecta el abuso en cuestión de horas sin reaccionar a la subida normal de las mañanas de mucha actividad, y la longitud máxima de mensaje impide que una sola instrucción consuma una parte grande del presupuesto.
7.6 Errores y límites
- Creer que TLS resuelve los ataques a nivel de aplicación.
- Límites de peticiones que ignoran el coste en tokens.
- Claves de API incrustadas en el código del navegador.
TLS protege el canal, no el contenido, así que la inyección de instrucciones y el abuso por parte de usuarios con sesión iniciada lo atraviesan sin obstáculos. Los límites que solo cuentan peticiones permiten a un atacante enviar menos instrucciones, pero mucho más largas, como mostró la prueba de carga de LCH. Las claves de API en el código del navegador puede leerlas cualquiera que abra la página, lo que le permite llamar directamente al proveedor del modelo y saltarse por completo las cuotas de LCH; las claves deben estar en el servidor.
7.6b Tiempos de espera y reintentos en las llamadas al modelo
Ask Lumen llama al proveedor del modelo a través de la red, y las respuestas lentas tientan a los ingenieros a reintentar de forma agresiva. Cada reintento reenvía la pregunta del paciente y cuesta dinero; los reintentos ilimitados durante una caída pueden multiplicar el tráfico y agotar el límite de frecuencia de todas las clínicas. LCH limita los reintentos a dos con una espera creciente y muestra a los pacientes un número de teléfono cuando el modelo no está disponible. Una espera creciente entre reintentos permite que un proveedor en apuros se recupere en lugar de verse inundado. El número de teléfono mantiene atendidos a los pacientes mientras el chatbot no funciona.
Ejercicios
- EX019 — TLS. Nombre dos cosas que TLS protege y dos que no. Rúbrica: 3 = confidencialidad/integridad en tránsito, autenticación del servidor frente a contenido malicioso, inyección/mal uso; 2 = tres; 1 = una o dos; 0 = nada.
- EX020 — Lectura del laboratorio. En el laboratorio, ¿por qué el límite de 1/s con ráfaga de 5 perjudica a los usuarios normales? Rúbrica: 3 = solo se atienden 62/90 porque las ráfagas naturales superan el cubo; 2 = solo el número; 1 = vago; 0 = incorrecto.
- EX021 — Claves. ¿Por qué las claves de API del modelo no deben aparecer en el código del navegador? Rúbrica: 3 = cualquiera puede leerlas y usarlas indebidamente, lo que causa costes y abuso; usar llamadas desde el servidor; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis
Las redes entregan los servicios de IA; TLS, la autenticación, las cuotas que tienen en cuenta los tokens y la supervisión protegen la entrega, pero no el contenido, del que se ocupan capítulos posteriores.
Siga estudiando — capítulo 07 de 40
← Capítulo 06 (borrador) · Índice de capítulos del curso · Capítulo 08 (borrador) →