Zusammenfassung

  • Die rechtliche Identität hinter almazcloud.network (AS210328, Organisation ORG-ZA238-RIPE) ist AO 'ALMAZ' aus Juschno-Sachalinsk: INN 6501304360, registriert am 06.05.2019, mit Marinefischzucht als Haupttätigkeit, Stammkapital von 10.000 RUB und zwei Beschäftigten.
  • Die Gewinn- und Verlustrechnung dieser Rechtsperson passt nicht zu einem internationalen Cloud-Betreiber: 2024 schloss sie mit 14,6 Mio. RUB Umsatz und 8,5 Mio. RUB Gewinn ab; 2025 mit null Umsatz und einem Verlust von 883.000 RUB.
  • Die Storefront verkauft Cloud-Produkte in US-Dollar an einen internationalen Markt und nutzt ein Rollenpostfach, das einen Geschäftsführer namens 'Maksim' impliziert – nicht die registrierte Direktorin Khan Marina Menkhoevna.
  • Der Routing-Fußabdruck ist ein Transit-Netz mit 512 IPv4-Adressen in drei Präfixen; zwei Präfixe sind in den Routingdaten einem Dritten zugeschrieben, und keine beobachteten Peers passen zum beworbenen Peering mit Yandex, Sberbank oder Rostelecom.
  • Kein öffentliches Register verbindet den beworbenen Betreiber mit der registrierten Rechtsperson oder mit betrieblicher Cloud-Kapazität: Die Diskrepanz ist der Befund, kein Urteil.

Die Rechtsperson hinter der Domain

Die RIPE-Registrierungsnummer 1196501003357 löst auf eine konkrete russische Rechtsperson auf. Spiegel des Staatsregisters identifizieren sie als AO 'ALMAZ' aus Juschno-Sachalinsk, INN 6501304360, registriert am 06.05.2019 (audit-it, checko, check.tochka). Ihre registrierte Haupttätigkeit ist weder Cloud noch Interconnection noch Telekommunikation, sondern Marinefischzucht. Die eingetragene alleinige Direktorin ist Khan Marina Menkhoevna, im Amt seit genau dem 06.05.2019; die gemeldete Belegschaft umfasst zwei Personen bei einem Stammkapital von 10.000 RUB (audit-it, tbank).

Die Unternehmensgenealogie ist kurz und geschlossen. Die Gründerin Matveeva Yulia Yurievna wurde am 30.11.2021 aus dem EGRUL gestrichen, der rechtliche Vorgänger OOO KROKS wurde am 05.03.2022 liquidiert (spark). Es gibt keine Ausschreibungen, kein Schiedsverfahren, keine Zwangsvollstreckungen. Die Rechtsperson existiert, ist aktiv und in allem, was ein Cloud-Käufer üblicherweise prüft, dünn dokumentiert.

Eine Bilanz wie ein Fischzucht-Mikrounternehmen

Die berichtete Gewinn- und Verlustrechnung bildet nicht die Ökonomie eines Cloud-Betreibers ab. 2024 meldete das Unternehmen 14,6 Mio. RUB Umsatz mit 8,5 Mio. RUB Gewinn; 2025 null Umsatz und einen Verlust von 883.000 RUB bei einem Durchschnittsgehalt von 86.200 RUB (audit-it, checko). Zwei Beschäftigte, 8,5 Mio. RUB Gewinn in einem Jahr, null Umsatz und Verlust im nächsten – das beschreibt eine Entität ohne technische Belegschaft, ohne sichtbare wiederkehrende Einnahmen und ohne die buchhalterische Basis, die eine Cloud-Plattform mit Dollar-Abrechnung in irgendeinem Register zeigen müsste.

Der Punkt ist nicht, dass ein Mikrounternehmen prinzipiell keine Infrastruktur weiterverkaufen könnte. Der Punkt ist, dass keines der beiden Register – das russische Staatsregister und das RIPE-Register – Belege für die angebotene Kapazität enthält: 10G-Ports, BGP-Sessions, GRE-Tunnel, VPN-Nutzer. Das Angebot ist nur in der Storefront prüfbar; die anbietende Person nur im Register; die beiden Datensätze kreuzen sich in keinem öffentlichen Dokument.

Die Storefront: Dollarpreise und ein Geschäftsführer namens 'Maksim'

Die kommerzielle Fassade ist almazcloud.network, Marke DIAMOND, und ist für einen internationalen Markt geschrieben: Dollarpreise pro Produkt, mit Cloud Connect zu 499 $/Monat pro 10G-Port, BGP-Ankündigungen zu 99 $/Monat, GRE zu 99 $/Monat je 100 Mbit/s, Cloud-VPN zu 9 $/Nutzer und einem Reselling-Programm zu 99 $/Monat. Das Kontaktpostfach nutzt eine Direktor-Rolle mit Eigennamen: director-maksim@. Dieses Detail impliziert einen Geschäftsführer namens 'Maksim'.

Die registrierte Direktorin von AO 'ALMAZ' ist Khan Marina Menkhoevna. Keines der geprüften Register enthält einen 'Maksim' in der Leitung der Rechtsperson. Die Storefront bewirbt zudem ein gewichtiges Interconnection-Positionierung: Peering mit Yandex, Sberbank und Rostelecom. Diese Behauptung ist ein Netzversprechen – und Netzversprechen werden an Routingdaten gemessen.

AS210328: 512 Adressen, drei Präfixe und ein Dritter in den Daten

