support 3D CLOUD COMMUNICATION vend une capacité hébergée qui dépend encore des racks, du transit et des créneaux de réparation

Résumé

• L'entité dénommée « support 3D CLOUD COMMUNICATION » est un rôle de contact RIPE, et non le nom légal vérifié d'une entreprise de support. L'entreprise correspondante est LLC « 3D CLOUD COMMUNICATION », une société à responsabilité limitée de Kiev constituée le 9 juillet 2025 avec un capital social de 600 000 UAH et une activité principale enregistrée couvrant le traitement des données, l'hébergement et les activités connexes.
• L'entreprise est actuellement liée à AS56421 et AS39755. Ces deux numéros sont antérieurs à l'entreprise de plusieurs années: leurs dates de création et leurs historiques de routage anciens ne doivent donc pas être présentés comme l'historique opérationnel de l'entreprise. AS39755 n'avait aucune route visible à la date de référence de la recherche. AS56421 venait juste de commencer à annoncer un /24 IPv4 et n'avait démontré aucune annonce IPv6.
• Le seul bloc visible,185.243.98.0/24, était également toujours annoncé par AS48693, dont l'organisation reste le titulaire enregistré du bloc et dont les nomsntup.netdemeuraient dans le DNS inverse. Cet état de multi-origine peut refléter une migration autorisée, un accord avec un client ou une transition. Cela ne prouve pas à lui seul un incident de routage, mais aucune autorisation publique ou ROA n'est venue clarifier la relation.
• À 12h00 UTC le 10 juillet, les observations de routes publiques montraient AS56421 via AS41033, tandis qu'un nombre bien plus important de routes observées aboutissaient encore à AS48693. Le registre RIPE listait de nombreuses relations d'importation prévues, mais une politique de routage prévue n'est pas la même chose qu'un transit simultané utilisable. Aucun second site, point d'échange, liaison physique, capacité de secours ou test de basculement n'a été vérifié pour l'entreprise.
• L'évaluation des preuves est Faible. Il existe bien une entreprise légale, un enregistrement réseau à jour et un signal BGP très récent. Il n'y a pas encore suffisamment de preuves publiques pour garantir une plateforme cloud orientée client, localiser ses racks, mesurer la capacité utilisable, vérifier la résilience électrique et matérielle, établir la localité des données ou évaluer les obligations de restauration et de migration.

Un libellé de support ne raconte pas une histoire d'entreprise

Le nom public inhabituel de l'entité trouve une explication simple. L'enregistrement du rôle RIPEnomme SCC86-RIPE « support 3D CLOUD COMMUNICATION » et lui attribue la responsabilité administrative via SP22450-RIPE. L'enregistrement de personneassocié identifie Slipych Pavlo. Ces enregistrements ont été créés le 31 décembre 2025. Ils constituent une preuve utile de contact et de responsabilité, mais le mot « support » ne doit pas être confondu avec un nom commercial, un service d'assistance doté de personnel ou une promesse de niveau de service.

L'identité légale est LLC « 3D CLOUD COMMUNICATION ». Leregistre d'entreprise Opendatabotfournit le numéro d'entreprise ukrainien 45920348, une date de constitution au 9 juillet 2025, une adresse légale à Kiev et un capital social de 600 000 UAH. Il identifie Pavlo Slipych comme directeur, fondateur et bénéficiaire effectif ultime. Leregistre YouControlmontrait l'entreprise enregistrée et non en liquidation lors de sa mise à jour le 23 juin 2026. La même identité légale est visible indépendamment via larecherche d'entreprises Hosting Ukraine.

Ces dates fixent une limite essentielle. Une société constituée en juillet 2025 ne peut pas revendiquer la durée de vie opérationnelle d'un système autonome observé pour la première fois en 2011 simplement parce que ce numéro lui est désormais associé. Elle a pu acquérir des droits, des contrats, des équipements ou des compétences auprès d'un opérateur antérieur, mais aucun registre public de transaction ne permet d'établir ce qui a été transféré. L'entreprise actuelle ne peut être évaluée que sur la base de sa propre constitution, de ses enregistrements à jour et de son comportement observable.

Le numéro plus ancien reste un contexte technique pertinent, et non une biographie corporative héritée.

Le registre légal limite également ce qui peut être affirmé avec certitude sur la propriété. L'entreprise se présente comme la propriété exclusive d'un seul individu, et non comme une filiale déclarée d'un groupe d'hébergement plus important. Aucune garantie publique de société mère, de bilan consolidé ou de partenaire d'infrastructure nommé n'a été trouvée. Les 600 000 UAH de capital social constituent un engagement capitalistique formel; ils ne révèlent ni la trésorerie disponible, ni le chiffre d'affaires annuel, ni l'inventaire des serveurs, ni la couverture d'assurance, ni les sommes mobilisables en cas d'interruption prolongée.

Un acheteur ne peut pas convertir le capital social en une estimation du temps de disponibilité.

Cela est important car la responsabilité dans une petite entreprise de services hébergés est souvent concentrée. La même personne peut négocier la capacité, approuver les dépenses, gérer les ressources d'adressage et assurer l'escalade. Cela peut accélérer les décisions, mais aussi créer un risque de personne clé. Les registres publics ne révèlent pas le nombre d'employés, la couverture des équipes, la profondeur technique ou une liste d'astreinte. Le rôle de contact prouve qu'il existe un responsable. Il ne prouve pas qu'un second ingénieur répondra lorsque le premier n'est pas disponible.

L'enregistrement pour l'hébergement est une preuve d'intention, pas un catalogue de produits

L'activité principale enregistrée de l'entreprise est le KVED ukrainien 63.11: traitement des données, hébergement sur des nœuds web et activités connexes. Les activités enregistrées additionnelles incluent la programmation, le conseil en technologies de l'information, la gestion d'équipements informatiques, l'édition de logiciels et d'autres services d'information. C'est la base publique la plus claire pour situer l'entreprise dans la catégorie cloud ou hébergement. Cela reste une classification administrative plutôt qu'une description d'un produit en fonctionnement.

Une activité enregistrée ne dit pas si l'entreprise vend des machines virtuelles, des serveurs bare-metal, des applications gérées, de la colocation, du stockage de sauvegarde ou uniquement du conseil technique. Elle ne nomme ni hyperviseur, ni plateforme de stockage, ni portail de facturation, ni gamme de systèmes d'exploitation, ni allocation de bande passante, ni durée minimale d'engagement, ni canal de support, ni juridiction client. Elle n'affiche ni prix, ni page de commande, ni page de statut, ni avis aux clients, ni politique d'utilisation acceptable.

