Own Cloud Networks vend une capacité hébergée qui reste dépendante des racks, du transit et des fenêtres de réparation

Résumé

• Own Cloud Networks possède une empreinte publique plus solide que ne le laisserait supposer un simple nom de société. Les enregistrements RDAP de l'APNIC indiquent ORG-OCN2-AP, AS134606, une allocation IPv4 160.250.204.0/23 et une attribution IPv6 2001:df4:bf40::/48, avec des contacts d'enregistrement et d'abus liés aux boîtes mail Own Cloud Networks et WebDedis.
• Les preuves actuelles de routage ne démontrent pas un numéro d'AS Own Cloud fonctionnant de manière indépendante. RIPEstat a montré qu'AS134606 n'avait aucun préfixe annoncé et une visibilité RIS nulle le 12 juillet 2026 à 08h00 UTC, alors que 160.250.204.0/24, 160.250.205.0/24 et 2001:df4:bf40::/48 étaient visibles comme étant annoncés par AS140641, YOTTA Network Services Private Limited. Hurricane Electric montre le même schéma concret: les préfixes Own Cloud sont annoncés par Yotta et signés valides pour cette origine.
• La surface commerciale WebDedis vend des VPS bon marché, de l'hébergement web, un placement dans des centres de données indiens, des serveurs dédiés, des variantes de VPS gérées et autogérées, de l'hébergement cPanel, de l'hébergement applicatif, de l'hébergement revendeur et du support. Ces pages constituent une preuve utile d'une entreprise d'hébergement orientée client, mais elles ne prouvent pas la propriété des baies, la redondance des installations, la profondeur du stock de pièces détachées, la diversité du transit, l'indépendance des sauvegardes ou le délai de récupération dont bénéficierait un client spécifique.
• La rétrogradation opérationnelle est donc « visible mais la reprise n'est pas prouvée ». Les acheteurs doivent vérifier le placement dans les centres de données, si Yotta n'est qu'un transit ou une dépendance d'hébergement plus profonde, ce qui se passe si la route annoncée par Yotta est retirée, quelle équipe de support peut agir en dehors des heures ouvrables, comment les sauvegardes sont restaurées en dehors du chemin défaillant et si les données peuvent être exportées avant qu'une panne de facturation, matérielle, amont ou du portail ne devienne une interruption d'activité.

Le registre public montre une empreinte réelle, pas un dossier de résilience abouti

La première distinction utile concernant Own Cloud Networks est entre l'existence et la résilience. Le registre public corrobore l'existence. L'enregistrement RDAP de l'APNIC pourAS134606désigneOWNCLOUDNETWORKS-AS-APcomme Own Cloud Networks en Inde, avec un enregistrement le 6 décembre 2024 et une date de dernière modification le 2 juillet 2025. L'entité d'organisationORG-OCN2-APde l'APNIC nomme Own Cloud Networks, donne une adresse à Gurugram, indique un numéro de téléphone et utilise[email protected]comme contact courriel. L'entité d'administrateurOwn Cloud Networkset l'entité d'abusIRTutilisent la même adresse à Gurugram et[email protected]. Il s'agit d'une piste d'identité tangible d'opérateur de réseau.

La piste des ressources de numérotation est également tangible. L'enregistrement RDAP IPv4 de l'APNIC pour160.250.204.0montre la plage 160.250.204.0-160.250.205.255 commeOWNCLOUDNETWORKS-IN, allouée de manière portable, pays IN, enregistrée le 11 décembre 2024. L'enregistrement RDAP IPv6 de l'APNIC pour2001:df4:bf40::montre le bloc 2001:df4:bf40::/48 attribué de manière portable à la même organisation. Il ne s'agit pas de pages marketing. Ce sont des enregistrements de registre pour des ressources de numérotation Internet.

La surface de services orientée client est visible via WebDedis. Lapage d'accueil WebDedisfait la publicité de l'hébergement Web, de l'hébergement VPS et de serveurs dédiés, décrit l'offre comme un hébergement bon marché avec un support 24h/24 et 7j/7, et expose une navigation produit pour les serveurs dédiés, les VPS, l'hébergement Web, l'hébergement applicatif et les noms de domaine. Lapage VPS bon marchévend des plans VPS indiens avec KVM Linux VPS, un accès root complet, une adresse IPv4 dédiée, des lignes de bande passante et une fonctionnalité « India centres de données ». Lapage serveurs dédiésfait la publicité de services de serveurs dédiés en Inde, aux États-Unis et en Europe. L'APNIC ne déclare pas que chaque produit WebDedis est opéré directement par Own Cloud Networks, mais les contacts APNIC utilisent des boîtes mail WebDedis, ce qui fait de la surface WebDedis une preuve pertinente de l'empreinte opérationnelle de Own Cloud.

Cela suffit à rejeter l'interprétation la plus faible. Il ne s'agit pas simplement d'un nom d'annuaire sans aucun signe d'infrastructure. Il possède un ASN, un espace d'adressage, des contacts d'abus, des pages de service et une visibilité de routage en direct pour ses préfixes. Mais le même enregistrement ne répond pas à la question client la plus importante: si une charge de travail échoue, où se trouve exactement l'élément défaillant, qui le contrôle et comment le client récupère-t-il?

