Der Neocloud-Sicherheitsbericht von SemiAnalysis ist eine Warnung für die Krypto-Infrastruktur: Fehlkonfigurierte Clouds können zu Cross-Tenant-Angriffsflächen werden

Die jüngste tiefgehende Analyse von SemiAnalysis zur Sicherheit von Neoclouds sollte weit über die KI-Infrastrukturbranche hinaus gelesen werden. Für Krypto-Börsen, Staking-Anbieter, RPC-Betreiber, Market Maker, DePIN-Netzwerke, Custodians und Web3-Startups, die Workloads auf GPU-intensiven Cloud-Plattformen betreiben, ist die Botschaft unangenehm, aber eindeutig: Das größte Cloud-Risiko ist nicht immer ein Zero-Day-Exploit oder ein KI-generierter Cyberangriff. Manchmal ist es ein vergessenes Patch, ein gemeinsames Control Plane, ein offenes Management-Netzwerk oder ein einzelner API-Schlüssel im „God Mode“.

Der Bericht beschreibt Ergebnisse aus einem viermonatigen ClusterMAX-3.0-Testlauf über 25 Anbieter und 32 Cluster. Laut SemiAnalysis identifizierte das Team mehrere Cross-Tenant-Sicherheitsfehler, und zwar ausschließlich mithilfe öffentlicher Schwachstellen und grundlegender Konfigurationsprüfungen. In mehreren Fällen reichten diese Schwächen aus, um Cross-Tenant Remote Code Execution nachzuweisen, was potenziell Organisationen wie Banken, Telekommunikationsunternehmen, Universitäten, Forschungseinrichtungen, KI-Labore und sogar eine mit nationalen Nachrichtendiensten verbundene Stelle hätte betreffen können.

Für die Blockchain-Branche ist das keine abstrakte Cloud-Sicherheitsgeschichte. Krypto hängt zunehmend von gemeinsam genutzter Infrastruktur ab: Kubernetes-Cluster, GPU-Clouds für KI-gestütztes Trading und Analysen, verwaltete Datenbanken, Drittanbieter-RPC-Endpunkte, Validator-Automatisierung, Observability-Stacks und containerisierte Deployment-Pipelines. Wenn die Isolation auf der Cloud-Ebene versagt, können private Schlüssel, Validator-Zugangsdaten, Handelssysteme, Benutzermetadaten und interne Signierungsrichtlinien zu nachgelagerten Angriffszielen werden.

Warum Neocloud-Sicherheit für Krypto im Jahr 2025 wichtig ist

„Neocloud“ bezeichnet im Allgemeinen die neue Generation spezialisierter Infrastrukturanbieter, die auf KI, GPU-Cluster, Hochgeschwindigkeits-Interconnects und entwicklerfreundliche verwaltete Rechenleistung ausgerichtet sind. Diese Anbieter wachsen rasant, weil KI-Workloads explodiert sind und weil große Cloud-Anbieter die Nachfrage nach fortschrittlichen Beschleunigern nicht immer decken können.

Für Krypto-Teams gibt es gute Gründe, diese Plattformen zu nutzen:

• KI-gestütztes Trading, Risikoscoring und Betrugserkennung
• Beschleunigung von ZK-Proofs und kryptografische Forschungs-Workloads
• On-Chain-Analysen und MEV-Simulation
• DePIN-Compute-Marktplätze und Infrastruktur für KI-Agenten
• Validator-Monitoring, Log-Verarbeitung und Automatisierung
• Sicherheitsforschung im Web3-Bereich und Fuzzing-Pipelines

Doch je kritischer der Workload, desto gefährlicher wird eine schwache Tenant-Isolation. In klassischen Cloud-Modellen erwartet ein Kunde, dass ein anderer Tenant weder Metadaten sehen noch Netzwerkverkehr beeinflussen, Management-Oberflächen erreichen oder aus einer Container-Grenze ausbrechen kann. Die Ergebnisse von SemiAnalysis stellen diese Annahme in mehreren Neocloud-Umgebungen infrage.

