support 3D CLOUD COMMUNICATION vend de la capacité hébergée qui dépend encore de racks, de transit et de fenêtres de réparation

Résumé

• L'entité appelée "support 3D CLOUD COMMUNICATION" est un rôle de contact RIPE, pas le nom légal vérifié d'une entreprise de support. La société 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 travaux connexes.
• La société est actuellement rattachée à AS56421 et AS39755. Les deux numéros précèdent la société de plusieurs années, donc leurs dates de création et leurs anciens historiques de routage ne peuvent pas être présentés comme l'historique opérationnel de la société. AS39755 n'avait pas de route visible à la date de coupure de la recherche. AS56421 venait tout juste de commencer à annoncer un /24 IPv4 et n'avait pas d'annonce IPv6 démontrée.
• Le seul bloc visible,185.243.98.0/24, était également encore annoncé par AS48693, dont l'organisation reste l'attributaire enregistré du bloc et dont les nomsntup.netfiguraient toujours dans le DNS inverse. Cet état multi-origine peut refléter une migration autorisée, un arrangement client ou une transition. Il ne prouve pas en soi un incident de routage, mais aucune autorisation publique ou autorisation d'origine de route n'a réglé la relation.
• À 12h00 UTC le 10 juillet, les observations publiques de routage montraient AS56421 via AS41033 tandis que beaucoup plus de chemins observés se terminaient encore chez AS48693. L'enregistrement 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, port d'échange, chemin physique de transport, capacité de secours ou test de basculement n'a été vérifié pour la société.
• La note de preuve est Faible. Il existe une véritable société légale, un enregistrement réseau actuel et un signal BGP très récent. Il n'y a pas encore assez de preuves publiques pour étayer une plateforme cloud orientée client, localiser ses racks, mesurer la capacité utilisable, vérifier l'alimentation et la résilience matérielle, établir la localisation des données, ou évaluer les obligations de restauration et de migration.

Un label de support n'est pas un historique d'entreprise

Le nom public inhabituel de l'entité a une origine simple. L'enregistrement de rôle RIPEappelle SCC86-RIPE "support 3D CLOUD COMMUNICATION" et lui donne la responsabilité administrative via SP22450-RIPE. L'enregistrement de personneassocié identifie Slipych Pavlo. Ces enregistrements ont été créés le 31 décembre 2025. Ce sont des preuves de contact et de responsabilité utiles, mais le mot "support" ne doit pas être confondu avec un nom commercial, un service d'assistance doté en personnel ou une promesse de niveau de service.

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

Ces dates fixent une limite essentielle. Une société constituée en juillet 2025 ne peut pas revendiquer la vie opérationnelle d'un système autonome vu pour la première fois en 2011 simplement parce que le numéro lui est maintenant rattaché. Elle peut avoir acquis des droits, des contrats, des équipements ou une expertise d'un opérateur antérieur, mais aucun compte rendu de transaction publique n'établit ce qui a été transféré. La société actuelle peut être évaluée à partir de sa propre constitution, de ses registres actuels et de son comportement observable.

Le numéro plus ancien reste un contexte technique pertinent, pas une biographie d'entreprise héritée.

Le registre légal réduit également ce qui peut être dit en toute sécurité sur la propriété. La société est présentée comme entièrement détenue par une seule personne, pas comme une filiale déclarée d'un plus grand groupe d'hébergement. Aucune garantie de société mère publique, bilan consolidé ou partenaire d'infrastructure nommé n'a été trouvé. 600 000 UAH de capital social établissent un engagement formel en capital; cela ne révèle pas la trésorerie disponible, le chiffre d'affaires annuel, l'inventaire des serveurs, la couverture d'assurance ou le montant disponible lors d'une panne prolongée.

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

Cela importe parce que 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'adresses et gérer l'escalade. Cela peut rendre les décisions rapides, mais cela peut aussi créer un risque lié à une personne clé. Les registres publics ne divulguent pas le nombre d'employés, la couverture des quarts de travail, la profondeur technique ou un roulement d'astreinte. Le rôle de contact prouve qu'un responsable existe. Il ne prouve pas qu'un deuxième ingénieur répondra lorsque le premier est indisponible.

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

L'activité principale enregistrée de la société est le KVED ukrainien 63.11: traitement des données, hébergement sur nœuds web et activités connexes. Les activités enregistrées supplémentaires 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 classer l'entreprise dans une catégorie cloud ou hébergement. C'est toujours une classification administrative plutôt qu'une description d'un produit en exploitation.

