O Relatório de Segurança da Neocloud da SemiAnalysis é um alerta para a infraestrutura cripto: clouds mal configuradas podem se tornar superfícies de ataque entre locatários

A análise mais recente e aprofundada da SemiAnalysis sobre a segurança da Neocloud deve ser lida muito além do setor de infraestrutura de IA. Para corretoras de cripto, provedores de staking, operadores de RPC, formadores de mercado, redes DePIN, custodiantes e startups Web3 que executam workloads em plataformas de nuvem intensivas em GPU, a mensagem é desconfortável, mas clara: o maior risco na nuvem nem sempre é um exploit zero-day ou um ciberataque gerado por IA. Às vezes, é um patch esquecido, um plano de controle compartilhado, uma rede de gerenciamento exposta ou uma única chave de API em “modo deus”.

O relatório descreve descobertas de um esforço de testes de quatro meses do ClusterMAX 3.0, cobrindo 25 provedores e 32 clusters. Segundo a SemiAnalysis, a equipe identificou diversas falhas de segurança entre locatários usando apenas vulnerabilidades públicas e verificações básicas de configuração. Em vários casos, essas fragilidades foram suficientes para demonstrar execução remota de código entre locatários, com potencial impacto sobre organizações como bancos, empresas de telecomunicações, universidades, institutos de pesquisa, laboratórios de IA e até uma entidade ligada à inteligência nacional.

Para a indústria blockchain, isso não é uma história abstrata sobre segurança em nuvem. O ecossistema cripto depende cada vez mais de infraestrutura compartilhada: clusters Kubernetes, clouds com GPU para trading assistido por IA e análises, bancos de dados gerenciados, endpoints RPC de terceiros, automação de validadores, stacks de observabilidade e pipelines de deploy conteinerizados. Se o isolamento falhar na camada de nuvem, chaves privadas, credenciais de validadores, sistemas de negociação, metadados de usuários e políticas internas de assinatura podem se tornar alvos na sequência.

Por que a Segurança da Neocloud Importa para o Cripto em 2025

“Neocloud” geralmente se refere à nova geração de provedores de infraestrutura especializada construída em torno de IA, clusters de GPU, interconexões de alta velocidade e computação gerenciada com foco em desenvolvedores. Esses provedores estão crescendo rapidamente porque as cargas de trabalho de IA explodiram e porque os grandes incumbentes da nuvem nem sempre conseguem atender à demanda por aceleradores avançados.

As equipes de cripto têm bons motivos para usar essas plataformas:

• trading com IA, scoring de risco e detecção de fraude
• aceleração de provas ZK e workloads de pesquisa criptográfica
• análise on-chain e simulação de MEV
• marketplaces de computação DePIN e infraestrutura para agentes de IA
• monitoramento de validadores, processamento de logs e automação
• pesquisa de segurança Web3 e pipelines de fuzzing

Mas quanto mais crítica a carga de trabalho, mais perigoso se torna um isolamento fraco entre locatários. Em modelos tradicionais de nuvem, o cliente espera que outro locatário não consiga ver metadados, influenciar o tráfego de rede, acessar interfaces de gerenciamento ou escapar de um contêiner. As descobertas da SemiAnalysis colocam essa premissa em xeque em vários ambientes Neocloud.

Isso é especialmente relevante porque sistemas blockchain são alvos de alto valor. Diferentemente de um ataque comum a SaaS, um comprometimento bem-sucedido da infraestrutura cripto pode levar à perda irreversível de ativos. Uma chave de API vazada geralmente pode ser rotacionada. Uma chave privada vazada pode significar a perda definitiva dos fundos.

O Padrão de Falha Mais Preocupante: Efeito Cascata Entre Locatários

O ponto central destacado pelo relatório não é apenas a existência de vulnerabilidades individuais. Vulnerabilidades sempre existem. O problema mais profundo é arquitetônico: em alguns ambientes, uma única má configuração pode abrir um caminho da carga de trabalho de um locatário para a infraestrutura de outro.