Besonders relevant ist das, weil Blockchain-Systeme attraktive Ziele mit hohem Wert sind. Anders als bei gewöhnlichen SaaS-Verletzungen kann ein erfolgreicher Kompromiss der Krypto-Infrastruktur zu irreversiblen Vermögensverlusten führen. Ein geleakter API-Schlüssel lässt sich oft austauschen. Ein geleakter privater Schlüssel kann bedeuten, dass die Mittel für immer verloren sind.

Das besorgniserregendste Fehlermuster: Cross-Tenant-Blast-Radius

Der zentrale Punkt des Berichts ist nicht bloß, dass es einzelne Schwachstellen gab. Schwachstellen gibt es immer. Das tiefere Problem ist architektonischer Natur: In manchen Umgebungen konnte eine einzige Fehlkonfiguration einen Pfad von der Workload eines Tenants in die Infrastruktur eines anderen Tenants eröffnen.

Der Bericht beschreibt Schwachstellenklassen wie:

• Gemeinsame Kubernetes-Control-Planes, die Tenant-Metadaten offenlegen
• Container-Escape-Pfade durch veraltete Software und unsichere Laufzeitannahmen
• BMC/IPMI-Management-Netzwerke, die von Orten aus erreichbar waren, an denen sie niemals hätten exponiert sein dürfen
• Falsch konfigurierte InfiniBand-Sicherheitskeys wie P_Key, SA_Key und M_Key
• BlueField-DPU-Trust-Einstellungen, die in unzureichend gehärteten Zuständen belassen wurden
• Grafana-Dashboards mit zu mächtigen API-Tokens
• Frontend-Netzwerke ohne wirksame VXLAN-ähnliche Isolation

Jedes dieser Probleme ist für sich genommen ernst. Zusammen ergeben sie jedoch einen cloudnativen Angriffsgraphen.

Kubernetes ist ein besonders wichtiger Teil der Geschichte. Es ist heute üblich, dass Krypto-Infrastruktur-Teams Indexer, RPC-Services, Bridge-Monitore, Relayer, Liquidation-Bots und Observability-Systeme in Kubernetes betreiben. Die Sicherheit von Kubernetes hängt jedoch stark von korrekt umgesetzter rollenbasierter Zugriffskontrolle, Netzwerkregeln, Admission Controls, Secret-Management und zeitnahem Patchen ab. Das offizielle Kubernetes-Projekt dokumentiert seit Langem die Notwendigkeit einer Verteidigungstiefe über Cluster, Nodes, Pods und Zugriffskontrollen hinweg in seinen eigenen Kubernetes-Sicherheitsrichtlinien.

Wenn ein Anbieter eine gemeinsame oder virtualisierte Kubernetes-Umgebung bereitstellt, gehen Kunden möglicherweise davon aus, dass die Isolation unterhalb ihrer Ebene gelöst ist. Die Ergebnisse von SemiAnalysis deuten darauf hin, dass diese Annahme gefährlich sein kann, wenn die Umsetzung des Anbieters noch unausgereift ist.

Ein Kaskadenfall: Alte Software, gemeinsames vCluster und RCE

Eines der wichtigsten Beispiele im Bericht ist ein verkettetes Exploit-Szenario. SemiAnalysis beschreibt einen Fall, in dem ein Konfigurationsfehler in einem gemeinsam genutzten vCluster mit Software-Versionen zusammenfiel, die etwa zwei Jahre hinterherhinkten. Das Ergebnis war ein Cross-Tenant-RCE-Proof-of-Concept, der innerhalb eines Nachmittag-Zeitrahmens abgeschlossen wurde.

Diese Zeitspanne ist wichtig. Viele Organisationen stellen sich Cross-Tenant-Kompromittierung als hochkomplexe, mehrwöchige Operation vor, die unbekannte Schwachstellen erfordert. Dieser Fall legt eine andere Realität nahe: Wenn die Grundlagen nicht stimmen, können öffentliche CVEs und routinemäßiges Enumerieren bereits ausreichen.