Une activité enregistrée ne dit pas si la société vend des machines virtuelles, des serveurs nus, des applications gérées, de la colocation, du stockage de sauvegarde ou seulement du conseil technique. Elle ne nomme pas d'hyperviseur, de plateforme de stockage, de portail de facturation, de gamme de systèmes d'exploitation, d'allocation de bande passante, de durée minimale, de canal de support ou de juridiction client. Elle ne montre pas de prix, de page de commande, de page de statut, d'avis client ou de 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 coupure.

La distinction est facile à manquer car "cloud" fait partie du nom de la société. Ladéfinition du cloud computing du NISTdécrit des caractéristiques telles que le libre-service à la demande, l'accès réseau large, la mise en commun des ressources, l'élasticité rapide et le service mesuré. L'activité légale soutient l'intention d'hébergement, tandis que les preuves publiques n'établissent pas ces caractéristiques opérationnelles. Un rack de serveurs provisionnés manuellement peut être un service d'hébergement utile sans être un cloud élastique. Inversement, une société peut revendre le cloud d'un tiers sans posséder de rack. Le nom seul ne résout aucun des deux cas.

Lesynopsis et recommandations cloud du NISTdistingue également les arrangements de service et de déploiement et souligne 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'alimentation, 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 partie différente de la chaîne. Si elle gère les équipements clients, la responsabilité change à nouveau. Aucun contrat public n'alloue ces tâches.

Le régulateur ukrainien des communications publie unregistre mensuel des fournisseurs de réseaux et services de communications électroniques, avec la page de données mise à jour le 2 juillet 2026. Une société qui prévoit de vendre du transport internet peut nécessiter une posture réglementaire différente d'une entreprise vendant de l'informatique 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 société. La conclusion sûre est limitée: ses activités corporatives permettent une hypothèse d'hébergement; elles ne prouvent pas ce qu'elle vend actuellement ni le caractère réglementaire du service.

Deux anciens numéros réseau sont arrivés dans 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 visibles de systèmes autonomes pour AS56421 et AS39755 ont été modifiés pour pointer vers cette organisation. Les deux conservent le nom ASEurolir-AS, une étiquette qui ne correspond pas au nouveau nom légal. Aucune des deux divergences n'est automatiquement problématique, mais elles montrent toutes deux pourquoi chaque champ doit être lu par date et fonction.

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

L'enregistrement d'AS39755a une date de création d'objet actuelle en mai 2018, tandis que lavue de statut de RIPEstatcontient des observations plus anciennes se terminant en juillet 2010. Des enregistrements de registre réémis ou reconstruits peuvent produire ce type de chronologie. Le point pertinent pour un client est plus simple: l'aperçu actuel d'AS39755le marquait comme non annoncé, et aucun préfixe actuel n'était visible depuis lui à la date de coupure.

Posséder ou sponsoriser un enregistrement de système autonome peut être utile avant le début du trafic. Cela permet à un réseau de définir une politique et d'arranger des sessions amont. Pourtant, un ASN n'est pas un routeur, une fibre, un rack ou un mégabit de transit acheté. C'est un identifiant utilisé pour exprimer un domaine de routage. L'explication des numéros de système autonome par le RIPE NCCest explicite: un ASN supporte une politique de routage externe distincte. L'identifiant peut être prêt bien avant que l'équipement ne soit installé, ou rester enregistré après l'arrêt du trafic.

La société actuelle a donc deux identifiants enregistrés mais un seul avec un signal opérationnel récent. Cette asymétrie devrait façonner toute revendication 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 aurait besoin de voir comment chaque numéro est utilisé, si les deux sont configurés sur des équipements séparés, et si un service peut se déplacer entre eux sans renumérotation ni temps d'arrêt prolongé.

Un /24 n'est devenu visible que quelques jours avant la publication

AS56421 est passé d'un indice d'enregistrement à un indice opérationnel 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. C'est une preuve inhabituellement récente: elle indique que l'ASN contrôlé par la société avait atteint au moins une partie du système de routage global, non qu'il l'avait fait depuis des mois.

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

Le préfixe contient 256 adresses IPv4. Même ce nombre simple doit être borné. Les conventions de réseau et de diffusion, les adresses de routeur, les pratiques d'allocation client, le filtrage et la réservation peuvent réduire l'espace assignable. Une adresse peut héberger de nombreux services virtuels derrière une traduction ou un 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.

C'est aussi la longueur de préfixe IPv4 minimale habituellement acceptée par une grande partie de l'Internet global, donc c'est une unité naturelle à annoncer même pour un petit périphérique.

Aucune origine IPv6 de la société n'a été établie à la date de coupure. Une preuve uniquement IPv4 ne rend pas un service d'hébergement inutilisable, mais elle rétrécit ce qui a été démontré. Un service moderne peut fournir IPv6 via un réseau parent, un proxy ou un autre arrangement de routage sans annoncer son propre bloc. Il n'y a simplement aucune base publique pour dire que 3D CLOUD COMMUNICATION offre IPv6 client, gestion dual-stack ou un chemin de migration testé entre les familles d'adresses.