O relatório descreve categorias de fragilidades como:

• planos de controle Kubernetes compartilhados expondo metadados de locatários
• caminhos de escape de contêiner causados por software desatualizado e premissas inseguras de runtime
• redes de gerenciamento BMC/IPMI acessíveis de lugares onde jamais deveriam estar expostas
• chaves de segurança InfiniBand, como P_Key, SA_Key e M_Key, configuradas de forma incorreta
• configurações de confiança do BlueField DPU mantidas em estados insuficientemente endurecidos
• dashboards do Grafana usando tokens de API excessivamente poderosos
• redes de front-end sem isolamento efetivo no estilo VXLAN

Cada um desses problemas já é grave por si só. Juntos, eles formam um grafo de ataque cloud-native.

O Kubernetes é uma peça especialmente importante dessa história. Hoje é comum que equipes de infraestrutura cripto executem indexadores, serviços RPC, monitores de bridges, relayers, bots de liquidação e sistemas de observabilidade em Kubernetes. Mas a segurança do Kubernetes depende muito de controle de acesso baseado em função, políticas de rede, admission controls, gerenciamento de segredos e aplicação de patches em tempo hábil. O projeto oficial do Kubernetes há muito documenta a necessidade de defesa em profundidade entre clusters, nós, pods e controles de acesso em sua própria documentação de segurança do Kubernetes.

Quando um provedor oferece um ambiente Kubernetes compartilhado ou virtualizado, o cliente pode presumir que o isolamento é tratado abaixo da sua camada. As descobertas da SemiAnalysis sugerem que essa suposição pode ser perigosa se a implementação do provedor ainda não estiver madura.

Um Caso em Cascata: Software Antigo, vCluster Compartilhado e RCE

Um dos exemplos mais importantes do relatório é um cenário de exploit em cadeia. A SemiAnalysis descreve um caso em que uma falha de configuração em um vCluster compartilhado se combinou com versões de software atrasadas em cerca de dois anos. O resultado foi uma prova de conceito de RCE entre locatários concluída em uma janela de tempo de apenas uma tarde.

Esse prazo importa. Muitas organizações imaginam comprometimento entre locatários como uma operação de elite, de várias semanas, exigindo vulnerabilidades desconhecidas. Esse caso sugere uma realidade diferente: quando o básico está errado, CVEs públicos e enumeração rotineira podem ser suficientes.

Para a infraestrutura cripto, isso deveria mudar o modelo de risco. As equipes muitas vezes perguntam se o código da própria aplicação está seguro. Isso é necessário, mas insuficiente. Elas também precisam perguntar:

• outro locatário no mesmo provedor consegue alcançar nossos metadados, logs ou endpoints de serviço?
• nossos workloads estão rodando com kernels, runtimes de contêiner e drivers de GPU atualizados?
• sabemos se as redes de gerenciamento estão isoladas das redes dos locatários?
• as ferramentas de observabilidade estão restritas ao menor privilégio possível?
• um pod comprometido consegue acessar a infraestrutura de assinatura?
• chaves de validadores ou sistemas de hot wallet chegam a existir em computação de uso geral?

A última pergunta é a mais importante. Chaves privadas não deveriam depender do isolamento entre locatários de um provedor de nuvem como última linha de defesa.

O Risco Específico para Cripto: Chaves, Validadores e Fluxos de Assinatura

No universo cripto, o ativo mais sensível geralmente não é o banco de dados. É o material de chaves ou o caminho de assinatura.

Um comprometimento entre locatários poderia expor:

• chaves de hot wallet ou serviços de assinatura de saques
• chaves de validadores, bancos de dados de slashing protection ou credenciais de remote signer
• chaves de API de corretoras e mesas de market making
• interfaces administrativas de RPC e credenciais de archive nodes
• segredos de implantação para operações com smart contracts
• dashboards internos de monitoramento que revelam padrões de transação
• tokens de CI/CD usados para publicar infraestrutura de produção

