HK CLOUD DATA CO., LIMITED vend une capacité hébergée qui dépend encore des baies, du transit et des créneaux de réparation

Résumé

• HK CLOUD DATA CO., LIMITED est visible dans le système public de numérotation Internet sous le numéro AS151206, un système autonome de Hong Kong enregistré en mai 2023. Son enregistrement APNIC nomme l’entreprise, mais montre également une chaîne de parrainage, d’administration, de maintenance des routes et de contact d’abus via BeeCloud.
• Les observations de routage actuelles montrent que l’AS151206 annonce 11 préfixes IPv4, 3 072 adresses IPv4 et un préfixe IPv6/32; le seul amont adjacent visible dans RIPEstat est l’AS140570, Hong Kong Beecloud System Technology Services Limited.
• Les preuves publiques propres à l’entreprise restent minces. Il n’existe pas d’entrée PeeringDB publique pour l’AS151206, pas de liste d’installations divulguée, pas de page d’état client, pas d’historique d’incidents publié, pas d’utilisation mesurée et aucun document prouvant une capacité multisite ou des droits de réparation indépendants.
• Le risque opérationnel est donc physique et contractuel plutôt que purement numérique: la capacité hébergée doit être soutenue par de véritables baies, de l’alimentation, des interconnexions amont, un espace d’adressage loué ou délégué, un inventaire matériel, du personnel de support, des contrôles de facturation et un chemin testé permettant aux clients de restaurer ou de migrer les charges de travail.

La trace publique commence par un système autonome, pas par un campus cloud

HK CLOUD DATA CO., LIMITED ne se présente pas publiquement comme un opérateur cloud mature avec un grand manuel de produits, une liste d’installations et des divulgations formelles de résilience. La preuve la plus solide propre à l’entreprise est plus étroite et plus technique.L’enregistrement RDAP de l’APNIC pour l’AS151206répertorieHKCLOUDDATA-AS-AP, nomme HK CLOUD DATA CO., LIMITED, donne Hong Kong comme pays, marque l’aut-num comme actif, et enregistre la date de création au 2 mai 2023 avec une dernière modification en septembre 2023.

Cet enregistrement est important, mais ce n’est pas un certificat de capacité cloud. Un système autonome donne une identité de routage à un réseau. Il n’identifie pas les baies qui hébergent les serveurs des clients, le contrat de centre de données qui fournit l’alimentation et les interconnexions, le port amont qui achemine le trafic de production, l’ingénieur qui peut entrer dans une cage après minuit, ni la partie propriétaire des disques lorsqu’un serveur hébergé tombe en panne.

Le détail APNIC empêche également une lecture simpliste de HK Cloud Data comme une plateforme autonome. La mêmevue WHOIS APNICidentifieORG-HCDC1-APcomme le déclarant, mais répertorie Hong Kong Beecloud System Technology Services Limited comme l’organisation parrainante, désigne le rôle BeeCloud comme contact administratif et technique, attribue la maintenance des routes àMAINT-HKBCS-HK, et utilise un contact de réponse aux incidents lié à BeeCloud dont la boîte mail a été validée en février 2026. L’adresse est le n° 9 Lai Yip Street, Kwun Tong, une adresse commerciale de Hong Kong. Le modèle de contact n’est donc pas « HK Cloud Data exploite seule un domaine cloud divulgué ». C’est « HK Cloud Data est un enregistrement d’entreprise routé exploité par, ou du moins administré dans, le contexte réseau BeeCloud. »

Cette distinction importe pour les lecteurs qui rencontrent l’entreprise via une fiche d’annuaire, une recherche de route, un bloc IPv4 loué, une facture d’hébergement ou une offre de serveur cloud. Lorsqu’un petit fournisseur cloud vend de la capacité, le client n’achète pas un ASN abstrait. Le client achète un faisceau de dépendances. Il faut un espace de centre de données, même loué. Il faut de l’alimentation, du refroidissement, du transit, des routeurs, des commutateurs, des serveurs, des pièces de rechange, des procédures de contrôle d’accès, une gestion des tickets et une autorité de facturation.

Si l’entreprise est imbriquée dans la chaîne administrative d’un autre opérateur, l’acheteur doit aussi savoir quelle partie légale ou opérationnelle peut autoriser les modifications, approuver une migration d’urgence, remplacer le matériel défaillant, rediriger le trafic, mettre à jour les enregistrements d’origine de route ou libérer les données après un litige.

Le dossier public soutient l’existence d’une identité de réseau routé à Hong Kong. Il ne soutient pas encore une affirmation solide selon laquelle HK Cloud Data aurait sa propre plateforme cloud multisite indépendante. L’article traite donc l’entreprise comme une identité visible de capacité d’hébergement avec une rétrogradation explicite des preuves: assez réelle pour router du trafic, mais trop peu divulguée pour accepter des revendications de résilience, de localité ou de capacité sans preuve de niveau de service.