La courte fenêtre d'observation est le fait de capacité le plus important. Une route visible depuis deux jours peut transporter du trafic de production, du trafic de test, une migration ou un nouveau segment client. Le routage public ne divulgue pas lequel. 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 de bande passante ou les comptes facturables. Traiter le /24 comme une preuve d'un domaine cloud confondrait l'accessibilité des adresses avec l'offre de calcul.

Le même bloc avait encore deux origines

L'événement de juillet n'était pas un remplacement propre dans la vue publique. L'aperçu de préfixe de RIPEstatidentifiait à la fois AS48693 et AS56421 comme origines. Une route annoncée depuis plus d'un système autonome est communément appelée condition multi-origine AS, ou MOAS. Elle peut être intentionnelle: les opérateurs utilisent des annonces qui se chevauchent lors de migrations, de multi-hébergement client, d'atténuation de DDoS et d'ingénierie du trafic. Elle peut aussi résulter d'une erreur ou d'une annonce non autorisée. L'observation seule ne décide pas de l'explication applicable.

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

Le nommage inverse restait également associé au réseau antérieur. Lavue de bloc d'IPinfolistaitgw.reserved.ntup.netpour la première adresse de passerelle etfree.ntup.netsur une grande partie de la plage dans son observation indexée. Le DNS inverse peut prendre du retard sur un transfert ou un bail légitimes, et les étiquettes génériquesfreene prouvent pas que les adresses sont inactives. Elles montrent cependant que le nommage public n'avait pas encore été retravaillé en un domaine de service reconnaissable de 3D CLOUD COMMUNICATION.

L'autorisation d'origine de route n'a pas réglé la question. Lerésultat de validation RPKI de RIPEstatretournaitunknown, sans autorisation d'origine de route validante pour la combinaison AS56421 et /24. Inconnu n'est pas invalide. Cela signifie que les parties prenantes n'avaient aucune déclaration cryptographique dans l'infrastructure de clé publique des ressources (RPKI) qui autorisait ou rejetait cette origine. L'aperçu RPKI du RIPE NCCexplique comment les autorisations d'origine de route permettent aux détenteurs de spécifier quel AS peut annoncer un préfixe.

Le risque pratique est la divergence. Certains réseaux peuvent préférer le chemin via AS48693, d'autres 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 atteindre des destinations différentes ou perdre la connectivité. Si l'arrangement est intentionnel et que les deux chemins convergent correctement, il peut supporter une transition.

Une lettre d'autorisation publique, une autorisation d'origine de route couvrant l'origine prévue, un enregistrement de préfixe mis à jour et une date de migration claire distingueraient une transition contrôlée d'un chevauchement non résolu.

La politique amont enregistrée est plus large que le transport 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. Le 7 juillet, il a été mis à jour à nouveau pour ajouter AS41033 et AS209155. Cela semble diversifié sur le papier. Une déclaration d'importation RPSL décrit cependant une 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 le chemin alternatif a une capacité suffisante pendant une panne.

À la date de coupure du 10 juillet, l'observation de voisin de RIPEstatvoyait un voisin gauche: AS41033. L'état BGP spécifique au moment montrait également les chemins AS56421 passant par AS41033. C'est une preuve opérationnelle pour une route amont. Ce n'est pas une preuve que les huit relations enregistrées plus anciennes étaient actives au même moment.

AS41033 est lui-même un réseau d'interconnexion substantiel. Sonenregistrement PeeringDBidentifie D2 CLOUD COMMUNICATIONS et liste une présence sur les échanges publics ainsi que des installations à Kiev, Varsovie, Francfort, Amsterdam et d'autres lieux. Lesite webde l'opérateur présente des services réseau. Ces faits aident à caractériser l'amont. Ils ne localisent pas le routeur d'AS56421. Une session client peut atteindre un amont étendu depuis une interconnexion locale sans occuper chaque installation que l'amont liste.

Cette distinction importe pour la région mondiale assignée. Une route portée par un réseau avec une 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. Le bord de routage vérifié utilisait un amont connecté internationalement. La zone de service, les pays de contractualisation, les devises de facturation, les langues de support et les choix de placement des données n'étaient pas établis publiquement.

Un amont observé laisse également une question de rétablissement de base. Si AS41033 retire la route, AS56421 a-t-il une deuxième session active avec une capacité indépendante? L'enregistrement suggère des candidats possibles, mais une réponse testée nécessite des observations de routage simultanées ou une documentation du fournisseur. Même deux chemins AS observés peuvent partager une seule entrée de fibre, une seule salle de rencontre, un seul routeur, une seule alimentation électrique ou un seul corridor métropolitain. La diversité logique est précieuse; l'indépendance physique nécessite des preuves supplémentaires.

