Résumé
- Global Cloud Ltd est un véritable opérateur réseau visible par RIPE, pas simplement un nom dans un annuaire. L’objet organisation RIPE pour ORG-GCL12-RIPEmentionne Global Cloud Ltd, donne le numéro d’immatriculation israélien
514919729, indique le type d’organisationLIR, et fournit l’adresse HaMasik St 4, Emek Hefer, Israël, avec le même numéro de téléphone que celui affiché sur le site web de l’entreprise. - La société est liée à AS61365, dont l’aperçu AS de RIPEstatdésigne le détenteur sous la mention
GC-5222 Global Cloud Ltdet montrait l’AS comme annoncé à la date de la requête du 11/07/2026. Lavue de l’état de routagede RIPEstat affichait quatre préfixes IPv4, 1 024 adresses IPv4 visibles, aucun préfixe IPv6 visible et deux voisins observés. - L’espace d’adressage de la société n’est pas un bloc tiers indépendant. L’enregistrement de préfixe RDAP RIPE pour 185.184.16.0/22et lavue whois de RIPEstatidentifient
IL-GLOBAL-20170102, pays IL, organisationORG-GCL12-RIPE, statutALLOCATED PA, et un fichier geofeed àgeofeed.xprsit.netqui associe le /22 et chaque /24 à Emek Hefer. - L’assurance de l’origine des routes est meilleure que celle de nombreuses petites empreintes hébergées. Les réponses de validation RPKI de RIPEstat pour185.184.16.0/24,185.184.17.0/24,185.184.18.0/24et185.184.19.0/24ont toutes renvoyé
validsous une ROA 185.184.16.0/22 avec longueur maximale 24. - La situation des fournisseurs de transit nécessite encore des tests de la part du client. L’objet aut-num RIPErépertorie des politiques pour AS1680, AS212616 et AS8551, tandis que lavue des voisins d’ASNde RIPEstat affichait AS1680 et AS212616 comme voisins observés et que savue de cohérence de routage ASmontrait AS8551 dans la politique whois mais pas dans BGP au moment de la requête.
- Le niveau de preuve est moyen. Les sources publiques soutiennent fortement l’identité juridique, le contrôle des ressources réseau, la joignabilité IPv4 actuelle et la validation de l’origine des routes. Elles ne prouvent pas le nombre de baies, la propriété des installations, la profondeur du matériel de rechange, la reprise testée sur plusieurs sites, l’éventail réel des charges de travail des clients, le temps de réponse du support contractuel ou les limites de portabilité des données.
Les archives publiques sont concrètes, mais la capacité cloud reste à démontrer
Global Cloud Ltd mérite un traitement différent de celui des noms de coquille vide d’hébergement qui n’apparaissent que dans des listes agrégées. L’entreprise a une identité réseau publique, un site web officiel, le statut LIR RIPE, un numéro d’immatriculation israélien dans l’objet organisation RIPE, un système autonome actif et une allocation IPv4 enregistrée. L’enregistrement RDAP aut-num RIPE pour AS61365nomme l’ASGC-5222, répertorie Global Cloud Ltd comme entité organisationnelle, et répète l’adresse HaMasik St 4, Emek Hefer, Israël. Lapage d’accueil en anglais de l’entreprisedonne la ligne de contact comme Hamasek 4, Emek Hefer Industrial Park, publie le numéro de téléphone 072-274-3030, et décrit des services liés au développement, au stockage et à la sécurité.
Cette combinaison rend la société suffisamment observable pour être analysée. Mais cela ne rend pas le service entièrement vérifiable de l’extérieur. Un client qui achète du cloud, de l’hébergement, des bureaux virtuels ou un service géré n’achète pas seulement un numéro d’AS. Il mise sur des baies, des circuits, des optiques, des routeurs, des hyperviseurs, du stockage, des travaux de sauvegarde, des licences, des équipes de support, des alimentations électriques, du contrôle d’accès, des systèmes de facturation et des procédures de migration.
L’Internet public peut montrer qu’AS61365 est joignable; il ne peut pas montrer si une charge de travail client particulière peut être restaurée après la panne d’une étagère de stockage, un litige avec un fournisseur, une coupure de courant ou un changement de routage.
La manière la plus utile de lire Global Cloud est donc de la voir comme une surface d’infrastructure de taille moyenne avec suffisamment de preuves publiques pour éviter les spéculations et assez de détails opérationnels manquants pour exiger une diligence. Lapage des services cloud en anglaisdu site de l’entreprise indique qu’elle propose des services de centre de données et de cloud, DaaS, PaaS, Infrastructure as a Service, des services de collaboration, des services informatiques et des services logiciels. Elle dit aussi que l’équipe de support travaille 24h/24, 7j/7 et que Global Cloud met l’accent sur la sécurité et la survivabilité. Ce sont des affirmations de service pertinentes. Elles ne remplacent pas un test de récupérabilité.
Les preuves contiennent aussi un petit indice éditorial révélateur. Certaines parties de la page cloud en anglais font référence à « Xpress Technologies » tandis que le domaine, les enregistrements RIPE et le pied de page parlent de Global Cloud. Il peut s’agir d’un contenu hérité, d’un résidu de modèle, d’une marque liée ou d’un artefact de traduction; les preuves publiques ne permettent pas de trancher. Le point de risque pour le client n’est pas que cette incohérence de nom prouve quoi que ce soit de négatif.
C’est que des promesses cloud larges devraient être réconciliées avec les contrats de service actuels, les schémas de plateforme actuels et les limites actuelles du support, au lieu d’être déduites d’un contenu web ancien ou incohérent.
Pour cet article, la thèse opérationnelle est simple: Global Cloud Ltd a une empreinte réseau israélienne réelle et un catalogue de services public assez large pour créer une dépendance client. Le travail de l’acheteur est de vérifier quelle part de ce catalogue est installée, où elle est hébergée physiquement, comment les routes basculent, comment le personnel répond en dehors des heures ouvrées, et comment les charges de travail peuvent quitter le service si celui-ci ne convient plus.
AS61365 donne à Global Cloud un avantage mesurable
Les preuves les plus solides spécifiques à l’entreprise commencent avec AS61365. L’aperçu AS de RIPEstatdésigne le détenteurGC-5222 Global Cloud Ltdet montrait l’AS annoncé à 08:00 UTC le 11 juillet 2026. Lepoint de terminaison d’état de routagede RIPEstat affichait quatre préfixes IPv4, 1 024 adresses IPv4, aucun préfixe IPv6, 326 pairs sur 327 du flux complet RIS IPv4 voyant la route, et une visibilité IPv6 nulle. Les quatre préfixes annoncés actuellement dans laréponse des préfixes annoncésétaient 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 et 185.184.19.0/24.
C’est un point d’entrée réseau significatif. Ce n’est pas non plus une empreinte à l’échelle hyperscale. Un /22 découpé en quatre annonces /24 peut prendre en charge des services clients, des plateformes hébergées, des VPN, du courrier électronique, des services de bureau, des réseaux de gestion, des clients en accès statique ou un mélange d’usages. Cela ne prouve pas en soi un vaste domaine public dans le cloud. Le nombre d’adresses IPv4 annoncées n’est pas le nombre de serveurs, de machines virtuelles, de locataires, de dépôts de sauvegarde ou de cibles de restauration.
L’absence d’IPv6 visible dans RIPEstat est également importante, car la préparation à IPv6 fait désormais partie de la planification réseau de nombreux acheteurs, même si le service immédiat peut fonctionner en IPv4.
Lepoint de terminaison de comptage de préfixesde RIPEstat ajoute un historique utile. Il montre le modèle actuel de Global Cloud avec quatre préfixes IPv4 après des changements de visibilité antérieurs et aucun compteur de préfixes IPv6 durant la fenêtre de requête du 11/07/2026. Lepoint de terminaison d’historique de routagemontre une ancienne visibilité d’AS61365 pour 94.30.220.0/24 en 2012-2014, puis la famille 185.184.16.0/22 à partir de 2017. Cet historique est un signe positif au niveau du routage: AS61365 n’est pas une expérience d’une semaine.
Mais la continuité de route n’est pas la continuité de service. Le passage d’un ancien historique en 94.30.220.0/24 à la famille 185.184.16.0/22 peut refléter un changement de fournisseur, de service, d’acquisition de ressources d’adressage, de clientèle ou simplement l’enregistrement visible de préfixes différents. Le BGP public n’explique pas la raison commerciale. Il montre seulement que l’AS a eu des routes observées à différentes périodes et que l’empreinte routée actuelle se compose des quatre /24 sous 185.184.16.0/22.
Les clients doivent donc considérer AS61365 comme un fait de départ solide et une preuve finale faible. Il peut justifier de poser des questions détaillées. Il ne peut pas remplacer les réponses. Si Global Cloud vend des serveurs virtuels, l’acheteur a besoin de l’architecture des hôtes et du stockage. S’il vend du bureau en tant que service, l’acheteur a besoin de la capacité de session utilisateur, des dépendances d’identité et des performances de lien. S’il vend des applications gérées, l’acheteur a besoin de la propriété opérationnelle et du détail des sauvegardes.
S’il vend de l’IaaS, l’acheteur doit savoir quelle partie de la pile est automatisée et quelle partie est un domaine d’hébergement géré manuellement.
L’allocation /22 soutient le contrôle, pas une échelle illimitée
Les preuves liées à l’espace d’adressage sont particulièrement utiles car elles relient les préfixes routés à Global Cloud plutôt qu’à un loueur d’adresses totalement distinct. L’enregistrement de préfixe RDAP RIPEpour 185.184.16.0/22 montre le handle185.184.16.0 - 185.184.19.255, le nomIL-GLOBAL-20170102, le typeALLOCATED PA, le pays IL, et l’entité organisationnelle Global Cloud. L’objet inetnum RIPE RESTrépète la même allocation et ajoute une URL de geofeed. L’objet organisationprésente Global Cloud Ltd en tant que LIR. Cela importe car c’est une position d’identité plus forte que celle d’un petit fournisseur annonçant simplement le bloc de quelqu’un d’autre.
Les étiquettes plus spécifiques du registre apportent de la couleur sans prouver l’usage client. Laréponse de hiérarchie de l’espace d’adressagede RIPEstat répertorie 185.184.16.0/24 en tant queSHVDOM-1-Subnet, 185.184.17.0/24 en tant queSHVDOM-Core-Subnet, 185.184.18.0/24 en tant queLNS-Static-Subentet 185.184.19.0/24 en tant queSHVDOM-Subnet. Ces noms suggèrent une segmentation interne et au moins une étiquette de service statique ou réseau. Ils ne prouvent pas quels produits sont vendus depuis chaque sous-réseau, quels clients les utilisent, ou si les étiquettes sont des descriptions opérationnelles actuelles plutôt que des noms administratifs.
Cette distinction est centrale dans l’économie de l’hébergement. Un fournisseur peut posséder ou exploiter une allocation d’adresses et néanmoins disposer d’une capacité serveur installée limitée derrière elle. Un fournisseur peut utiliser un /24 pour le service client statique, un autre pour la gestion ou les fonctions cœur, et un autre pour les charges de travail hébergées. Un fournisseur peut aussi vendre des services dont le plan de contrôle ou le site web se trouve dans un réseau différent. La carte des adresses publiques indique à l’acheteur par où commencer, pas où chaque dépendance s’arrête.
Le site web public de l’entreprise illustre ce point. Une simple recherche DNS pendant l’enquête a montré queglobalcloud.meetwww.globalcloud.mese résolvaient en 212.29.210.119, et lavue whois de RIPEstat pour 212.29.210.119place cette adresse dansIL-NETVISION-980831, et non dans l’allocation 185.184.16.0/22 de Global Cloud. Cela n’a rien d’inhabituel. Beaucoup de fournisseurs hébergent leur site marketing chez un autre opérateur ou sur une autre plateforme. Le point est simplement que l’extrémité du site web ne doit pas être considérée comme une preuve de l’endroit où vivent les charges de travail cloud des clients.
Pour les clients, la bonne question n’est donc pas « Global Cloud possède-t-elle des adresses? » Elle en a. La meilleure question est de savoir comment ces adresses sont allouées aux services, si les attributions d’adresses IP client sont portables, comment le DNS inverse et la réputation sont gérés, comment une renumérotation fonctionnerait et si l’acheteur reçoit un préavis suffisant si Global Cloud change de fournisseurs de transit, de sous-réseaux ou de plateformes de services.
RPKI est une véritable force dans les preuves publiques actuelles
La validation de l’origine des routes est l’un des rares contrôles publics pour lesquels l’empreinte de Global Cloud semble plus solide que la ligne de base pauvre en informations. Le point de terminaison de validation RPKI de RIPEstat a renvoyévalidpour 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 et 185.184.19.0/24 lorsqu’il a été interrogé pour AS61365. Chaque réponse pointait vers une ROA validante pour 185.184.16.0/22, origine AS61365, longueur maximale 24. Cela signifie que les quatre annonces /24 actuelles correspondent à l’autorisation d’origine de route publiée au moment de la requête.
La valeur technique est étroite mais réelle. LaRFC 6811explique la validation de l’origine des préfixes BGP comme un moyen pour un routeur de déterminer si l’AS qui prétend annoncer le préfixe est autorisé par le détenteur du préfixe. RPKI ne chiffre pas les paquets, n’empêche pas toutes les fuites de routes, ne prouve pas que le chemin est le meilleur, qu’un centre de données est résilient, ou ne résout pas la sécurité applicative. Il réduit néanmoins une classe de risques d’annonces d’origine erronées lorsque les réseaux appliquent des politiques de validation.
Pour Global Cloud, cela importe parce que l’empreinte routée est compacte. Si un fournisseur a quatre /24 actuellement visibles et aucune IPv6 visible, des erreurs d’origine de route peuvent affecter une grande partie de la surface de service public. Des ROA valides pour les annonces /24 actuelles donnent aux clients une meilleure position de départ que ne le ferait un résultatunknownouinvalid. Elles montrent également que la relation entre le détenteur de l’adresse et l’origine dispose d’au moins un contrôle moderne de sécurité du routage en place.
La réserve est que RPKI n’est pas un SLA client. Il ne dit pas si AS1680, AS212616 ou tout autre chemin de transit a suffisamment de capacité pour acheminer le trafic après une panne. Il ne dit pas si les routeurs sont redondants. Il ne dit pas si le filtrage anti-DDoS est actif. Il ne dit pas si les sauvegardes clients sont récupérables. Il ne dit même pas si chaque objet de route opérationnel est en ordre. Laréponse de cohérence de routage des préfixesde RIPEstat montrait l’objet de route agrégé 185.184.16.0/22 dans le whois, 185.184.19.0/24 à la fois dans BGP et le whois, et les annonces 185.184.16.0/24, 185.184.17.0/24 et 185.184.18.0/24 dans BGP sans objets de route whois correspondants dans cette vue de cohérence spécifique. Laréponse de cohérence de routage d’ASde RIPEstat présente la même divergence.
Cette divergence n’est pas une crise car l’état RPKI est valide et l’objet de route agrégé existe. Elle reste une preuve opérationnelle utile. Les clients doivent demander si Global Cloud s’appuie intentionnellement sur l’objet de route agrégé plus RPKI pour les /24, si les filtres IRR utilisés par les fournisseurs de transit acceptent les annonces actuelles, et quel processus de contrôle des modifications protège les mises à jour de ROA et d’objets de route.
Une petite incohérence dans une vue de registre peut devenir un incident important si un filtre de fournisseur, un serveur de routes ou un fournisseur de transit l’interprète différemment pendant la maintenance.
La version courte: RPKI est une force. Il faut la saluer comme un contrôle actuel et la remettre ensuite à sa juste place.
La diversité de transit est visible, mais l’histoire du basculement reste inachevée
La question opérationnelle la plus importante n’est pas le nombre de noms de fournisseurs qui apparaissent dans un objet de politique. C’est quels chemins peuvent acheminer le trafic quand un chemin, un routeur, une interconnexion ou un contrat commercial tombe en panne. Les archives publiques de Global Cloud fournissent suffisamment de preuves pour poser cette question avec précision.
L’objet aut-num RIPE pour AS61365inclut des entrées de politique pour AS1680, AS212616 et AS8551. RIPEstat identifieAS1680comme Cellcom Fixed Line Communication L.P,AS212616comme K.M.A ADVANCED TECHNOLOGIES LTD, etAS8551comme Bezeq International Ltd. Ce sont des noms de réseaux israéliens sérieux. Lepoint de terminaison des voisins d’ASNmontrait toutefois deux voisins observés au dernier temps de requête disponible: AS1680 et AS212616. Le point de terminaison de cohérence de routage AS montrait AS1680 et AS212616 à la fois dans BGP et le whois, tandis qu’AS8551 apparaissait dans le whois mais pas dans BGP à ce moment-là.
Les échantillons de chemin affinent l’image. Pour 185.184.16.0/24, les chemins BGP échantillonnés se terminaient par AS1680 AS61365. Pour 185.184.17.0/24 et 185.184.18.0/24, le motif de dernier saut dominant visible se terminait également par AS1680 AS61365. Pour 185.184.19.0/24, le motif visible se terminait par AS1680 AS212616 AS61365. Il ne s’agit pas d’une carte complète des opérateurs, et les collecteurs publics peuvent manquer des sessions privées ou à faible visibilité.
C’est tout de même un indice utile: différents /24 peuvent emprunter des chemins différents adjacents ou quasi adjacents, et AS212616 est visible dans le chemin de route au moins pour la vue 185.184.19.0/24.
Les clients ne doivent pas interpréter cela comme « relié à un seul réseau » ou « totalement redondant » sans plus de preuves. Il est préférable de le lire comme « multi-hébergement partiellement visible ou complexité de politique de fournisseur ». Le client doit demander quels ASN sont des transits de production actifs, lesquels sont des sauvegardes, lesquels sont historiques, et lesquels transportent des services clients spécifiques.
La réponse doit inclure les engagements de bande passante, la diversité des routeurs, la diversité physique des interconnexions, les fenêtres de maintenance, la gestion des DDoS, les contacts d’escalade et les tests de basculement récents.
Le chemin de défaillance est concret. Si AS1680 subit un incident régional ou un problème de filtre de routage, les quatre /24 peuvent-ils continuer via AS212616 ou un autre chemin? Si AS212616 fait partie du chemin 185.184.19.0/24, quel service client dépend de ce /24? Si AS8551 est dans l’objet de politique mais pas actuellement visible dans BGP, s’agit-il d’une session de réserve, d’un arrangement historique inactif, d’un chemin planifié ou d’un artefact de politique? Si le trafic bascule après une défaillance, le fournisseur a-t-il suffisamment de capacité amont et de préférence de route propre pour éviter les pertes de paquets?
Ces questions ne sont pas accusatoires. Elles sont la différence entre un catalogue de services et une conception opérationnelle. Un fournisseur d’hébergement peut honnêtement vendre un service résilient à partir d’une périphérie publique compacte s’il a testé des routes, une capacité de réserve et des escalades claires. Il peut aussi vendre un catalogue large à partir d’une chaîne de dépendance étroite qui fonctionne bien jusqu’au premier incident majeur de baie ou de fournisseur. Les données publiques placent Global Cloud quelque part entre ces deux conclusions.
La diligence directe du client détermine de quel côté la réalité se rapproche le plus.
Emek Hefer est un signal de localité fort, pas un certificat de baie
Global Cloud a plusieurs signaux de localité israéliens qui se chevauchent. L’objet organisation RIPEindique HaMasik St 4, 3877701, Emek Hefer, Israël. L’entité aut-num RDAPrépète cette adresse. Lapage d’accueil de Global Clouddonne Hamasek 4, Emek Hefer Industrial Park, et le même numéro de téléphone. Lefichier geofeed référencé dans l’objet inetnum RIPEassocie 185.184.16.0/22 et chacun des quatre /24 àIL, IL-HA, Emek Hefer.
C’est suffisant pour discuter d’Israël et d’Emek Hefer comme le signal de localisation publique dominant pour l’entreprise et son espace d’adressage. Ce n’est pas suffisant pour dire que chaque charge de travail client, sauvegarde, journal, session d’administrateur ou copie de reprise après sinistre se trouve physiquement à Emek Hefer. L’adresse du registre IP, la localité du geofeed et les coordonnées de contact ne constituent pas un audit d’installation.
Un fournisseur peut exploiter des baies sur un site, louer de la capacité sur un autre, utiliser des services de sauvegarde distants, exécuter des outils de support via des plateformes cloud, ou héberger certains services publics chez d’autres opérateurs.
La géolocalisation montre aussi pourquoi la prudence est nécessaire. Lavue geolocde RIPEstat et lavue MaxMind GeoLiteplaçaient le /22 en Israël mais à Ar Rayna, pas à Emek Hefer. Ce conflit ne réfute pas le geofeed. Les bases de données de géolocalisation IP diffèrent souvent, et les données de geofeed peuvent représenter l’intention de l’opérateur ou une localité auto-publiée. Cela prouve que les acheteurs ne doivent pas utiliser une recherche de géolocalisation IP comme une garantie de placement physique.
La localité importe parce que le catalogue de services de Global Cloud inclut des services de type centre de données, cloud, bureau, plateforme, logiciel et sauvegarde. Lapage officielle de l’Autorité israélienne de protection de la vie privée relative à la sécurité des donnéesdécrit des réglementations de sécurité des données qui s’appliquent aux secteurs privé et public et mettent en place des mécanismes organisationnels autour de la sécurité des bases de données. Le même portail gouvernemental publie desdocuments réglementaires sur la vie privée concernant les données transférées vers Israël depuis l’Espace économique européen. Ces pages officielles ne nous disent pas quels clients de Global Cloud traitent des données personnelles ou si Global Cloud agit en tant que sous-traitant dans un contrat spécifique. Elles expliquent pourquoi un acheteur ne peut pas laisser la localisation des données comme une simple phrase marketing.
Pour un client, les questions pratiques sont simples. Où les charges de travail principales sont-elles hébergées? Où les sauvegardes sont-elles stockées? Les sauvegardes sont-elles chiffrées et testées? Quels employés, sous-traitants ou fournisseurs peuvent accéder aux systèmes depuis l’extérieur d’Israël? Les journaux, les flux de surveillance, les tickets de support ou les systèmes d’identité sont-ils traités sur des plateformes étrangères? Si le client doit prouver la manipulation de données israéliennes, de l’EEE ou spécifiques à un secteur, quelles pièces contractuelles et quels contrôles techniques Global Cloud fournit-elle?
Les preuves publiques de Global Cloud soutiennent le thème de la souveraineté et de la localisation des données parce que l’entreprise a une empreinte réseau et de bureau israélienne et vend des services adjacents au cloud. Elles ne soutiennent pas une déclaration de conformité globale.
Le catalogue de services est assez large pour créer une dépendance client sérieuse
Lapage cloud en anglaisde Global Cloud ne se limite pas à une simple proposition d’hébergement web. Elle décrit des services de centre de données et de cloud, l’intégration entre les systèmes d’entreprise et les terminaux, la surveillance et la maintenance continues, la virtualisation sur des plateformes de type VMware et KVM/XEN/Hyper-V, une connexion Internet sécurisée, un stockage sécurisé, DaaS, PaaS, Infrastructure as a Service, un service de collaboration, IT as a Service et Software as a Service. Lapage d’hébergement en anglaisrépète le thème du centre de données et du cloud et énumère l’hébergement, DaaS et des services de téléphonie. Lapage à proposindique en hébreu que Global Cloud Ltd a été fondée en 2013 et positionne l’entreprise autour d’un service personnalisé par des experts locaux.
Ces affirmations importent car elles placent Global Cloud dans la couche de dépendance plutôt que dans celle du nom de domaine banalisé. Une entreprise utilisant DaaS dépend du courtage de session, de l’identité, du stockage, de la performance des terminaux et du support. Une entreprise utilisant IaaS dépend du calcul, du stockage, du réseau, de la gestion des images et de la récupération. Une entreprise utilisant des services de collaboration ou de téléphonie dépend de la disponibilité, des flux d’appels, des annuaires, du provisionnement des utilisateurs et de l’export de configuration.
Une entreprise utilisant des logiciels gérés dépend des correctifs, des sauvegardes, du contrôle d’accès et de l’approbation des changements.
L’empreinte réseau publique peut soutenir de tels services, mais elle ne révèle pas leur profondeur installée. Quatre /24 visibles peuvent supporter une plateforme régionale significative, en particulier pour un fournisseur israélien ciblé. Ils peuvent aussi masquer un domaine beaucoup plus restreint si les services sont fournis via des plateformes tierces ou de la capacité louée.
Les affirmations du site web en matière de sécurité, de survivabilité et de support 24h/24, 7j/7 doivent être converties en engagements mesurables: canaux de support, temps de réponse, notification d’incident, fréquence des sauvegardes, temps de restauration, point de restauration, export de données, basculement côté client et assistance à la résiliation.
Une tension pratique dans les preuves du site web concerne les horaires de support. L’en-tête de la page d’accueil en anglais indique des heures de bureau du dimanche au jeudi, de 09h00 à 18h00, avec fermeture le vendredi et le samedi. La page cloud indique que l’équipe de support travaille 24h/24, 7j/7. Il peut y avoir une explication simple: les horaires du bureau commercial diffèrent de la couverture du support technique. L’acheteur doit rendre cette distinction explicite dans le contrat. Qu’est-ce qui est assuré 24h/24, 7j/7? Qu’est-ce qui est en astreinte? Quel niveau de gravité obtient une réponse immédiate?
Quel chemin de contact fonctionne pendant une panne réseau? Le portail de support est-il hébergé en dehors de l’environnement concerné? Qui peut approuver des changements d’urgence en dehors des heures normales de bureau?
Le catalogue de services crée également une dépendance en matière de licences et de plateforme. La page cloud fait référence au support d’infrastructure de type VMware, XEN et Microsoft. Un client doit demander si son service est dédié, multi-locataire ou sous-traité; si les licences de plateforme sont incluses; si les snapshots sont portables; si les images de machines virtuelles peuvent être exportées dans des formats standard; et si les données d’identité, de téléphonie ou de collaboration peuvent être migrées sans un long projet manuel.
La leçon centrale pour le risque client est que les preuves publiques de Global Cloud sont suffisamment crédibles pour être prises au sérieux, mais aussi assez larges pour que l’acheteur ne doive pas accepter une seule assurance générique de « cloud ». Chaque service du catalogue a un mode de défaillance différent.
La capacité installée et la capacité utilisable peuvent diverger rapidement
Les acheteurs de cloud confondent souvent la capacité installée avec la capacité utilisable. La capacité installée est ce qu’un fournisseur a construit, loué ou configuré dans des conditions normales. La capacité utilisable est ce qui reste disponible quand quelque chose tombe en panne, quand un client grandit, quand un fournisseur change ses conditions, ou quand une migration doit se faire sous contrainte. L’empreinte visible de Global Cloud est assez grande pour un véritable service hébergé et assez petite pour que les clients demandent combien de place de réserve existe derrière.
Le /22 contient 1 024 adresses IPv4. L’IPv4 publique est rare, et le contrôle d’un /22 est précieux pour un fournisseur d’hébergement régional. Mais le nombre d’adresses n’est pas le nombre de calculs. Si certaines adresses sont utilisées pour l’infrastructure, l’accès client statique, le NAT, la gestion, le courrier électronique, les VPN, les passerelles de bureau ou les équipements réseau, le pool d’adresses publiques disponibles pour de nouveaux services hébergés peut être plus petit que le nombre brut ne le suggère.
Si certains services sont adressés en privé derrière des passerelles, le pool d’adresses publiques peut sous-estimer la capacité de calcul. Le BGP public seul ne peut pas résoudre cela.
Les étiquettes de sous-réseau plus spécifiques ajoutent à la question.SHVDOM-Core-Subnetressemble à une infrastructure cœur;LNS-Static-Subentsuggère une fonction d’accès statique ou d’abonné;SHVDOM-SubnetetSHVDOM-1-Subnetsuggèrent une segmentation spécifique au service. Ce ne sont que des étiquettes de registre, mais elles devraient amener l’acheteur à cartographier le service acheté avec la dépendance réelle. Un client DaaS est-il servi depuis une ferme de bureaux sur un /24? Une fonction d’accès statique ou LNS est-elle liée à la connectivité client? La gestion cloud et les charges de travail client sont-elles séparées? Les réseaux de sauvegarde sont-ils visibles ou privés?
La capacité utilisable dépend aussi du stock de matériel. Si un serveur tombe en panne, Global Cloud peut-elle le remplacer localement, ou la réparation dépend-elle du stock du fournisseur et des délais d’importation? Si un routeur ou un pare-feu tombe en panne, y a-t-il un équipement de rechange sur site avec une configuration à jour? Si une baie de stockage se dégrade, y a-t-il assez de marge pour reconstruire sans écraser les performances? Si un cluster d’hyperviseurs perd un nœud, les hôtes restants sont-ils dimensionnés pour N+1 ou simplement pour une charge moyenne?
Aucune de ces questions ne trouve de réponse dans les enregistrements RIPE ou les affirmations du site web. C’est précisément pourquoi elles doivent être posées. Les archives publiques prouvent l’existence d’un opérateur réel et une joignabilité actuelle. Le contrat doit prouver la capacité de service et la capacité de récupération.
Les baies, les fournisseurs de transit, le matériel, le support et la facturation sont les véritables chemins de défaillance
Le principal chemin de défaillance de ce dossier n’est pas théorique. Pour Global Cloud, les chemins de défaillance publique les plus plausibles sont une interruption de baie ou d’installation, un problème de fournisseur de transit ou de filtre de route, une pénurie de matériel, un échec d’escalade de support, un litige de facturation ou de contrat fournisseur, et des limites de migration.
Une défaillance de baie ou d’installation testerait l’accès physique. Si la capacité cloud de Global Cloud est concentrée dans une seule salle ou chez un seul fournisseur de centre de données, un problème d’alimentation, de refroidissement, de fibre, de contrôle d’accès ou de téléopération pourrait devenir une interruption de service. Le site web de l’entreprise revendique la sécurité et la survivabilité, et son contenu cloud en hébreu revendique plusieurs centres de données géographiquement séparés et des options de reprise après sinistre. Les archives publiques ne vérifient pas le nombre, l’identité ou l’indépendance de ces sites.
Un client doit demander une liste des sites sous confidentialité si nécessaire, mais la réponse doit tout de même indiquer si les systèmes primaires, de sauvegarde et de gestion partagent un même domaine de défaillance.
Une défaillance de fournisseur de transit testerait la dépendance envers AS1680 et AS212616. Les enregistrements publics de voisins et de cohérence montrent deux pairs observés, avec AS8551 dans la politique mais pas visible dans BGP au moment de la requête. Un client doit demander si chaque /24 routé a au moins deux chemins actifs, si ces chemins entrent par des routeurs et des bâtiments différents, si tous les chemins sont dimensionnés pour le basculement, et si l’atténuation des DDoS dépend d’un seul opérateur. La réponse doit être une conception réseau actuelle, pas seulement un objet de registre.
Une pénurie de stock de matériel testerait l’économie derrière le service. Des fournisseurs de petite taille peuvent fournir un excellent service avec des pièces de rechange locales prudentes et une couverture claire du fournisseur. Ils peuvent aussi être en difficulté si un disque, une alimentation, un module de routeur ou un boîtier de pare-feu défaillant doit être sourcé après l’incident. Le client doit demander des objectifs de remplacement par type de service: hôte virtuel, serveur dédié, baie de stockage, commutateur haut de baie, routeur de périphérie, pare-feu, dispositif de sauvegarde et équipement de site client le cas échéant.
Une défaillance de support testerait la différence entre l’expression 24h/24 et 7j/7 et l’escalade réelle. La revendication de support 24h/24 et 7j/7 sur le site web est utile, mais les clients doivent définir les niveaux de gravité, les canaux de ticket, l’escalade téléphonique, la couverture linguistique, l’autorité après les heures ouvrées et les communications d’incident. Si le site de support ou le courrier électronique dépend du même réseau fournisseur, le client doit connaître le chemin hors bande.
Une défaillance de facturation ou de contrat fournisseur est moins dramatique qu’une coupure de courant mais peut être tout aussi perturbante. Parce que Global Cloud est un LIR et possède son propre espace d’adressage, la dépendance aux ressources d’adressage semble plus contrôlée que pour les fournisseurs qui annoncent des blocs loués. Cependant, le transit amont, les licences logicielles, les baux de centres de données, les services de sauvegarde et les services de type Microsoft peuvent tous créer des dépendances contractuelles.
Les clients doivent demander quel préavis s’applique avant que des changements de prix, d’adresses IP, de plateforme ou de fournisseur ne les affectent.
Une défaillance de migration est le risque le plus silencieux. Si un client souhaite partir, peut-il exporter les images de machines virtuelles, les profils de bureau, les données de messagerie, les bases de données logicielles, la configuration téléphonique, la politique de pare-feu, les zones DNS, les journaux et les sauvegardes dans des formats utilisables? Global Cloud offre-t-elle une fenêtre de chevauchement payante? Les adresses IP du client peuvent-elles être déplacées ou seulement les noms DNS? Le bon moment pour répondre à ces questions est avant que le service ne devienne critique.
Qui est affecté lorsque ce type de fournisseur échoue
Les utilisateurs affectés ne sont probablement pas des clients hyperscale abstraits. Le site web de Global Cloud s’adresse aux entreprises qui ont besoin d’intégration, de bureaux virtuels, de systèmes logiciels, de téléphonie, de collaboration, d’hébergement et d’informatique gérée. Cela désigne des organisations de petite et moyenne taille, des centres d’appels, des équipes de développement, des détaillants, des cabinets de services professionnels et des entreprises locales qui peuvent ne pas vouloir exploiter leur propre infrastructure. Pour ces clients, le fournisseur n’est pas seulement un vendeur.
Il peut être l’endroit où les employés se connectent chaque matin, où les applications s’exécutent, où les sauvegardes reposent, ou encore où les outils de téléphonie et de collaboration dépendent de l’identité et de l’accès réseau.
L’impact opérationnel d’une défaillance dépend donc du service. Un client d’hébergement web peut subir une indisponibilité publique et des changements DNS. Un client DaaS peut perdre les sessions de travail des employés. Un client d’application gérée peut perdre la continuité des processus métier. Un client de téléphonie peut perdre le routage d’appels. Un client IaaS peut devoir faire face à la récupération de serveur, à la cohérence du stockage et à la reconstruction du pare-feu. Un client de service logiciel peut rencontrer des questions d’export de données et de licences.
C’est pourquoi le large catalogue de services de Global Cloud augmente le fardeau de la diligence. Un fournisseur qui vend uniquement de l’hébergement web statique peut être évalué avec un seul ensemble de vérifications. Un fournisseur qui vend des services de centre de données, du cloud, du bureau, de la plateforme, des logiciels, de la collaboration et de l’informatique nécessite une carte des risques par service. La même périphérie AS61365 peut être pertinente pour plusieurs produits, mais chaque produit a des exigences différentes en matière d’état, de récupération et de migration.
L’impact diffère également selon la sensibilité des données. Un client qui manipule des dossiers d’employés, des informations liées à la santé, des dossiers financiers ou des données personnelles européennes a plus à vérifier qu’un client qui gère un site vitrine public. Les documents officiels israéliens sur la vie privée cités plus haut indiquent clairement que la sécurité des bases de données et le traitement transfrontalier des données sont des sujets réglementés.
L’acheteur doit exiger une répartition écrite des responsabilités: quelle partie est le responsable du traitement ou le sous-traitant, qui gère l’accès, comment les sauvegardes sont protégées, comment les incidents sont signalés, et où les données sont transférées.
Global Cloud peut être un fournisseur régional pratique pour les clients qui souhaitent un support local et un routage israélien. Les preuves publiques soutiennent cette possibilité. Elles ne suppriment pas la nécessité de tester les chemins de défaillance avant que le fournisseur ne devienne un point unique de continuité des activités.
Ce qui améliorerait le niveau de preuve
Les preuves publiques actuelles méritent un niveau moyen parce que la couche des ressources réseau est solide alors que la couche de capacité de service est sous-documentée. Le niveau s’améliorerait si Global Cloud publiait ou fournissait plusieurs types de preuves opérationnelles vérifiables.
Premièrement, elle pourrait fournir un résumé actuel des installations et des plateformes. Cela ne nécessite pas d’exposer des plans d’étage sensibles. Il devrait identifier les sites principaux et secondaires, si les sites sont détenus ou en colocation, s’ils sont indépendants géographiquement et en termes de domaine d’alimentation, quels services tournent où, et comment les sauvegardes sont séparées. Les allégations du site web concernant plusieurs centres de données et la reprise après sinistre deviendraient bien plus convaincantes si elles étaient assorties des rôles actuels des sites et des types de services.
Deuxièmement, elle pourrait fournir un résumé actuel du routage et du transit. AS1680 et AS212616 sont visibles dans BGP; AS8551 est dans la politique. Le fournisseur pourrait dire lesquels sont actifs, en réserve ou historiques; si chaque /24 a une diversité de route active; si le basculement est testé; et ce à quoi les clients doivent s’attendre pendant la maintenance. Elle pourrait également publier un profil PeeringDB. Unerequête API PeeringDB pour l’ASN 61365a retourné une réponse 404 d’entité non trouvée au moment de la recherche, ce qui signifie qu’aucun profil réseau PeeringDB public n’était disponible via cette requête API. PeeringDB est volontaire, donc l’absence n’est pas une preuve d’absence. C’est tout de même une occasion manquée de divulgation pour les informations d’interconnexion, d’installation et de contact.
Troisièmement, elle pourrait documenter les objectifs de sauvegarde et de restauration pour chaque produit. DaaS, IaaS, hébergement, logiciel et téléphonie ne devraient pas partager une promesse de sauvegarde générique unique. Chacun devrait avoir une date de dernière restauration testée, un objectif de temps de récupération, un objectif de point de récupération, des exclusions et des responsabilités client. Si la restauration dépend d’options de sauvegarde achetées par le client, cela doit être clair.
Quatrièmement, elle pourrait documenter les droits de migration. La confiance dans un service hébergé s’améliore lorsque les clients savent comment ils peuvent partir. Les formats d’export, les fenêtres de transition DNS et IP, la portabilité des images, les extractions de bases de données, les exportations de profils, les exportations de courrier électronique, les exportations de configuration téléphonique et la rétention des journaux doivent être clairs avant un litige ou une panne.
Cinquièmement, elle pourrait nettoyer et aligner le langage des services publics. La page de services en anglais est utilisable, mais le mélange de formulations Global Cloud et Xpress Technologies, les problèmes d’orthographe et le contenu partiellement traduit rendent plus difficile pour les tiers de savoir quelles allégations sont actuelles. Un catalogue de services plus propre ne prouverait pas la résilience, mais il réduirait l’ambiguïté.
Ces améliorations ne sont pas cosmétiques. Elles transformeraient une empreinte routée crédible en une dépendance client plus vérifiable.
Les questions pratiques de l’acheteur
Un client qui envisage Global Cloud doit commencer par les faits qui sont déjà bons. Demander à l’entreprise de confirmer qu’AS61365 et 185.184.16.0/22 sont la périphérie de production actuelle pour le service acheté. Demander lesquels de 185.184.16.0/24, 185.184.17.0/24, 185.184.18.0/24 et 185.184.19.0/24 sont utilisés pour le service. Demander si les ROA RPKI restent valides et qui approuve les changements de route. Demander si l’état des objets de route et de l’IRR est suffisant pour tous les filtres des fournisseurs de transit.
Puis poser les questions physiques. Où le service principal est-il hébergé? La baie, la cage ou la salle de données est-elle détenue, louée ou sous-traitée? Quelles alimentations électriques, onduleurs, groupes électrogènes, systèmes de refroidissement et processus de téléopération sont impliqués? Quelles pièces de rechange sont sur place? Qui peut entrer en dehors des heures ouvrées? Quels services partagent le même bâtiment et lesquels sont séparés?
Puis poser les questions réseau. Quels fournisseurs de transit transportent le trafic de production aujourd’hui? Lesquels sont en réserve? AS1680 ou AS212616 peuvent-ils indépendamment supporter la pleine charge? Quel est le rôle actuel d’AS8551? Y a-t-il des routeurs et des interconnexions séparés? Les contrôles anti-DDoS sont-ils spécifiques à un opérateur? Les changements BGP sont-ils examinés par des pairs et testés?
Puis poser les questions de support. Que signifie 24h/24 et 7j/7 en pratique? Cela couvre-t-il le support téléphonique, la réponse des ingénieurs, la surveillance, les changements d’urgence et les communications avec les clients? Que se passe-t-il le vendredi ou le samedi lorsque la ligne téléphonique publique des heures de bureau indique une fermeture? Quel est le chemin de contact hors bande si le réseau du fournisseur est lui-même défaillant?
Puis poser les questions de données. Où se trouvent les données primaires, les sauvegardes, les journaux et les données de tickets de support? Quelles plateformes traitent les données d’identité, de messagerie, de surveillance ou de collaboration? Quelles réglementations le client doit-il satisfaire, et quelles preuves Global Cloud peut-elle fournir? Comment les sauvegardes sont-elles chiffrées, restaurées et supprimées?
Enfin, poser les questions de sortie. Comment le client peut-il exporter les systèmes, les données et la configuration? Peut-il conserver les adresses IP, ou doit-il renuméroter? Quelle est la durée de la fenêtre de chevauchement? Quelle assistance est incluse? Que se passe-t-il si la résiliation fait suite à un litige de facturation, un incident de service ou un changement de fournisseur?
Ces questions ne supposent pas que Global Cloud est faible. Elles supposent que la capacité hébergée est physique, contractuelle et opérationnelle même lorsqu’elle est vendue en tant que cloud.
La conclusion: réseau crédible, preuve de récupérabilité incomplète
Global Cloud Ltd est plus substantielle dans les archives publiques que ne le suggérerait l’hypothèse d’une empreinte ténue du dossier. L’entreprise a un objet organisation LIR RIPE, un AS actif, une allocation IPv4 claire, quatre annonces /24 actuellement visibles, une couverture d’origine de route RPKI valide, des signaux de localité israéliens et un catalogue de services officiel autour du cloud, de l’hébergement, du bureau, des logiciels, de la collaboration et de l’informatique gérée. C’est suffisant pour établir un sujet d’infrastructure-entreprise crédible.
L’incertitude restante ne porte pas sur l’existence du nom. Elle porte sur la quantité de services récupérables qui se cachent derrière ce nom. Les données publiques ne prouvent pas le nombre de baies, de sites, de serveurs, de systèmes de stockage, d’ingénieurs de support, de tests de basculement ou de charges de travail client. Elles ne prouvent pas si le large catalogue de services est fourni depuis une infrastructure détenue par Global Cloud, une infrastructure en colocation, des plateformes partenaires ou un mélange. Elles ne prouvent pas si un client peut migrer proprement en situation de stress.
C’est pourquoi le titre de l’article est intentionnellement physique. Global Cloud vend de la capacité hébergée, mais la valeur de cette capacité dépend encore des baies, du transit et des fenêtres de réparation. AS61365 peut être visible alors qu’un client subit encore un problème de restauration. Un /22 peut être bien enregistré alors qu’un acheteur a encore besoin d’une preuve de matériel de rechange. Une ROA valide peut protéger la validation de l’origine alors qu’un incident chez le fournisseur de transit teste encore le basculement.
Une revendication de support 24h/24, 7j/7 peut être vraie alors que le client a encore besoin de détails sur l’escalade.
Le niveau de preuve doit rester Moyen jusqu’à ce que Global Cloud ou ses clients puissent vérifier l’indépendance des installations, le basculement des routes, l’escalade du support, la restauration des sauvegardes et les droits de migration. La couche réseau publique est réelle et relativement bien documentée. La couche de résilience des services reste une tâche de diligence.