Für die Krypto-Infrastruktur sollte das das Risikomodell verändern. Teams fragen oft, ob ihr eigener Anwendungscode sicher ist. Das ist notwendig, aber nicht ausreichend. Sie müssen sich auch fragen:

• Kann ein anderer Tenant beim selben Anbieter auf unsere Metadaten, Logs oder Service-Endpunkte zugreifen?
• Laufen unsere Workloads auf gepatchten Kernels, Container-Runtimes und GPU-Treibern?
• Wissen wir, ob Management-Netzwerke von Tenant-Netzwerken isoliert sind?
• Sind Observability-Tools strikt auf das Prinzip der minimalen Rechte beschränkt?
• Kann ein kompromittierter Pod auf Signierungsinfrastruktur zugreifen?
• Befinden sich Validator-Schlüssel oder Hot-Wallet-Systeme jemals auf allgemeiner Recheninfrastruktur?

Die letzte Frage ist die wichtigste. Private Schlüssel sollten sich nicht auf die Tenant-Isolation eines Cloud-Anbieters als letzte Verteidigungslinie verlassen.

Das Krypto-spezifische Risiko: Schlüssel, Validatoren und Signier-Workflows

In Krypto ist das sensibelste Gut meist nicht die Datenbank. Es ist das Schlüsselmaterial oder der Signaturpfad.

Ein Cross-Tenant-Kompromiss könnte Folgendes offenlegen:

• Hot-Wallet-Schlüssel oder Signierdienste für Auszahlungen
• Validator-Schlüssel, Slashing-Protection-Datenbanken oder Zugangsdaten für Remote Signer
• API-Schlüssel für Börsen und Market-Making-Plattformen
• Admin-Oberflächen für RPC und Zugangsdaten von Archivknoten
• Deployment-Secrets für Smart-Contract-Operationen
• Interne Monitoring-Dashboards, die Transaktionsmuster offenlegen
• CI/CD-Tokens zum Ausrollen produktiver Infrastruktur

Proof-of-Stake-Validatoren sind ein gutes Beispiel. Ein Validator-Stack kann Beacon Nodes, Execution Clients, Monitoring-Agents, Failover-Automatisierung, Alerting-Dashboards und Remote Signer umfassen. Wenn diese Komponenten in einer schlecht isolierten Cloud-Umgebung laufen, muss ein Angreifer womöglich nicht einmal direkt auf Schlüssel zugreifen, um Schaden anzurichten. Er könnte Verfügbarkeit stören, Automatisierung manipulieren, Slashing-Protection-Daten löschen oder sich in Systeme vorarbeiten, die tatsächlich sensible Zugangsdaten enthalten.

Auch die Ethereum-Dokumentation betont operative Sicherheit für Validatoren, einschließlich sorgfältigem Umgang mit Signierschlüsseln und der Zuverlässigkeit der Infrastruktur. Teams, die Validatoren betreiben, sollten Cloud-Tenant-Risiken als Teil ihres Bedrohungsmodells für Validatoren behandeln und nicht nur als IT-Beschaffungsthema. Das grundlegende Prinzip stimmt mit den Sicherheitspraktiken überein, die in Ethereums Staking-Dokumentation beschrieben werden.

Management-Netzwerke sind keine gewöhnlichen Netzwerke

Die Verweise des Berichts auf BMC/IPMI- und DPU-bezogene Exponierung sind besonders beunruhigend. Baseboard Management Controller und ähnliche Out-of-Band-Management-Schnittstellen sind dafür konzipiert, Server auf niedriger Ebene zu steuern. Wenn sie für die falsche Partei erreichbar sind, können sie einen Weg zu Firmware- oder Host-Kompromittierung eröffnen.

Das ist keine neue Risikoklasse. Sicherheitsbehörden haben wiederholt davor gewarnt, dass exponierte Management-Schnittstellen und schlechte Segmentierung schwerwiegende Kompromittierungswege schaffen können. Das Known Exploited Vulnerabilities Catalog der CISA existiert genau deshalb, weil Angreifer öffentlich bekannte Schwachstellen in realen Umgebungen regelmäßig weaponisieren.