Une adresse à Kiev n'est pas un plan de racks

Les registres légaux et RIPE placent la société au 39 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, du traitement du courrier, des locaux commerciaux partagés ou des installations dans lesquelles l'équipement est également présent. Aucun des registres de la société 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écom authentique. Lesite public de R-TELutilise la même adresse et fait la promotion d'Internet entreprise et d'un support 24h/24. Leregistre corporatif de R-TELplace également la société de télécommunications là-bas. Lapage de contact d'Orionliste l'adresse pour les services Internet, tandis que leregistre de la société 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 un espace technique, ou simplement héberger plusieurs locataires sans lien. Une photographie de la salle des serveurs d'un autre opérateur n'établirait pas la propriété des machines de la société. Une adresse postale commune n'établirait pas un chemin de fibre protégé. La preuve nécessaire est ordinaire et spécifique: le nom de l'opérateur de l'installation, le pays et la ville, que la société possède ou loue l'espace rack, les limites de puissance du rack, les entrées opérateur, les fournisseurs d'interconnexion, les contrôles d'accès et la partie responsable des mains distantes.

La localisation physique façonne plus que la latence. Elle détermine le réseau électrique, la logistique du carburant du générateur, l'environnement de refroidissement, les contrôles d'incendie, l'exposition à la protection civile, le temps de trajet du technicien et la loi régissant les données stockées. Kiev fonctionne sous pression d'infrastructure 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 supposer une panne particulière.

La société n'a pas publié son plan de site, la durée de l'alimentation de secours ou l'emplacement de reprise.

Un client devrait donc résister à deux erreurs opposées. La première est de déduire que l'adresse légale est un centre de données et d'attribuer chaque actif télécom à proximité à la société. La seconde est de déduire qu'aucune infrastructure n'existe parce qu'aucun plan de site public n'a été trouvé. Les petits fournisseurs opèrent souvent depuis des espaces loués sans marketing extensif. L'évaluation correcte est plus étroite: un nexus opérationnel à Kiev est plausible et l'adresse a des associations télécom, 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 par le client dépend d'un ensemble d'actifs finis. À la base se trouvent un bâtiment, une arrivée électrique, des commutateurs, des batteries, des générateurs ou autre alimentation de secours, le refroidissement, les contrôles d'incendie et la sécurité physique. Au-dessus se trouvent les racks, la distribution électrique, les serveurs, le stockage, les commutateurs, les routeurs, les optiques et le câblage. Le transit, l'espace d'adressage et le routage rendent le système accessible.

La facturation, la surveillance, les sauvegardes, les identifiants et les techniciens transforment la machine 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 un bord réseau accessible. L'adresse de Kiev pointe vers un emplacement légal et de contact. Cela 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 nommé, fournisseur d'équipement, couche de virtualisation, plateforme de sauvegarde ou système de surveillance n'a été lié publiquement à la société.

Cela crée une limite de propriété qu'un contrat doit résoudre. La société peut posséder le matériel mais louer le rack et l'alimentation. Elle peut louer des serveurs auprès d'un autre hôte et ne contrôler que le logiciel et la facturation. Elle peut revendre des instances virtuelles et n'exploiter aucune machine physique. Elle peut fournir une gestion pour des systèmes appartenant au client. Chaque arrangement peut fournir un service légitime, mais le propriétaire de la panne change. Une panne électrique d'installation est escaladée différemment d'un disque loué défaillant; un différend 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 arrangement pourrait être une utilisation autorisée de type provider-independent, un bail ou une transition, mais les registres publics n'énoncent pas les termes commerciaux. Si l'accès au bloc dépend de l'accord d'une autre partie, la résiliation ou le litige peut forcer une renumérotation.

Pour les clients qui placent sur liste blanche des adresses, publient des enregistrements DNS ou lient des licences aux IP, la renumérotation peut devenir une interruption d'activité.

Il en va de même pour le transport amont. Si un fournisseur fournit tout le transit actuellement utilisable, un défaut de paiement ou de contrat peut supprimer l'accessibilité même si les serveurs restent sous tension. Si une relation de revendeur fournit le matériel, des paiements manqués peuvent menacer l'accès au calcul séparément. La facture cloud cache ces dépendances parce que le client paie une seule contrepartie. Une due diligence devrait reconstruire la chaîne et identifier où l'entreprise peut réparer directement et où elle ne peut qu'ouvrir un ticket chez quelqu'un d'autre.

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

