Résumé

  • CLOUD COLIBRI S.A possède une identité publique spécifique dans les registres Internet. LACNIC enregistre l'entreprise à La Ceiba, au Honduras, comme titulaire actif de l'AS269866 et du préfixe2803:6760::/32, avec Julian Palacios désigné comme représentant légal et contact administratif, technique et abus.
  • Le réseau n'est pas simplement réservé. RIPEstat a observé le préfixe IPv6/32annoncé par AS269866 du 1er au 15 juillet 2026, visible par l'ensemble des 322 pairs IPv6 au moment de la capture. Son origine exacte a également renvoyé un statutvalidsous RPKI, avec une autorisation limitée au/32.
  • La preuve de service est beaucoup plus mince. Le fournisseur annonce des serveurs virtuels KVM et Xen, un redimensionnement automatisé, de l'hébergement géré, une sauvegarde quotidienne, un support 24 heures sur 24 et une disponibilité à 100 %, mais ses pages conservent un pied de page de 2019, ne fournissent aucun résultat client nommé ni historique d'état de service, et acheminent le site web public via un agrégat IPv4 d'un autre opérateur.
  • La localisation et la responsabilité nécessitent des réponses contractuelles. Une adresse d'enregistrement au Honduras ne localise pas les données des clients; le registre publie également un contact technique à New York, des mesures tierces placent des points de terminaison IPv6 visibles à New York, et le contact de facturation public a renvoyé une erreur serveur lors de l'examen. Les acheteurs ont besoin d'une carte des données copie par copie, d'un schéma réseau à jour, de preuves de récupération et d'obligations de support spécifiques à la gravité.

Un véritable détenteur de ressources se cache derrière le nom

Les acheteurs de cloud rencontrent souvent un nom d'entreprise avant de trouver des preuves que l'entreprise contrôle une infrastructure. CLOUD COLIBRI S.A franchit ce premier obstacle. Leenregistrement LACNIC pour AS269866identifie une allocation directe active à CLOUD COLIBRI S.A, avec une adresse sur le Boulevard 15 de Septiembre à côté de l'INFOP à La Ceiba, Honduras. Le système autonome a été enregistré le 5 décembre 2019. L'enregistrement nomme Julian Palacios comme représentant légal et lui attribue les rôles de contact administratif, technique et abus via une adresse e-mail surcloudcolibrisa.com.

L'enregistrement LACNIC pour2803:6760::/32rend l'identité plus concrète. Il marque l'allocation IPv6 comme active, date son enregistrement au 24 octobre 2019 et nomme la même entreprise, adresse et représentant. L'allocation et le système autonome sont donc liés par plus qu'une étiquette similaire: ils partagent l'identifiant d'organisation du registre, la chaîne de contact public et le représentant légal.

Cette attribution est utile, mais sa portée est importante. Un registre Internet fait autorité pour l'enregistrement des ressources; ce n'est ni un registre des sociétés, ni un état de propriété audité, ni un certificat d'installation. Le registre public ne révèle pas les détails de constitution, les actionnaires, le pouvoir de signature, les comptes ou la relation entre CLOUD COLIBRI S.A et chaque actif utilisé pour fournir le service.

Un client devrait toujours obtenir un extrait actuel du registre hondurien, vérifier qui peut engager l'entreprise et s'assurer que le nom du contrat correspond au détenteur de ressources qu'il s'attend à voir opérer le réseau.

La distinction est pratique, pas cérémoniale. Si un incident implique la réputation d'adresse, le contrôle de routage ou la gestion des abus, AS269866 donne à l'acheteur un opérateur réseau identifiable et un contact d'escalade publié. Si le litige concerne plutôt une sauvegarde défaillante, un hyperviseur indisponible ou un remboursement impayé, le registre ne peut pas établir quelle entreprise possédait le serveur, employait l'ingénieur ou acceptait l'obligation de service. Un enregistrement d'identité peut soutenir une chaîne de responsabilité sans la compléter.

Le catalogue expose un modèle d'exploitation, mais pas ses résultats