Aucun catalogue de produits public lié de manière sécurisée au numéro d'entreprise 45920348 n'a été identifié à la date de référence.

La distinction est facile à négliger car le mot « cloud » figure dans le nom de l'entreprise. Ladéfinition de l'informatique en nuage du NISTdécrit des caractéristiques telles que le libre-service à la demande, l'accès large au réseau, la mutualisation des ressources, l'élasticité rapide et le service mesuré. L'activité légale vient étayer l'intention d'hébergement, bien que les preuves publiques n'établissent pas ces caractéristiques opérationnelles. Un rack de serveurs provisionnés manuellement peut constituer un service d'hébergement utile sans pour autant être un cloud élastique. À l'inverse, une entreprise peut revendre le cloud d'un tiers sans posséder le moindre rack. Le nom seul ne tranche aucun des deux cas.

Lasynthèse et les recommandations du NIST sur le clouddistinguent également les accords de service et de déploiement et soulignent la nécessité de comprendre les responsabilités du fournisseur. C'est le problème pratique ici. Si 3D CLOUD COMMUNICATION revend de la capacité, l'opérateur sous-jacent peut contrôler l'énergie, le remplacement du matériel et une grande partie du réseau. Si elle loue des racks et possède des serveurs, elle contrôle une portion différente de la chaîne. Si elle gère du matériel client, la responsabilité change encore. Aucun contrat public ne répartit ces obligations.

Le régulateur ukrainien des communications publie unregistre mensuel des fournisseurs de réseaux et services de communications électroniques, avec la page du jeu de données mise à jour au 2 juillet 2026. Une entreprise qui prévoit de vendre du transit Internet peut avoir besoin d'une posture réglementaire différente de celle qui vend de la puissance de calcul sur la connectivité d'un autre opérateur. Les preuves examinées ici n'établissent pas quelles notifications ou autorisations s'appliquent à l'offre réelle de cette entreprise. La conclusion prudente est limitée: ses activités corporatives autorisent une hypothèse d'hébergement; elles ne prouvent pas ce qu'elle vend actuellement ni la nature réglementaire du service.

Deux numéros de réseau anciens sont arrivés à l'intérieur d'une nouvelle identité corporative

L'enregistrement d'organisation RIPEpour ORG-LCC13-RIPE a été créé le 31 décembre 2025 et nomme LLC « 3D CLOUD COMMUNICATION » avec le numéro d'entreprise 45920348. Le jour suivant, les enregistrements de systèmes autonomes visibles pour AS56421 et AS39755 ont été modifiés pour pointer vers cette organisation. Tous deux conservent le nom d'ASEurolir-AS, une étiquette qui ne correspond pas au nouveau nom légal. Aucune de ces divergences n'est automatiquement problématique, mais toutes deux montrent pourquoi chaque champ doit être lu à la lumière de sa date et de sa fonction.

L'enregistrement actuel d'AS56421indique que le numéro a été créé le 17 février 2011. L'historique de l'état de routage de RIPEstata vu ce numéro annoncer91.223.123.0/24pour la première fois le 18 février 2011. L'entreprise n'existait pas à ce moment-là. La date enregistre l'histoire du numéro de réseau, et non l'ancienneté de LLC 3D CLOUD COMMUNICATION.

L'enregistrement d'AS39755a une date de création de l'objet actuel en mai 2018, tandis que lavue d'état de RIPEstatcontient des observations plus anciennes remontant à juillet 2010. Des enregistrements de registre réémis ou reconstruits peuvent produire ce genre de chronologie. Le point pertinent pour un client est plus simple: lavue d'ensemble actuelle d'AS39755le signalait comme non annoncé, et aucun préfixe courant n'était visible depuis ce numéro à la date de référence.

Posséder ou parrainer un enregistrement de système autonome peut être utile avant que le trafic ne commence. Cela permet à un réseau de définir des politiques et d'organiser des sessions avec des fournisseurs de transit. Cependant, un ASN n'est ni un routeur, ni une fibre, ni un rack, ni un mégabit de transit contracté. C'est un identifiant utilisé pour exprimer un domaine de routage. L'explication de RIPE NCC sur les numéros de système autonomeprécise explicitement qu'un ASN prend en charge une politique de routage externe distincte. L'identifiant peut être prêt bien avant l'installation de l'équipement, ou rester enregistré après l'arrêt du trafic.

Dès lors, l'entreprise actuelle possède deux identifiants enregistrés, mais un seul présente un signal opérationnel récent. Cette asymétrie doit peser dans toute affirmation de résilience. Deux ASN ne signifient pas deux réseaux. Ils n'impliquent pas deux centres de données, deux routeurs de bordure ou deux contrats. L'inactivité d'AS39755 l'écarte comme preuve d'une sauvegarde actuelle. Un client devrait examiner comment chaque numéro est utilisé, si les deux sont configurés sur des équipements distincts et si un service peut basculer d'un numéro à l'autre sans renumérotation ni temps d'arrêt prolongé.

Un /24 est devenu visible seulement quelques jours avant la publication

AS56421 est passé d'une trace d'enregistrement à une trace opérationnelle en juillet 2026. Unobjet de route RIPEautorisant l'association entre AS56421 et185.243.98.0/24a été créé le 7 juillet. L'historique de routage de RIPEstat pour le préfixea commencé à voir AS56421 comme origine le 8 juillet. Il s'agit d'une preuve inhabituellement récente: elle indique que l'ASN contrôlé par l'entreprise avait atteint au moins une partie du système de routage mondial, et non qu'il le faisait depuis des mois.

À 12h00 UTC le 10 juillet, l'état BGP de RIPEstat pour le bloccontenait 381 routes observées. Vingt-sept aboutissaient à AS56421, tandis que 354 aboutissaient à AS48693. Les comptages des collecteurs de routes ne sont ni une mesure de part de marché, ni une mesure de trafic, et les collecteurs ne représentent pas tous les réseaux. Ils montrent que la nouvelle origine avait une propagation limitée, alors que l'origine établie restait beaucoup plus visible à ce moment-là.