Cet écart est important car les produits vendus ne sont pas uniquement des abonnements logiciels. Un VPS est une partition de serveurs physiques. Un serveur dédié est une boîte spécifique ou un petit ensemble de boîtes. L'hébergement Web dépend de panneaux de contrôle, de stockage partagé, de files d'attente de messagerie, de DNS, de bases de données, de sauvegardes et de personnel de support. Un domaine ou un compte de facturation peut faire partie du chemin de récupération.

L'étiquette marketing peut être « cloud », mais le chemin de défaillance passe toujours par les baies, l'alimentation, le refroidissement, la fibre, l'origine de la route, le stock de pièces de rechange et les personnes capables d'apporter des modifications sous pression.

Le jugement de cet article est donc nuancé. Own Cloud Networks dispose de preuves publiques crédibles d'une empreinte d'hébergement en direct. Il ne dispose pas encore de preuves publiques suffisamment solides pour considérer cette empreinte comme une infrastructure cloud résiliente de manière indépendante. La lecture responsable n'est pas « éviter par défaut », mais « vérifier avant de s'y fier pour un système qui ne peut tolérer un sauvetage manuel ».

WebDedis vend une économie d'hébergement: prix bas, petits plans et risque physique partagé

Les pages WebDedis rendent le modèle commercial évident. L'offre s'adresse aux acheteurs à la recherche d'un hébergement Web, d'un service VPS, de serveurs dédiés et d'un hébergement applicatif courant à bas prix, et non aux entreprises à la recherche d'un contrat de résilience multi-régions entièrement audité. Le titre de la page d'accueil décrit « Best Cheap Web Hosting, VPS Hosting & Dedicated Servers ». La page VPS bon marché fait la publicité de VPS indiens à partir de 99 Rs par mois, et ses données structurées indiquent que le service est une offre VPS.

La page explique le VPS comme des serveurs physiques dédiés partitionnés en plusieurs serveurs virtuels, chaque nœud fonctionnant de manière indépendante avec des ressources CPU, RAM, stockage et système d'exploitation allouées.

Cette description est utile car elle expose la frontière d'abstraction. Un client peut acheter un petit plan virtuel, mais le fournisseur doit toujours placer ce plan sur un nœud hôte disposant de capacités CPU, mémoire, disque, réseau et alimentation limitées. Un prix d'entrée bas peut être parfaitement rationnel pour des sites de développement, des sites Web de petites entreprises, des applications à faible trafic, des environnements de test et des clients qui savent qu'ils achètent une récupération au mieux des efforts. Cela ne constitue pas en soi une preuve de capacité de réserve réservée.

Le menu produit montre également une gamme de modèles de contrôle de service. WebDedis propose des VPS bon marché, des VPS cPanel, des VPS autogérés, des VPS entièrement gérés, des VPS Windows autogérés et des VPS Windows entièrement gérés. Cette distinction modifie le chemin de défaillance. Dans un VPS autogéré, le client peut assumer la charge de la maintenance du système d'exploitation tandis que le fournisseur est responsable du nœud, de l'alimentation, du réseau et de la couche de virtualisation. Dans un VPS entièrement géré, le client peut s'attendre à plus d'aide au niveau de la couche logicielle.

La frontière du support doit être écrite, car le moment de la défaillance est généralement celui où « géré » devient ambigu.

Le service de serveur dédié crée une dépendance différente. Lapage des serveurs dédiéspropose une offre de serveur dédié et une navigation vers les pages de serveurs dédiés Linux et Windows pour l'Inde, les États-Unis et l'Europe. Un serveur dédié peut réduire le risque de voisin bruyant, mais il augmente l'exposition au risque lié au stock de matériel et à la fenêtre de réparation. Si une carte mère, un SSD, une alimentation, une carte réseau ou un contrôleur RAID tombe en panne, la récupération dépend des pièces de rechange, des droits d'accès, des interventions à distance et de la volonté du fournisseur de remplacer ou de migrer rapidement la machine. Le client peut avoir plus de contrôle sur le système d'exploitation mais moins d'élasticité qu'un grand cloud public.

L'hébergement Web et l'hébergement cPanel ajoutent une couche supplémentaire. Lapage d'hébergement cPanelet d'autres pages d'hébergement font la publicité de fonctionnalités d'hébergement partagé telles que des bases de données, des comptes de messagerie, un placement dans des centres de données indiens, un langage de disponibilité et de support. L'hébergement partagé est souvent le moyen le plus économique de maintenir un petit site en ligne, mais c'est aussi l'endroit le plus facile pour qu'un pool de stockage défaillant, un panneau de contrôle, un sous-système de messagerie ou un processus de sauvegarde affecte de nombreux clients à la fois. Le petit client ne peut souvent pas voir de quel serveur, volume de stockage ou lien amont il dépend.

