Os Números Que Deveriam Tirar Seu Sono

Vamos começar com um dado que exige atenção imediata: em uma varredura recente de 2.931 bancos de dados MySQL expostos, 2.930 já estavam marcados por operadores de ransomware. Não é uma previsão. Não é um "pode acontecer". É um status confirmado de direcionamento.

O percentual? Gelado: 99,96%.

Se você operava com a ideia de que bancos de dados expostos poderiam passar despercebidos — ficando quietos até alguém tropeçar neles — esses dados destroem essa ilusão. Atacantes não estão esperando. Eles já estão de olho.

O Manual de 2019 Que Ainda Funciona Perfeitamente

Aqui está o ponto perturbador: a estratégia sendo usada não é algum ataque sofisticado de cadeia zero-day. É basicamente a mesma metodologia que circula desde 2019-2020.

Estamos falando de:

• Varredura automatizada por portas expostas de banco (3306, no caso do MySQL)
• Credential stuffing com credenciais padrão ou fracas
• Enumeração de banco para identificar alvos de alto valor
• Exfiltração silenciosa de dados antes da criptografia
• Deploy de ransomware com cronogramas cada vez mais agressivos

As ferramentas amadureceram. A automação melhorou. Mas o ponto de entrada principal? Má configuração. Portas expostas. Ambientes de teste esquecidos conectados à internet pública.

Isso não é reflexo de atores sofisticados de estados-nações. É escaneamento oportunista em escala industrial, executado por grupos que transformaram o comprometimento de bancos de dados em um modelo de negócio eficiente.

Por Que Bancos de Dados Expostos São Frutas ao Alcance de Todos

Você pode estar se perguntando: se isso é tão conhecido, por que os bancos continuam expostos?

A resposta é enganosamente simples:

1. Conveniência do desenvolvedor – Desenvolvimento local frequentemente significa portas abertas para acesso fácil. Às vezes a publicação em produção acontece com essas configurações intactas.

2. Erros de configuração na nuvem – Instâncias em nuvem pública frequentemente iniciam com grupos de segurança em estados permissivos "só para testar".

3. Ambientes de teste esquecidos – Aquele servidor de staging de 2022? Ainda rodando. Ainda exposto.

4. Falta de visibilidade – Times simplesmente não sabem o que está facing a internet.

5. A suposição de obscuridade – "Quem nos atingiria?" A resposta: bots automatizados que não discriminam.

O Que Isso Significa Para Sua Infraestrutura

Se você roda qualquer banco de dados MySQL — seja para sua aplicação, seus relatórios analíticos ou dados de clientes — precisa tratar instâncias expostas como comprometidas, mesmo que não tenha visto evidência de intrusão.

O manual do atacante assume que:

• Bancos de dados são mal monitorados
• Backups podem estar no mesmo sistema comprometido
• Organizações entrarão em pânico e pagarão ao invés de restaurar de backups verificados
• Tempos de detecção e resposta são lentos o bastante para tornar a criptografia vantajosa

Eles não estão errados, em muitos casos.

Ações Imediatas Para Tomar

Audite sua exposição:

• Use ferramentas como Shodan, Censys ou BinaryEdge para verificar se seus IPs aparecem em bancos de dados de varredura da internet
• Revise os security groups e network ACLs do seu provedor de nuvem
• Garanta que nenhuma porta de banco seja acessível a partir de 0.0.0.0/0

Fortaleça a autenticação:

• Exija senhas fortes e únicas para todas as contas de banco
• Implemente allowlisting de IP sempre que possível
• Considere túneis de conexão via VPN ou bastion hosts ao invés de exposição direta

Verifique sua estratégia de backup:

• Backups estão armazenados offline ou em zona de segurança separada?
• Quando foi o último teste de restauração bem-sucedido?
• Você tem capacidade de recovery point-in-time?

Ative logs e monitoramento:

• Logs de auditoria de banco devem capturar tentativas de conexão, queries e ações administrativas
• Configure alertas para padrões de acesso incomuns ou exportação massiva de dados
• Considere soluções de monitoramento de atividade de banco (DAM)

O Quadro Maior: Segurança Como Infraestrutura Fundamental

Isso não é apenas um problema de banco de dados. É um lembrete de que segurança precisa ser tratada como infraestrutura fundamental, não como reflexão tardia.

Na NameOcean, vemos esse padrão repetidamente — startups e desenvolvedores se movendo rápido, shipando features, e inadvertidamente expondo infraestrutura. A pressão para iterar rapidamente é real, mas o custo de um incidente de ransomware ou vazamento de dados supera amplamente as horas de engenharia necessárias para proteger tudo corretamente desde o início.

Seu registrador de domain, seu provedor de hosting, sua configuração de DNS — todos são pontos de entrada que merecem o mesmo escrutínio que você (esperançosamente) aplica à sua camada de banco de dados.

Conclusão: Assuma Que Você Está Sob Observação

Os 2.930 bancos de dados sinalizados não são anomalias. São representativos de uma realidade mais ampla: se seu banco está exposto à internet, já está no radar de alguém.

O manual tem seis anos porque funciona. Não deixe a familiaridade com esses métodos de ataque te adormecer em falsa segurança. Em vez disso, deixe isso motivar ação.

Audite sua exposição. Tranque o acesso. Verifique seus backups. E lembre-se: no cenário de ameaças atual, invisibilidade não é estratégia de segurança.

Fique seguro por aí.

Tem dúvidas sobre como proteger sua infraestrutura de banco de dados ou ambiente de hosting? Deixe nos comentários — estamos aqui para ajudar você a construir de forma segura desde a raiz.