AS151206 est actif, mais semble se situer un cran derrière BeeCloud

La couche de routage constitue la partie la plus actuelle des preuves.L’aperçu AS de RIPEstatmontre que l’AS151206 est annoncé avec la chaîne de détenteur « HKCLOUDDATA-AS-AP - HK CLOUD DATA CO., LIMITED ». Savue de statut de routagea observé l’ASN le 12 juillet 2026 avec une visibilité complète du collecteur IPv4 et IPv6, une première route vue en mai 2023, 11 préfixes IPv4, 3 072 adresses IPv4, un préfixe IPv6 et un voisin observé.

Laliste des préfixes annoncésest plus révélatrice que le décompte. L’AS151206 originait103.150.210.0/23,2406:7c0::/32, dix blocs IPv4 de taille/24provenant de plusieurs pools de registres, et203.168.235.0/24. Un/23routé plus dix/24routés équivaut aux 3 072 adresses IPv4 observées. Cela représente une capacité d’adressage significative pour l’hébergement, la revente de transit, les serveurs privés virtuels, les serveurs dédiés ou les services BGP clients. Ce n’est pas une preuve que 3 072 adresses sont attribuées à des clients actifs ou qu’il existe suffisamment de calcul et de bande passante pour utiliser chaque adresse en condition de panne.

La vue de l’adjacence est plus prudente. Larequête de voisins AS de RIPEstatn’a montré qu’un seul AS voisin visible: l’AS140570. L’enregistrement RDAP de l’APNIC pour l’AS140570identifie ce réseau commeHKBCS-AS-AP, Hong Kong Beecloud System Technology Services Limited. C’est le même nom d’exploitation BeeCloud qui apparaît dans la trace des contacts et de maintenance de l’AS151206. Au niveau de l’observation des routes, HK Cloud Data ressemble donc à une identité routée en aval ou de type client derrière BeeCloud, plutôt qu’un réseau présentant directement son propre mélange d’amonts étendu à l’internet public.

Cela ne rend pas le réseau faible en soi. Un petit fournisseur cloud peut rationnellement placer son ASN orienté client derrière un opérateur parent ou parrain plus solide. Le profil d’interconnexion public de BeeCloud est plus large que celui de l’AS151206.PeeringDB répertorie l’AS140570comme « Hong Kong Beecloud », avec une politique sélective, plusieurs entrées d’échange et d’installation, et une mise à jour en mai 2026. RIPEstat voit également de nombreux voisins autour de l’AS140570. Mais la connectivité plus large de BeeCloud n’est pas automatiquement héritée par chaque client de HK Cloud Data de manière physiquement diversifiée. La question cruciale est de savoir si l’AS151206 dispose de plus d’un point d’échange utilisable, de plus d’un chemin d’installation, d’une capacité de réserve suffisante du côté survivant, et d’un chemin de support capable de restaurer le service lorsque BeeCloud ou un fournisseur de BeeCloud rencontre un problème.

L’absence d’uneentrée PeeringDB publique pour l’AS151206renforce cette prudence. L’absence de PeeringDB n’est pas une preuve d’absence de peering; de nombreux petits réseaux ne tiennent pas de profils publics. Cela signifie qu’un acheteur ne peut pas utiliser une liste d’installations publique pour l’AS151206 afin de confirmer où il est présent, quels échanges Internet il atteint, ou s’il dispose d’interconnexions indépendantes distinctes de BeeCloud. Le graphe BGP public dit que l’ASN est actif. Il ne dit pas que le produit hébergé est résilient.

La combinaison d’adresses ressemble à une capacité hébergée assemblée à partir de plusieurs pools

La combinaison de préfixes pointe également vers une histoire d’économie d’hébergement. Un fournisseur peut originer sa propre allocation, un espace délégué, des blocs d’adresses loués ou des préfixes appartenant aux clients. Ce sont des arrangements commerciaux différents avec des modes de défaillance différents. Si une plage d’adresses appartient à un autre détenteur et est uniquement routée par l’AS151206 en vertu d’un accord, le client doit savoir ce qui se passe si le bail, l’autorisation ou l’objet de route est retiré.

La trace APNIC et RDAP montre que tout l’espace d’adressage visible n’est pas enregistré directement auprès de HK Cloud Data. Les enregistrements103.150.210.0/23et2406:7c0::/32renvoyés parRDAPetRDAP pour le bloc IPv6pointent vers Shenzhen Tuteng Network Co., Ltd. Plusieurs préfixes45.200.*et156.*sont associés dans RDAP à Cloud Innovation Support et à un code pays de Hong Kong. L’enregistrement203.168.235.0/24est une attribution APNIC non portable au rôle d’exploitation BeeCloud via le contexte HK Cable. Les enregistrements154.18.162.0/24et209.146.7.0/24se trouvent sous des allocations Cogent dans le RDAP ARIN.