Le préfixe contient 256 adresses IPv4. Même ce simple chiffre doit être mis en contexte. Les conventions de réseau et de diffusion, les adresses de routeur, les pratiques d'attribution aux clients, le filtrage et la réservation peuvent réduire l'espace assignable. Une adresse peut héberger de nombreux services virtuels derrière de la traduction ou de l'hébergement basé sur le nom; un client dédié peut consommer plusieurs adresses. Le /24 ne révèle ni le nombre de serveurs, ni la capacité vendue.

Il s'agit aussi de la longueur minimale habituelle de préfixe IPv4 acceptée par une grande partie de l'Internet mondial, ce qui en fait une unité naturelle pour annoncer même pour un petit réseau terminal.

Aucune origine IPv6 de l'entreprise n'a été établie à la date de référence. Une preuve uniquement IPv4 ne rend pas un service d'hébergement inutilisable, mais elle réduit ce qui a été démontré. Un service moderne peut fournir de l'IPv6 via un réseau fédérateur, un proxy ou un autre accord de routage sans annoncer son propre bloc. Simplement, aucun fondement public ne permet ici d'affirmer que 3D CLOUD COMMUNICATION propose de l'IPv6 au client, une gestion dual-stack ou un chemin de migration éprouvé entre les familles d'adresses.

La courte fenêtre d'observation est le fait de capacité le plus important. Une route visible pendant deux jours peut transporter du trafic de production, du trafic de test, une migration ou un nouveau segment de clientèle. Le routage public ne révèle pas laquelle de ces hypothèses est la bonne. Il ne peut pas révéler le nombre de processeurs, la mémoire, le stockage, la densité de virtualisation, les unités de rack occupées, la consommation électrique, l'engagement en bande passante ou les comptes facturables. Traiter le /24 comme une preuve d'infrastructure cloud confondrait l'accessibilité des adresses avec la capacité de calcul.

Le même bloc avait encore deux origines

L'événement de juillet n'a pas été un remplacement net dans la vue publique. Lavue d'ensemble du préfixe de RIPEstata identifié à la fois AS48693 et AS56421 comme origines. Une route annoncée depuis plus d'un système autonome est communément appelée une condition de multi-origine ou MOAS. Cela peut être intentionnel: les opérateurs utilisent des annonces superposées pendant les migrations, le multi-hébergement client, l'atténuation DDoS et l'ingénierie de trafic. Cela peut aussi résulter d'une erreur ou d'une annonce non autorisée. L'observation seule ne détermine pas quelle explication s'applique.

Les registres de propriété maintiennent l'incertitude. L'enregistrement inetnum de RIPEattribue le bloc à une organisation identifiée comme Rices Privately owned enterprise sous le nom de réseau NTS-03. Sonenregistrement d'organisationfournit un numéro d'enregistrement ukrainien et un domaine de contactntup.net. Unobjet de route pour AS48693indépendant existait depuis décembre 2023. L'objet de route le plus récent pour AS56421 était maintenu sous un mainteneur différent de celui du contact de l'entreprise.

La dénomination inverse restait également associée à l'ancien réseau. Lavue de bloc d'IPinfolistaitgw.reserved.ntup.netpour la première adresse de passerelle etfree.ntup.netdans une grande partie de la plage lors de son observation indexée. Le DNS inverse peut accuser un retard par rapport à un transfert ou une location légitime, et les étiquettes génériquesfreene prouvent pas que les adresses sont inactives. Elles montrent cependant que la dénomination publique n'avait pas encore été retravaillée pour présenter un ensemble de services reconnaissable de 3D CLOUD COMMUNICATION.

L'autorisation d'origine de route n'a pas résolu la question. Lerésultat de validation RPKI de RIPEstata renvoyéunknown, sans autorisation d'origine de route validée pour la combinaison AS56421 et /24. Inconnu n'est pas invalide. Cela signifie que les parties de confiance n'avaient pas de déclaration cryptographique dans l'Infrastructure de Clé Publique de Ressources autorisant ou refusant cette origine. Lavue d'ensemble du RPKI par RIPE NCCexplique comment les ROA permettent aux titulaires de spécifier quel AS peut annoncer un préfixe.

Le risque pratique est la divergence. Certains réseaux peuvent préférer la route via AS48693, d'autres la route via AS56421, en fonction de la politique et de la longueur du chemin. Si les deux origines ne mènent pas au même service ou réseau coordonné, les utilisateurs peuvent se retrouver sur des destinations différentes ou perdre la connectivité. Si l'accord est intentionnel et que les deux routes convergent correctement, cela peut étayer une transition.

Une lettre publique d'autorisation, une ROA couvrant l'origine prévue, un enregistrement de préfixe à jour et une date de migration claire distingueraient un transfert contrôlé d'une superposition non résolue.

La politique de fournisseurs enregistrée est plus large que le transit observé

L'enregistrement RIPE d'AS56421 listait un long ensemble de relations d'importation et d'exportation prévues, incluant AS6939, AS5577, AS202171, AS174, AS42602, AS50073, AS203142 et AS1299. Il a été mis à jour le 7 juillet pour y ajouter AS41033 et AS209155. Cela semble diversifié sur le papier. Toutefois, une déclaration d'importation RPSL décrit la politique de routage déclarée. Elle ne prouve pas qu'un circuit physique est installé, qu'une session BGP est établie, qu'un port est payé ou que la route alternative dispose d'une capacité suffisante en cas de panne.

À la date de référence du 10 juillet, l'observation des voisins de RIPEstatvoyait un seul voisin côté amont: AS41033. L'état BGP spécifique au moment montrait également que les routes d'AS56421 passaient par AS41033. C'est une preuve opérationnelle d'un chemin fournisseur. Ce n'est pas une preuve que les huit relations enregistrées plus anciennes étaient toutes actives simultanément.

AS41033 est lui-même un réseau de transit substantiel. Sonenregistrement PeeringDBidentifie D2 CLOUD COMMUNICATIONS et fait état d'une présence publique sur des points d'échange et dans des installations à Kiev, Varsovie, Francfort, Amsterdam et d'autres emplacements. Lesite webde l'opérateur présente des services réseau. Ces faits aident à caractériser le fournisseur. Ils ne situent pas le routeur d'AS56421. Une session client peut atteindre un fournisseur à large couverture depuis une interconnexion locale sans pour autant occuper toutes les installations que ce fournisseur liste.