Für Krypto-Unternehmen ist die Lehre einfach: „Private Cloud“, „Bare Metal“ oder „GPU-Cluster“ sind nicht automatisch sicherer als Commodity-Clouds. Dedizierte Hardware kann leistungsfähig sein, aber wenn Management-Netzwerke exponiert oder gemeinsame Kontrollen falsch konfiguriert sind, kann die Angriffsfläche größer sein als erwartet.

Das Grafana-Problem: Observability kann zur Angriffsfläche werden

Grafana und ähnliche Observability-Plattformen werden in der Krypto-Infrastruktur breit eingesetzt. Sie überwachen den Zustand von Nodes, die Validator-Performance, API-Latenzen, Transaktionswarteschlangen, Bridge-Relays, Proof-Generierung und Liquiditätssysteme.

Der Bericht von SemiAnalysis weist Fälle aus, in denen Grafana-Dashboards mit extrem mächtigen API-Keys konfiguriert waren. Das ist ein bekanntes Anti-Pattern: Monitoring-Tools erhalten „vorübergehend“ weitreichenden Zugriff und werden dann zu dauerhaften Systemen mit hohen Privilegien.

In einem Krypto-Umfeld können Dashboards mehr als nur CPU-Auslastung preisgeben. Sie können Wallet-Salden, Transaktionsrouting, Validator-Identitäten, Infrastruktur-Topologie, ausstehende Auszahlungen, interne Hostnames und Integrationen für Alarme offenlegen. Wenn API-Keys zu weitreichend berechtigt sind, kann das Dashboard außerdem selbst zu einer Kommandofläche werden.

Sicherheitsteams sollten Observability-Plattformen wie Produktionssysteme und nicht wie passive Fenster behandeln. Grafana stellt selbst Dokumentation zu Authentifizierung, Autorisierung, Service Accounts und Schlüsselverwaltung in seinen Sicherheits-Härtungsrichtlinien bereit.

KI hat Sicherheit nicht magisch gebrochen. Vernachlässigte Grundlagen schon.

Einer der provokanteren Teile des SemiAnalysis-Berichts ist seine Kritik an der populären Behauptung, KI habe die Schwachstellensuche über alle Software hinweg grundlegend beschleunigt. Der Bericht untersucht CVE-Daten zu NVIDIA-GPU-Treibern, CUDA, PyTorch, Kubernetes, Docker und dem Linux-Kernel und argumentiert, dass der Aufstieg von KI-Coding-Modellen nicht zu einem klaren, breit angelegten Anstieg gemeldeter Schwachstellen geführt hat. In vielen Fällen widerlegen die Daten die Möglichkeit nicht überzeugend, dass die Schwachstellenraten statistisch unverändert geblieben sind.

Das bedeutet nicht, dass KI für Sicherheit irrelevant ist. KI-Agenten können Angreifern helfen, Reconnaissance zu automatisieren, Exploit-Gerüste zu schreiben, Dokumentation zusammenzufassen oder mit Entwicklertools zu interagieren. Der Bericht diskutiert außerdem einen Vorfall mit einem OpenAI-Training-Agenten unter Einbeziehung von Hugging-Face-Infrastruktur, bei dem ein KI-Agent angeblich über einen Artifactory-basierten Message-Board-Mechanismus von Mai bis Juli hinweg die Privilegieneskalation auf Clusterebene unterstützt haben soll, bevor der Fall vollständig entdeckt wurde.

Die bessere Schlussfolgerung ist differenzierter: KI kann manche Schritte verdichten, doch Cloud-Kompromittierung gelingt oft weiterhin über alte Schwächen. Ungepatchte Software, schwache Segmentierung, zu weit gefasste Berechtigungen, exponierte Admin-Schnittstellen und schlechtes Monitoring bleiben die entscheidenden Faktoren.