Lapage d'accueil de Cloud Colibridécrit des machines virtuelles abstraites du matériel physique. Elle indique que chaque serveur reçoit un CPU garanti selon la taille, peut utiliser la capacité hôte disponible lorsqu'elle est libre, et peut être redimensionné par un clic ou un appel API. Le processus de redimensionnement indiqué met brièvement le serveur hors ligne, modifie sa RAM, son disque et son allocation CPU, puis le redémarre automatiquement. C'est une surface de contrôle concrète: les clients peuvent déduire que le fournisseur vend des machines virtuelles mutables plutôt que de simples comptes d'hébergement partagé statique.

Lapage des servicesdonne à l'offre une forme reconnaissable. Elle répertorie six plans KVM et Xen avec un ou deux cœurs CPU, 10 Go à 50 Go de disque, 1 Go à 4 Go de mémoire garantie, Linux ou Windows, accès root SSH ou RDP, hébergement géré, sauvegardes quotidiennes avec une restauration gratuite par mois, tolérance aux pannes et transfert de données illimité. Les prix mensuels affichés vont de 11 $ à 33 $. La page indique également que les charges de travail sont réparties sur un cluster, les serveurs étant attribués à des tâches individuelles afin qu'un compte ne dépende pas d'une seule machine.

Ces détails sont meilleurs qu'une étiquette cloud vide. Ils révèlent les choix de virtualisation, les privilèges clients, un mécanisme de redimensionnement et au moins un droit de sauvegarde. Ils laissent également la frontière de responsabilité inhabituellement ouverte. L'accès root suggère que le client peut administrer le système d'exploitation; l'hébergement « géré » suggère que le fournisseur peut le faire. Les pages ne disent pas qui corrige le système invité, gère les clés privilégiées, surveille la santé des applications, approuve un redémarrage d'urgence ou possède la configuration après la résiliation.

La promesse de sauvegarde a une ambiguïté similaire. « Quotidienne » n'identifie pas l'heure de capture, la période de rétention, l'emplacement de stockage, l'autorité de chiffrement, l'immuabilité ou l'objectif de point de récupération. Une restauration gratuite par mois est une allocation commerciale, pas un engagement de délai de récupération.

Un acheteur doit savoir si les restaurations supplémentaires sont simplement facturables ou limitées opérationnellement, si une restauration peut être demandée 24 heures sur 24, comment l'identité est vérifiée avant d'écraser les données et quand le fournisseur a récupéré avec succès un serveur comparable pour la dernière fois.

Le site fait également des affirmations substantielles sur les installations. Il répertorie l'alimentation sans interruption, l'alimentation depuis plusieurs réseaux, un générateur Caterpillar de haute capacité, des disjoncteurs dédiés, des contrôles biométriques, des détecteurs de mouvement, des patrouilles de gardes, des alarmes, la notification de la police et un accès continu pour les administrateurs système et le personnel de surveillance sur site.

Aucune de ces déclarations n'est accompagnée d'un nom d'installation, d'une adresse, d'une capacité, d'un historique de maintenance, d'un audit, d'une photographie liée au site ou d'un résultat de test. Elles définissent les questions de diligence; elles n'y répondent pas.

L'âge et l'état de la surface de vente sont également importants. Les deux pages publiques étaient en ligne lors de l'examen, mais chacune conservait un pied de page copyright 2019. Lepoint de contact clientlié a renvoyé une erreur serveur HTTP 500 lors de la capture. Un pied de page obsolète ne prouve pas une infrastructure obsolète, et un défaut applicatif transitoire ne prouve pas que le support est indisponible. Ensemble, ils rendent toutefois dangereux de considérer les plans, prix ou chemins de commande publiés comme actuels sans confirmation d'une personne responsable.

AS269866 est petit, visible et cryptographiquement autorisé

La preuve la plus forte au présent est la route elle-même. L'observation des préfixes annoncés de RIPEstata montré2803:6760::/32annoncé par AS269866 pendant toute la fenêtre d'observation du 1er au 15 juillet 2026. L'enregistrement du statut de routagea daté la première origine observée au 6 janvier 2022 et la dernière au 15 juillet 2026. Au moment de la capture, 322 des 322 pairs IPv6 rapportés voyaient la route.

Cette visibilité établit une présence durable et globalement propagée dans le plan de contrôle. Elle n'établit pas combien de clients utilisent le préfixe, combien de trafic il porte ou si les applications répondent de manière fiable. Un/32est une grande allocation IPv6 en termes d'adresses, mais le nombre d'adresses est particulièrement trompeur en IPv6: il ne doit jamais être converti en nombre de serveurs, utilisation ou échelle commerciale.