Cette distinction est importante pour la région Global attribuée. Une route transportée par un réseau à portée internationale rend un service IPv4 accessible mondialement. Cela ne prouve pas que 3D CLOUD COMMUNICATION exploite une infrastructure mondiale ou vend sur tous les marchés. L'emplacement corporatif vérifié est Kiev. La bordure de routage vérifiée utilisait un fournisseur connecté internationalement. La zone de desserte, les pays contractants, les devises de facturation, les langues de support et les options de localisation des données n'étaient pas établis publiquement.

Un seul fournisseur observé laisse aussi une question de base sur la reprise. Si AS41033 retire la route, AS56421 a-t-il une seconde session active avec une capacité indépendante? Le registre suggère des candidats possibles, mais une réponse prouvée nécessite des observations de routes simultanées ou une documentation du fournisseur. Même deux routes AS observées peuvent partager une entrée de fibre, une salle d'interconnexion, un routeur, une alimentation électrique ou un couloir métropolitain. La diversité logique est précieuse; l'indépendance physique exige des preuves supplémentaires.

Une adresse à Kiev n'est pas une carte des racks

Les registres légaux et RIPE placent l'entreprise au 39 de la rue Idzykovsky Family, à Kiev. C'est une adresse enregistrée et de contact vérifiée. Ce n'est pas un emplacement de serveur vérifié. Les adresses corporatives peuvent identifier des bureaux, une gestion de courrier, des locaux commerciaux partagés ou des installations où se trouvent également des équipements. Aucun des registres de l'entreprise ne spécifie de suite, de rack, de cage, d'allocation électrique ou de salle de données.

L'adresse a un contexte télécoms authentique. Lesite public de R-TELutilise la même adresse postale et annonce de l'Internet pour les entreprises et un support 24h/24. Leregistre corporatif de R-TELy situe également l'entreprise de télécommunications. Lapage de contact d'Orionliste l'adresse pour des services Internet, tandis que leregistre de l'entreprise immobilièreidentifie une entité au même numéro dont les activités incluent la possession ou la location de biens immobiliers. Ce sont des signaux de localisation utiles, mais ils ne prouvent pas un contrat, un lien de propriété ou une infrastructure partagée avec 3D CLOUD COMMUNICATION.

Le bâtiment pourrait offrir un accès opérateur et de l'espace technique, ou simplement héberger plusieurs locataires sans rapport entre eux. Une photographie de la salle des serveurs d'un autre opérateur n'établirait pas la propriété des machines de l'entreprise. Une adresse postale commune n'établirait pas une route de fibre protégée.

Les preuves nécessaires sont ordinaires et spécifiques: le nom de l'opérateur de l'installation, le pays et la ville, si l'entreprise possède ou loue de l'espace rack, les limites de puissance du rack, les entrées opérateurs, les fournisseurs d'interconnexion, les contrôles d'accès et la partie responsable des interventions à distance.

L'emplacement physique détermine plus que la latence. Il détermine le réseau électrique, la logistique de carburant du générateur, l'environnement de refroidissement, les contrôles incendie, l'exposition aux risques de défense civile, le temps de déplacement des techniciens et la loi qui régit les données stockées. Kiev subit des pressions infrastructurelles en temps de guerre. Ce contexte rend la continuité électrique et la reprise géographique particulièrement importantes, mais il ne doit pas être utilisé pour présumer d'une défaillance particulière.

L'entreprise n'a pas publié la conception de son site, l'autonomie de l'énergie de secours ou l'emplacement de reprise.

Dès lors, un client doit résister à deux erreurs opposées. La première consiste à déduire que l'adresse légale est un centre de données et à attribuer tous les actifs télécoms voisins à l'entreprise. La seconde consiste à déduire qu'il n'y a pas d'infrastructure parce qu'aucun plan de site public n'a été trouvé. Les petits fournisseurs opèrent souvent depuis des espaces loués sans marketing étendu. L'évaluation correcte est plus limitée: un ancrage opérationnel à Kiev est plausible et l'adresse a des associations télécoms, mais l'emplacement et la propriété des racks restent non vérifiés.

Chaque instance hébergée repose sur une chaîne physique et contractuelle

Que l'offre soit un serveur privé virtuel, un serveur géré ou une instance cloud, l'unité visible pour le client dépend d'une pile d'actifs finis. À la base se trouvent un bâtiment, une arrivée électrique, un appareillage, des batteries, un générateur ou une autre alimentation de secours, la climatisation, les contrôles incendie et la sécurité physique. Au-dessus viennent les racks, la distribution électrique, les serveurs, le stockage, les commutateurs, les routeurs, l'optique et le câblage. Le transit, l'espace d'adressage et le routage rendent le système accessible.

La facturation, la supervision, les sauvegardes, les identifiants et les techniciens transforment la machinerie en service.

Les preuves publiques de l'entreprise ne vérifient que des fragments de cette chaîne. L'activité enregistrée pointe vers l'hébergement. L'observation BGP de juillet pointe vers une bordure réseau accessible. L'adresse de Kiev pointe vers un emplacement légal et de contact. Elle ne vérifie pas une salle de données, un seul serveur, une baie de stockage ou un client payant. Aucun opérateur d'installation, fournisseur de matériel, couche de virtualisation, plateforme de sauvegarde ou système de supervision n'a été publiquement lié à l'entreprise.

Cela crée une frontière de propriété qu'un contrat doit résoudre. L'entreprise peut être propriétaire du matériel, mais louer les racks et l'énergie. Elle peut louer des serveurs chez un autre hébergeur et ne contrôler que le logiciel et la facturation. Elle peut revendre des instances virtuelles sans exploiter aucune machine physique. Elle peut fournir de la gestion pour des systèmes appartenant aux clients. Chaque arrangement peut offrir un service légitime, mais change qui est responsable en cas de défaillance.

Une panne de courant dans l'installation se gère différemment d'une panne d'unité louée; un litige de transit est différent d'un abonnement client expiré.

Les enregistrements de préfixes ajoutent une autre couche contractuelle. Le bloc IPv4 visible reste attribué à Rices Privately owned enterprise, tandis qu'AS56421 l'a annoncé via AS41033. Cet accord pourrait être une utilisation autorisée de type indépendant du fournisseur, une location ou une transition, mais les registres publics n'indiquent pas les conditions commerciales. Si l'accès au bloc dépend de l'accord d'une autre partie, une résiliation ou un litige peut forcer une renumérotation.

