Algumas das principais preocupações dos nossos clientes ao descobrirem que o cside opera como um proxy são: "o que acontece se o cside cair?" ou "vai adicionar latência?"
A verdade é que projetamos nossos produtos para diferentes níveis de "dias ruins". Em um incidente de indisponibilidade global, a abordagem mais simples é a mais adequada. Ao sair do caminho, garantimos que nossa queda não se torne a sua queda. Neste post, vamos detalhar como construir um serviço de runtime para maximizar o uptime do cliente.
TLDR:
- Geralmente deixamos os sites mais rápidos. Isso depende dos seus scripts e de quantos podem ser armazenados em cache. O cside pode ser implementado sem adicionar latência, dependendo da implementação híbrida. Operamos em muitas regiões diferentes — esse número muda o tempo todo, mas pelo menos 9 localizações geográficas distintas é o padrão. Fazer o proxy próximo ao usuário reduz diretamente a latência potencial, e ter múltiplas localizações nos permite rotear o tráfego ponto a ponto por rotas mais rápidas, em vez das rotas BGP padrão.
- Se o cside enfrentar um incidente, há múltiplos mecanismos de proteção em vigor. Incidentes raramente resultam em impacto para o cliente, muito menos em indisponibilidade real do serviço de runtime.
- Se o cside cair, interrompemos o script que roteia seu tráfego por nós. Ao remover o cside do fluxo de tráfego, não haveria nenhum impacto no site do cliente. Imagine essa arquitetura como um interruptor de segurança virtual.
Quais soluções o cside oferece?
O cside oferece 3 abordagens para segurança de dependências client-side:
- Modo Direct - Mais fácil e bastante seguro
Caso de uso: Me preocupo com segurança client-side, preciso de algo fácil de explicar para o restante do time e estou disposto a fazer algumas concessões para não gerar confusão organizacional.
Modelo de operação: permitir que o script seja servido diretamente por fontes de terceiros em que confio; scripts nos quais não confio recebem o tratamento de segurança completo. Scripts próprios são verificados no lado do cliente e buscados pelo cside.
Prós: Mais fácil de implementar — basta adicionar um script. (quase) Sem impacto de desempenho — encapsular JS no navegador pode adicionar uma quantidade insignificante de latência (milissegundos de um único dígito). Capacidade de interromper ações de scripts ou bloqueá-los por URL, hash ou domínio.
Contras: Nem sempre é garantido verificar o mesmo payload de script que o usuário recebeu — mas é próximo. Sem ganhos de desempenho em scripts estáticos ou otimizáveis. As ações no navegador ficam basicamente expostas, mesmo quando fortemente ofuscadas.
Implementação: Adicione nosso script ao seu site.
Você ainda pode colocar o cside entre scripts não confiáveis e o usuário final.
- Modo Gatekeeper - Mais seguro
Caso de uso: Sou um alvo de alto valor e preciso de controle total de segurança.
Modelo de operação: todos os scripts de terceiros passam pelo cside, exceto os que eu selecionei; scripts próprios são verificados no lado do cliente e buscados pelo cside.
Prós: Visibilidade total. Controle total. Aumento de desempenho em alguns scripts. Sabemos que o que o usuário recebeu é o que verificamos. Não precisamos lidar com as limitações dos navegadores — temos controle sobre a entrega do script e visibilidade forense completa.
Contras: A palavra "proxy" vem à mente e gera preocupação nas pessoas, mas explicaremos abaixo por que, neste caso, não deveria ser motivo de preocupação. Em scripts altamente dinâmicos, pode haver adição de latência. Scripts estáticos geralmente são entregues mais rapidamente.
Implementação: Adicione nosso script ao seu site. Sinalize os scripts em que você confia e que não precisam ser servidos pelo cside. Por padrão, não fazemos o gatekeeping de alguns scripts incompatíveis com a entrega por uma URL diferente. Modelo de operação: todos os scripts passam pelo cside, exceto alguns.
- Modo Scan - Mais rápido
Caso de uso: Não tenho como adicionar um script ao site.
Modelo de operação: Preciso manter um olho, não consigo realmente adicionar nada ao site, então a observabilidade é um bom começo.
Prós: Baixo custo. Configuração rápida e fácil. Inteligência de ameaças do cside coletada por milhares de outros sites com bilhões de visitantes combinados.
Contras: Ataques client-side são dinâmicos; um scan estático é, por design, menos propenso a detectar um ataque. Um ataque altamente direcionado pode conseguir evitar a detecção.
Por que abordamos dessa forma
O time do cside atua em segurança client-side há algum tempo, em diferentes fornecedores.
Entendemos as limitações e contribuímos ativamente com organismos de padronização como o W3C para ajudar a tornar a segurança client-side tecnicamente viável.
Detecções client-side são fáceis de fazer engenharia reversa e contornar por especificação. Navegadores, ao contrário da maioria dos sistemas operacionais, não permitem que fornecedores de segurança tenham mais controle ou prioridade. O que um script de segurança client-side essencialmente faz é encapsular APIs que podem ser usadas por agentes maliciosos e monitorar quais scripts as utilizam. Infelizmente, detecções client-side muito rígidas podem quebrar algumas bibliotecas client-side. O problema é que nem todo script funciona bem com APIs encapsuladas.
Ao combinar as detecções no navegador com detecções em nosso próprio motor, criamos um cenário equilibrado que aproveita o melhor de todos os mundos. Equilibramos capacidade de detecção com facilidade de uso e resiliência, dando ao cliente a capacidade de escolher a abordagem.
Por que o cside é diferente dos serviços de 'proxy' tradicionais
Quando a maioria das pessoas pensa em proxy, imediatamente pensa em Cloudflare, Akamai, Fastly, etc. Embora esses sejam excelentes para CDN de uso geral e proteção contra DDoS, o cside.com representa uma abordagem fundamentalmente diferente.
Em vez de fazer proxy de tráfego HTTP como proxies e firewalls tradicionais, fazemos o gatekeeping dos componentes baseados em navegador e dos JavaScripts que o usuário final carregaria no seu navegador a partir da internet pública ao visitar seu site ou aplicação web. Isso permite visibilidade completa dos scripts, ver o que o usuário final vê e bloquear qualquer tentativa maliciosa de roubar ou coletar PII, dados de cartão de crédito e IDs de carteiras de criptomoedas. Proxies tradicionais geralmente operam com um princípio de tudo ou nada. Isso cria um único ponto de falha e flexibilidade operacional limitada. A abordagem híbrida do cside muda completamente o jogo ao permitir proxy seletivo e controle script por script, proxy completo ou modo somente captura. Além disso, operamos com um design fail-open para nunca afetar seu site, páginas de pagamento ou checkouts em caso de incidente.
O tipo de incidente importa
Há uma série de possíveis causas de interrupção:
- Mudanças de código
- Carga substancial inesperada
- Indisponibilidade de provedores upstream
Para cada uma, temos um runbook.
Para cada uma, temos medidas preventivas.
Para cada uma, temos redundância.
Não estamos assumindo nenhum risco.
Prevenindo indisponibilidades causadas por mudanças de código
Como a maioria das empresas de nível enterprise, temos um processo de testes rigoroso e testamos nosso código sob pressão antes de chegar à produção.
Além disso, temos ambientes de "desenvolvimento" e "staging" onde testamos nossas mudanças minuciosamente antes mesmo de chegarem à produção. Nosso ambiente de staging é um espelho completo da produção — motor de gatekeeping e tudo mais — então cada atualização é testada na mesma configuração que nossos usuários utilizam. Dessa forma, garantimos que o proxy esteja totalmente funcional após cada mudança.
Nosso motor roda em uma configuração totalmente distribuída em múltiplas regiões, então os usuários acessam a instância mais próxima deles. Quando estamos prontos para ir para produção, fazemos rollouts graduais pelas nossas regiões. O novo código é implantado em uma região primeiro e progressivamente expandido para as demais. No improvável evento de uma mudança de código problemática chegar a esse ponto, ela fica contida e é detectada cedo nessa primeira região antes que o rollout continue globalmente.
Algo está errado, e agora? Redundância por protocolo.
Por design, o cside é um proxy híbrido. Isso significa que podemos ser implementados para fazer proxy de alguns, todos ou a maioria dos scripts, exceto aqueles que explicitamente não fazemos proxy. E isso é completamente configurável pelos nossos clientes.
Por padrão, não fazemos proxy de scripts próprios e de scripts específicos que impedem o proxy por design. Isso não significa que os estamos ignorando. Apenas os tratamos de forma um pouco diferente. Eles ainda passam pelo nosso pipeline para serem analisados, ainda buscamos seu conteúdo mesmo que o proxy não os esteja servindo e ainda podemos notificar nossos clientes se algo parecer suspeito.
E para casos em que um script é realmente sensível e os clientes não querem que ele passe pelo proxy de forma alguma, ele pode ser completamente excluído.
Essa flexibilidade é muito valiosa para nós, pois nos dá opções para ajustar rapidamente nossos comportamentos no site do cliente. Quando ocorre um incidente ou precisamos depurar rapidamente, temos opções para limitar o impacto imediatamente.
Por exemplo: se o proxy tivesse alguma indisponibilidade, poderíamos imediatamente parar de servir os scripts por um dos mecanismos mencionados acima, para evitar que as páginas quebrem. Alguns desses controles também estão disponíveis no dashboard para que os clientes os configurem por conta própria.
Geralmente, quando algo começa a dar errado, um dos nossos serviços internos não públicos mostra indicadores de um problema antes que ele se torne crítico. Nesse ponto, nosso sistema de alertas de incidentes entra em ação. O time do cside opera uma rotação de plantão global 24/7, com escalonamentos para especialistas no assunto. Estamos planejando publicar um post sobre nossos processos de gerenciamento de incidentes em breve — fique ligado!
Além disso, construímos serviços secundários de backup prontos no nosso back-end para manter qualquer serviço com alta disponibilidade e cobrir até cenários de desastre. Por exemplo, no caso do proxy, se o proxy primário não conseguisse lidar com a carga por causa de um pico de tráfego inesperado, um serviço secundário está pronto para assumir.
Em um futuro próximo, o cside planeja usar IPs anycast para balancear a carga automaticamente para um local alternativo por protocolo. Isso é mais do que um fator de redundância — é também uma decisão de design que aumenta o desempenho.
O cside caiu, o que acontece agora?
Boa notícia: isso nunca aconteceu. Se acontecer algum dia, significaria que toda uma cadeia de mecanismos de proteção falhou. Ainda assim, estamos preparados.
Veja como funciona. Caso nosso proxy caia, nosso script client-side não rotearia o tráfego para o cside. Em outras palavras, seu site simplesmente continua sem nós. Parece simples, né? É por design. Em um incidente de indisponibilidade global, a abordagem mais simples é a mais adequada. Ao sair do caminho, garantimos que nossa queda não se torne a sua queda.
O único tráfego com o qual precisamos nos preocupar nesse ponto são os scripts prefixados no lado do servidor. Esses também estão cobertos. Lidamos com eles por meio de um proxy de fallback que redireciona os scripts para sua fonte original. Isso é muito menos pesado computacionalmente e essa infraestrutura roda em um serviço de terceiros infinitamente escalável.
O resultado: nenhum impacto no uptime do cliente. A única concessão é que, durante esse incidente, não teríamos visibilidade pelo nosso serviço de proxy.
Dito isso, um evento repentino de indisponibilidade global é bastante raro e extremamente improvável.
Geralmente, vemos sinais de alerta com bastante antecedência, então temos tempo suficiente para reagir.
Os clientes sempre estarão acessíveis!
Criamos o cside porque sabíamos que todos os outros métodos existentes no mercado davam uma falsa sensação de segurança e não tinham a visibilidade necessária para proteger seus clientes. Ter que construir e manter um proxy distribuído e rápido não é uma tarefa pequena. Conhecíamos os riscos e nos comprometemos a enfrentá-los. Também é importante destacar que os scripts de terceiros client-side hoje geralmente não são monitorados, inclusive em relação a SLAs de uptime. Encontramos URLs desatualizadas em sites ativos a cada hora. Isso é muito comum. Vamos te dar visibilidade e garantias que você não tinha antes. Uptime importa e você não tem visibilidade de uptime sobre dependências de terceiros client-side hoje — mas se você usar o cside, isso vai mudar.
Por design, garantimos evitar qualquer ponto único de falha e usamos mecanismos de proteção simples e de baixa complexidade. O método de proteção de baixa complexidade costuma ser o mais confiável em um incidente.