Rien de tout cela ne prouve quoi que ce soit d’anormal. Les marchés de l’hébergement et du transit impliquent couramment des blocs d’adresses délégués, loués, réattribués ou routés par le client. Cela permet cependant de garder le terme « capacité » honnête. La capacité d’adressage n’est pas la capacité de calcul. Ce n’est pas non plus la permanence contractuelle. Un serveur virtuel lié à un espace délégué peut dépendre du maintien par le fournisseur de l’autorisation d’origine, de l’exactitude du registre, des filtres amont et d’une relation de facturation avec le détenteur de l’adresse.

Si l’un de ces éléments fait défaut, la machine peut rester alimentée tandis que son adresse publique ne fonctionne plus.

RPKI offre une vérification partielle. Les validations RPKI de RIPEstat pour103.150.210.0/23,45.200.123.0/24,156.230.15.0/24et203.168.235.0/24renvoient une autorisation d’origine valide pour l’AS151206. Les routes échantillonnées154.18.162.0/24et209.146.7.0/24ont renvoyé « inconnu » plutôt que « invalide » au moment de l’examen. Inconnu n’est pas une conclusion de détournement; selon laRFC 6811, cela signifie que le validateur ne dispose pas d’une autorisation d’origine de route correspondante pour cette route. Cela reste une lacune opérationnelle si les clients attendent une preuve cryptographique d’origine de route pour chaque préfixe de production.

Cette combinaison soutient une lecture pratique du rôle de HK Cloud Data. L’entreprise peut vendre ou prendre en charge des serveurs cloud, du transit IP, un accès Internet dédié, de la location d’adresses ou du BGP géré dans un contexte BeeCloud. Mais le dossier public ne permet pas à un client de distinguer les ressources possédées des ressources routées, les allocations permanentes des blocs de location, et les adresses de réserve de la capacité de service active. Pour les charges de travail critiques, cette distinction n’est pas de la comptabilité.

C’est la différence entre une route qui peut être réparée par la propre équipe du fournisseur et une route qui nécessite également qu’un autre détenteur, un amont ou un objet de registre reste aligné.

Le langage de service public de BeeCloud aide à expliquer l’offre, mais pas le plan de reprise

Le contexte de service public autour de BeeCloud aide à expliquer pourquoi HK Cloud Data apparaît dans un lot de services cloud. Lapage d’accueilen anglais de BeeCloud annonce l’atténuation DDoS, un numéro d’opérateur basé sur les services OFCA, la technologie BGP, un langage de fournisseur à double boucle locale, le partage de bande passante internationale dédiée, le transit IP et la gestion des routes IP, des opérations de sécurité gérées, la détection DDoS et le trou noir automatique, et des solutions de cloud privé ou public. Sapage de servicesdécrit des boucles locales doubles, un accès partagé à la plateforme Internet, la prise en charge de multiples adresses IP, un accès Internet dédié, un accès Internet à routage intelligent, un service de route vers la Chine, une facturation au 95e centile, la location d’ASN et d’IPv4, la configuration et la gestion BGP, et un centre d’opérations de sécurité 24 heures sur 24. Lesite BCTSHKen chinois décrit le service BeeCloud Global Telecom avec du haut débit commercial à Hong Kong, du transit IP et un langage SD-WAN mondial.

Ces pages sont utiles car elles montrent le type de famille de produits commerciaux autour de l’enregistrement AS151206: bande passante, routes, filtrage de sécurité, capacité cloud, location d’adresses IP et réseau géré. Elles ne suffisent pas à certifier les actifs propres de HK Cloud Data. Les pages ne publient pas de liste d’installations pour l’AS151206. Elles ne nomment pas les baies ou les centres de données utilisés par HK Cloud Data.

Elles ne divulguent pas la redondance des routeurs, la capacité en état de panne, le matériel de commutation, la réplication du stockage, la conservation des sauvegardes, les droits de migration des clients, le personnel de support, les pièces de rechange ou les indicateurs d’incidents. Elles incluent également un langage marketing large qui doit être traduit en faits d’ingénierie avant de pouvoir étayer une revendication de résilience.

Lapage de boutique de BeeCloudest un bon exemple de la raison pour laquelle la prudence est nécessaire. Elle présente les prix des forfaits IPv4 et indique que le routage peut être diffusé via différents fournisseurs en même temps, tout en affichant un texte générique de châssis de serveur qui ne doit pas être traité comme un inventaire d’équipement vérifié. Un client peut raisonnablement lire la page comme un signal indiquant que BeeCloud vend des services d’hébergement ou de routage liés aux adresses. Un client ne devrait pas la lire comme une preuve que l’AS151206 dispose d’une capacité de lames Cisco, de lames de rechange locales ou d’un plan de basculement multi-fournisseur testé.