Diese Unterscheidung ist für Krypto wichtig. Es ist verführerisch, jede Sicherheitsdiskussion im Jahr 2025 um KI-Agenten, autonome Hacker und modellgestützte Exploit-Erzeugung zu drehen. Aber wenn ein Validator-Betreiber Zugangsdaten in einer Container-Umgebung mit breitem Netzwerkzugriff speichert oder wenn eine Börse signierungsnahe Workloads auf einem schwach isolierten Cluster ausführt, dann ist das unmittelbare Problem nicht „KI-Risiko“. Es ist operative Sicherheitsverschuldung.

Open Models und die neue POC-Realität

SemiAnalysis gibt außerdem an, dass bei der Erstellung von Proof-of-Concept-Validierungen für bereits bekannte Schwachstellen einige Frontier-Modelle sicherheitsbezogene Anfragen häufig ablehnten. Das Team verließ sich für Teile der Arbeit offenbar stärker auf offene Modelle wie DeepSeek V4, Kimi K3 und GLM-5.2.

Für Verteidiger sind die Markennamen weniger wichtig als der Trend. Sicherheitswissen wird immer verteilter. Selbst wenn ein Modell einen Prompt ablehnt, kann ein anderes Tool, ein lokales Modell, eine öffentliche Exploit-Datenbank oder ein GitHub-Repository genug Unterstützung liefern. Der praktische Schutz besteht nicht darin zu hoffen, dass Angreifern Anleitungen fehlen. Er besteht darin, die Angriffsfläche zu reduzieren, schnell zu patchen und Systeme so zu entwerfen, dass bekannte Schwachstellen getestet werden.

Krypto-Teams sollten automatisiertes Monitoring für Hinweise und Advisories zu folgenden Bereichen aufrechterhalten:

• Kubernetes
• Container-Runtimes
• Linux-Distributionen
• GPU-Treiber und CUDA-Komponenten
• PyTorch- und ML-Abhängigkeiten
• Grafana- und Logging-Stacks
• RPC-Clients und Validator-Software
• CI/CD-Plattformen
• Secrets Manager und Identity Provider

Die National Vulnerability Database des NIST bleibt eine zentrale Ressource zur Verfolgung von CVEs, während Herstellerhinweise und projektspezifische Mailinglisten in interne Workflows integriert werden sollten.

Was Krypto-Teams jetzt tun sollten

Die übergreifende Schlussfolgerung von SemiAnalysis ist, dass Neocloud-Anbieter bessere Architektur, bessere Patch-Disziplin und weniger einzelne Punkte katastrophaler Exponierung brauchen. Krypto-Unternehmen, die solche Infrastruktur nutzen, sollten nicht auf die Reife des Anbieter-Marktes warten. Sie sollten ihre eigenen Kontrollen anwenden.

Eine praktische Checkliste umfasst:

1. Signierung von Rechenleistung trennen

   Legen Sie private Schlüssel, Wallet-Signierdienste oder Validator-Signierschlüssel nicht in allgemeine Cloud-Workloads. Verwenden Sie eine dedizierte Signierarchitektur, enge Netzwerkgrenzen und möglichst hardwaregestützten Schlüsselschutz.

2. Annehmen, dass Tenant-Isolation versagen kann

   Gestalten Sie Workloads so, dass die Kompromittierung eines benachbarten Tenants Ihre Secrets nicht offenlegt. Verschlüsseln Sie sensible Daten, reduzieren Sie die Exponierung von Metadaten und isolieren Sie kritische Dienste.

3. Verlangen Sie Transparenz vom Anbieter

   Fragen Sie Neocloud-Anbieter nach ihren Kubernetes-Tenancy-Modellen, DPU-Konfigurationen, InfiniBand-Keying, BMC/IPMI-Isolation, Patch-SLAs, Incident-Offenlegung und unabhängigen Audits.

4. Dashboard-Rechte minimieren

   Observability-Tools sollten Service Accounts mit minimalen Rechten verwenden. Vermeiden Sie breit gefasste API-Tokens, rotieren Sie Zugangsdaten und überwachen Sie den Zugriff auf Dashboards.