Die beworbene Aut-num ist AS210328, ein kleines reines Transit-Netz: drei angekündigte Präfixe mit zusammen 512 IPv4-Adressen, davon zwei RPKI-valide (bgp.he, ping.pe, stat.ripe, peeringdb). In den Routingdaten erscheinen zwei dieser Präfixe zugeschrieben an einen Dritten, Vlad Cojuhari – eine Zuschreibung, die die Storefront nicht erwähnt und die kein Register mit AO 'ALMAZ' verbindet (ipinfo, ping.pe).

Der Kontrast zum Storefront-Versprechen ist vollständig. Es gibt keine beobachteten Peers, die zum beworbenen Peering mit Yandex, Sberbank oder Rostelecom passen; das Netz zeigt keine Adjazenzen zu einer dieser drei Entitäten (bgp.he, stat.ripe). Ein Käufer, der Cloud Connect für 499 $/Monat als 'Premium'-Interconnection bucht, erwirbt nach den beobachtbaren Daten Transit in einem 512-Adressen-Netz mit einem Dritten in der Zuschreibung.

Widersprüchliche Upstreams und eine unverifizierbare admin-c-Kette

Die Routing-Snapshots widersprechen sich selbst. Ein Snapshot von 2021 zeigt AS12695 als Upstream; die aut-num mit Bearbeitungen von 2026 zeigt AS48693 (stat.ripe, whois.ipip). Die beiden Upstreams teilen sich nicht die beiden dritt-zugeschriebenen Präfixe, und die admin-c/tech-c-Kette von RIPE ist nicht verifizierbar, weil Personenbezug-Schwarzierung sie verdeckt.

Diese Grenze ist wichtig. Die Schwarzierung personenbezogener Daten ist eine legitime und weit verbreitete Praxis; sie bedeutet aber, dass der normale Mechanismus der Adressregister – wer verwaltet die Ressource – die zentrale Frage dieses Falls nicht beantworten kann: wer AS210328 tatsächlich kontrolliert. Die Diskrepanz zwischen rechtlicher Identität, Storefront-Persona und Präfix-Zuschreibung bleibt ungelöst, nicht weil Register alles verbergen, sondern weil kein öffentliches Register sie verbindet.

Registerbearbeitungen von 2026 gegen einen statischen Fußabdruck seit 2022

Die Bearbeitungshistorie des RIPE-Registers ist die zweite zeitliche Anomalie. Die Organisation ORG-ZA238-RIPE wurde am 13.05.2026 geändert; die aut-num am 21.08.2026 bearbeitet; das ROA für das Präfix 185.136.15.0/24 wurde am 20.08.2026 erzeugt (stat.ripe). Derweil ist der kommerzielle Fußabdruck – dieselben Produkte, dieselben Preise, dasselbe Postfach – seit 2022 statisch (almazcloud.network).

Das Ergebnis ist ein Muster, das wir in unserer früheren Identitätsprüfung bereits dokumentiert haben: aktuelle Registerbearbeitungen bei statischem kommerziellem Fußabdruck und einer Rechtsperson ohne operative Cloud-Historie (btw.media, btw.media).

Was wir nicht wissen

  • Wer tatsächlich AS210328 kontrolliert. Kein öffentliches Register stellt das fest.
  • Wer 'Maksim' ist. Das Rollenpostfach der Storefront impliziert einen Geschäftsführer dieses Namens; weitergehende Belege gibt es nicht.
  • Wo die angebotene Kapazität gehostet ist. Keine der geprüften Quellen dokumentiert Server, Rechenzentren oder betriebliche Cloud-Sessions, die der registrierten Rechtsperson zugeordnet wären.
  • Ob die Zuschreibung der zwei Präfixe an Vlad Cojuhari ein Routingdaten-Detail, ein Weiterverkaufsverhältnis oder etwas anderes ist: Die Daten zeigen die Zuschreibung; ihre Bedeutung ist von außen nicht verifizierbar.

Praktische Konsequenzen

Für Cloud-Käufer ist der Fall eine Erinnerung daran, dass eine aut-num mit ROA und RPKI-Validität kein verifizierter Betreiber ist: Es ist ein angekündigtes Netz. Die Frage, wer hinter der Ressource steht – die 'whois-rdap-accountability' eigentlich beantworten soll – beantwortet hier keiner der üblichen Mechanismen: Das Staatsregister sagt das eine (ein Fischzucht-Mikrounternehmen), die Storefront das andere (ein internationaler Cloud-Betreiber mit einem Geschäftsführer 'Maksim'), und die Routingdaten zeigen ein drittes (ein Transit-Netz mit einem Dritten in den Präfixen).

Für Peers und Betreiber, die eine Interconnection mit AS210328 prüfen, ist der härteste beobachtbare Befund die Abwesenheit von Peers, die zum beworbenen Peering passen. Storefront-Versprechen sind keine Netzdaten.

Was wir beobachten

Die Indikatoren sind die drei Mechanismen, die – ändern sie sich – eine Konvergenz oder größere Divergenz erzeugen würden: Änderungen im EGRUL von AO 'ALMAZ' (Direktoren, Belegschaft, Tätigkeit), neue Bearbeitungen der RIPE-Objekte aut-num und Organisation, und Änderungen in der Zuschreibung der angekündigten Präfixe. Eine Storefront, die Verträge, SLAs oder prüfbare Kapazität veröffentlicht; eine Belegschaft über zwei Personen hinaus; eine nicht geschwärzte admin-c/tech-c-Kette: jedes dieser Ereignisse würde die Analyse verändern.