Observabilidade e Gestão de Ciclo de Vida em Defesas

Introdução

Manter uma plataforma de grande escala disponível e responsiva exige a construção de inúmeros mecanismos de defesa. Limites de taxa, controles de tráfego e medidas protetivas distribuídas por múltiplas camadas de infraestrutura são essenciais para a saúde do serviço durante abusos ou ataques. No entanto, esses mesmos sistemas de proteção podem, silenciosamente, superar sua utilidade original e começar a impactar negativamente usuários legítimos. Isso é particularmente verdadeiro para proteções implementadas como respostas emergenciais durante incidentes, onde a rapidez na resposta muitas vezes implica em controles mais amplos, não necessariamente concebidos para o longo prazo. O feedback dos usuários destaca a importância crítica da observabilidade e da gestão de ciclo de vida para defesas, tanto quanto para as funcionalidades principais de uma plataforma.

O Problema Identificado: Bloqueios Indevidos

Recentemente, identificamos que usuários estavam recebendo erros de "too many requests" (muitas requisições) durante uma navegação normal e de baixo volume, como ao seguir um link de outro serviço ou simplesmente navegando sem padrões óbvios de abuso.

• Relatos de Usuários: Clientes legítimos, realizando poucas requisições normais, atingiam limites de taxa que não deveriam se aplicar a eles.
• Causa Raiz: Regras de proteção, adicionadas durante incidentes de abuso passados, permaneceram ativas. Essas regras eram baseadas em padrões fortemente associados a tráfego abusivo no momento de sua criação.
• Desafios dos Sinais Compostos: Infelizmente, esses mesmos padrões acabaram correspondendo a algumas requisições de usuários legítimos deslogados. Utilizamos uma combinação de técnicas de fingerprinting padrão da indústria e lógica de negócios específica da plataforma – sinais compostos para distinguir uso legítimo de abuso. Embora esses sinais fornecessem filtragem, uma pequena porcentagem (0,5-0,9%) das requisições que correspondiam a impressões digitais suspeitas e às regras de lógica de negócios eram bloqueadas 100% do tempo.
• Impacto: O impacto geral foi pequeno, mas consistente. No entanto, para os clientes afetados, qualquer bloqueio incorreto é inaceitável e disruptivo. Esta é uma dificuldade comum na defesa de plataformas em escala: durante incidentes ativos, é preciso reagir rapidamente, aceitando trade-offs para manter o serviço disponível. As mitigações são corretas e necessárias naquele momento, mas esses controles de emergência não envelhecem bem à medida que os padrões de ameaça e as ferramentas e usos legítimos evoluem. Sem manutenção ativa, mitigações temporárias tornam-se permanentes, e seus efeitos colaterais se acumulam silenciosamente.

Rastreador na Pilha: A Complexidade da Investigação

A própria investigação demonstrou por que esses problemas podem persistir. Ao recebermos relatos de erros, rastreamos as requisições através de múltiplas camadas de infraestrutura para identificar onde os bloqueios ocorriam. Nossas infraestruturas de proteção são frequentemente personalizadas e multi-camadas, aproveitando a flexibilidade de projetos open-source como HAProxy, adaptados aos requisitos operacionais e escala.

• Fluxo de Requisições: Cada camada tem razões legítimas para limitar ou bloquear requisições. Durante um incidente, uma proteção pode ser adicionada em qualquer uma dessas camadas, dependendo de onde o abuso pode ser melhor mitigado e quais controles são mais rápidos de implantar.
• O Desafio de Rastrear: Quando uma requisição é bloqueada, rastrear qual camada tomou essa decisão requer a correlação de logs de múltiplos sistemas, cada um com seus próprios esquemas.
• Etapas da Investigação (Trabalhando de trás para frente):
  • Relatos de Usuários: Forneceram timestamps e padrões de comportamento aproximados.
  • Logs da Camada de Borda (Edge tier): Mostraram as requisições chegando à nossa infraestrutura.
  • Logs da Camada de Aplicação (Application tier): Revelaram respostas 429 "Too Many Requests".
  • Análise de Regras de Proteção: Finalmente identificou quais regras correspondiam a essas requisições.

A investigação, partindo de relatos externos até configurações de regras distribuídas, sublinhou que manter uma visibilidade abrangente sobre o que está bloqueando requisições e onde, é essencial.

O Ciclo de Vida das Mitigações de Incidentes

A principal razão pela qual essas proteções se tornaram obsoletas é a falta de gestão de ciclo de vida:

• Cada mitigação era necessária no momento em que foi adicionada.
• Controles que não tiveram uma gestão de ciclo de vida consistente (definir datas de expiração, conduzir revisões de regras pós-incidente ou monitorar o impacto) transformaram-se em dívida técnica que se acumulou até ser percebida pelos usuários.

Nossas Ações e Próximos Passos

Após a identificação do problema, agimos imediatamente e estamos implementando melhorias contínuas.

• Ações Imediatas:
  • Revisamos as mitigações, analisando o que cada uma bloqueava atualmente versus o que pretendia bloquear originalmente.
  • Removemos as regras que não estavam mais servindo ao seu propósito, mantendo as proteções contra ameaças contínuas.
• Melhorias Contínuas no Gerenciamento do Ciclo de Vida:
  • Aprimoramento da visibilidade em todas as camadas de proteção para rastrear a origem dos limites de taxa e bloqueios.
  • Tratamento das mitigações de incidentes como temporárias por padrão. Torná-las permanentes deve exigir uma decisão intencional e documentada.
  • Implementação de práticas pós-incidente que avaliem os controles de emergência e os desenvolvam em soluções sustentáveis e direcionadas.

Mecanismos de defesa – mesmo aqueles implantados rapidamente durante incidentes – precisam do mesmo cuidado que os sistemas que protegem. Eles demandam observabilidade, documentação e manutenção ativa. Quando as proteções são adicionadas durante incidentes e deixadas no lugar, elas se tornam uma dívida técnica que se acumula silenciosamente, podendo comprometer a experiência do usuário e a integridade da plataforma.