La différence entre un menu de produits et une preuve opérationnelle est particulièrement marquée à Hong Kong. Le territoire dispose d’un marché des opérateurs et des centres de données exceptionnellement dense. Le portail gouvernemental des centres de données décrit Hong Kong comme ayant une infrastructure de télécommunications robuste, environ 300 fournisseurs de services à haut débit, 12 systèmes de câbles sous-marins externes et une très haute fiabilité de l’alimentation électrique sur sapage Pourquoi Hong Kong. Lapage des câbles sous-marinsde l’OFCA indique également que Hong Kong disposait de 12 systèmes de câbles sous-marins et de 10 stations d’atterrissement de câbles en juillet 2025. Cet environnement facilite l’achat d’interconnexions, de transit, de colocation et de services de centres de données pour un petit fournisseur. Il rend également facile pour les acheteurs de confondre l’abondance du marché avec la redondance d’un fournisseur particulier.

Si HK Cloud Data vend des serveurs hébergés à partir de baies dans une seule cage louée, son profil de risque diffère de celui d’un fournisseur disposant d’une capacité active dans plusieurs installations indépendantes de Hong Kong. S’il utilise les services d’adressage et de transit de BeeCloud, son chemin de restauration diffère de celui d’un fournisseur qui possède toutes les sessions amont et l’inventaire des routeurs. Si le service repose sur un espace d’adressage délégué, le chemin de migration diffère de celui d’un fournisseur qui peut simplement déplacer son propre agrégat. Les documents publics ne tranchent pas ces alternatives.

Ils identifient une famille de services plausible et une frontière opérationnelle BeeCloud qui exige une diligence directe de la part du client.

La localité de Hong Kong est précieuse, mais la localité n’est pas synonyme de souveraineté des données

La région de HK Cloud Data importe parce que Hong Kong reste un important hub de centres de données et de connectivité en Asie. L’accès à faible latence aux échanges de Hong Kong, aux routes orientées vers le continent, aux câbles sous-marins régionaux et aux clients professionnels locaux peut être commercialement précieux. Pour les clients qui ont besoin d’hébergement à Hong Kong, la promesse peut être pratique plutôt que juridique: garder les charges de travail près des utilisateurs de Hong Kong, payer dans un marché familier, se connecter à des partenaires locaux et utiliser les heures de support locales.

Mais la localité doit être définie. Une société enregistrée à Hong Kong, un ASN de Hong Kong, une adresse de contact à Hong Kong et des préfixes routés à Hong Kong ne prouvent pas en eux-mêmes où les données des clients sont stockées, où les sauvegardes sont répliquées, d’où le personnel de support peut accéder aux systèmes, ou quelle juridiction contrôle chaque fournisseur. Un serveur virtuel peut avoir une adresse IP de Hong Kong tandis que son plan de contrôle, ses outils de support, ses sauvegardes, sa surveillance ou sa copie de reprise après sinistre dépendent de systèmes extérieurs à l’installation visible par le client.

Un fournisseur peut également héberger à Hong Kong mais acheminer la gestion ou le traitement des abus via une autre société d’exploitation.

C’est pourquoi le thème de la souveraineté et de la localité des données appartient au même article que le transit et les baies. LeGuide sur l’informatique en nuagedu Commissaire à la protection de la vie privée de Hong Kong indique aux organisations utilisant des services en nuage de prendre en compte des mesures contractuelles et de sécurité lorsque des données personnelles sont traitées par des fournisseurs de services en nuage, y compris les cas où le traitement des données a lieu en dehors de Hong Kong. Ce guide n’interdit pas l’utilisation du cloud. Il renvoie la responsabilité au client en tant qu’utilisateur des données: le client doit savoir ce que fait le fournisseur, qui traite les données, où elles peuvent aller, et comment l’accès non autorisé, la perte, l’effacement ou la conservation sont empêchés.

Pour les clients de HK Cloud Data, le déficit de preuves est donc double. Premièrement, un déficit physique: le dossier public ne montre pas quel centre de données, quelle baie, quelle plateforme de stockage ou quel site de sauvegarde de Hong Kong détient une charge de travail. Deuxièmement, un déficit de contrôle: l’enregistrement AS151206 place la responsabilité administrative et technique dans la chaîne de contacts BeeCloud, tandis que les pages de produits publiques se trouvent sous les marques BeeCloud.

Si un acheteur se fie à une promesse de localité à Hong Kong, le contrat devrait nommer le site d’hébergement ou la zone d’hébergement autorisée, les emplacements de sauvegarde et de réplication, le modèle d’accès au support, les sous-traitants, la procédure de retour des données et le processus de vérification de la suppression.

Les clients devraient également séparer la localité de l’adresse de la localité du service. Une base de données de routes peut montrer une adresse originaire de Hong Kong, mais une application peut encore dépendre d’un DNS distant, d’un stockage de sauvegarde distant, d’outils de sécurité administrés à l’étranger ou de personnel distant. Inversement, une installation de Hong Kong peut utiliser le transit international et la surveillance à distance sans violer les besoins d’un client si le contrat et l’évaluation des risques le permettent. Les sources publiques ne prouvent ni une violation ni une force.