Pour les clients qui incluent des adresses dans des listes blanches, publient des enregistrements DNS ou lient des licences à des IP, la renumérotation peut devenir une interruption d'activité.

Il en va de même pour le transport du fournisseur. Si un seul fournisseur achemine tout le transit utilisable actuellement, un défaut de paiement ou de contrat peut supprimer l'accessibilité même si les serveurs restent sous tension. Si une relation de revente fournit le matériel, des impayés peuvent menacer l'accès au calcul séparément. La facture cloud masque ces dépendances parce que le client ne paie qu'une seule contrepartie. La diligence raisonnable doit reconstituer la chaîne et identifier les points où l'entreprise peut réparer directement et ceux où elle ne peut qu'ouvrir un ticket chez un tiers.

La capacité installée n'est pas la capacité utilisable

Le seul actif réseau quantifié en faveur de l'entreprise dans la vue publique est un /24: 256 adresses IPv4. Il n'y a pas de vitesse de port vérifiée, de débit de données engagé, d'allocation de rafale, de stockage total, de nombre de cœurs, de réserve mémoire, de nombre de racks ou d'allocation électrique. Même si ces chiffres étaient annoncés, chacun nécessiterait une interprétation. Les interfaces installées ne sont pas la marge de trafic, et le stockage brut n'est pas la capacité protégée pour le client.

Considérons une liaison montante hypothétique de 10 Gbit/s. Son étiquette décrirait la vitesse de l'interface, non l'engagement de transit, le débit soutenu, la limite de paquets par seconde ou la capacité disponible après la défaillance d'un autre circuit. Un contrat d'un gigabit sur un port de dix gigabits peut saturer à un gigabit. Deux ports de dix gigabits sur un routeur peuvent tomber ensemble. Actuellement, aucun chiffre de port ne peut être attribué à 3D CLOUD COMMUNICATION, de sorte que cette comparaison élémentaire ne peut même pas être faite.

La capacité de calcul présente des écueils similaires. Un hôte peut contenir des dizaines de cœurs de processeur tandis que la sursouscription met en concurrence les charges de travail occupées. Le stockage alloué dynamiquement peut afficher beaucoup plus d'espace logique que de média physique. Les copies de réplication peuvent améliorer la disponibilité tout en consommant de la capacité non commercialisable. Les données de sauvegarde peuvent partager la même baie ou le même domaine électrique que la production.

Sans preuve d'utilisation, de réservation, de domaine de panne et de restauration, un chiffre de catalogue n'établirait toujours pas la résilience utilisable.

Le nombre d'adresses IPv4 est particulièrement faible comme indicateur. L'hébergement virtuel peut placer de nombreux domaines derrière une seule adresse; les services dédiés peuvent utiliser une adresse par instance; les périphériques réseau et les allocations de rechange en consomment d'autres. Lavue des préfixes annoncés de RIPEstataffichant un /24 indique que la bordure avait une petite empreinte IPv4 routable. Elle ne dit rien sur le nombre d'adresses attribuées aux clients ou sur le fait que le bloc transportait des services de calcul.

Une déclaration de capacité crédible séparerait les ressources installées, allumées, contractées, occupées et disponibles. Pour le réseau, cela signifie la vitesse du port, l'engagement payé, le pic normal, le pic en état de panne et la diversité des chemins. Pour le calcul, cela signifie les hôtes physiques, la surcharge réservée, la politique d'attribution et la marge restante. Pour le stockage, cela signifie la capacité brute, protégée, utilisée et restaurable.

Aucune de ces couches n'est publique pour l'entreprise, de sorte que l'article ne peut pas convertir de manière responsable la nouvelle route en une affirmation de capacité disponible pour le client.

Le premier chemin de défaillance est le chemin lui-même

La condition MOAS de juillet est le chemin de défaillance observable le plus immédiat. Si AS48693 et AS56421 mènent intentionnellement au même point final, la coordination doit maintenir les deux routes cohérentes pendant la transition. S'ils mènent à des points finaux différents, la sélection de route peut diviser les utilisateurs. Un retrait accidentel d'une origine peut améliorer ou dégrader l'accessibilité selon la route préférée par un réseau. Sans ROA, la validation cryptographique de l'origine ne clarifie pas l'origine prévue.

Une entrée d'objet de route est utile, mais ce n'est pas un contrôle de sécurité complet. BGP, normalisé dans laRFC 4271, échange l'accessibilité en fonction de la politique et des attributs de chemin; il n'authentifie pas nativement le fait que l'organisation annonciatrice soit propriétaire du préfixe. RPKI, dont l'architecture est décrite dans laRFC 6480, permet aux détenteurs d'adresses de faire des déclarations d'origine vérifiables. Une ROA valide ne préviendrait pas toutes les fuites ou pannes, mais elle réduirait l'ambiguïté pour les réseaux qui appliquent la validation d'origine de route.

Le chemin de défaillance suivant est la perte du fournisseur. Dans l'observation ponctuelle, AS41033 était le seul voisin visible pour AS56421. Une panne de routeur, un défaut d'interconnexion, une suspension commerciale ou une erreur de politique chez le fournisseur pourraient supprimer la nouvelle origine. La liste plus longue dans le registre peut se convertir en redondance réelle, mais tant que plusieurs routes actives n'apparaissent pas et ne peuvent pas écouler la charge complète, cela reste une politique planifiée ou historique plutôt qu'une capacité de reprise démontrée.

Vient ensuite la bordure locale. Les preuves publiques ne montrent pas si AS56421 fonctionne sur un ou plusieurs routeurs, si les sessions de route se terminent sur des châssis distincts ou si les configurations sont sauvegardées. Une seule alimentation défaillante, une configuration corrompue, une optique périmée ou une console inaccessible peut anéantir plusieurs fournisseurs nominaux. Le matériel de rechange et l'accès hors bande déterminent souvent le temps de reprise plus que le nombre d'opérateurs dans un registre.

Enfin, il y a la continuité DNS et d'adressage. Les anciens noms inversesntup.netsuggèrent que la gestion des noms traverse encore une frontière organisationnelle. Le DNS direct des clients peut être hébergé ailleurs, mais aucun service autoritaire n'a été identifié. Lors d'une migration de préfixe, un DNS obsolète, des listes blanches, des liaisons TLS, des bases de données de géolocalisation et la réputation anti-abus peuvent continuer à pointer vers l'ancien réseau. Le mouvement technique n'est achevé que lorsque ces systèmes environnants sont mis à jour et que les clients savent ce qui a changé.