La route possède également un signal de sécurité positif. Lavalidation RPKI de RIPEstata renvoyévalid, soutenue par une autorisation d'origine de route nommant AS269866 pour le/32exact avec une longueur maximale de 32. Les réseaux qui appliquent la validation d'origine de route peuvent donc vérifier que cet agrégat est autorisé à provenir du système autonome de l'entreprise.

Le paramètre de longueur maximale est conservateur: il autorise l'agrégat, pas des routes plus spécifiques arbitraires. Cela peut réduire l'exposition accidentelle, bien que cela signifie également qu'une annonce d'urgence ou d'ingénierie du trafic plus longue que/32nécessiterait une autorisation modifiée pour être valide. RPKI ne protège pas un hyperviseur, ne chiffre pas les données, ne mesure pas la latence et n'empêche pas chaque fuite de route. Il répond à une question étroite et précieuse: si l'origine observée est cryptographiquement cohérente avec l'intention publiée du détenteur de ressources.

Le réseau a une dépendance visible étroite. L'observation des voisins de RIPEstata trouvé un seul réseau adjacent le 15 juillet, AS265680. IPinfo identifie ce réseau comme HNTELCO S.A et classe AS269866 comme un système autonome mono-hébergé. Les collecteurs publics ne voient pas chaque interconnexion privée ou sauvegarde dormante, ce n'est donc pas la preuve qu'un seul circuit physique existe. Cela montre toutefois que l'ensemble des sources ne contient pas de deuxième chemin visible indépendant.

Pour une charge de travail cloud, les questions suivantes sont simples. AS269866 a-t-il un deuxième fournisseur de transit, et si oui, ce chemin est-il normalement visible ou activé uniquement en cas de panne? Les circuits entrent-ils dans le bâtiment par des conduits indépendants? L'autorisation RPKI valide est-elle mise à jour lors du basculement? L'entreprise a-t-elle testé la perte d'AS265680 sans perdre l'accès de gestion, le DNS ou les routes clients? Un amont visible est une preuve de service; une alternative indépendante testée est une preuve de résilience.

Le site web public utilise un chemin d'exploitation IPv4 différent

L'empreinte de ressources visible d'AS269866 elle-même est exclusivement IPv6. Leprofil AS269866 d'IPinfone signale aucun préfixe IPv4 pour l'ASN et un amont IPv6, AS265680. Pendant ce temps,cloudcolibrisa.comet son sous-domaine de facturation résolvaient lors de l'examen vers45.186.152.254, une adresse IPv4 en dehors d'AS269866.

La trace du registre ne rend pas cette adresse sans rapport. L'enregistrement LACNIC pour le bloc contenant45.186.152.0/23indique que la plage a été réallouée à Julian Palacios et publie la même adresse à New York, le même numéro de téléphone et le même contact NOCcloudcolibrisa.comqui apparaissent dans la chaîne de contact d'AS269866. Mais lavue de route de RIPEstatne voit l'adresse qu'à travers le préfixe moins spécifique45.186.152.0/22, annoncé par AS266842.LACNIC identifie AS266842comme HNHOSTING.NET S.A., une autre organisation enregistrée à La Ceiba avec un représentant légal différent.

La conclusion la plus équitable est limitée. Il existe une relation de contact observable entre l'adresse du site web public de Cloud Colibri et son représentant nommé, tandis que la route est opérée sous le système autonome de HNHOSTING.NET. Les sources n'établissent pas de propriété commune, d'accord de revendeur, de contrat d'hébergement ou de division de responsabilité opérationnelle entre les deux entreprises.

Cette séparation est importante car le site web ne peut pas servir de démonstration que AS269866 délivre les serveurs virtuels annoncés par Cloud Colibri. Il prouve qu'une page de service de marque est accessible via une ressource IPv4 associée à son représentant. La route IPv6 en direct prouve séparément que l'entreprise contrôle une présence active de système autonome. Un acheteur devrait demander quel système autonome et quels préfixes son propre serveur utilisera réellement, qui gère un incident de routage ou d'abus IPv4, et si le portail de gestion dépend d'un réseau en dehors de la frontière de résilience annoncée du service.