Le fait économique important n'est pas que l'hébergement à bas prix est mauvais. L'hébergement à bas prix est un marché légitime, et de nombreux sites ont besoin précisément de ce compromis prix-performance. Le fait important est que l'hébergement à bas prix pousse l'acheteur à poser des questions plus claires sur ce qui a été réservé. La sauvegarde est-elle incluse? Est-elle mensuelle, quotidienne ou manuelle? Se trouve-t-elle dans le même système de stockage? Le client peut-il la récupérer sans un panneau de contrôle fonctionnel? Y a-t-il une capacité de réserve pour redémarrer un nœud ailleurs?

La promesse de support inclut-elle la réparation du système d'exploitation ou seulement l'accessibilité du nœud?

Si Own Cloud Networks et WebDedis veulent être jugés comme une infrastructure résiliente plutôt que comme une capacité bon marché, les preuves publiques devraient aller au-delà du menu produit et du prix. Elles devraient montrer le placement des installations, la topologie amont, l'architecture de sauvegarde, l'escalade du support, les fenêtres de maintenance et la restauration testée. En l'absence de ces preuves, la lecture la plus juste est commerciale: il s'agit d'une empreinte de vente au détail d'hébergement et de VPS avec des ressources visibles, pas d'une plateforme cloud indépendante documentée publiquement.

Les preuves de routage sont réelles, mais elles passent par Yotta

Les preuves techniques les plus solides se situent au niveau de la couche d'espace d'adressage. La partie la plus faible est le routage indépendant. Le 12 juillet 2026, la requêteannounced-prefixes de RIPEstat pour AS134606n'a retourné aucun préfixe sur la fenêtre de requête de deux semaines. La requêterouting-status de RIPEstat pour AS134606a signalé une visibilité IPv4 et IPv6 nulle, un espace annoncé nul et aucun voisin observé à 08h00 UTC. Lavue d'ensemble AS de RIPEstatdécrit AS134606 commeOWNCLOUDNETWORKS-AS-AP - Own Cloud Networksmais le marque comme non annoncé.

L'espace d'adressage Own Cloud lui-même est visible. La requêterouting-status de RIPEstat pour 160.250.204.0/24a montré le préfixe vu pour la première fois le 7 janvier 2025, vu pour la dernière fois le 12 juillet 2026, avec l'origine AS140641 et une visibilité sur 325 pairs IPv4 RIS sur 325. Larequête pour 160.250.205.0/24a montré la même origine et une visibilité IPv4 complète. Larequête pour 2001:df4:bf40::/48a montré l'origine AS140641 et une visibilité IPv6 complète sur 322 pairs IPv6 RIS sur 322. En termes simples, les préfixes étaient visibles globalement, mais pas depuis le propre ASN de Own Cloud.

AS140641 appartient à Yotta Network Services Private Limited dans le registre APNIC. L'enregistrement RDAP de l'APNIC pourAS140641nommeYOTTAen Inde, enregistré en 2020. Lavue d'ensemble AS de RIPEstat pour AS140641nomme le titulaire commeYOTTA - YOTTA NETWORK SERVICES PRIVATE LIMITEDet marque l'ASN comme annoncé. Lesdonnées announced-prefixes de RIPEstat pour AS140641incluent les deux /24 IPv4 et le /48 IPv6 de Own Cloud dans la fenêtre actuelle de deux semaines.

Le BGP Toolkit de Hurricane Electric corrobore cette séparation. Lapage AS134606identifie Own Cloud Networks en Inde mais ne montre aucun préfixe annoncé. Les pages160.250.204.0/24,160.250.205.0/24et2001:df4:bf40::/48montrent chacune Own Cloud Networks comme titulaire du préfixe et AS140641, Yotta Network Services Private Limited, comme origine d'annonce. Elles montrent également la validité IRR et RPKI pour cette origine.

La RPKI est particulièrement révélatrice. La vue de validation RPKI de RIPEstat pour160.250.204.0/24,160.250.205.0/24et2001:df4:bf40::/48montre AS140641 comme une origine valide. Les mêmes données montrent également des entrées AS134606 qui seraient invalides comme origine pour ces annonces de préfixes spécifiques au moment de la requête. Cela ne constitue pas automatiquement un problème. Cela peut refléter un arrangement de routage délibéré hébergé en amont. Mais cela signifie qu'un client ne devrait pas considérer le propre ASN de Own Cloud comme la frontière de résilience active à moins que Own Cloud ne puisse expliquer la conception du routage.

C'est la principale conclusion réseau de l'article. Own Cloud Networks semble contrôler les ressources de numérotation, et ces ressources sont visibles sur l'Internet mondial. L'origine de route visible, cependant, est Yotta. Cela pourrait être une conception sensée: un petit fournisseur d'hébergement peut utiliser un plus grand réseau indien pour le routage amont, le placement en centre de données ou les deux. Mais cela fait de Yotta une partie de la chaîne de dépendance du client.

Si la politique de routage, l'installation, l'interconnexion, la relation de compte ou la file d'attente de support de Yotta échouent, les ressources publiques de Own Cloud pourraient être affectées même si la marque et le panneau client de Own Cloud sont toujours opérationnels.

La question technique de l'acheteur est donc spécifique: Yotta est-il uniquement une origine de route amont pour les préfixes attribués à Own Cloud, ou est-ce aussi le centre de données, la baie, l'alimentation, les interventions à distance et la dépendance d'accès d'urgence? Le registre public ne répond pas à cela. Jusqu'à ce qu'il le fasse, un client devrait traiter Yotta comme un fournisseur critique dans le chemin de service.