Le seul actif réseau quantifié face à 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 garanti, de tolérance de rafale, de total de stockage, de nombre de cœurs, de pool 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 même chose que la marge de trafic, et le stockage brut n'est pas la même chose que la capacité client protégée.

Considérons une liaison montante hypothétique de 10 Gbps. Son libellé décrirait la vitesse d'interface, pas 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 encore être congestionné à un gigabit. Deux ports de dix gigabits sur un routeur peuvent tomber en panne ensemble. Aucun chiffre de port n'est actuellement attribuable à 3D CLOUD COMMUNICATION, donc même cette comparaison élémentaire ne peut pas être faite.

La capacité de calcul a des pièges similaires. Un hôte peut contenir des dizaines de cœurs de processeur tandis que la sursouscription fait que les charges de travail occupées entrent en contention. Le stockage finement provisionné peut montrer beaucoup plus d'espace logique que de support physique. Les copies de réplique peuvent améliorer la disponibilité tout en consommant une capacité qui n'est pas vendable. Les données de sauvegarde peuvent partager la même baie ou le même domaine électrique que la production.

Sans preuves d'utilisation, de réservation, de domaine de défaillance et de restauration, un chiffre de catalogue n'établirait toujours pas une résilience utilisable.

Le nombre d'adresses IPv4 est particulièrement faible en tant que proxy. 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 équipements réseau et les assignations de réserve en consomment d'autres. Lavue des préfixes annoncés de RIPEstatmontrant un /24 indique que le bord avait une petite empreinte IPv4 routable. Cela ne dit rien sur combien d'adresses étaient allouées aux clients ou si le bloc transportait des services de calcul du tout.

Une déclaration de capacité crédible séparerait les ressources installées, allumées, sous contrat, occupées et disponibles. Pour le réseau, cela signifie vitesse de port, engagement payé, pic normal, pic en cas de panne et diversité de route. Pour le calcul, cela signifie hôtes physiques, surcharge réservée, politique d'allocation et marge restante. Pour le stockage, cela signifie capacité brute, protégée, utilisée et restaurable. Aucune de ces couches n'est publique pour la société, donc l'article ne peut pas convertir de manière responsable la nouvelle route en une revendication de capacité disponible pour le client.

Le premier chemin de défaillance est la route elle-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 à la même extrémité, la coordination doit maintenir les deux chemins cohérents pendant la transition. S'ils mènent à des extrémités différentes, la sélection de route peut diviser les utilisateurs. Un retrait accidentel par une origine peut améliorer ou détériorer l'accessibilité selon le chemin que préférait un réseau. Sans autorisation d'origine de route, la validation cryptographique d'origine ne clarifie pas l'origine prévue.

Une entrée d'objet de route est utile mais pas un contrôle de sécurité complet. BGP, normalisé dans laRFC 4271, échange l'accessibilité selon la politique et les attributs de chemin; il n'authentifie pas nativement que l'organisation d'origine possède le préfixe. Le 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 autorisation valide n'empêcherait pas chaque fuite ou panne, mais elle réduirait l'ambiguïté pour les réseaux qui appliquent la validation d'origine de route.

Le prochain chemin de défaillance est la perte de l'amont. À l'observation spécifique au moment, AS41033 était le seul voisin visible pour AS56421. Une panne de routeur, une défaillance d'interconnexion, une suspension commerciale ou une erreur de politique amont pourrait supprimer la nouvelle origine. La liste plus longue dans l'enregistrement pourrait devenir une redondance réelle, mais jusqu'à ce que plusieurs chemins vivants apparaissent et puissent porter la charge complète, elle reste une politique planifiée ou historique plutôt qu'une capacité de rétablissement démontrée.

Vient ensuite le bord local. Les preuves publiques ne montrent pas si AS56421 fonctionne sur un routeur ou plusieurs, si les sessions de route se terminent sur des châssis séparés, ou si les configurations sont sauvegardées. Une seule alimentation défaillante, configuration corrompue, optique expiré ou console inaccessible peut vaincre plusieurs amonts nominaux. Le matériel de rechange et l'accès hors bande déterminent souvent le temps de rétablissement plus que le nombre de transporteurs dans un enregistrement.

Enfin, il y a le DNS et la continuité d'adresse. Les noms inverses plus anciensntup.netsuggèrent que l'administration du nommage traverse encore une frontière organisationnelle. Le DNS client direct peut être ailleurs, mais aucun service faisant autorité n'a été identifié. Lors d'une migration de préfixe, le DNS obsolète, les listes blanches, les liaisons TLS, les bases de données de géolocalisation et la réputation anti-abus peuvent continuer à pointer vers le réseau précédent. Le déménagement technique n'est complet que lorsque ces systèmes environnants sont mis à jour et que les clients savent ce qui a changé.

L'alimentation, le stock de matériel et la réparation humaine restent des espaces vides

