A computação em nuvem está transformando a maneira como as empresas desenvolvem aplicativos, oferecendo escalabilidade rápida e novas possibilidades de armazenamentos e análise de dados. No entanto, essa flexibilidade traz desafios significativos no gerenciamento dos custos.
Quando há um aumento repentino nas solicitações de acesso no seu ambiente, seus recursos utilizarão da escalabilidade automaticamente para atender à demanda. Se o ambiente não estiver bem arquitetado, isso pode levar à interrupção dos serviços que você gerencia e a um aumento na fatura no final do mês quando os serviços são gerenciados pela AWS.
Para lidar com essa questão, muitas empresas utilizam ferramentas como as práticas recomendadas da AWS Well-Architected para revisar seus ambientes, controlam os custos por meio de ferramentas de observabilidade como o AWS Cost Explorer, criam orçamentos diários e mensais com o AWS Budgets e contam com a calculadora de preços da AWS para estimar os custos e auxiliar no planejamento financeiro.
Agora em caso de um ataques de negação de serviço distribuídos (DDoS), os custos podem aumentar significativamente devido à escalabilidade automática dos recursos em resposta à demanda.
Para mitigar esse risco, a AWS disponibiliza os serviços como o AWS Shield e o AWS WAF para prover medidas de segurança robustas. Além disto, o AWS Auto Scaling Group possui configurações mínimas, desejadas e máximas, para não permitir a escalabilidade horizontal, além daquela arquitetada.
Ataque de Negação de Carteira (DoW)
O ataque de negação de carteira (Denial of Wallet; DoW) é um exemplo inédito de possível ameaça aos recursos em nuvem, onde os custos estimados diferem drasticamente dos custos reais.
Este ataque envolve a manipulação dos custos de saída (transferência para a Internet), de um serviço na nuvem (exemplo, Amazon S3), com um número reduzido de solicitações especiais, resultando em custos muito maiores do que os dados que foram realmente transferidos.
“Em cenários de “Ataque de negação de carteira” (DoW), o atacante não visa o serviço em si, mas sim a carteira do usuário, através da transferência indevida de grande quantidade dados para a Internet”
Quando se trata de transferência de dados de saída no Amazon S3, é importante notar que essa quantidade pode diferir dos dados recebidos pelo seu aplicativo, especialmente se a conexão for encerrada prematuramente.
Por exemplo, se você solicitar um objeto de 10 GB e encerrar a conexão após receber os primeiros 2 GB de dados, o Amazon S3 tentará interromper o streaming de dados, mas isso pode não acontecer instantaneamente.
Nesse caso, a saída de transferência de dados pode ser de 3 GB (1 GB a mais do que os 2 GB recebidos). Consequentemente, você será cobrado por 3 GB de transferência de dados.
Entendendo a extensão do problema
A extensão do problema é ainda mais preocupante: De acordo com Ben Liesfeld, em seu artigo no blog.limbus-medtec.com, ao replicar uma situação em que apenas 300 MB de dados foram baixados do Amazon S3 em 30 segundos, a AWS o cobrou por mais de 6 GB.
Se um invasor conseguir induzir custos de 6 GB em apenas 30 segundos, imagine os custos gerados ao longo de um dia ou durante o fim de semana, ao executar múltiplos threads em paralelo.
É importante notar que o Amazon S3 é altamente disponível, e em cenários do mundo real, é improvável que você atinja limites de largura de banda.
Essa situação é alarmante para qualquer pessoa que hospede arquivos grandes em um bucket S3 público, já que os custos de saída podem disparar rapidamente nessas circunstâncias.
Porém, há uma boa notícia: esse comportamento foi observado apenas para arquivos grandes(>1 GB), quando os clientes de software os baixam por meio de solicitações HTTP(S) RANGE.
Com essas solicitações, o cliente pode solicitar a recuperação de parte de um arquivo, sem baixar o arquivo inteiro.
Ao cancelar rapidamente essas solicitações, um cliente pode solicitar partes de um arquivo sem realmente baixar todos os dados.
Infelizmente, devido à maneira como a AWS calcula os custos de saída, a transferência de todo o intervalo de bytes é cobrada, mesmo que as solicitações sejam canceladas antes do envio dos dados.
Essa vulnerabilidade pode resultar em custos significativos e deve ser levada muito a sério por qualquer pessoa ou empresa, que utilizam o Amazon S3 para armazenamento de grandes objetos.
Existem algumas soluções alternativas para mitigar o ataque:
- Criar alertas de custos: O primeiro passo é configurar alertas de custos. Recomenda-se ativar o AWS Cost Anomaly Detection, que alerta sobre eventos de cobrança anormais. Essa ferramenta pode lhe ajudar a identificar rapidamente o evento adverso e limitar o impacto financeiro.
- Monitorar solicitações de API HTTP: Você pode monitorar as solicitações de API HTTP para seus buckets S3. Embora haja um atraso de algumas horas, isso pode ajudar a identificar uma quantidade incomum de solicitações, permitindo que você tome medidas para proibir o acesso ao recurso, se necessário. No entanto, essa solução pode ser um último recurso drástico e pode interromper temporariamente o serviço.
Considerações finais
Prevenir completamente esse tipo de ataque não é fácil devido ao design do Amazon S3, que prioriza o desempenho e a escalabilidade. Mesmo que você não esteja hospedando objetos no Amazon S3 publicamente, ainda há riscos, pois é possível observar comportamento semelhante ao disponibilizar arquivos por meio de URLs pré-assinados.
Portanto, é importante estar vigilante, acompanhar os custos e implementar medidas de segurança adequadas, mesmo em cenários aparentemente seguros.