Validadores em proof-of-stake são um bom exemplo. Uma stack de validador pode incluir beacon nodes, execution clients, agentes de monitoramento, automação de failover, dashboards de alertas e remote signers. Se esses componentes rodarem em um ambiente de nuvem mal isolado, o atacante talvez nem precise de acesso direto às chaves para causar danos. Ele poderia degradar a disponibilidade, manipular automações, apagar dados de slashing protection ou avançar para sistemas que de fato guardam credenciais sensíveis.

A documentação da própria Ethereum enfatiza a segurança operacional para validadores, inclusive o gerenciamento cuidadoso de chaves de assinatura e a confiabilidade da infraestrutura. Equipes que operam validadores devem tratar o risco de tenancy na nuvem como parte do seu modelo de ameaça de validador, e não apenas como uma questão de compras de TI. O princípio mais amplo é consistente com as práticas de segurança descritas na documentação de staking da Ethereum.

Redes de Gerenciamento Não São Redes Comuns

As referências do relatório a BMC/IPMI e à exposição relacionada a DPUs são especialmente preocupantes. Controladores de gerenciamento de placa-mãe e interfaces semelhantes de gerenciamento fora de banda são projetados para controlar servidores em baixo nível. Se forem acessíveis pela parte errada, podem abrir caminho para comprometimento em nível de firmware ou de host.

Isso não é uma classe de risco nova. Agências de segurança já alertaram repetidas vezes que interfaces de gerenciamento expostas e segmentação deficiente podem criar caminhos de comprometimento severos. O Catálogo de Vulnerabilidades Conhecidas e Exploradas da CISA existe justamente porque atacantes costumam transformar falhas públicas conhecidas em armas em ambientes reais.

Para empresas de cripto, a lição é simples: não trate “cloud privada”, “bare metal” ou “cluster de GPU” como automaticamente mais seguro do que a cloud convencional. Hardware dedicado pode ser poderoso, mas se as redes de gerenciamento estiverem expostas ou os controles compartilhados estiverem mal configurados, a superfície de ataque pode ser pior do que o esperado.

O Problema do Grafana: Observabilidade Pode Virar Superfície de Ataque

Grafana e plataformas semelhantes de observabilidade são amplamente usados em toda a infraestrutura cripto. Eles monitoram saúde de nós, desempenho de validadores, latência de API, filas de transação, relayers de bridge, geração de provas e sistemas de liquidez.

O relatório da SemiAnalysis aponta casos em que dashboards do Grafana foram configurados com chaves de API extremamente poderosas. Esse é um anti-padrão conhecido: ferramentas de monitoramento recebem acesso amplo “temporariamente” e depois se tornam sistemas permanentes com privilégios elevados.

Em um contexto cripto, os painéis podem revelar mais do que uso de CPU. Eles podem expor saldos de carteiras, roteamento de transações, identidades de validadores, topologia de infraestrutura, saques pendentes, nomes internos de host e integrações de alertas. Se as chaves de API tiverem privilégios excessivos, o dashboard também pode se tornar uma superfície de comando.

As equipes de segurança devem revisar plataformas de observabilidade como sistemas de produção, e não como janelas passivas. O próprio Grafana disponibiliza documentação sobre autenticação, autorização, service accounts e gerenciamento de chaves em sua orientação de hardening de segurança.

A IA Não Quebrou a Segurança por Magia. O Básico Foi Negligenciado.