Le langage de centre de données indien aide la localité, mais pas la preuve du domaine de défaillance

Les pages WebDedis utilisent à plusieurs reprises un langage d'hébergement indien. La page VPS bon marché présente « India centres de données » comme une fonctionnalité. Plusieurs tableaux d'hébergement Web utilisent « Indian centres de données ». La page d'accueil et la navigation produit orientent les acheteurs indiens vers un hébergement local à bas prix et des VPS. Pour de nombreux clients, c'est un réel avantage.

Une empreinte de centre de données local peut réduire la latence, simplifier les paiements, maintenir le support dans un marché familier et faciliter les discussions sur la localisation des données par rapport à un fournisseur d'hébergement partagé étranger.

La localité, cependant, n'est pas la même chose que la résilience. Un service peut être en Inde et n'avoir qu'une seule baie, une seule dépendance amont, un seul pool de stockage, un seul emplacement de sauvegarde, un seul système de facturation et une seule file d'attente de support. Il peut également se trouver dans un grand centre de données indien alors que le client n'a aucun droit contractuel de contacter l'opérateur de l'installation, aucune visibilité sur les alimentations électriques et aucune assurance qu'une autre baie ou salle dispose d'une marge réservée pour le basculement.

Les preuves publiques n'identifient pas la salle ou la baie exacte où les charges de travail Own Cloud/WebDedis s'exécutent. Elles ne précisent pas si l'affirmation de centre de données indien fait référence aux installations de Yotta, à un autre fournisseur de colocation, à un parc de serveurs loués, à un accord de revente ou à plusieurs emplacements. Elles ne disent pas si les serveurs dédiés en Inde appartiennent à WebDedis, sont loués à un autre fournisseur ou provisionnés par l'intermédiaire d'un partenaire grossiste.

Elles ne disent pas si les hôtes VPS, les nœuds d'hébergement Web, les sauvegardes et les panneaux de contrôle se trouvent dans la même installation.

Cette incertitude modifie ce que la « souveraineté des données et la localité » devraient signifier pour un acheteur. Il ne suffit pas de demander si le service est indien. L'acheteur doit savoir où les données de production sont stockées, où les sauvegardes sont stockées, où les journaux sont stockés, d'où l'accès du support peut provenir et si un emplacement non indien apparaît dans le chemin de récupération. Une page marketing peut dire Inde. Un contrat et un test de restauration devraient montrer le chemin réel des données.

Laloi de 2023 sur la protection des données personnelles numériquesfait de la gouvernance des données personnelles une question au niveau du conseil d'administration pour les organisations indiennes. Elle ne transforme pas chaque VPS indien en une conception conforme. Les clients ont toujours besoin d'obligations de traitement, de procédures de notification des violations, d'engagements de suppression, de contrôles d'accès et de registres indiquant où résident les données et les sauvegardes. Si une petite entreprise utilise WebDedis pour héberger des formulaires clients, des dossiers scolaires, des rendez-vous cliniques, des commandes de détail ou des documents d'employés, elle a besoin de preuves que l'emplacement d'hébergement et la gestion des sauvegardes correspondent à ses responsabilités légales.

Lesdirectives CERT-In sur les incidents cybernétiquessont également pertinentes pour les opérations d'hébergement car elles imposent des attentes en matière de signalement des incidents et de conservation des journaux aux fournisseurs de services et aux utilisateurs en Inde. Le point pour les clients de Own Cloud est pratique: si un serveur hébergé est compromis, suspendu, restauré ou migré, qui détient les journaux, combien de temps sont-ils conservés et le client peut-il les obtenir assez rapidement pour remplir ses obligations?

Pour les clients financiers réglementés, ladirective cadre de la RBI sur l'externalisation informatiquerappelle que l'externalisation des opérations cloud ou d'hébergement n'externalise pas la responsabilité. Même lorsque le fournisseur est petit, le client doit comprendre la sous-traitance, l'accès aux données, les droits d'audit, la continuité des activités et les modalités de sortie. Les pages publiques de Own Cloud ne publient pas ces réponses pour les clients réglementés. Cela ne disqualifie pas le service pour un usage ordinaire. Cela signifie que l'usage réglementé nécessite des preuves privées.

La localité des données n'est donc un avantage que lorsqu'elle est explicite. Le placement indien peut être précieux. L'empreinte APNIC et WebDedis visible de Own Cloud est indienne. Mais aucun acheteur ne devrait assimiler « centre de données indien » à « protection des données indépendante, sauvegarde indépendante et récupération testée ».

Le principal chemin de défaillance est la baie, l'origine de route, le support et la facturation combinés

Le chemin de défaillance probable pour Own Cloud Networks n'est pas un événement dramatique unique. C'est un empilement de dépendances ordinaires qui deviennent visibles en même temps. Une baie perd l'alimentation. Un nœud tombe en panne. Un périphérique de stockage se dégrade. Une route est retirée. Un filtre DDoS change. Un compte de facturation est suspendu. Un client ne peut pas accéder au panneau. Un ticket de support attend derrière une file d'attente. Chaque événement est gérable isolément. Ensemble, ils définissent si le fournisseur est un service cloud ou un ensemble d'hébergement fragile.