Une route réseau peut sembler saine alors que chaque serveur client derrière elle est indisponible. Le service physique dépend de l'alimentation et du refroidissement à chaque rack. Aucune déclaration publique ne donne les alimentations utilitaires de la société, la disposition UPS, la capacité du générateur, la durée du carburant, la redondance du refroidissement ou le calendrier de maintenance. L'adresse partagée de Kiev ne peut pas remplir ces champs car les opérateurs voisins peuvent utiliser des salles, des alimentations 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éplique testée existent. Cela peut devenir une panne prolongée si un remplacement doit traverser une frontière, si le firmware diffère ou si le seul ingénieur compétent est indisponible. La société n'a pas divulgué les fournisseurs de serveurs, la protection de stockage, les ratios de pièces de rechange, les conditions de mains distantes ou les objectifs de remplacement.

Ce n'est pas une preuve que les pièces de rechange sont absentes; cela signifie 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 la société identifie un directeur et les registres 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'a été trouvé. Le label "support" lui-même ne peut pas remplacer une réponse de ticket testée.

La facturation appartient également à 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 délais de grâce, de traitement des litiges, d'avis de renouvellement et d'un moyen d'exporter les données avant la résiliation. Aucun terme public 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 la société, des définitions de sévérité, des objectifs de réponse et de restauration, des règles d'avis de maintenance, des conditions de crédit, et une escalade téléphonique qui est testée. Un fournisseur peut être petit et publier des obligations claires. Dans ce cas, le contact public basé sur Outlook dans les vues du registre et le rôle générique établissent l'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 devrait être testée une couche à la fois. Deux machines virtuelles sur un seul hôte ne protègent ni contre la panne de l'hôte ni contre la perte de puissance 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 électrique défaillante. Deux racks dans une salle peuvent partager le refroidissement et l'alimentation du bâtiment. Deux sites connectés via un seul transporteur peuvent partager la même route. La redondance n'existe que lorsque l'alternative survit à la défaillance pertinente.

Aucun second site de 3D CLOUD COMMUNICATION n'a été vérifié. Aucun matériel public ne nomme une région de sauvegarde, une zone de disponibilité, un emplacement de réplique 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 route ne localise pas le calcul. La portée globale d'AS41033 ne la fournit pas car la liste d'installations d'un amont n'est pas la liste d'installations du client.

Le rétablissement nécessite également de l'état. Le trafic web sans état peut se déplacer rapidement si le DNS, les certificats et le déploiement d'application sont préparés. Une base de données a besoin de répliques cohérentes ou de sauvegardes restaurables. Une machine virtuelle peut avoir besoin d'images disque, de clés, de paramètres réseau et d'assez de capacité de calcul à destination. La société n'a pas publié d'objectifs de point de récupération ou de temps de récupération, de rétention des sauvegardes, de résultats de test de restauration ou de l'étendue d'une offre de reprise après sinistre.

L'évaluation des risques du cloud computing d'ENISAtraite la dépendance au fournisseur, le traitement des données, la continuité des activités et la défaillance technique comme des risques connectés. Ce cadre correspond à ce cas. Un second site n'a d'importance que si le client peut l'atteindre, si les données y sont, si le système d'identité fonctionne, si le fournisseur a l'autorité de l'activer et si le contrat permet le déplacement. Une épingle sur une carte n'est pas un rétablissement.

Les preuves qui augmenteraient la confiance incluent deux installations nommées dans des domaines de puissance et de risque métropolitain distincts, des routes actives via des amonts indépendants, une réplication documentée, un exercice de restauration récent et des instructions client pour exporter les données. Les preuves qui l'augmenteraient davantage incluent des temps de rétablissement mesurés et la confirmation que la capacité réseau et de calcul du chemin de secours peut porter la charge de production. Rien n'était public à la date de coupure.

La localisation des données ne peut pas être déduite de l'adresse de la société

Le sujet assigné de la souveraineté des données est pertinent précisément parce que l'emplacement n'est pas résolu. Une adresse légale à Kiev établit le nexus juridictionnel de la société. Elle n'établit pas où les données clients, les sauvegardes, les journaux ou les copies de support sont stockés. Un serveur pourrait être dans le même bâtiment, ailleurs en Ukraine, dans un autre pays européen ou sur une plateforme de sous-traitant. Le chemin de 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 un. Le premier est le site de calcul principal. Le second est le site de sauvegarde ou de réplique. Le troisième est l'emplacement à partir duquel 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 disant seulement que le fournisseur est ukrainien laisse la géographie physique et opérationnelle ouverte.