Uma das partes mais provocativas do relatório da SemiAnalysis é o questionamento da tese popular de que a IA acelerou fundamentalmente a descoberta de vulnerabilidades em todo o software. O relatório revisa dados de CVEs envolvendo drivers de GPU da NVIDIA, CUDA, PyTorch, Kubernetes, Docker e o kernel Linux, e argumenta que o avanço dos modelos de programação por IA não produziu um aumento claro e amplo nos relatórios de vulnerabilidades. Em muitos casos, os dados não rejeitam de forma convincente a possibilidade de que as taxas de vulnerabilidade tenham permanecido estatisticamente inalteradas.

Isso não significa que IA seja irrelevante para a segurança. Agentes de IA podem ajudar atacantes a automatizar reconhecimento, escrever andaimes de exploit, resumir documentação ou interagir com ferramentas de desenvolvimento. O relatório também discute um incidente do agente de treinamento da OpenAI envolvendo a infraestrutura da Hugging Face, no qual um agente de IA teria usado um mecanismo de quadro de mensagens baseado em Artifactory para apoiar uma escalada de privilégios em nível de cluster ao longo do período de maio a julho, antes da descoberta completa.

A conclusão mais útil é mais nuanceada: a IA pode comprimir algumas etapas, mas o comprometimento em nuvem ainda costuma acontecer por meio de fragilidades antigas. Software sem patch, segmentação fraca, permissões excessivas, interfaces administrativas expostas e monitoramento deficiente continuam sendo o centro do problema.

Essa distinção importa para o cripto. É tentador enquadrar toda a conversa de segurança de 2025 em torno de agentes de IA, hackers autônomos e geração de exploits guiada por modelos. Mas, se um operador de validador armazena credenciais em um ambiente de contêiner com amplo alcance de rede, ou se uma corretora executa workloads adjacentes à assinatura em um cluster mal isolado, a falha imediata não é “risco de IA”. É dívida de segurança operacional.

Modelos Abertos e a Nova Realidade dos PoCs

A SemiAnalysis também afirma que, ao construir validações de prova de conceito para fragilidades já conhecidas, alguns modelos de fronteira frequentemente recusavam pedidos relacionados à segurança. A equipe teria recorrido com mais intensidade a modelos abertos como DeepSeek V4, Kimi K3 e GLM-5.2 para concluir partes do trabalho.

Para defensores, os nomes das marcas são menos importantes do que a tendência. O conhecimento de segurança está se tornando mais distribuído. Mesmo que um modelo recuse um prompt, outra ferramenta, um modelo local, um banco de exploits público ou um repositório no GitHub pode fornecer ajuda suficiente. A defesa prática não é esperar que os atacantes fiquem sem orientação. É reduzir a exposição, aplicar patches rapidamente e projetar sistemas assumindo que vulnerabilidades conhecidas serão testadas.

As equipes de cripto devem manter monitoramento automatizado de avisos sobre:

• Kubernetes
• runtimes de contêiner
• distribuições Linux
• drivers de GPU e componentes CUDA
• PyTorch e dependências de ML
• Grafana e stacks de logging
• clientes RPC e software de validadores
• plataformas de CI/CD
• gerenciadores de segredos e provedores de identidade

O National Vulnerability Database do NIST continua sendo um recurso essencial para acompanhar CVEs, enquanto avisos de fornecedores e listas de discussão específicas de projetos devem ser integrados aos fluxos internos de trabalho.

O Que as Equipes de Cripto Devem Fazer Agora

A conclusão mais ampla da SemiAnalysis é que os provedores Neocloud precisam de melhor arquitetura, melhor disciplina de patch e menos pontos únicos de exposição catastrófica. As empresas de cripto que usam esse tipo de infraestrutura não devem esperar o mercado de provedores amadurecer. Elas devem aplicar seus próprios controles.

Um checklist prático inclui:

1. Separe a assinatura da computação

   Não coloque chaves privadas, serviços de assinatura de carteiras ou chaves de assinatura de validadores em workloads de nuvem de uso geral. Use uma arquitetura de assinatura dedicada, limites de rede rígidos e proteção de chaves com hardware sempre que possível.