Le chemin de la baie est le plus simple. Si un hôte VPS tombe en panne, le client doit savoir si les machines virtuelles redémarrent automatiquement ailleurs ou si le support doit intervenir. Si un serveur dédié tombe en panne, le client doit savoir si du matériel de rechange est sur place, si les disques peuvent être déplacés, si le remplacement est couvert et si le client ou le fournisseur est propriétaire des supports contenant les données. Si l'hébergement partagé tombe en panne, le client doit savoir si le panneau de contrôle, la base de données et les files d'attente de messagerie peuvent être restaurés indépendamment.

Le chemin amont est plus spécifique en raison du routage originaire de Yotta. Si AS140641 cesse d'annoncer 160.250.204.0/24, 160.250.205.0/24 ou 2001:df4:bf40::/48, la joignabilité publique du client peut disparaître même si les serveurs Own Cloud sont toujours alimentés. Si le problème est une politique de routage de Yotta, Own Cloud doit avoir un chemin d'escalade vers Yotta. Si le problème est une interconnexion ou une panne d'installation, Own Cloud doit avoir l'autorité d'ouvrir l'incident approprié. Si le problème est une relation commerciale, le client peut n'avoir aucun levier direct.

Le chemin du portail et de la facturation est plus discret mais tout aussi important. De nombreux fournisseurs d'hébergement bon marché centralisent l'état du compte, les renouvellements, la suspension du service, les sauvegardes et le support dans un seul panneau de facturation. Si le panneau est indisponible ou si une erreur de facturation suspend le service, le client peut être privé de l'accès aux données mêmes dont il a besoin pour migrer. Les pages WebDedis renvoient à une connexion de facturation et à des flux de commande. C'est normal.

Les acheteurs devraient tout de même demander ce qui se passe lorsqu'un état de facturation entre en conflit avec la récupération d'urgence.

Le chemin du support est là où le langage de service devient une réalité opérationnelle. WebDedis annonce un support 24h/24 et 7j/7 sur ses pages d'accueil et d'hébergement. C'est utile, mais un support 24x7 peut signifier beaucoup de choses: chat en direct, téléphone, accusé de réception de ticket, triage junior, action d'administrateur système ou intervention à distance en centre de données. Un petit client doit savoir laquelle de ces options s'applique à son plan. Un client plus important a besoin d'une escalade nommée, de délais de réponse et de l'autorité pour approuver les changements en dehors des heures ouvrables.

Le chemin de sauvegarde relie tout cela. Si les sauvegardes sont stockées dans la même installation et contrôlées par le même panneau de compte, elles aident en cas d'erreurs mais pas en cas de défaillance d'accès au fournisseur. Si les sauvegardes sont mensuelles, elles peuvent être trop anciennes pour un système d'entreprise. Si les sauvegardes sont gérées par le fournisseur, le client doit savoir s'il peut en recevoir une copie pendant que le serveur principal est en panne. Si les sauvegardes ne sont pas incluses, le client a besoin de sa propre copie hors fournisseur avant que quoi que ce soit ne casse.

Le meilleur test de défaillance pour Own Cloud n'est donc pas une question générique de disponibilité. Le test est le suivant: supposons qu'une baie ou un hôte soit en panne, que des changements de route AS140641 soient nécessaires, que la file d'attente standard des tickets soit lente et que le panneau client soit indisponible. Qui agit, d'où, avec quelles informations d'identification et comment le client fait-il circuler à nouveau les données ou le trafic?

Les allégations de capacité doivent être converties en capacité de récupération utilisable

Les fournisseurs d'hébergement vendent souvent de la capacité installée. Les clients ont besoin de capacité de récupération utilisable. La différence est facile à manquer. La capacité installée est la quantité totale de CPU, RAM, disque et réseau disponible dans l'ensemble du parc d'un fournisseur. La capacité de récupération utilisable est la quantité qui peut absorber une défaillance pendant que les autres clients continuent de fonctionner.

Les pages de plans WebDedis montrent les tailles et les fonctionnalités des plans, y compris les petites tailles de VPS, les limites de bande passante, les adresses IPv4 dédiées et le placement en centre de données indien. Ce sont des faits produits. Ils n'indiquent pas au client s'il y a une marge de réserve si le nœud sous-jacent tombe en panne. Ils n'indiquent pas si une revendication de 1 Gbps s'applique au port, à la liaison montante partagée, à la politique d'utilisation équitable du plan ou à la route en cas de congestion. Ils n'indiquent pas si les E/S de stockage sont dédiées, partagées ou soutenues par des baies partagées.

Les serveurs dédiés rendent la capacité plus tangible mais pas nécessairement plus récupérable. Si un client loue un serveur spécifique, cette capacité est installée parce que la machine existe. La capacité de récupération nécessite une autre machine compatible, des disques de rechange ou une restauration d'image testée. Elle nécessite également une propriété claire des licences et des clés logicielles. Si le fournisseur ne peut pas fournir le même jeu d'instructions CPU, la même disposition de stockage, le même mappage IP public ou le même état de pare-feu, la récupération peut être une reconstruction plutôt qu'un redémarrage.