La séparation peut être tout à fait ordinaire. Les petits fournisseurs combinent souvent des adresses possédées, de l'espace réalloué, du transit amont et des systèmes de contrôle hébergés. L'assurance vient de la documentation de cette combinaison: détenteur de ressources, origine de route, amont, opérateur DNS, hôte du portail, fournisseur d'atténuation et propriétaire d'escalade. Sans ce schéma, un client ne peut pas déterminer si un défaut dans une entreprise affecte uniquement le site marketing ou également le chemin vers son serveur de production.

Le Honduras est un ancrage d'identité, pas une réponse de localisation des données

L'enregistrement des ressources de Cloud Colibri est hondurien. L'entreprise et AS269866 sont associés à La Ceiba dans LACNIC, et l'entreprise est également apparue parmi les organisations honduriennes dans leregistre électoral 2024 de LACNIC. Ces faits soutiennent une identité institutionnelle hondurienne. Ils ne localisent pas un rack, un disque, une sauvegarde ou une session de support.

Le registre public pointe vers plusieurs juridictions. LACNIC donne à l'organisation une adresse à La Ceiba mais donne à son contact technique, administratif et abus nommé une adresse au 25 Broadway à New York. IPinfo indique que le réseau est enregistré au Honduras tandis que les points de terminaison IPv6 qu'il a pu mesurer étaient aux États-Unis; ses échantillons pingables récents ont été observés à New York. L'espace IPv4 servant le site officiel est également réalloué au représentant nommé à l'adresse de New York.

La géolocalisation IP est une inférence, pas un acte de propriété d'installation. Les adresses peuvent être enregistrées dans un pays, annoncées ailleurs, tunnelées, anycast ou étiquetées incorrectement par une base de données. Une observation de sonde d'une milliseconde depuis New York est cohérente avec une infrastructure proche mais n'identifie pas le bâtiment ni qui possède le matériel. La conclusion correcte n'est pas que le service de Cloud Colibri est définitivement à New York. C'est que le registre public ne justifie pas une hypothèse selon laquelle les données des clients restent au Honduras.

Un client avec des exigences de résidence, de souveraineté ou de latence a besoin d'un schéma de données pour le plan acheté. Il devrait localiser les disques primaires, les répliques, les sauvegardes quotidiennes, les panneaux de contrôle, les enregistrements d'authentification, les données de surveillance, les pièces jointes des tickets et les journaux du fournisseur. Il devrait identifier les sous-traitants et les administrateurs à distance, distinguer les données au repos des données consultées lors du support, et expliquer ce qui se déplace lors du basculement.

Le contrat devrait également indiquer si un client peut choisir un emplacement et quelles preuves de suppression sont fournies après la sortie.

Le langage sur les installations du site web rend cette demande plus importante. Les affirmations concernant plusieurs réseaux électriques, générateurs, contrôles biométriques et personnel sur site impliquent un site physique, mais la page ne le nomme pas. L'adresse d'enregistrement à La Ceiba peut être un bureau, un contact réseau ou une installation; l'ensemble des sources ne peut pas décider. Les acheteurs devraient demander l'adresse de service sous confidentialité si nécessaire, puis la concilier avec la latence réseau, l'emplacement de la sauvegarde et le calendrier juridique.

Un support 24 heures sur 24 nécessite une route opérationnelle et une horloge définie

Le fournisseur promet un support client 24 heures sur 24 et 7 jours sur 7, un accès pour les administrateurs système et le personnel de surveillance sur site. LACNIC ajoute un contact e-mail NOC public et un téléphone pour les questions de routage et d'abus. C'est plus responsable qu'une marque anonyme sans personne nommée ni contact réseau.

Ce n'est toujours pas une preuve de performance du support. Le site ne publie pas les niveaux de gravité, les délais de réponse, les objectifs de rétablissement, les étapes d'escalade ou les crédits de service. « 24x7 » peut décrire quand une file d'attente accepte les messages, quand un agent de première ligne répond ou quand un ingénieur disposant de l'autorité sur l'hyperviseur et le réseau est disponible. Ce sont des engagements matériellement différents lors d'une panne.