Elles montrent que le récit de localité de HK Cloud Data ne peut pas être déduit du seul AS151206.

Le principal chemin de panne est une pile, pas une simple coupure

Pour un petit fournisseur de capacité hébergée, le chemin de panne commence généralement sous l’interface cloud. Un client peut voir « serveur hors ligne », « IP inaccessible », « VPS suspendu », « perte de paquets », « échec de facturation » ou « migration retardée ». Derrière ces symptômes se cachent plusieurs défauts différents.

La première est la dépendance aux installations. Les baies ont besoin d’espace de centre de données, de lignes d’alimentation, de refroidissement, de systèmes d’incendie, d’accès au bâtiment, d’interconnexions et de support à distance. Si HK Cloud Data utilise des baies louées ou un espace contrôlé par BeeCloud, la capacité de récupération du fournisseur dépend du contrat de l’installation et de ceux qui peuvent approuver l’accès. Une seule ligne d’alimentation surchargée, une PDU défaillante, un problème de refroidissement ou une cage verrouillée peut arrêter un serveur même si le BGP reste sain.

La fiabilité générale de l’alimentation électrique de Hong Kong aide le marché, mais elle ne garantit pas la conception au niveau des baies d’un petit fournisseur.

La deuxième est la dépendance amont. RIPEstat montre l’AS151206 avec un voisin visible, l’AS140570. BeeCloud peut avoir une diversité amont et d’échange plus large, mais le chemin AS151206 orienté client dépend visiblement de BeeCloud dans le graphe public. Une erreur de politique BeeCloud, une défaillance de port, un filtre de route, une mauvaise configuration de l’atténuation DDoS, un litige de facturation ou un problème d’interconnexion peut affecter l’AS151206 même si les serveurs de HK Cloud Data sont alimentés.La RFC 4271décrit BGP comme un protocole de joignabilité entre systèmes autonomes; il indique à Internet où les préfixes peuvent être atteints, pas qui peut réparer le port physique ou résoudre le problème commercial qui a fait disparaître une route.

La troisième est la dépendance au contrôle des adresses. Plusieurs préfixes origénés semblent être enregistrés ou associés à des parties autres que HK Cloud Data. Si un préfixe loué ou délégué est retiré, si une autorisation d’origine de route est modifiée, ou si un amont décide que la documentation est insuffisante, les clients peuvent perdre la joignabilité publique alors que leur machine reste intacte. La validation RPKI pour de nombreux préfixes est un signe positif.

Le statut inconnu pour certains préfixes routés et le pool d’adresses hétérogène signifient que les clients doivent demander quels préfixes sont permanents, lesquels sont loués, et quel préavis ou chemin de migration s’applique si les droits d’adresse changent.

La quatrième est l’inventaire matériel. La capacité hébergée n’est utilisable que si des pièces de rechange et des serveurs déployables existent là où ils sont nécessaires. Le langage de service de BeeCloud mentionne des offres de cloud et de serveur, mais aucune page publique ne prouve la quantité de calcul, de disque, de mémoire, d’optique ou d’équipement de routage de rechange attribuée à HK Cloud Data. Un fournisseur peut vendre un plan virtuel instantanément et avoir encore besoin de plusieurs heures ou jours pour remplacer un hôte physique défaillant si les pièces compatibles ne sont pas locales.

La cinquième est la main-d’œuvre de support. Une déclaration d’opérations 24 heures sur 24 est utile, mais la restauration dépend de la bonne personne avec la bonne autorité. Le répondant doit savoir si la panne concerne une machine virtuelle, une baie de stockage, un hyperviseur, un commutateur haut de baie, une interconnexion, une route amont, un filtre DDoS, une suspension de facturation, un bail d’adresse ou un incident d’installation. Si la panne incombe à un opérateur de centre de données, un transporteur de gros ou un détenteur d’adresse, HK Cloud Data ou BeeCloud doit coordonner plutôt que simplement réparer.

Les chaînes d’escalade font partie du réseau.

La sixième est la migration des clients. Si le fournisseur perd une baie, un préfixe ou un amont pendant plus longtemps que le client ne peut tolérer, la question de la reprise devient la portabilité. Le client peut-il exporter une image disque complète? Peut-il déplacer des adresses IP, ou seulement des données? Les sauvegardes sont-elles accessibles si le compte de facturation fait l’objet d’un litige? Existe-t-il un transfert documenté pour le DNS, le DNS inverse, les objets de route, la politique de pare-feu et les journaux de sécurité? La visibilité des routes publiques ne répond pas à ces questions.

La preuve d’un seul amont visible devrait déclencher un test de capacité après panne

La principale question de conception n’est pas de savoir si BeeCloud lui-même n’a qu’un seul amont. BeeCloud semble avoir un profil d’interconnexion plus large. La question est de savoir quelle partie de ce profil est réellement disponible pour l’AS151206 et ses clients après la plus grande panne crédible.