La récupération VPS dépend du cluster de virtualisation. WebDedis décrit les VPS comme des nœuds virtuels sur des serveurs physiques dédiés. Cela peut être fiable si les hôtes sont bien gérés, mais la résilience dépend de l'utilisation de disques locaux ou de stockage partagé, de la réalisation de snapshots hors hôte, de la possibilité de migrer un nœud à chaud, de la disponibilité de l'anti-affinité et de l'existence d'une capacité d'hôte de réserve après une défaillance. Aucun de ces détails n'est visible publiquement.

La récupération de l'hébergement partagé dépend de la pile du plan de contrôle. Un serveur cPanel peut être facile à gérer et à sauvegarder, mais de nombreux petits hébergeurs exécutent des serveurs partagés denses. Une seule panne de serveur peut mettre hors service plusieurs sites clients, boîtes aux lettres et bases de données. Le client doit demander si les sauvegardes sont par compte, où elles sont stockées, si la restauration est en libre-service et si le fournisseur a récemment restauré un serveur entier.

La même logique s'applique à la capacité IP. Own Cloud détient une allocation /23 IPv4 et une attribution /48 IPv6, mais les preuves BGP montrent les parties routées comme deux /24 IPv4 et un /48 IPv6 via Yotta. L'espace d'adressage aide un hébergeur à éviter la dépendance au pool IP d'un tiers, mais comme l'origine est Yotta, la capacité de routage utilisable dépend toujours de cet arrangement amont. Un client qui a besoin d'une continuité d'adresse IP statique devrait demander s'il peut conserver les mêmes adresses si la relation d'hébergement, la baie ou l'amont change.

La question pratique d'approvisionnement est simple: qu'est-ce qui a été réservé pour la défaillance? Un plan VPS à bas prix peut ne rien réserver au-delà de la gestion normale de l'hôte. Un plan d'hébergement professionnel peut inclure une sauvegarde mensuelle mais pas un basculement rapide. Un serveur dédié peut inclure un remplacement au mieux des efforts. Un serveur géré peut inclure une aide pratique mais pas un second site. L'acheteur doit adapter le plan au risque plutôt que de supposer que le mot « cloud » signifie qu'il existe une capacité excédentaire.

Les sauvegardes et la migration sont la véritable voie de sortie

Pour un petit fournisseur d'hébergement, le contrôle le plus fort du client n'est souvent pas le basculement interne au fournisseur. C'est la capacité de partir proprement. Cela commence par les sauvegardes, mais ne s'arrête pas là. Une sauvegarde n'est utile que si elle peut être restaurée en dehors du chemin défaillant, avec les bonnes données, clés, DNS, cohérence de base de données et configuration applicative.

Leguide de planification d'urgence du NISTconsidère l'analyse d'impact sur les activités, les stratégies de récupération, les tests de plans et la maintenance comme des contrôles de continuité centraux. Lesconseils de sécurité du stockage du NISTfont la distinction entre les snapshots, les sauvegardes, la réplication, l'archivage et l'assurance de restauration. Ces distinctions sont importantes pour les clients de Own Cloud. Un snapshot local sur un nœud VPS n'est pas la même chose qu'une sauvegarde hors fournisseur. Une sauvegarde mensuelle d'hébergement partagé n'est pas la même chose qu'une restauration testée. Une sauvegarde détenue par le fournisseur n'est pas la même chose qu'une copie de sortie détenue par le client.

La question de la portabilité du cloud est également assez ancienne pour avoir un cadre clair. Lesynopsis et recommandations cloud du NISTrelie les accords de service, les performances, la fiabilité, le transfert de données, la sécurité et la portabilité. Pour un client Own Cloud/WebDedis, cela signifie demander non seulement si les données peuvent être téléchargées, mais dans quel format, à quelle vitesse, dans quel état du compte, avec quelles informations d'identification et pendant que quel service est en panne.

La surface produit WebDedis inclut un langage de migration sur certaines pages et met l'accent sur des mises à niveau faciles et le support. C'est un langage commercial utile, mais il devrait être converti en un manuel de sortie. Pour un site Web, le manuel comprend les fichiers, les bases de données, les zones DNS, les boîtes aux lettres, les certificats SSL, les tâches cron, les secrets applicatifs et les informations d'identification du compte. Pour un VPS, il comprend des images disque ou des scripts de reconstruction, des règles de pare-feu, des clés SSH, la surveillance et les versions des paquets.

Pour un serveur dédié, il comprend la disposition des disques, le micrologiciel, les licences, les attributions IP et le matériel de remplacement.

Le client devrait tester la sortie pendant que tout est sain. Restaurer une copie chez un autre fournisseur. Pointer un domaine de test vers l'hôte alternatif. Confirmer l'intégrité de la base de données. Confirmer le flux de messagerie. Confirmer que l'ancien fournisseur peut fournir une sauvegarde utilisable sans supplication manuelle. Confirmer que la dépendance à l'IP publique n'est pas cachée dans les listes d'autorisation du pare-feu, les passerelles de paiement, les intégrations API ou le glue DNS.

