Capítulo 11 — Redes y protocolos
Mapa de la lección
Lección 11 publicada. Mapa, ejemplo, EX031.
flowchart TD
N0["Resultados de aprendizaje"]
N1["11.1 El recorrido de la solicitud"]
N2["11.2 Amenazas propias de las API de IA"]
N3["11.3 Segmentación"]
N4["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX031"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["11.1 El recorrido de la solicitud"]
N2["11.2 Amenazas propias de las API de IA"]
N3["11.3 Segmentación"]
N4["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]
[Resultados de aprendizaje]
|
v
[11.1 El recorrido de la solicitud]
|
v
[11.2 Amenazas propias de las API de IA]
|
v
[11.3 Segmentación]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX031]
Resultados de aprendizaje
Usted será capaz de (1) explicar el recorrido de red de una solicitud a un servicio de modelos (DNS, TCP, TLS, HTTP); (2) identificar amenazas de nivel de red para los servicios de IA (interceptación, denegación de servicio, abuso de las API); (3) diseñar la segmentación de red para el entrenamiento, el servicio y los sistemas de las herramientas; y (4) interpretar los límites de tasa y las cuotas de las API como controles de seguridad.
11.1 El recorrido de la solicitud
Un cliente resuelve el nombre del servicio con DNS, abre una conexión TCP, negocia TLS (que autentica al servidor y cifra el tráfico) y envía una solicitud HTTP, normalmente un JSON que contiene un prompt o unas características. El servidor devuelve una respuesta, quizá transmitida token a token. Cada capa tiene sus propios modos de fallo: suplantación de DNS, configuración errónea de TLS, contrabando de solicitudes HTTP, cuerpos de tamaño excesivo. Los ingenieros revisan cada capa por separado. Los registros DNS se protegen y se monitorizan, la configuración de TLS se contrasta con las recomendaciones vigentes y la capa HTTP impone un tamaño máximo del cuerpo y un tiempo máximo de solicitud antes de que el modelo vea nada. Una solicitud rechazada en el perímetro casi no cuesta nada; la misma solicitud, si llega al modelo, puede costar segundos de tiempo de acelerador.
11.2 Amenazas propias de las API de IA
Además de los ataques de red clásicos, las API de IA se enfrentan a la extracción de modelos mediante consultas sistemáticas (Tramèr et al., arXiv:1609.02943), a la inferencia de pertenencia a través de las salidas de confianza y al consumo ilimitado (OWASP LLM10): prompts y salidas largos que agotan la capacidad de cómputo o el presupuesto. Como cada solicitud es cara, los límites ordinarios de solicitudes por segundo no bastan; las cuotas deben tener en cuenta los tokens y el cómputo.
"""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 muestra un cubo de testigos que atiende por completo a un cliente normal mientras limita a un cliente que inunda el servicio. Un límite demasiado estricto (1/s, ráfaga de 5) empieza a rechazar tráfico legítimo: los límites son un compromiso que hay que ajustar con datos de uso reales.
11.3 Segmentación
Sitúe los clústeres de entrenamiento, los registros de modelos, los puntos de servicio y los sistemas de las herramientas en zonas de red separadas. El servicio no debe llegar a los almacenes de datos de entrenamiento; el sistema de las herramientas de un agente basado en LLM (por ejemplo, un sistema de órdenes de trabajo) debe aceptar llamadas solo del servicio de política, no directamente del anfitrión del modelo. El filtrado de salida impide que un componente comprometido o manipulado envíe datos a destinos arbitrarios, una mitigación directa de la exfiltración mediante llamadas a herramientas inyectadas.
Las zonas se imponen con reglas de cortafuegos y se comprueban con pruebas: desde el anfitrión del modelo, una conexión al sistema de órdenes de trabajo o a una dirección externa debe fallar. Registrar estas pruebas hace que la segmentación siga verificada tras los cambios de red, en lugar de darse por supuesta.
11.4 Ejemplo resuelto (caso sintético de NRS)
El anfitrión del modelo de Wrench podía conectarse a internet para obtener los boletines de proveedores y también podía llamar directamente a la API de órdenes de trabajo. Sam trasladó la obtención de boletines a un servicio de ingesta separado que guarda copias depuradas, eliminó la salida a internet del anfitrión del modelo e hizo que la API de órdenes de trabajo aceptara solicitudes solo del servicio de política, con TLS mutuo. Los cambios cortaron a nivel de red ambos caminos de lo no confiable a lo privilegiado. Aunque un boletín manipule el modelo, el anfitrión del modelo no puede enviar datos al exterior ni llegar al sistema de órdenes de trabajo sin pasar por el servicio de política. Sam verifica cada cambio intentando las conexiones bloqueadas desde el anfitrión del modelo y registrando los rechazos como evidencia.
11.5 Errores y límites
- Límites de tasa sobre las solicitudes, pero no sobre los tokens ni el cómputo.
- Redes planas en las que el anfitrión del modelo llega a todo.
- Salida sin restricciones desde componentes que procesan texto no confiable.
Contar solo las solicitudes permite que un cliente envíe unos pocos prompts enormes que cuestan tanto como miles de prompts pequeños. Las redes planas hacen que un único componente manipulado pueda llegar a todos los sistemas. La salida sin restricciones da a las instrucciones inyectadas una vía para enviar datos al exterior. La tercera configuración del laboratorio añade otra lección: los límites ajustados sin datos de uso pueden rechazar un tercio de las solicitudes legítimas, así que las cuotas necesitan medición además de razonamiento de seguridad.
Ejercicios — capítulo 11
- EX031 — Lectura del laboratorio. Con 2/s y ráfaga de 10, ¿cuántas solicitudes normales y de inundación se atienden, y por qué 1/s perjudica a los usuarios normales? Rúbrica: 3 = 90/90 y 129/3000; las ráfagas normales superan el cubo más pequeño; 2 = solo los números; 1 = vago; 0 = incorrecto.
- EX032 — Segmentación. Describa (con palabras) cuatro zonas para Wrench y los flujos permitidos. Rúbrica: 3 = ingesta, modelo, política, herramientas, con flujos direccionales y sin camino directo modelo→herramientas; 2 = laguna menor; 1 = vago; 0 = nada.
- EX033 — Filtrado de salida. Explique cómo el filtrado de salida limita el impacto de la inyección de prompts. Rúbrica: 3 = el componente manipulado no puede enviar datos a destinos del atacante; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
Los servicios de IA son servicios de red con solicitudes caras. TLS, la segmentación, el control de salida y las cuotas que tienen en cuenta el cómputo reducen la interceptación, el abuso y el impacto de los componentes manipulados.
Siga estudiando — capítulo 11 de 50
← Capítulo 10 (borrador) · Índice de capítulos del curso · Capítulo 12 (borrador) →