Un petit AS aval peut être connecté à un réseau amont de plusieurs manières. Il peut avoir une seule interconnexion physique vers BeeCloud et s’appuyer sur les amonts de BeeCloud au-delà de ce point. Il peut avoir des ports redondants dans la même paire de routeurs BeeCloud. Il peut avoir deux points d’échange physiquement séparés dans deux installations, les deux utilisant l’AS140570 comme AS suivant. Il peut avoir un transit de secours direct que RIPEstat n’a pas vu au moment de l’observation. Le BGP public ne peut pas distinguer ces possibilités lorsqu’un seul AS adjacent est visible.

C’est pourquoi la question de la capacité doit être formulée comme un test en état de panne. La capacité annoncée normale ne suffit pas. L’acheteur doit savoir ce qui reste après qu’une baie a perdu l’alimentation, qu’un commutateur d’accès est tombé en panne, qu’une interconnexion BeeCloud est retirée, qu’un fournisseur amont filtre un préfixe, qu’un bail d’adresse ne peut être renouvelé, qu’une politique d’atténuation DDoS met le trafic en trou noir, ou qu’une installation devient inaccessible aux intervenants à distance.

Le fournisseur devrait pouvoir indiquer la capacité installée normale, la capacité engagée envers les clients et la capacité survivante après la plus grande panne unique. Si la réponse est « nous utilisons BeeCloud », la question suivante est de savoir quelles installations et liaisons BeeCloud. Si la réponse est « nous avons deux boucles locales », la question suivante est de savoir si elles utilisent des conduits, des entrées de bâtiment et des nœuds d’agrégation séparés.

Si la réponse est « nous pouvons diffuser via différents fournisseurs », la question suivante est de savoir si l’AS151206 a des autorisations de route signées, des filtres testés et une bande passante suffisante sur les deux chemins pour supporter la charge de production.

L’environnement souterrain de Hong Kong rend cette couche physique importante. Lapage de protection de l’infrastructure de télécommunications souterrainesde l’OFCA explique que l’espace souterrain urbain contient des conduits, des câbles à fibre optique et des fils de cuivre dont des dommages accidentels peuvent causer de graves perturbations, et elle établit des obligations concernant la localisation et la protection des lignes souterraines. C’est un rappel que deux services logiques peuvent encore partager un seul corridor physique. Un serveur cloud peut avoir deux routes sur un schéma alors que les deux routes dépendent de la même entrée de bâtiment, de la même colonne montante, de la même salle alimentée ou de la même exposition aux travaux de génie civil.

La même logique s’applique aux routes sous-marines et régionales. L’OFCA note que les opérateurs peuvent avoir besoin de réseaux en anneau reliant les stations d’atterrissement de câbles aux centres de données, et peuvent acheter des services auprès de titulaires de licences unifiées. Un petit fournisseur d’hébergement peut bénéficier des nombreux câbles de Hong Kong sans en être propriétaire.

Mais un client qui dépend de l’accès au continent, de la latence régionale ou du transit international devrait savoir quelle partie de ce chemin est sous le contrôle du fournisseur, quelle partie est fournie par BeeCloud, et quelle partie est achetée à un autre opérateur.

Les revendications de résilience ont besoin de créneaux de réparation, pas d’adjectifs

Le terme « cloud » peut brouiller la réalité des réparations. Les clients peuvent supposer que la capacité cloud se déplace automatiquement. Sur les marchés des petits serveurs hébergés et des VPS, de nombreuses plateformes sont plus proches d’une capacité physique louée avec une couche de gestion. Il peut y avoir de la virtualisation, des instantanés et quelques hôtes de rechange, mais une baie défaillante doit encore être alimentée, refroidie, accessible et réparée. Une route défaillante doit encore être filtrée, autorisée et annoncée.

Des preuves de résilience utiles seraient spécifiques. Elles identifieraient les sites de centres de données utilisés pour les charges de travail de HK Cloud Data, sans exposer de détails sensibles sur les cages. Elles indiqueraient si l’entreprise possède des serveurs, loue de la capacité bare-metal, revend l’infrastructure de BeeCloud ou mélange ces modèles. Elles énuméreraient les amonts normaux et les amonts de secours pour l’AS151206, expliqueraient si les amonts entrent par des installations séparées, et indiqueraient quels préfixes sont origénés avec des autorisations d’origine de route valides.

Elles publieraient un chemin d’escalade de support et une page d’historique de statut. Elles définiraient les fenêtres de maintenance, les préavis aux clients, le support de migration planifiée et les droits d’exportation de données.