C'est particulièrement important pour les clients utilisant l'espace d'adressage Own Cloud pour de nombreux petits sites Web. Les pages 160.250.204.0/24 et 160.250.205.0/24 de Hurricane Electric montrent de nombreux mappages de domaines sous les préfixes. De tels signaux DNS passifs et dérivés de certificats ne prouvent pas les listes de clients, les revenus ou la responsabilité légale. Ils suggèrent que l'espace d'adressage dessert de véritables propriétés Web.

Si ces propriétés incluent de petites entreprises, des écoles, des cliniques, des magasins ou des sociétés de services locaux, leurs propriétaires peuvent ne pas avoir de personnel distinct de reprise après sinistre. Leur contrôle de résilience le plus sûr est une sauvegarde actuelle et portable.

La migration n'est pas un manque de confiance. C'est une partie normale de la possession d'une charge de travail hébergée. Un fournisseur peut être honnête, réactif et techniquement compétent tout en subissant un événement d'alimentation, amont, de facturation ou matériel qui dépasse sa capacité publique. Le client qui a répété la migration peut traiter la panne comme un incident de service. Le client qui n'a pas répété la migration peut découvrir que sa seule copie de l'entreprise se trouve derrière le même panneau défaillant.

Qui est affecté lorsque ce système tombe en panne

Les parties affectées sont plus larges que le titulaire du compte. Un plan d'hébergement bon marché peut soutenir un magasin, une école, une clinique, un site d'actualités, une agence de voyage, une organisation communautaire, un portfolio de développeur ou un fournisseur de logiciels local. Si l'hébergeur tombe en panne, la personne qui a acheté le plan est peut-être la seule à connaître Own Cloud ou WebDedis de nom, mais l'impact public est ressenti par les clients, les patients, les étudiants, les donateurs, le personnel, les partenaires de paiement, les partenaires de livraison et les personnes à la recherche d'informations.

Les signaux BGP et de domaine passif rendent ce risque concret. Les pages de Hurricane Electric pour les préfixes IPv4 de Own Cloud montrent de nombreux domaines mappés à des adresses à l'intérieur de 160.250.204.0/24 et 160.250.205.0/24. Cela ne doit pas être surinterprété. Les mappages DNS peuvent être périmés, l'hébergement partagé peut colocaliser des domaines non liés et l'agrégation par des tiers peut inclure des enregistrements historiques. Néanmoins, le signal correspond au modèle produit WebDedis: une empreinte d'hébergement dense pour de nombreuses petites propriétés Web.

Lorsque l'hébergement dense tombe en panne, la communication importe autant que la réparation. Le fournisseur a besoin d'un canal d'état qui ne dépend pas du parc d'hébergement défaillant. Les clients doivent savoir s'ils doivent attendre, restaurer ailleurs, changer le DNS, renouveler un paiement, contacter le support par téléphone ou éviter d'aggraver la situation. Un fournisseur qui ne communique que par le même portail ou serveur de messagerie qui a échoué laisse les clients dans l'incertitude.

Les clients les plus vulnérables sont ceux qui combinent production, sauvegarde, DNS et support dans le même compte. Si le panneau du fournisseur est indisponible, ils peuvent ne pas pouvoir changer le DNS. Si les sauvegardes sont stockées chez le même fournisseur, ils peuvent ne pas pouvoir restaurer ailleurs. Si la messagerie est hébergée sur le même serveur, ils peuvent ne pas recevoir les messages d'incident. Si la facturation est également liée au même compte, un problème de renouvellement ou de suspension peut ressembler à une panne technique.

Pour les acheteurs professionnels, la réponse consiste à cartographier les fonctions métier, pas seulement les serveurs. Quelles fonctions doivent survivre: site Web, base de données, messagerie, paiements, réservations, admission des patients, gestion de l'apprentissage, tickets de support, authentification, partage de fichiers, journaux d'audit? Quel composant Own Cloud ou WebDedis soutient chacune d'elles? Quel chemin alternatif fonctionne si ce composant est indisponible? Quelle personne est autorisée à le déplacer? La cartographie peut être courte, mais elle doit exister avant la panne.

Pour Own Cloud Networks, de meilleures preuves publiques seraient également utiles. Une page d'état, une description des installations, une explication amont, une politique de sauvegarde, un processus d'abus, une portée de support et une documentation de récupération en langage clair réduiraient l'incertitude. Aucun de ces éléments ne nécessite la publication d'une architecture sensible. Ils permettent simplement aux clients de distinguer l'hébergement à bas prix au mieux des efforts de la capacité gérée critique pour l'entreprise.

Questions d'approvisionnement auxquelles il faut répondre avant une utilisation en production

Un acheteur peut utiliser Own Cloud Networks ou WebDedis de manière rationnelle si la charge de travail correspond aux preuves. L'important est de poser les bonnes questions avant que la première facture ne devienne une dépendance.