L'énergie, le stock de matériel et la réparation humaine restent des angles morts

Une route réseau peut sembler saine alors que tous les serveurs clients situés derrière sont indisponibles. Le service physique dépend de l'énergie et de la climatisation dans chaque rack. Aucune déclaration publique ne fournit les arrivées électriques de l'entreprise, la configuration des onduleurs, la capacité du générateur, l'autonomie en carburant, la redondance de refroidissement ou le programme de maintenance. L'adresse partagée de Kiev ne peut pas combler ces lacunes car les opérateurs voisins peuvent utiliser des salles, des arrivées et des contrats différents.

L'inventaire matériel est tout aussi important pour un petit fournisseur. Un disque défaillant peut être routinier si des pièces de rechange compatibles et une réplication éprouvée existent. Cela peut devenir une interruption prolongée si un remplacement doit franchir une frontière, si le firmware diffère ou si le seul ingénieur compétent n'est pas disponible. L'entreprise n'a pas divulgué ses fournisseurs de serveurs, la protection du stockage, les ratios de pièces de rechange, les conditions d'intervention à distance ou les objectifs de remplacement.

Cela ne signifie pas qu'il n'y a pas de pièces de rechange; cela signifie simplement que le temps de réparation ne peut pas être estimé publiquement.

La main-d'œuvre de support fait partie de la capacité. Un CPU annoncé reste inutilisable si personne ne peut récupérer un hôte défaillant ou réinitialiser un compte bloqué. Le registre de l'entreprise identifie un dirigeant et les enregistrements RIPE identifient une personne administrative nommée derrière le rôle. Aucun effectif total, horaires de support, chemin d'escalade ou couverture linguistique n'ont été trouvés. Le libellé « support » seul ne peut pas remplacer une réponse éprouvée aux tickets.

La facturation appartient aussi à la carte des défaillances. Un nouveau fournisseur peut dépendre de factures manuelles, d'un processeur de paiement ou d'un panneau de revendeur. Une erreur de facturation peut suspendre le service aussi efficacement qu'un routeur cassé. Les clients ont besoin de périodes de grâce, de gestion des litiges, d'avis de renouvellement et d'un moyen d'exporter les données avant résiliation. Aucune condition publique n'établit ces protections pour 3D CLOUD COMMUNICATION.

La preuve de niveau de service la plus utile serait banale: une adresse de support sur le propre domaine de l'entreprise, des définitions de gravité, des objectifs de réponse et de restauration, des règles de préavis de maintenance, des conditions de crédit et une escalade téléphonique éprouvée. Un fournisseur peut être petit et tout de même publier des obligations claires. Dans ce cas, le contact public basé sur Outlook visible dans les registres et le rôle générique établissent une accessibilité pour l'administration réseau, pas un engagement de support client.

La redondance nécessite des domaines de défaillance séparés

La résilience doit être testée couche par couche. Deux machines virtuelles sur un hôte ne protègent pas contre la défaillance de l'hôte ni la perte d'énergie du rack. Deux hôtes dans un rack peuvent protéger contre une panne de carte mère, mais pas contre une unité de distribution d'énergie défaillante. Deux racks dans une salle peuvent partager le refroidissement et l'alimentation du bâtiment. Deux sites connectés via un opérateur peuvent partager le même chemin. La redondance n'existe que lorsque l'alternative survit à la défaillance pertinente.

Aucun second site n'a été vérifié pour 3D CLOUD COMMUNICATION. Aucun document public ne nomme une région de secours, une zone de disponibilité, un emplacement de réplication ou une localité sélectionnable par le client. AS39755 ne fournit pas cette preuve car il n'avait pas de route actuelle. La longue liste d'importation d'AS56421 ne la fournit pas car la politique de routage ne localise pas le calcul. La portée mondiale d'AS41033 ne la fournit pas car la liste d'installations d'un fournisseur n'est pas la liste d'installations du client.

La reprise nécessite aussi un état. Le trafic web sans état peut se déplacer rapidement si le DNS, les certificats et le déploiement de l'application sont préparés. Une base de données a besoin de réplicas cohérents ou de sauvegardes restaurables. Une machine virtuelle peut nécessiter des images disque, des clés, des configurations réseau et une capacité de calcul de réserve suffisante à destination. L'entreprise n'a pas publié d'objectifs de point de reprise ou de temps de reprise, de rétention des sauvegardes, de résultats de tests de restauration ou l'étendue d'une éventuelle offre de reprise après sinistre.

L'évaluation des risques de l'informatique en nuage de l'ENISAtraite la dépendance au fournisseur, la gestion des données, la continuité des activités et la défaillance technique comme des risques connectés. Ce cadre s'applique bien à ce cas. Un second site n'a d'importance que si le client peut y accéder, que les données y sont, que le système d'identité fonctionne, que le fournisseur a l'autorité pour l'activer et que le contrat permet le mouvement. Un marqueur sur une carte n'est pas, à lui seul, une reprise.

Les preuves qui augmenteraient la confiance comprennent deux installations nommées dans des domaines énergétiques et de risque métropolitain distincts, des routes actives via des fournisseurs indépendants, une réplication documentée, un exercice de restauration récent et des instructions au client pour exporter les données. Celles qui l'augmenteraient encore plus incluent des temps de reprise mesurés et la confirmation que la capacité réseau et de calcul du chemin de secours peut écouler la charge de production. Rien de cela n'était public à la date de référence.

La localité des données ne peut pas être déduite de l'adresse de l'entreprise

Le thème assigné de la souveraineté des données est pertinent précisément parce que la localisation n'est pas résolue. Une adresse légale à Kiev établit le lien juridictionnel de l'entreprise. Elle n'établit pas où sont stockées les données des clients, les sauvegardes, les journaux ou les copies de support. Un serveur pourrait se trouver dans le même bâtiment, ailleurs en Ukraine, dans un autre pays européen ou sur la plateforme d'un sous-traitant. La route via AS41033 ne répond pas à cette question: les paquets peuvent traverser une ville ou un pays sans que les données y soient stockées.