Le dossier public ne montre pas ces éléments aujourd’hui. Les preuves actuelles indiquent que l’AS151206 est actif et sécurisé pour de nombreux préfixes, que BeeCloud l’administre et en est le voisin, et que BeeCloud vend le type de services haut débit, transit, BGP, location IPv4, DDoS et cloud qui pourrait soutenir cette activité. Cela ne dit pas que HK Cloud Data dispose de deux centres de données indépendants à Hong Kong, de deux amonts indépendants à la périphérie de l’AS151206, de suffisamment de serveurs de rechange pour absorber la perte d’une baie, ou d’un plan de reprise testé.

Les clients devraient traiter cela comme une condition d’achat, pas comme une raison de rejeter le service. Les petits fournisseurs peuvent être utiles précisément parce qu’ils peuvent vendre une capacité ciblée, des blocs IPv4, des routes de Hong Kong, un support local et une aide BGP flexible à un prix ou une rapidité que les grandes plateformes cloud peuvent ne pas égaler. Le compromis est que l’acheteur doit intégrer la divulgation des dépendances dans l’achat. « Combien de vCPU? » et « combien d’IP? » ne suffisent pas.

Les questions plus fortes sont: où se trouve le serveur, qui possède l’hôte, qui possède le préfixe, qui possède la liaison montante, que se passe-t-il lorsque BeeCloud est injoignable, quelle est la plus longue fenêtre de restauration, et la charge de travail peut-elle partir si la réponse est trop lente?

L’hygiène de routage est préférable au silence, mais encore incomplète

Il y a des signes positifs dans les preuves de routage. L’AS151206 n’est pas simplement un objet de registre obsolète; les observations RIPEstat actuelles montrent une origination en direct. Beaucoup de ses préfixes se valident sous RPKI pour l’AS151206. La boîte mail d’abus de l’APNIC a une date de validation récente. La chaîne administrative BeeCloud est explicite plutôt que cachée. Ce sont des signes utiles pour une petite identité de service cloud.

Les lacunes de routage restantes sont également spécifiques. Les routes échantillonnées associées à Cogent ont renvoyé un statut RPKI inconnu, donc la validation d’origine ne couvre pas toutes les routes visibles. Le graphe public ne montre pas de deuxième amont adjacent à l’AS151206. Il n’y a pas de profil PeeringDB public pour l’AS151206. Plusieurs blocs d’adresses semblent être associés à d’autres détenteurs, donc la continuité des droits d’adresse doit être confirmée par contrat.

Aucun document public n’explique si le DNS inverse, les objets de route, les ROA RPKI et les contacts d’abus sont maintenus par HK Cloud Data, BeeCloud, des loueurs d’adresses ou des amonts.

La pratique de la sécurité du routage importe parce que les clients d’un fournisseur de capacité hébergée ont souvent peu de contrôle sur les annonces. LaRFC 7454recommande des contrôles opérationnels tels que le filtrage des préfixes, les limites de préfixes maximum, le filtrage de chemin et la discipline de politique de routage pour les opérations BGP. Les clients ne peuvent pas vérifier ces paramètres privés à partir d’un collecteur de routes. Ils peuvent exiger du fournisseur qu’il documente les préfixes prévus, maintienne des contacts corrects, publie des autorisations d’origine de route lorsque c’est possible, et teste les procédures de retrait et de basculement avant que les charges de travail de production n’en dépendent.

Il existe également un risque de facturation et de suspension distinct de la sécurité. Sur les marchés de la location d’adresses et de l’hébergement à bas coût, les clients peuvent disparaître d’Internet non pas à cause d’une rupture de câble, mais parce qu’un bail de préfixe, une plainte d’abus, un mode de paiement, une facture amont ou un compte de revendeur échoue. Les documents publics de BeeCloud incluent un langage de location IPv4 et de gestion BGP, donc les acheteurs devraient demander si les droits d’adresse sont groupés avec le serveur, facturés séparément, limités dans le temps, portables et soumis à l’approbation d’un tiers.

Un plan de restauration qui ignore la facturation et l’autorité du registre est incomplet.

La meilleure interprétation est équilibrée: l’hygiène de routage de HK Cloud Data n’est pas négative. Elle est partiellement visible et partiellement rassurante. Mais elle n’est pas suffisamment complète pour en déduire une résilience cloud de niveau entreprise.

Qui est affecté lorsque le système tombe

Les utilisateurs affectés sont probablement des clients de petite et moyenne taille achetant de la localité à Hong Kong, des adresses IP, un accès Internet dédié, des serveurs cloud, la gestion BGP ou des routes orientées vers le continent. Les sources publiques ne nomment pas les clients de HK Cloud Data, et aucune organisation particulière ne doit être déduite. Le profil d’impact peut néanmoins être décrit.

Pour un client d’hébergement web, la panne peut être l’injoignabilité publique, des modifications DNS qui ne peuvent être effectuées rapidement, une perte de trafic SEO, des pages de paiement défaillantes ou des panneaux d’administration inaccessibles. Pour un opérateur SaaS utilisant la capacité VPS de Hong Kong, la panne peut être la perte de sessions, l’accumulation de files d’attente, des exportations de données échouées ou une charge de support client.