La portabilité est l'autre côté de la souveraineté. Un client doit savoir s'il peut exporter des disques virtuels, des dumps de base de données, des données d'objet, des journaux et des clés de chiffrement dans des formats utilisables. Il doit savoir combien de temps une exportation prend, quelles limites de bande passante s'appliquent, et si des frais ou des arriérés peuvent bloquer l'accès. Le nouveau /24 et le chevauchement d'adresses persistant rendent la portabilité réseau particulièrement concrète: un client ne devrait pas supposer qu'une IP assignée peut le suivre chez un autre fournisseur.

Les chemins de migration ont également besoin de temps et de coopération. Les valeurs de durée de vie DNS peuvent être abaissées, les répliques peuvent être amorcées, et les données peuvent être copiées avant un basculement. Mais un contrat de fournisseur résilié peut supprimer le temps nécessaire pour un déménagement ordonné. Aucun terme de résiliation, suppression, séquestre ou exportation n'a été trouvé pour 3D CLOUD COMMUNICATION. Les acheteurs devraient traiter la sortie des données comme une dépendance non tarifée et non vérifiée jusqu'à ce que ces termes soient fournis.

Les preuves ne soutiennent pas une affirmation selon laquelle les données clients sont en dehors de l'Ukraine, ni une affirmation qu'elles restent à l'intérieur. Elles soutiennent seulement la nécessité d'un calendrier de localisation écrit. Ce calendrier devrait identifier les villes et les pays, les opérateurs d'installations, la géographie des sauvegardes, l'administration à distance, les sous-traitants, le calendrier de suppression et la loi régissant les litiges. Sans cela, "Global" décrit une portée réseau potentielle, 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 rivaliser en achetant des intrants en gros et en ajoutant une gestion réactive. L'économie peut être attractive: les unités de rack louées évitent de construire une installation; les serveurs loués réduisent les dépenses en capital; les arrangements de transit et d'adresses peuvent être achetés de manière incrémentielle; une petite équipe peut automatiser le provisionnement de routine. Les clients peuvent recevoir plus d'attention directe que d'une plateforme hyperscale. Aucun de ces avantages n'exige que le fournisseur possède un bâtiment.

La même structure crée une dépendance au renouvellement et à la marge. Le loyer du rack, l'électricité, le transit, l'utilisation des adresses, les locations 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'introduction bas peut être durable 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 cette distinction ici.

Le capital social de 600 000 UAH ne doit pas être interprété comme des dépenses d'infrastructure. Il peut soutenir les opérations de démarrage, mais le chiffre légal ne dit pas s'il a acheté de l'équipement, reste liquide ou couvre une quelconque responsabilité particulière. La page publique de la société ne fournissait pas de revenus, d'actifs, de dettes, de nombre d'employés ou de comptes audités pour une année d'exploitation complète. La société avait moins d'un an à la date de coupure de la recherche.

L'action technique la plus récente – annoncer un /24 via un amont observé – est cohérente avec une activité de début ou de changement d'opérations réseau. Ce n'est pas suffisant pour 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 disantfreesont suggestifs mais pas décisifs. Un catalogue orienté marché, des factures, des références clients, des rapports d'utilisation ou un historique de statut de service fourniraient des preuves opérationnelles plus solides.

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é, l'amont, la contrepartie de l'espace d'adressage, le loueur d'équipement, le fournisseur de logiciel et le personnel de support. Le fournisseur devrait être capable d'identifier quelles dépendances sont prépayées, au mois ou annulables, et ce qu'il advient des données client si un contrat se termine. Un seul frais mensuel bas n'est pas une mesure de résilience à moins qu'il ne finance ces obligations.

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

Plusieurs signaux publics pointent dans une direction cohérente. La société a choisi une activité d'hébergement, adopté un nom cloud, créé des contacts RIPE, est devenue l'organisation sur deux enregistrements de systèmes autonomes et a initié une nouvelle origine via un amont de marque cloud. Son adresse enregistrée est partagée par des entreprises de télécommunications. Ensemble, ces faits suggèrent une tentative d'établir ou d'acquérir une opération 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 location d'installation. Le chevauchement d'adresses ne peut pas prouver une relation avec R-TEL ou Orion. La liste d'installations de l'amont ne peut pas prouver où se trouve le routeur de la société. Le DNS inverse ne peut pas prouver que les adresses sont inutilisées. Un objet de route ne peut pas prouver que chaque partie commerciale pertinente a approuvé l'origine. Le MOAS ne peut pas prouver une transition bénigne ou un événement hostile sans plus de contexte.

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

Ce qui réglerait la question commerciale est simple. Un site web contrôlé par la société devrait nommer le vendeur légal et le numéro d'entreprise, décrire les produits et prix, publier les conditions, identifier les canaux de support, divulguer les emplacements des données et expliquer l'annulation. Ce qui réglerait la question d'infrastructure est une déclaration d'installation et de réseau identifiant les limites de l'opérateur de rack, les amonts actifs, l'autorisation de route, les engagements de port, IPv6, les sites de sauvegarde et le rétablissement testé.

