Capítulo 7 — Redes e protocolos
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX019.
flowchart TD
N0["7.1 O caminho de uma requisição"]
N1["7.2 O que o TLS faz e o que não faz"]
N2["7.3 Autenticação de APIs e limitação de taxa"]
N3["7.4 Ameaças de IA no nível da rede"]
N4["7.6b Tempos limite e novas tentativas nas chamadas a"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX019"]
Desenho lógico
flowchart LR
N0["7.1 O caminho de uma requisição"]
N1["7.2 O que o TLS faz e o que não faz"]
N2["7.3 Autenticação de APIs e limitação de taxa"]
N3["7.4 Ameaças de IA no nível da rede"]
N4["7.6b Tempos limite e novas tentativas nas chamadas a"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[7.1 O caminho de uma requisição]
|
v
[7.2 O que o TLS faz e o que não faz]
|
v
[7.3 Autenticação de APIs e limitação de taxa]
|
v
[7.4 Ameaças de IA no nível da rede]
|
v
[7.6b Tempos limite e novas tentativas nas chamadas a]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX019]
Objetivos de aprendizagem
Você vai (1) explicar como uma requisição de chatbot atravessa a internet (DNS, TCP, TLS, HTTP); (2) descrever o que o TLS protege e o que não protege; (3) explicar autenticação de APIs e limitação de taxa; e (4) relacionar controles de rede a ameaças de IA como extração e esgotamento de recursos.
7.1 O caminho de uma requisição
O navegador consulta o domínio do chatbot (DNS), conecta-se (TCP), estabelece um canal cifrado e autenticado (TLS) e envia uma requisição HTTP contendo a mensagem. O servidor de aplicação, por sua vez, pode chamar uma API de modelo por outra conexão TLS. Cada etapa deixa um registro que pode ajudar numa investigação: a consulta DNS, o handshake TLS no balanceador de carga, a requisição HTTP no servidor de aplicação e a chamada de saída ao provedor do modelo. No Ask Lumen, uma única mensagem de paciente atravessa, portanto, duas conexões cifradas, e o servidor de aplicação é o único lugar onde o texto em claro fica visível para a LCH. É ali que ficam as verificações de entrada, o registro em log e as decisões de política.
7.2 O que o TLS faz e o que não faz
O TLS protege os dados em trânsito contra escuta e adulteração e autentica o servidor. Não protege contra uma mensagem maliciosa de um usuário autenticado, contra injeção de prompt dentro do conteúdo nem contra o mau uso dos dados depois que chegam. No Ask Lumen, o TLS garante que a mensagem de um paciente chegue ao servidor da LCH sem ser lida nem alterada e que o paciente esteja falando com o site verdadeiro da LCH. Não faz nada quanto a um paciente que digita uma instrução feita para manipular o modelo, ou a um documento de parceiro que carrega texto oculto. Esses problemas estão dentro do canal protegido e exigem controles na aplicação.
7.3 Autenticação de APIs e limitação de taxa
As APIs autenticam quem as chama com chaves ou tokens. Limites de taxa e cotas restringem quanto cada chamador pode usar. Em APIs de IA, os custos crescem com os tokens, então os limites devem contar tokens, e não apenas requisições. O OWASP LLM10 (consumo ilimitado) abrange ataques que esgotam recursos ou orçamentos.
"""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 Lab R mostra o compromisso. A 5 requisições por segundo com rajada de 20, toda requisição normal é atendida e a inundação obtém 319 de 3.000. A 1 por segundo com rajada de 5, a inundação cai para 64, mas o cliente normal perde 28 de suas 90 requisições. Um limite deve ser definido a partir do uso normal medido, e não escolhido apenas para deter ataques.
7.4 Ameaças de IA no nível da rede
Consultas sistemáticas podem copiar um modelo (Tramèr et al., arXiv:1609.02943). Inundações de prompts longos podem esgotar a capacidade. Controles de rede — autenticação, cotas, monitoramento, segmentação e filtragem de saída — reduzem esses riscos e limitam o que um componente comprometido consegue alcançar. A extração exige muitas consultas, então cotas por cliente e monitoramento de padrões incomuns de consulta aumentam seu custo. A filtragem de saída importa se um componente for comprometido: um servidor de inferência que só alcança o provedor do modelo não consegue enviar dados para outro lugar. A segmentação mantém os servidores do chatbot separados do banco de dados de agendamento, exceto pela interface estreita da ferramenta de agendamento.
7.5 Exemplo resolvido (caso sintético da LCH)
O endpoint público de chat do Ask Lumen não tinha limites por sessão. Um teste de carga sintético que enviava prompts longos multiplicou por dez os custos do modelo em uma hora. A LCH acrescentou cotas de tokens por sessão, um tamanho máximo de mensagem e um alerta quando os gastos passam de 150% da mediana diária. Contar tokens em vez de requisições foi a mudança decisiva: alguns poucos prompts muito longos haviam custado mais do que milhares de mensagens normais. O limiar de alerta de 150% da mediana diária pega o abuso em poucas horas e ignora a alta normal das manhãs movimentadas, e o tamanho máximo de mensagem impede que um único prompt consuma uma grande parte do orçamento.
7.6 Erros e limites
Três erros são comuns: acreditar que o TLS resolve ataques no nível da aplicação; limites de requisições que ignoram o custo em tokens; e chaves de API embutidas no código do navegador. O TLS protege o canal, não o conteúdo, então a injeção de prompt e o abuso por usuários conectados passam direto por ele. Limites só de requisições deixam um atacante enviar menos prompts, porém muito mais longos, como mostrou o teste de carga da LCH. Chaves de API no código do navegador podem ser lidas por qualquer pessoa que abra a página, o que permite chamar diretamente o provedor do modelo e contornar por completo as cotas da LCH; as chaves pertencem ao servidor.
7.6b Tempos limite e novas tentativas nas chamadas ao modelo
O Ask Lumen chama o provedor do modelo pela rede, e respostas lentas tentam os engenheiros a repetir chamadas de forma agressiva. Cada nova tentativa reenvia a pergunta do paciente e custa dinheiro; novas tentativas sem limite durante uma indisponibilidade podem multiplicar o tráfego e esgotar o limite de taxa de todas as clínicas. A LCH limita as novas tentativas a duas, com espera crescente, e mostra aos pacientes um número de telefone quando o modelo está indisponível. Uma espera crescente entre tentativas permite que um provedor em dificuldades se recupere em vez de ser inundado. O número de telefone mantém os pacientes atendidos enquanto o chatbot está fora do ar.
Exercícios
- EX019 — TLS. Nomeie duas coisas que o TLS protege e duas que não protege. Rubrica: 3 = confidencialidade/integridade em trânsito, autenticação do servidor vs conteúdo malicioso, injeção/mau uso; 2 = três; 1 = uma ou duas; 0 = nenhuma.
- EX020 — Leitura do laboratório. No laboratório, por que o limite de 1/s com rajada 5 prejudica os usuários normais? Rubrica: 3 = só 62/90 atendidas, porque as rajadas naturais excedem o balde; 2 = só o número; 1 = vago; 0 = errado.
- EX021 — Chaves. Por que chaves de API de modelos não devem aparecer no código do navegador? Rubrica: 3 = qualquer pessoa pode lê-las e usá-las indevidamente, gerando custo e abuso; usar chamadas no servidor; 2 = parcial; 1 = vago; 0 = errado.
Síntese
As redes entregam serviços de IA; TLS, autenticação, cotas que consideram tokens e monitoramento protegem a entrega, mas não o conteúdo, de que tratam os capítulos seguintes.
Continue estudando — capítulo 07 de 40
← Capítulo 06 (rascunho) · Índice de capítulos do curso · Capítulo 08 (rascunho) →