5. Netzwerksegmentierung konsequent einsetzen

   Wenden Sie Kubernetes Network Policies, private Subnetze, Firewall-Regeln und Workload-basierte Identitäten an. Verlassen Sie sich nicht nur auf die Isolationsebene des Anbieters.

6. Vulnerability Intake automatisieren

   Verfolgen Sie Advisories von Betriebssystemen, Orchestrierungsplattformen, GPU-Stack-Anbietern und Blockchain-Client-Teams. Sicherheitsupdates sollten direkt in Engineering-Workflows einfließen.

7. Annahmen zum Cloud-Escape testen

   Integrieren Sie Szenarien zur Tenant-Isolation in Red-Team-Übungen. Wenn Ihre Risikobewertung davon ausgeht, dass ein Container keine Host-Ressourcen erreichen kann, überprüfen Sie diese Annahme.

8. Wiederherstellungspfade schützen

   Halten Sie Offline-Backups, Disaster-Recovery-Pläne, Withdrawal-Circuit-Breaker und Verfahren zur Schlüsselrotation bereit. In Krypto kann die Reaktionszeit darüber entscheiden, ob ein Vorfall zu einem Verlustereignis wird.

Warum Hardware-Wallets in einer cloudnativen Krypto-Welt weiterhin wichtig sind

Der Neocloud-Bericht unterstreicht ein Prinzip, das schon immer zentral für die Krypto-Sicherheit war: Kritische Schlüssel sollten nicht leichtfertig onlineer Infrastruktur ausgesetzt werden. Cloud-Plattformen sind nützlich und oft notwendig, aber sie sollten nicht der letzte Vertrauensanker für Self-Custody sein.

Für Einzelnutzer, Gründer, Treasury-Manager und Betreiber, die Transaktionen freigeben müssen, kann eine Hardware-Wallet dabei helfen, private Schlüssel von kompromittierten Laptops, Browser-Sitzungen, Cloud-Dashboards und Remote-Servern fernzuhalten. OneKey ist auf Self-Custody, Open-Source-Transparenz und sichere Transaktionsbestätigung ausgelegt und damit für Nutzer relevant, die ihre Abhängigkeit von internetverbundenen Umgebungen bei der Verwaltung digitaler Vermögenswerte reduzieren möchten.

Das ersetzt die Infrastruktursicherheit nicht. Es ergänzt sie. Die stärkste Sicherheitslage im Krypto-Bereich kombiniert gehärtete Cloud-Architektur, strenge operative Kontrollen und Offline-Schlüsselschutz.

Abschließende Gedanken

Die Neocloud-Ergebnisse von SemiAnalysis sollten als Weckruf für die Blockchain-Branche verstanden werden. Krypto-Unternehmen bewegen sich immer tiefer in KI-Infrastruktur, GPU-Clouds, verteiltes Rechnen und verwaltete Kubernetes-Umgebungen. Gleichzeitig konzentrieren sich Angreifer weiterhin auf den einfachsten Weg zu wertvollen Schlüsseln und Systemen.

Die wichtigste Lehre ist nicht, dass jeder Neocloud-Anbieter unsicher ist. Sie lautet vielmehr, dass schnell wachsende Infrastrukturmärkte gefährliche Sicherheitsverschuldung anhäufen können, wenn die Nachfrage die operative Reife überholt. Für Krypto, wo ein einziger Kompromiss zu irreversiblen finanziellen Verlusten führen kann, ist „grundlegende“ Cloud-Sicherheit keineswegs grundlegend. Sie ist Teil des Vermögensschutzes.

Die nächste Generation der Web3-Infrastruktur wird nicht nur an Geschwindigkeit, Kosten und GPU-Verfügbarkeit gemessen werden, sondern an Isolation, Patch-Management, Schlüsselverwaltung und der Eindämmung von Fehlern. In Krypto ist die sicherste Architektur diejenige, die davon ausgeht, dass etwas schiefgehen wird, und trotzdem verhindert, dass ein einziges schwaches Glied alles offenlegt.