Ce qui réglerait la question de statut opérationnel est un routage soutenu plus une activité orientée client dans le temps.

Jusqu'à ce que ces éléments apparaissent, la dégradation correcte est explicite. La société n'est pas un nom fictif: c'est une SARL ukrainienne enregistrée avec des registres réseau actuels 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 la société contre des affirmations que les preuves ne peuvent pas porter.

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

Avant de placer une charge de travail de production, un client devrait demander à la société d'identifier la partie contractante légale comme LLC "3D CLOUD COMMUNICATION" et d'utiliser le numéro d'entreprise 45920348 sur le contrat et la facture. Le contrat devrait 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 devrait identifier quels actifs la société possède et lesquels sont fournis par d'autres opérateurs.

Le calendrier réseau devrait indiquer les préfixes clients, les amonts, l'AS d'origine attendu, le statut de l'autorisation d'origine de route et la conception du basculement. Pour le /24 actuellement visible, il devrait expliquer les annonces concurrentes AS48693 et AS56421, identifier l'autorisation du détenteur d'adresses et donner une date d'achèvement s'il s'agit d'une migration. Les clients devraient savoir si les adresses sont portables, comment la renumérotation est gérée et si un changement de route déclenche un avis.

Le calendrier des installations devrait nommer la ville, le pays et l'opérateur pour le service principal et de sauvegarde. Il devrait décrire la puissance du rack, l'alimentation de secours, le refroidissement, l'accès physique, les mains distantes et les entrées opérateur à un niveau approprié pour la due diligence. Les plans d'étage sensibles ne sont pas nécessaires; les limites de propriété et de défaillance ne le sont pas non plus. S'il n'y a qu'un seul site, le contrat devrait le dire clairement et éviter d'impliquer une redondance géographique.

Le calendrier de service devrait définir la disponibilité, les exclusions, la maintenance, la sévérité, la réponse, la restauration, les crédits et l'escalade. Il devrait 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. Il devrait dire quelles pannes l'entreprise répare directement et lesquelles dépendent d'un ticket d'installation ou d'amont. Il devrait également traiter de la perte d'un ingénieur nommé.

Le calendrier de sortie devrait être aussi détaillé que la commande. Les clients ont besoin de formats d'exportation d'images machine et de données, de limites de débit et de frais, de rétention après annulation, de confirmation de suppression, d'accès pendant les litiges et d'assistance pendant la migration. Ils devraient conserver leurs propres sauvegardes et identifiants indépendants. Un service qui ne peut pas être quitté de manière prévisible n'est pas entièrement contrôlé par le client, quelle que soit la facilité avec laquelle il a été acheté.

Enfin, les preuves devraient être actualisées après la transition de routage de juillet. Une visibilité d'origine soutenue, la suppression ou l'explication de l'origine plus ancienne, une autorisation d'origine de route valide, un transit alternatif actif et un nommage inverse cohérent amélioreraient matériellement la confiance réseau. Une page produit publique, des conditions légales et un historique de statut amélioreraient la confiance commerciale. Des preuves d'installation et de restauration amélioreraient la confiance en la résilience. Chacune comble une lacune différente; aucune ne peut remplacer toutes les autres.

La note honnête est un bord actif avec des preuves de service faibles

Il y a plus ici qu'un 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 amont observé immédiatement avant la publication. Ce sont des faits significatifs.

Les faits s'arrêtent avant l'implication commerciale la plus forte du titre. Aucune offre orientée client liée à la société 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 multi-origine, attribué à une autre organisation, avec un statut RPKI inconnu et un nommage inverse plus ancien. Le second ASN enregistré était inactif. La zone de service et la géographie des données restaient non spécifiées.

Cette combinaison soutient une note de preuve réseau Faible, pas une conclusion que la société est inactive. C'est un jeune opérateur légal avec un bord nouvellement actif et un grand écart de divulgation. La route peut mûrir, la transition d'adresse peut s'achever et du matériel commercial peut émerger. Au 10 juillet 2026, les acheteurs devraient traiter la capacité hébergée, la redondance et le service mondial comme des affirmations nécessitant une preuve directe.

La leçon physique est plus large mais spécifique à l'entreprise dans ses détails. Un nom cloud peut être enregistré en un jour; un ASN peut précéder son détenteur actuel de quinze ans; un /24 peut apparaître via un fournisseur de transit en quelques heures. Un hébergement fiable prend plus de temps car il nécessite que l'alimentation, 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 attend encore d'être montrée.