Capítulo 2 — Redes e protocolos
Mapa da aula
Aula 02 publicada. Mapa, exemplo, EX005.
flowchart TD
N0["2.1 Protocolos"]
N1["2.2 TLS e segmentação"]
N2["2.4 Sinais de abuso"]
N3["2.4b Documentando as configurações de rede"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX005"]
Desenho lógico
flowchart LR
N0["2.1 Protocolos"]
N1["2.2 TLS e segmentação"]
N2["2.4 Sinais de abuso"]
N3["2.4b Documentando as configurações de rede"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX005"]
[2.1 Protocolos]
|
v
[2.2 TLS e segmentação]
|
v
[2.4 Sinais de abuso]
|
v
[2.4b Documentando as configurações de rede]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX005]
Objetivos de aprendizagem
Você vai (1) descrever os protocolos que um serviço de IA usa; (2) configurar TLS e segmentação de rede; (3) ajustar limites no gateway; (4) reconhecer sinais de abuso na rede.
2.1 Protocolos
Os clientes chegam ao HelpBot por HTTPS (HTTP sobre TLS); o orquestrador chama a API do modelo do fornecedor por HTTPS, com uma chave de API; os serviços internos conversam por HTTP ou gRPC dentro da rede privada; o DNS resolve todos os nomes. As respostas do chat costumam ser transmitidas em fluxo contínuo (streaming), por isso as conexões ficam abertas por mais tempo que requisições comuns. O streaming afeta diretamente as configurações de segurança. Uma resposta do HelpBot pode levar 20 segundos para terminar, então um tempo limite do gateway ajustado para carregamentos comuns de página corta as respostas, e um tempo limite longo demais deixa um único cliente manter centenas de conexões abertas. A chamada à API do fornecedor é a única conexão que sai da rede da Kestrel, e ela leva a chave de API, por isso a regra de saída do orquestrador deve permitir esse único nome de host e nada mais. O DNS importa porque uma resolução errada do host do fornecedor mandaria a chave para outro lugar.
2.2 TLS e segmentação
Use versões atuais do TLS e certificados válidos em todo lugar, inclusive nas chamadas internas, quando possível. Segmente as redes: o serviço de gerenciamento de roteadores deve aceitar conexões apenas do serviço de ferramentas, não da internet nem da rede geral do escritório. As regras de firewall são escritas como listas de permissão. A segmentação também é o que limita o dano se o orquestrador for manipulado. Mesmo com instruções injetadas num artigo, o modelo só pode pedir uma ferramenta ao orquestrador; se o serviço de gerenciamento de roteadores aceita conexões apenas do serviço de ferramentas, nada mais na rede consegue chamá-lo diretamente. Ana verificou isso tentando alcançar a porta do gerenciamento de roteadores a partir da rede do escritório, na cópia de homologação, e registrando que a conexão foi recusada. Uma regra que nunca foi testada é apenas uma intenção escrita.
2.3 Limites no gateway
Um gateway de API impõe tamanho máximo de requisição, tempos limite para conexões em streaming e limites de taxa por cliente. Limites do tipo balde de fichas (token bucket) permitem rajadas normais, mas cortam enxurradas. Os limites protegem a disponibilidade e o custo — OWASP LLM10 Consumo Ilimitado (Unbounded Consumption).
"""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")
Saída 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
O laboratório mostra o equilíbrio em números. Um limite de 5 por segundo com rajada de 20 atendeu às 90 requisições normais, mas deixou passar 319 de 3.000 requisições da enxurrada; 2 por segundo com rajada de 10 ainda atendeu às 90 requisições normais e reduziu a enxurrada para 129; 1 por segundo com rajada de 5 reduziu a enxurrada para 64, mas atendeu a apenas 62 das 90 requisições normais. A configuração do meio é a que a Kestrel escolheu, porque na simulação ela não custa nada aos clientes. Um orçamento diário de tokens foi acrescentado porque um limite de taxa sozinho não impede mensagens longas.
2.4 Sinais de abuso
Muitas requisições de uma conta; muitas contas de um endereço; tráfego em horários incomuns; requisições com entradas muito longas; crescimento súbito dos tokens usados. São sinais para investigar, não prova de ataque. Cada sinal também tem uma explicação inocente. A conta que enviou 40.000 mensagens quase no tamanho máximo durante um fim de semana era claramente anormal, mas uma família que compartilha um roteador doméstico pode gerar muitas contas a partir de um endereço, e clientes do turno da noite escrevem em horários incomuns. A regra de Ana é combinar pelo menos dois sinais antes de escalar e verificar se uma chave de API vazada poderia explicar o tráfego antes de culpar um cliente. Os registros do gateway precisam guardar ID da conta, endereço de origem, tamanho da mensagem e contagem de tokens para que essas verificações sejam possíveis.
2.4b Documentando as configurações de rede
Registre cada regra de firewall, limite do gateway e certificado com sua finalidade e seu responsável. Quando um limite for alterado, registre por quê. Isso ajuda o próximo técnico a entender as configurações durante um incidente. Uma boa entrada é curta. Para o gateway do HelpBot: "Limite por conta de 2 requisições/s, rajada de 10, orçamento diário de tokens; finalidade: impedir enxurradas de uma única conta (o pico da conta no fim de semana); responsável: operações de serviço; alterado após o incidente das 40.000 mensagens; verificação em laboratório: atende 90/90 normais, 129/3.000 da enxurrada." Quando, mais tarde, um cliente reclamar de estar sendo limitado, o próximo técnico pode ver por que o limite existe antes de aumentá-lo e pode rodar de novo o laboratório com os valores propostos para ver o que a mudança deixaria passar.
2.5 Exemplo resolvido (caso sintético da Kestrel)
A conta do fornecedor do HelpBot dobra num fim de semana. Ana confere os registros do gateway: uma conta de cliente enviou 40.000 mensagens, cada uma perto do tamanho máximo. Não havia limite por conta. Ela configura 2 requisições por segundo com rajada de 10 e um orçamento diário de tokens; no análogo de laboratório, essa configuração atende às 90 requisições normais e admite apenas 129 de 3.000 requisições da enxurrada. Os números explicam por que a correção teve duas partes. Um limite de 2 por segundo ainda permite mais de 170.000 requisições por dia de uma conta, então sozinho ele teria desacelerado o pico sem pôr um teto na conta. O orçamento diário de tokens limita o custo por conta, independentemente do ritmo. Ana também verificou que o tráfego de API da conta vinha pelo login normal do aplicativo, descartando uma chave do fornecedor vazada, antes de registrar como causa uma única conta abusiva.
2.6 Erros e limites
Três erros são comuns: serviços internos acessíveis de qualquer lugar; ausência de limites para conexões em streaming; e limites apenas por endereço IP. Na Kestrel, cada um deles teria anulado um controle descrito neste capítulo. Se o serviço de gerenciamento de roteadores fosse acessível pela rede do escritório, a verificação de titularidade no serviço de ferramentas poderia ser contornada por completo. Sem limites para conexões em streaming, um cliente pode manter abertas centenas de respostas lentas e esgotar o gateway mesmo ficando abaixo da taxa de requisições. Limites apenas por endereço IP falham nos dois sentidos: um atacante pode alternar endereços, e muitos clientes legítimos atrás de um endereço compartilhado de uma operadora móvel seriam limitados juntos.
Exercícios
- EX005 — Protocolos. Liste os protocolos usados numa conversa do HelpBot e o que cada um protege ou faz. Rubrica: 3 = HTTPS, TLS, DNS, interno, API do fornecedor com seus papéis; 2 = três ou quatro; 1 = um ou dois; 0 = nenhum.
- EX006 — Segmentação. Escreva regras de permissão de firewall para o serviço de gerenciamento de roteadores. Rubrica: 3 = só o serviço de ferramentas, porta específica, negar o resto; 2 = parcial; 1 = vago; 0 = nenhuma.
- EX007 — Laboratório. Que configuração do laboratório você escolheria, e por quê? Rubrica: 3 = 2/s com rajada de 10, com razões tiradas dos números; 2 = escolha com razões parciais; 1 = só a escolha; 0 = nenhuma.
- EX008 — Pico da conta. Liste as verificações que Ana deve fazer após o pico da conta. Rubrica: 3 = volume por conta, tamanho da entrada, padrão de horário, vazamento de chave; 2 = três; 1 = uma ou duas; 0 = nenhuma.
Síntese
Proteja os protocolos, segmente a rede para que ferramentas poderosas só sejam acessíveis por quem as chama e limite a taxa dos endpoints de IA para proteger a disponibilidade e o custo.
Continue estudando — capítulo 02 de 18
← Capítulo 01 (rascunho) · Índice de capítulos do curso · Capítulo 03 (rascunho) →