Les clients ont besoin de quatre emplacements, pas d'un seul. Le premier est le site de calcul principal. Le deuxième est le site de sauvegarde ou de réplication. Le troisième est l'emplacement depuis lequel les administrateurs peuvent accéder aux données. Le quatrième est l'emplacement légal de chaque sous-traitant qui peut les traiter ou les récupérer. Ceux-ci peuvent différer. Un contrat qui déclare simplement que le fournisseur est ukrainien laisse ouverte la géographie physique et opérationnelle.

La portabilité est l'autre face de la souveraineté. Un client doit savoir s'il peut exporter des disques virtuels, des exports de bases de données, des données objets, des journaux et des clés de chiffrement dans des formats utilisables. Il doit savoir combien de temps prend une exportation, quelles limites de bande passante s'appliquent et si des frais ou des impayés peuvent bloquer l'accès. Le nouveau /24 et le chevauchement continu d'adresses rendent la portabilité réseau particulièrement concrète: un client ne doit pas présumer qu'une adresse IP attribuée peut le suivre chez un autre fournisseur.

Les chemins de migration nécessitent également du temps et de la coopération. Les valeurs TTL du DNS peuvent être abaissées, les réplicas peuvent être ensemencés et les données peuvent être copiées avant un basculement. Mais un contrat fournisseur défaillant peut supprimer le temps nécessaire à un mouvement ordonné. Aucune condition publique de résiliation, de suppression, de séquestre ou d'exportation n'a été trouvée pour 3D CLOUD COMMUNICATION. Les acheteurs doivent traiter la sortie des données comme une dépendance non tarifée et non vérifiée jusqu'à ce que ces conditions soient fournies.

Les preuves n'étayent pas l'affirmation que les données des clients se trouvent hors d'Ukraine, ni celle qu'elles y restent. Elles n'étayent que la nécessité d'un calendrier de localité écrit. Ce calendrier doit identifier les villes et les pays, les opérateurs d'installation, la géographie de secours, l'administration à distance, les sous-traitants, les délais de suppression et la loi applicable aux litiges. Sans cela, « Global » décrit la portée potentielle du réseau, pas une offre vérifiée de résidence des données.

L'économie de l'hébergement concentre le risque dans des contrats que le client ne peut pas voir

Les petits fournisseurs d'hébergement peuvent être compétitifs en achetant des intrants en gros et en y ajoutant une gestion réactive. L'économie peut être séduisante: des unités de rack louées évitent de construire une installation; des serveurs loués réduisent les dépenses d'investissement; le transit et les accords d'adressage peuvent être acquis progressivement; une petite équipe peut automatiser le provisionnement courant. Les clients peuvent recevoir une attention plus directe que celle qu'ils obtiendraient d'une plateforme à grande échelle. Aucun de ces avantages n'exige que le fournisseur soit propriétaire d'un bâtiment.

La même structure crée une dépendance au renouvellement et à la marge. Le loyer du rack, l'énergie, le transit, l'utilisation des adresses, les baux de matériel, les licences et la main-d'œuvre de support sont des obligations récurrentes. Un fournisseur ne peut vendre de la capacité que tant que ces contrats restent financés et coordonnés. Un prix d'appel bas peut être viable si l'automatisation et l'utilisation sont fortes, ou fragile s'il omet les coûts de remplacement, de sauvegarde et de support. Aucune liste de prix publique ni état financier ne permet ici de faire cette distinction.

Le capital social de 600 000 UAH ne doit pas être interprété comme une dépense d'infrastructure. Il peut soutenir les opérations de démarrage, mais le chiffre légal ne dit pas s'il a acheté des équipements, s'il reste liquide ou s'il couvre une responsabilité particulière. La page publique de l'entreprise n'a fourni ni chiffre d'affaires, ni actifs, ni dette, ni effectif, ni comptes audités pour une année opérationnelle complète. L'entreprise avait moins d'un an à la date de référence de la recherche.

L'action technique la plus récente — annoncer un /24 via un fournisseur observé — est cohérente avec une entreprise qui démarre ou modifie ses opérations réseau. Cela ne suffit pas à estimer l'échelle. Le bloc peut supporter un petit ensemble de serveurs, une transition réseau, un client, un environnement de test ou un inventaire futur. Les noms inverses indiquantfreesont suggestifs mais pas décisifs. Un catalogue commercial, des factures, des références clients, des rapports d'utilisation ou un historique de l'état du service fourniraient une preuve opérationnelle plus solide.

Pour un acheteur, la question économique clé est de savoir qui doit continuer à être payé pour que le service fonctionne. Cela inclut l'installation, l'électricité, le fournisseur, la contrepartie pour l'espace d'adressage, le loueur de matériel, le fournisseur de logiciels et le personnel de support. Le fournisseur doit pouvoir identifier quelles dépendances sont prépayées, mensuelles ou résiliables, et ce qu'il advient des données du client si un contrat prend fin. Un simple tarif mensuel bas n'est pas une mesure de la résilience à moins qu'il ne finance ces obligations.

Les signaux non officiels ne sont utiles que lorsque leurs limites sont indiquées

Plusieurs signaux publics pointent dans une direction cohérente. L'entreprise a choisi une activité d'hébergement, adopté un nom dans le cloud, créé des contacts RIPE, est devenue l'organisation dans deux enregistrements de systèmes autonomes et a initié une nouvelle annonce via un fournisseur avec une marque cloud. Son adresse enregistrée est partagée par des sociétés de télécommunications. Ensemble, ces faits suggèrent une tentative d'établir ou d'acquérir une exploitation d'hébergement et de réseau à Kiev.

Ils ne peuvent pas prouver un lancement de produit, une base de clients, une flotte de serveurs ou une occupation d'installation. Le chevauchement d'adresses ne peut pas prouver une relation avec R-TEL ou Orion. La liste d'installations du fournisseur ne peut pas prouver où se trouve le routeur de l'entreprise. Le DNS inverse ne peut pas prouver que les adresses ne sont pas utilisées. Un objet de route ne peut pas prouver que toutes les parties commerciales concernées ont approuvé l'origine. La condition MOAS ne peut prouver ni une transition bénigne, ni un événement hostile sans plus de contexte.

La séquence des dates est en elle-même un signal: constitution de l'entreprise en juillet 2025, organisation et contacts RIPE fin décembre, mises à jour des ASN le 2 janvier 2026, objet de route le 7 juillet et origine observée à partir du 8 juillet. Cela ressemble à une préparation par étapes suivie de l'activation du réseau. Cela pourrait aussi refléter un transfert administratif dont le service commercial n'est pas encore public. Les preuves établissent la chronologie, pas l'intention.