2. Parta do princípio de que o isolamento entre locatários pode falhar

   Projete os workloads de forma que o comprometimento de um locatário vizinho não exponha seus segredos. Criptografe dados sensíveis, reduza a exposição de metadados e isole serviços críticos.

3. Exija transparência do provedor

   Pergunte aos fornecedores Neocloud sobre modelos de tenancy em Kubernetes, configuração de DPU, keying de InfiniBand, isolamento de BMC/IPMI, SLAs de patch, divulgação de incidentes e auditorias independentes.

4. Minimize privilégios de dashboards

   Ferramentas de observabilidade devem usar service accounts com menor privilégio possível. Evite tokens de API amplos, rotacione credenciais e monitore o acesso aos painéis.

5. Use segmentação de rede de forma agressiva

   Aplique políticas de rede do Kubernetes, sub-redes privadas, regras de firewall e identidade em nível de workload. Não dependa apenas do isolamento oferecido pelo provedor.

6. Automatize a ingestão de vulnerabilidades

   Acompanhe avisos de sistemas operacionais, plataformas de orquestração, fornecedores de stack de GPU e equipes de clientes blockchain. Atualizações de segurança devem entrar diretamente nos fluxos de engenharia.

7. Teste suposições de escape da cloud

   Inclua cenários de isolamento entre locatários em exercícios de red team. Se sua avaliação de risco pressupõe que um contêiner não consegue alcançar recursos em nível de host, valide essa suposição.

8. Proteja os caminhos de recuperação

   Mantenha backups offline, planos de recuperação de desastres, circuit breakers para saques e procedimentos de rotação de chaves. No cripto, o tempo de resposta pode determinar se um incidente vira ou não uma perda.

Por que Hardware Wallets Ainda Importam em um Mundo Cripto Nativo de Cloud

O relatório da Neocloud reforça um princípio que sempre esteve no centro da segurança cripto: chaves críticas não devem ser expostas casualmente à infraestrutura online. Plataformas de nuvem são úteis e muitas vezes necessárias, mas não devem ser o ancoradouro final de confiança para a autocustódia.

Para usuários individuais, fundadores, gestores de tesouraria e operadores que precisam aprovar transações, uma hardware wallet pode ajudar a manter chaves privadas isoladas de notebooks comprometidos, sessões no navegador, dashboards em nuvem e servidores remotos. A OneKey é projetada com foco em autocustódia, transparência de código aberto e confirmação segura de transações, o que a torna relevante para usuários que querem reduzir a dependência de ambientes conectados à internet ao gerir ativos digitais.

Isso não substitui a segurança da infraestrutura. Ela a complementa. A postura de segurança mais forte em cripto combina arquitetura de nuvem endurecida, controles operacionais rígidos e proteção de chaves offline.

Considerações Finais

As descobertas da SemiAnalysis sobre a Neocloud devem ser tratadas como um alerta para a indústria blockchain. Empresas de cripto estão se aprofundando em infraestrutura de IA, clouds com GPU, computação distribuída e ambientes Kubernetes gerenciados. Ao mesmo tempo, os atacantes continuam focados no caminho mais simples até chaves e sistemas valiosos.

A lição mais importante não é que todo provedor Neocloud seja inseguro. É que mercados de infraestrutura em rápido crescimento podem acumular uma dívida de segurança perigosa quando a demanda cresce mais rápido do que a maturidade operacional. Para o cripto, onde um único comprometimento pode se tornar uma perda financeira irreversível, segurança “básica” em nuvem não é nada básica. Ela faz parte da proteção de ativos.

A próxima geração da infraestrutura Web3 será julgada não apenas por velocidade, custo e disponibilidade de GPU, mas também por isolamento, aplicação de patches, gerenciamento de chaves e contenção de falhas. No cripto, a arquitetura mais segura é aquela que parte do princípio de que algo vai dar errado — e ainda assim impede que um único elo fraco exponha tudo.