Transação em andamento
O pagamento que não completa precisa ser reconciliado depois, com o cliente já sabendo que algo falhou.
DDoS Defense · Serviços financeiros
Proteção DDoS para instituições financeiras
Transação que não completa não é lentidão: é prejuízo com horário registrado.
Mitigação Always-On para operação transacional, com os seus prefixos anunciados pela rede da UPX. O ataque é absorvido antes de chegar ao seu link, sem janela de abrir chamado para começar a filtrar.
Empresas que confiam na UPX
Controles auditados
O risco
O custo não termina com o restabelecimento
A transação interrompida precisa ser reconciliada depois. O incidente entra no registro que a regulação exige. O cliente que tentou pagar e não conseguiu lembra do episódio na próxima vez.
Quando o prefixo fica inacessível, não é o site que sai do ar.
API de parceiro
Quem consome a sua API para liquidar, consultar saldo ou autorizar passa a ver timeout. O incidente vira deles também.
Canal de atendimento
App e internet banking fora do ar levam o volume ao call center, que não foi dimensionado para isso.
Operação interna
O mesmo prefixo carrega VPN, ferramenta de risco e painel de mesa. Quando ele cai, o time também para.
Exposição
As janelas em que a indisponibilidade custa mais
Liquidação, fechamento de mês e pico de Pix concentram o maior custo de indisponibilidade. São as janelas que o desenho da proteção precisa cobrir.
Janela de liquidação e fechamento contábil
Horário de pico de transação instantânea
Datas de vencimento concentrado (folha, boleto, tributo)
Nas três janelas a mitigação já está ativa: o tráfego entra pela rede da UPX e a filtragem parte da detecção, sem acionamento.
A proteção, traduzida para a sua operação.
A oferta técnica é a mesma do resto do pilar. O que muda é o que ela significa aqui.
O volume não chega ao seu link
O ataque é absorvido na rede da UPX, em Equinix SP2 e Ascenty SP3. O seu circuito recebe o tráfego já filtrado.
Sem blackhole do prefixo
Mitigação sem autorização
Evidência do incidente
Como funciona
Quatro etapas, nenhuma dentro da sua rede.
A ativação é por anúncio BGP: sem hardware no seu rack, sem agente na aplicação e sem redesenho de rede. Você continua dono dos prefixos e da política de roteamento.
01
Anúncio BGP
Os seus prefixos passam a ser anunciados pela rede da UPX.
02
Desvio do tráfego
Todo o tráfego de entrada dos prefixos passa pela rede da UPX.
03
Filtragem
O ataque é filtrado na rede da UPX, antes de consumir o seu link.
04
Tráfego filtrado
O tráfego filtrado é devolvido à sua infraestrutura.
Conformidade e evidência
Disponibilidade é requisito, não só expectativa
A regulação trata a continuidade do serviço financeiro como obrigação, com registro de incidente e plano de resposta. Proteção de disponibilidade é um dos insumos desse plano.
Continuidade operacional
O plano precisa cobrir indisponibilidade de canal digital, com mecanismo de mitigação declarado, e não só procedimento de resposta.
Registro e evidência do incidente
O relatório por campanha documenta início, fim, pico, vetores e volume, com o ticket correspondente.
Quem atende durante o incidente
O contato é direto com a engenharia que opera a rede, inclusive por WhatsApp, sem camada de triagem.
Dado em trânsito
A mitigação é de rede e transporte: não há terminação de TLS nem inspeção de payload. A sua chave privada não sai do seu lado.
Começar
Fale com a engenharia
A engenharia que opera a rede responde com o handoff recomendado e a proposta para a sua operação.
Está sofrendo um ataque DDoS?
Se sua operação está sob ataque, fale diretamente com nossa equipe para solicitar atendimento emergencial.
Solicitar atendimento emergencialPerguntas frequentes
Dúvidas de quem opera neste segmento.
A mitigação interfere no TLS das minhas transações?
Não. O escopo é rede e transporte (L3 e L4), sem terminação de TLS e sem inspeção de payload. A sessão criptografada segue entre o seu cliente e a sua infraestrutura, e a sua chave privada não sai do seu lado.Minha API de parceiro fica coberta?
Fica, se estiver atrás do prefixo anunciado. A proteção é por rede: tudo dentro do bloco /24 está coberto, incluindo API de parceiro, homologação e endpoint não divulgado.O que recebo para registrar o incidente internamente?
Um relatório da campanha com início, fim, pico, vetores identificados e volume absorvido, e um ticket pelos canais combinados. Ele é gerado automaticamente ao fim do ataque, sem você solicitar.Em quanto tempo a mitigação começa?
A mitigação é automática a partir da detecção: não há janela de abrir chamado nem autorização por vetor. Em Always-On não existe acionamento no momento do ataque, porque o tráfego já entra pela rede de mitigação. Em Sob Demanda, soma-se o acionamento e o tempo de convergência do BGP.Always-On ou Sob Demanda: qual escolher?
Always-On mantém os seus prefixos sempre anunciados pela UPX, sem acionamento no momento do ataque — é o indicado para operação financeira e transacional e para ambientes em data center. Sob Demanda anuncia só durante o ataque, por ação sua ou por gatilho combinado: custa menos, mas a reação depende do acionamento e da convergência BGP. Hoje a detecção na borda do seu ambiente não é o nosso ponto mais forte; se o seu cenário depende de gatilho automático a partir dela, fale com a engenharia antes de fechar o modo.A proteção cobre ataque na camada de aplicação?
Não. O escopo é rede e transporte (L3 e L4), com mitigação específica por vetor. HTTP flood, abuso de API por credencial válida, injeção e bot de scraping são tratados por WAF e por bot management, que são produtos separados. As duas camadas se complementam: sem mitigação de rede o WAF nunca recebe a requisição, porque o link saturou antes.O volume do ataque gera cobrança?
Não. A banda suja absorvida pela rede da UPX não é tarifada nem limitada por contrato. A fatura não muda com o tamanho da campanha.
Outros segmentos
A mesma proteção, em outra operação
DDoS Defense
Comece por um /24 real.
Escolha um bloco com pico conhecido. A UPX ativa por GRE, faz o teste de desvio com o seu time na plataforma e entrega o primeiro relatório.