Pour une entreprise achetant de l’espace d’adressage, la panne peut être un retrait de route, le blocage du courrier sortant, une dérive de géolocalisation, une inscription sur une liste d’abus ou l’incapacité à conserver des listes d’autorisation de clients de longue durée. Pour un acheteur utilisant le service de Hong Kong comme un contrôle de localité, la panne peut être une perte de confiance quant à l’endroit où les données sont stockées ou à la rapidité avec laquelle elles peuvent être retournées.

Les cas aux conséquences les plus élevées sont ceux qui combinent plusieurs dépendances. Un client peut acheter un serveur virtuel, un bloc IPv4 loué, un filtrage DDoS et un transit de route vers la Chine auprès de la même chaîne de fournisseurs. Si un problème de périphérie BeeCloud affecte à la fois la route du serveur et le plan de contrôle DDoS, le client perd à la fois le chemin de production et le chemin d’atténuation. Si le préfixe loué n’est pas portable, le client ne peut pas simplement déplacer l’image du serveur vers un autre cloud et conserver la même adresse.

Si les sauvegardes sont stockées dans la même installation ou le même compte, la fenêtre de migration s’élargit.

C’est pourquoi un client sérieux devrait concevoir son propre plan de reprise même lorsque le fournisseur est honnête et compétent. Conservez des sauvegardes hors fournisseur. Utilisez un DNS avec des identifiants contrôlés par le client. Gardez l’infrastructure en tant que code ou les notes de construction en dehors du serveur hébergé. Comprenez quelles adresses IP peuvent être déplacées et lesquelles ne le peuvent pas. Testez les exportations. Si le service est sensible à la latence, préqualifiez un deuxième fournisseur d’hébergement à Hong Kong ou régional.

Si le service est sensible aux données, documentez où les données et les sauvegardes sont autorisées à résider.

Le fournisseur peut aider en rendant ces réalités visibles plutôt qu’en les cachant derrière un langage cloud générique. Une divulgation claire n’affaiblit pas un petit fournisseur; elle permet aux bons clients d’acheter le bon produit. Certaines charges de travail n’ont besoin que d’une joignabilité à Hong Kong peu coûteuse et peuvent tolérer une reprise manuelle. D’autres ont besoin d’une continuité multisite contractuelle et devraient payer pour une architecture différente.

Le niveau de preuve pratique est moyen-faible, avec des pistes claires d’amélioration

HK Cloud Data n’est pas un cas de preuve négative. L’entreprise dispose d’un ASN enregistré APNIC actif, d’une origination de route actuelle, d’une trace cohérente de contacts et de parrainage BeeCloud, de nombreuses routes validées RPKI, et d’un contexte de service plausible autour des offres haut débit, transit, BGP, DDoS et cloud de BeeCloud. Ces faits justifient de la traiter comme une identité de réseau opérationnelle.

Les preuves ne sont pas non plus suffisamment solides pour une conclusion confiante sur la résilience cloud. Il n’existe pas de carte publique indépendante des installations de l’AS151206, pas de liste publique de sites de centres de données, pas d’entrée PeeringDB directe, pas de deuxième amont adjacent visible, pas de couverture RPKI complète pour chaque préfixe échantillonné, pas d’historique de disponibilité ou d’incidents publié, pas d’inventaire matériel, pas de description du stockage ou des sauvegardes, pas d’indicateurs de support, et pas de politique de migration des clients.

Plusieurs blocs d’adresses semblent liés à d’autres détenteurs ou fournisseurs, ce qui fait de la diligence en matière de contrôle des adresses une partie de l’examen de résilience.

La meilleure divulgation suivante serait modeste et pratique: une déclaration de service datée pour l’AS151206 qui nomme la partie exploitante, le modèle d’hébergement, les installations utilisées au niveau de la ville, le modèle de dépendance amont et BeeCloud, la propriété ou le statut de location des préfixes, la couverture RPKI, les conditions de sauvegarde et d’exportation de données, le chemin d’escalade du support, la politique de fenêtre de maintenance et la capacité en état de panne. Cela ne nécessiterait pas de révéler des numéros de baie sensibles ou des configurations de routeurs.

Cela transformerait une trace de route publique éparse en une description de service de niveau approvisionnement.

D’ici là, la conclusion correcte est prudente. HK CLOUD DATA CO., LIMITED vend ou prend en charge une capacité hébergée dans une orbite opérationnelle BeeCloud de Hong Kong, et l’AS151206 est véritablement visible sur Internet.

Mais la valeur de cette capacité dépend encore de l’infrastructure ordinaire: des baies qui restent alimentées, un transit qui reste autorisé, des droits d’adresse qui restent valides, du matériel qui peut être remplacé, du personnel de support qui peut agir, une facturation qui n’interrompt pas les routes, et des données client qui peuvent être restaurées ou déplacées lorsque la dépendance cachée du fournisseur est la partie qui tombe en panne.