Ce qui résoudrait la question commerciale est simple. Un site web contrôlé par l'entreprise devrait nommer le vendeur légal et le numéro d'entreprise, décrire les produits et les prix, publier les conditions générales, identifier les canaux de support, révéler les emplacements des données et expliquer la résiliation. Ce qui résoudrait la question infrastructurelle est une déclaration sur les installations et le réseau qui identifie les limites de l'opérateur de rack, les fournisseurs actifs, l'autorisation de route, les engagements de port, IPv6, les sites de secours et la reprise éprouvée.

Ce qui résoudrait la question de l'état opérationnel est un routage soutenu associé à une activité orientée client dans le temps.

Jusqu'à ce que ces éléments apparaissent, la dégradation correcte est explicite. L'entreprise n'est pas un nom fictif: c'est une LLC ukrainienne enregistrée avec des enregistrements réseau à jour et une route récente. Mais le dossier public pour un cloud fiable orienté client reste incomplet. La différence protège à la fois les lecteurs et l'entreprise contre des affirmations que les preuves ne peuvent soutenir.

Un acheteur doit rendre la chaîne de dépendance contractuelle

Avant de placer une charge de production, un client doit demander à l'entreprise d'identifier la partie contractante légale comme LLC « 3D CLOUD COMMUNICATION » et d'utiliser le numéro d'entreprise 45920348 dans le contrat et la facture. Le contrat doit indiquer si le service est de la revente, de l'hébergement géré, un serveur privé virtuel, du bare metal, de la colocation ou une autre forme. Il doit identifier les actifs que l'entreprise possède et ceux qui sont fournis par d'autres opérateurs.

L'annexe réseau doit indiquer les préfixes du client, les fournisseurs, l'AS d'origine attendu, l'état de l'autorisation d'origine de route et le plan de basculement. Pour le /24 actuellement visible, elle doit expliquer les annonces concurrentes d'AS48693 et d'AS56421, identifier l'autorisation du titulaire des adresses et donner une date de fin s'il s'agit d'une migration. Les clients doivent savoir si les adresses sont portables, comment la renumérotation est gérée et si un changement de route déclenche un préavis.

L'annexe sur les installations doit nommer la ville, le pays et l'opérateur pour le service principal et le service de secours. Elle doit décrire la puissance du rack, l'énergie de secours, le refroidissement, l'accès physique, les interventions à distance et les entrées opérateurs à un niveau approprié pour la diligence raisonnable. Des plans d'étage détaillés ne sont pas nécessaires; les limites de propriété et de défaillance le sont. S'il n'y a qu'un seul site, le contrat doit l'indiquer clairement et éviter de suggérer une redondance géographique.

L'annexe de service doit définir la disponibilité, les exclusions, la maintenance, la gravité, la réponse, la restauration, les crédits et l'escalade. Elle doit indiquer ce qui est sauvegardé, à quelle fréquence, où résident les copies, combien de temps elles sont conservées et comment les restaurations sont testées. Elle doit préciser quelles pannes l'entreprise répare directement et lesquelles dépendent d'un ticket auprès de l'installation ou du fournisseur. Elle doit aussi traiter de la perte d'un ingénieur nommé.

L'annexe de sortie doit être aussi détaillée que la commande. Les clients ont besoin de formats d'image machine et d'exportation de données, de limites de débit et de frais, de rétention après résiliation, de confirmation de suppression, d'accès pendant les litiges et d'assistance pendant la migration. Ils doivent conserver leurs propres sauvegardes et identifiants indépendants. Un service dont on ne peut pas sortir de manière prévisible n'est pas entièrement sous le contrôle du client, quelle que soit la facilité de son achat.

Enfin, les preuves doivent être mises à jour après la transition de routage de juillet. La visibilité soutenue de l'origine, la suppression ou l'explication de l'ancienne origine, une ROA valide, un transit alternatif actif et une dénomination inverse cohérente amélioreraient matériellement la confiance dans le réseau. Une page produit publique, des conditions légales et un historique de statut amélioreraient la confiance commerciale. Les preuves sur les installations et la restauration amélioreraient la confiance dans la résilience. Chacune de ces améliorations comble un manque différent; aucune ne peut remplacer toutes les autres.

La qualification honnête est une bordure active avec des preuves de service faibles

Il y a plus ici qu'un simple nom dans un catalogue d'entreprises. LLC 3D CLOUD COMMUNICATION est active dans les registres corporatifs ukrainiens. Elle a une activité principale liée à l'hébergement. Ses enregistrements d'organisation et de contact RIPE sont cohérents avec l'identité légale. AS56421 a commencé à apparaître comme origine d'un bloc IPv4 via un fournisseur observé juste avant la publication. Ce sont des faits significatifs.

Ces faits sont loin de l'implication commerciale la plus forte du titre. Aucune offre orientée client liée à l'entreprise n'a été vérifiée. Aucun rack, serveur, plateforme de stockage, centre de données, vitesse de port, second site ou engagement de support n'a été établi. Le seul bloc visible restait dans un état de multi-origine, attribué à une autre organisation, avec un statut RPKI inconnu et une dénomination inverse plus ancienne. Le second ASN enregistré était inactif. La zone de service et la géographie des données restaient non spécifiées.

Cette combinaison justifie une qualification de preuve réseau Faible, et non la conclusion que l'entreprise est inactive. C'est un jeune opérateur légal avec une bordure nouvellement activée et un important déficit de divulgation. La route peut mûrir, la transition d'adresses peut se terminer et un matériel commercial peut émerger. À la date du 10 juillet 2026, les acheteurs doivent traiter la capacité hébergée, la redondance et le service mondial comme des affirmations qui exigent des preuves directes.

La leçon physique est plus large mais spécifique à l'entreprise dans ses détails. Un nom de cloud peut être enregistré en un jour; un ASN peut être antérieur de quinze ans à son titulaire actuel; un /24 peut apparaître via un fournisseur de transit en quelques heures. L'hébergement fiable prend plus de temps parce qu'il exige que l'énergie, le matériel, les pièces de rechange, les contrats, les personnes, les sauvegardes et les sorties répétées fonctionnent ensemble. Pour support 3D CLOUD COMMUNICATION, ces dépendances sont la substance qui reste à démontrer.