Premièrement, renseignez-vous sur le placement des installations. Quel centre de données indien héberge le plan? S'agit-il d'une installation Yotta, d'une salle de colocation distincte ou d'un fournisseur de serveurs en gros? Y a-t-il plus d'un emplacement? Les sauvegardes sont-elles dans la même salle? Les hôtes virtuels, les panneaux de contrôle, la facturation, le DNS et les systèmes de sauvegarde sont-ils séparés? Le client peut-il choisir ou vérifier la localité?

Deuxièmement, renseignez-vous sur le routage. Pourquoi les préfixes Own Cloud sont-ils annoncés par AS140641 plutôt que par AS134606? AS134606 est-il réservé pour une utilisation future, une politique interne ou un basculement? Que se passe-t-il si Yotta ne peut pas annoncer les routes? Own Cloud dispose-t-il d'une alternative amont ou d'une autre origine de route? Les IP des clients sont-elles portables si le fournisseur change d'amont? Existe-t-il un plan RPKI pour le basculement qui ne rendra pas l'origine alternative invalide?

Troisièmement, renseignez-vous sur le matériel et la réparation. Pour les serveurs dédiés, à qui appartient le serveur? Quelles pièces sont stockées? Quelle est la fenêtre de remplacement? Les disques sont-ils déplacés ou restaurés à partir d'une sauvegarde? Qui s'occupe des supports contenant les données? Pour les VPS, la défaillance de l'hôte est-elle automatique ou manuelle? Le stockage est-il local ou partagé? Y a-t-il assez de capacité de réserve pour redémarrer les machines virtuelles affectées pendant la maintenance?

Quatrièmement, renseignez-vous sur l'autorité de support. Que signifie le support 24x7 pour le plan acheté? S'agit-il d'un accusé de réception de ticket, d'un dépannage en direct ou d'une action d'ingénierie? Un support téléphonique est-il disponible pour les incidents critiques? Qui peut escalader vers le centre de données ou Yotta? Le client reçoit-il un chemin d'urgence nommé pour les charges de travail de production?

Cinquièmement, renseignez-vous sur la sauvegarde et la portabilité. Les sauvegardes sont-elles incluses? À quelle fréquence sont-elles effectuées? Où sont-elles stockées? Le client peut-il les télécharger sans un panneau fonctionnel? Les sauvegardes de base de données sont-elles cohérentes au niveau applicatif? Le fournisseur peut-il restaurer vers un autre hôte? Le client a-t-il testé la restauration en dehors de Own Cloud/WebDedis? Que se passe-t-il si le service est suspendu ou contesté?

Sixièmement, renseignez-vous sur les processus juridiques et de sécurité. Quels journaux sont conservés? Comment les signalements d'abus sont-ils traités? Comment les données, les informations d'identification et les sauvegardes des clients sont-elles protégées? Comment les obligations indiennes de signalement d'incident et de protection des données sont-elles prises en charge? Quels sous-traitants peuvent accéder au système? Quel est le processus de sortie lorsqu'un client part normalement?

Ces questions ne sont pas excessives. Ce sont les questions normales cachées sous chaque achat de VPS bon marché. Plus le prix mensuel est bas, plus il est important de savoir quels risques sont exclus du marché.

Le verdict: une empreinte réseau visible, une confiance opérationnelle conditionnelle

Own Cloud Networks obtient une conclusion d'empreinte réelle. Les enregistrements APNIC montrent une organisation indienne, AS134606, des ressources IPv4 et IPv6 portables, des contacts liés à WebDedis et une entité d'abus mise à jour. WebDedis fait la publicité d'une surface d'hébergement en direct au détail couvrant les VPS, l'hébergement Web, les serveurs dédiés, l'hébergement applicatif, l'hébergement revendeur et le support. RIPEstat et Hurricane Electric montrent les préfixes de Own Cloud visibles sur l'Internet mondial.

La rétrogradation est tout aussi claire. L'origine de route active est AS140641 de Yotta, et non AS134606 de Own Cloud. Les pages publiques n'identifient pas l'installation exacte, la frontière de propriété, le placement des baies, le modèle de matériel de rechange, l'emplacement des sauvegardes, l'historique des restaurations, l'escalade du support ou les droits de portabilité des données. Les preuves soutiennent la disponibilité du service en tant qu'empreinte d'hébergement; elles ne soutiennent pas le traitement de Own Cloud comme une plateforme cloud résiliente de manière indépendante sans preuves privées.

Pour les sites à faible risque, les expériences, les petites entreprises disposant de leur propre sauvegarde, les charges de développement et les clients qui acceptent une récupération manuelle, le service peut correspondre au prix. Pour les données réglementées, la production à haute disponibilité, les systèmes de paiement, les dossiers médicaux ou scolaires, les sites de service public, les portails clients ou toute charge de travail où une longue restauration serait matériellement préjudiciable, la barre de diligence est plus élevée. Ces clients devraient exiger une réponse de récupération écrite avant de déplacer la production.

La phrase la plus importante pour un acheteur est simple: Own Cloud Networks vend de la capacité hébergée, et la capacité semble réelle, mais la frontière de récupération n'est pas publique. Le client ne devrait acheter que la résilience qu'il peut voir, tester et exporter. Tout le reste reste une hypothèse reposant sur une baie, une route originaire de Yotta et une file d'attente de support.