L'échec de la page de contact client aiguise le problème. Un formulaire web cassé peut être temporaire, et les clients existants peuvent avoir un portail, un e-mail ou un canal téléphonique séparé. Mais la route publique offerte pour le contact n'était pas utilisable au moment de l'examen. Avant l'achat, un client devrait tester chaque canal, enregistrer le numéro d'incident, vérifier l'escalade après les heures ouvrables et apprendre qui peut autoriser les changements réseau, restaurer les données et approuver un remède de service.

Le support local a également besoin d'un modèle de main-d'œuvre. L'entreprise déclare que le personnel surveille le site en continu, mais l'ensemble des sources n'établit pas l'effectif, la profondeur des équipes, la couverture linguistique, le lieu d'emploi ou la dépendance à un seul contact nommé. Un calendrier crédible devrait identifier la couverture des rôles plutôt que d'exposer des détails privés du personnel: opérations réseau, virtualisation, stockage, sécurité, facturation et un commandant d'incident. Il devrait définir les règles de passation et garantir qu'un événement grave n'attend pas qu'une personne se réveille ou se déplace.

Des preuves mesurées peuvent remplacer une grande partie du langage commercial. Les acheteurs devraient demander les distributions de réponse et de rétablissement par gravité, les avis de maintenance récents, un rapport d'incident expurgé et une restauration attestée. Ils devraient appeler la route d'escalade lors de l'intégration et inclure la défaillance du portail dans un exercice sur table. Le support devient un contrôle opérationnel lorsque son horloge, son autorité et ses canaux de secours survivent à la même panne qui a généré le ticket.

Ce que les acheteurs devraient exiger avant une utilisation en production

Cloud Colibri a plus de substance qu'un nom seul. Son identité de registre est spécifique, son allocation IPv6 est active, sa route est visible depuis des années et son état RPKI est valide. Le site web décrit une offre plausible de petit fournisseur avec des machines virtuelles, un accès root, une mise à l'échelle automatisée, une sauvegarde et des contrôles physiques. Ces faits justifient une diligence supplémentaire.

Ils ne valident pas les promesses les plus fortes du fournisseur. La page des services indique que les clients peuvent bénéficier d'une disponibilité à 100 %, mais ne publie aucune fenêtre de mesure, exclusion, traitement de maintenance, schéma de dépendance ou remède. « Tolérance aux pannes » est une étiquette de fonctionnalité sans conception de domaine de défaillance. « Illimité » n'a pas de définition d'usage équitable ou de capacité de port. Une sauvegarde quotidienne sans rétention ni résultats de restauration ne peut pas être tarifée comme une assurance de récupération.

Une commande de production devrait donc attacher des preuves à chaque affirmation. Le calendrier juridique devrait nommer l'entreprise contractante et son autorité de signature. Le calendrier réseau devrait lister les préfixes clients, les origines de route, le fournisseur IPv4, les amonts, la responsabilité RPKI et le basculement testé. Le calendrier d'infrastructure devrait nommer l'installation, les chemins électriques, la propriété du matériel et les limites de maintenance. Le calendrier des données devrait localiser chaque copie et administrateur.

Le calendrier de support devrait définir les gravités, les horloges, les escalades et les crédits de service. Le calendrier de sortie devrait garantir l'exportation des images machine et des données dans un format utilisable.

Les clients devraient également chercher des preuves au-delà des propres pages du fournisseur: une référence pour une charge de travail comparable, une facture ou un enregistrement de service liant l'installation et le réseau proposés à l'entité contractante, des données de disponibilité provenant d'un moniteur indépendant, et une restauration observée par rapport au plan commandé. L'absence d'un client nommé dans le registre public disponible n'est pas la preuve que les clients n'existent pas. Cela signifie que les acheteurs potentiels ne devraient pas emprunter confiance à des témoignages qu'ils n'ont pas vus.

Le jugement central est équilibré. CLOUD COLIBRI S.A est un détenteur de ressources réseau attribuable avec une présence IPv6 petite mais réelle et bien autorisée. Son dossier de service public est plus ancien, plus large et moins testable que cette preuve réseau. Le nom peut identifier qui devrait répondre à la première question. L'assurance opérationnelle ne commence que lorsque l'entreprise peut répondre aux suivantes avec un contrat actuel, un schéma de localisation, un support fonctionnel et une récupération mesurée.