02 Emre Erim trading as Medyabim centres de données doit prouver si la capacité de centre de données commercialisée peut survivre aux contraintes d'alimentation et de connectivité

Résumé

• Les enregistrements publics de RIPE donnent à Medyabim une identité juridique et réseau cohérente. Leregistre RDAP de RIPE pour AS44922nomme MEDYABIM-AS, liste Emre Erim comme contact administratif et technique, et inclut ORG-MIH2-RIPE avec le nom « Emre Erim trading as Medyabim centres de données »; leregistre d'organisation RIPEindique le pays TR, le statut LIR, une adresse à Bursa et des coordonnées.
• La surface routée actuelle est réelle mais étroite. L'aperçu AS de RIPEstata marqué AS44922 comme annoncé, tandis que lestatut de routagemontrait un préfixe IPv4, aucun préfixe IPv6, 256 adresses IPv4 et un voisin observé à l'instantané vérifié. Lavue des préfixes annoncéslistait seulement 37.247.116.0/24 comme actuel.
• Le contrôle positif le plus fort est la sécurité d'origine de route pour ce /24 actuel. Lavalidation RPKI de RIPEstat pour 37.247.116.0/24 via AS44922a retourné valide, avec une ROA autorisant AS44922 et une longueur maximale /24.
• Les propres pages de Medyabim commercialisent une empreinte opérationnelle plus large que ce que la surface de route AS44922 actuelle prouve. Lapage centre de donnéesrevendique du matériel dédié prêt dans les baies Medyabim, une longue expérience des serveurs Linux DirectAdmin, des options de serveurs en Turquie et à l'étranger, une capacité de sortie totale de 50 Gbit/s, des chemins de fournisseurs nommés tels que Turk Telekom et Superonline, et une surveillance du trafic client. Lapage colocationrevendique une continuité de service de 99 % avec bande passante, un support 24/7, un placement derrière pare-feu, un port de redémarrage gratuit et cinq adresses IP.
• Les assurances publiques restent incomplètes. Les pages officielles ne publient pas d'alimentation électrique double, d'autonomie de générateur, de topologie de refroidissement, de suppression d'incendie, de salles de rencontre des transporteurs, de fenêtres de maintenance, de résultats de basculement mesurés, de certification des installations ni de profil d'interconnexion PeeringDB actuel. Le domaine propre de Medyabim se résout en 185.7.83.213, alors que RIPEstat montre que 185.7.83.0/24 est actuellement annoncé par DATAFOREST plutôt que par AS44922, de sorte que les cartes de dépendance côté client doivent séparer la marque Medyabim, son extrémité AS44922, l'espace d'adressage attribué et les surfaces de service annoncées par des tiers.

La question utile n'est pas de savoir si Medyabim existe

Il existe une catégorie de profils d'hébergement régionaux où le premier devoir est de prouver que l'entreprise est plus qu'une ligne dans un annuaire. Medyabim n'est pas si faible. Le registre public contient une personne physique nommée, un nom commercial, un enregistrement d'organisation RIPE, un système autonome, des ressources d'adressage attribuées, des pages de service officielles, une adresse de contact à Bursa et des offres de produits en état de marche.

Le problème est différent: le registre public prouve l'identité et une extrémité de route limitée, tandis que le langage marketing de l'entreprise demande aux clients de croire en une histoire de capacité de centre de données plus large.

La source d'identité la plus solide est RIPE. L'enregistrement RDAP pour AS44922nomme le système autonome MEDYABIM-AS et liste l'organisation « Emre Erim trading as Medyabim centres de données ». Il liste également Emre Erim comme contact administratif et technique, avec une adresse à Bursa et un numéro de téléphone. L'enregistrement d'organisation RIPE REST pour ORG-MIH2-RIPEporte le même nom commercial, le pays TR, le type LIR, l'adresse de Bursa, le téléphone, le fax, les références de mainteneur Medyabim, et la date de création en mars 2008. C'est bien plus solide qu'une entrée d'annuaire d'hébergement récupérée sur le web.

La proprepage de contactde Medyabim ancre indépendamment l'adresse opérationnelle publique. Elle décrit « Medyabim centres de données ve Internet Hizmetleri » et donne Kükürtlü Mahallesi, Oulu Caddesi, Oylum Sitesi F Blok Kat 3 No 13, Osmangazi, Bursa, avec des numéros de téléphone et l'adresse e-mail publique[email protected]. Cette adresse correspond étroitement à l'adresse RIPE. Cela importe car l'entité n'est pas présentée comme un label cloud offshore sans visage. Ses preuves publiques pointent vers un opérateur basé à Bursa dont les enregistrements de ressources réseau et le site commercial sont au moins mutuellement cohérents.

La page d'histoire de l'entreprise ajoute l'auto-description. Lapage à proposde Medyabim dit que l'entreprise opère depuis 2000 autour de services Internet, de produits logiciels et de systèmes clés en main basés sur Linux; dit qu'elle s'est ensuite concentrée sur l'enregistrement de domaines, l'hébergement web, les serveurs dédiés, la gestion de serveurs et le conseil; et dit qu'à partir de 2006, elle a construit à Bursa, avec ses propres ressources, un centre de données d'une capacité de plus de 500 serveurs pour ses propres serveurs et ceux de sociétés d'hébergement web. Ce n'est pas une preuve indépendante de baies installées ou de capacité électrique, mais c'est une revendication opérationnelle spécifique et testable.

La question n'est donc pas « y a-t-il un Medyabim? ». La question est « sur quelles parties de la capacité commercialisée par Medyabim un client peut-il compter lorsque l'alimentation, le refroidissement, le routage, le support ou la dépendance amont tombent en panne? ». Pour un acheteur de centre de données ou de colocation, l'identité n'est que la première porte. Le test le plus difficile est la capacité récupérable: le matériel, l'alimentation des baies, le refroidissement, la fibre, le routage et les processus humains qui restent disponibles pendant une panne.

AS44922 est visible, mais sa surface de route publique actuelle est petite

RIPEstat confirme que AS44922 est annoncé. Lepoint de terminaison de l'aperçu ASétiquette le titulaire « MEDYABIM-AS Emre Erim trading as Medyabim centres de données » et marque la ressource comme annoncée à l'instantané vérifié. C'est la conclusion réseau positive. Medyabim a une extrémité de système autonome publique que le système de routage peut voir.

L'échelle de cette extrémité est modeste. Lepoint de terminaison de statut de routagede RIPEstat a montré un préfixe IPv4, 256 adresses IPv4, zéro préfixe IPv6 et un voisin observé. Lepoint de terminaison des préfixes annoncésa listé 37.247.116.0/24 comme l'annonce actuelle de AS44922. Lepoint de terminaison des voisins ASNa montré un seul voisin gauche observé, AS16276. L'aperçu AS de RIPEstat pour AS16276identifie ce voisin comme OVH SAS.

Cela ne signifie pas que Medyabim n'a que 256 clients, une seule baie ou un seul service. Le BGP public ne voit pas les VLAN privés, le stock de revendeurs, l'hébergement adressé par le fournisseur, l'inventaire des serveurs, les interconnexions client ou les surfaces web externalisées. Mais cela signifie que l'extrémité AS44922 visible n'est pas un backbone public large et multi-préfixes, multi-voisins au moment de la vérification. Si un acheteur évalue Medyabim comme dépendance de centre de données, la carte BGP publique ne prouve pas à elle seule la résilience multi-opérateurs.

Lavue de cohérence de routage AS de RIPEstatrend l'écart plus net. Elle a listé 37.247.116.0/24 comme présent à la fois dans le BGP et le whois/IRR de RIPE. Elle a également listé 37.247.117.0/24 et 2a03:400::/32 comme présents dans le whois/IRR mais pas dans le BGP au moment de la vérification. La même vue de cohérence a montré d'anciens pairs d'import/export whois AS9121 et AS53667 non vus dans le BGP, tandis que AS16276 était vu dans le BGP mais pas dans la politique d'import/export whois. C'est un type de dérive normal dans les enregistrements de routage plus anciens, mais c'est exactement pourquoi un client devrait demander des diagrammes actuels au lieu de se fier au texte historique de la politique du registre.

Le contrôle positif est RPKI. La route AS44922 actuelle, 37.247.116.0/24, a passé lavérification de validation RPKIde RIPEstat comme valide. Cela importe car l'autorisation d'origine de route est l'un des rares contrôles publics qu'un acheteur d'hébergement peut vérifier sans voir les documents privés des installations. Une ROA valide ne prouve pas l'alimentation, le refroidissement ou le basculement. Elle montre que l'origine AS44922 visible actuelle n'est pas laissée comme une revendication d'origine de route inconnue dans la couche de validation publique.

La conclusion sur la route est donc étroite et utile. AS44922 est réel. Sa route IPv4 visible actuelle est valide selon RPKI. Sa surface amont observée est mince. Ses preuves IPv6 ne sont pas actuellement annoncées. Ses enregistrements de politique de routage publique ne suffisent pas à prouver la diversité des opérateurs ou le basculement. Un client ne devrait pas traiter cela comme un réseau fantôme, ni comme un réseau de centre de données résilient prouvé.

Les preuves IPv6 et des préfixes dormants exigent une rétrogradation

Medyabim a des preuves de registre IPv6. L'enregistrement de recherche RIPE pour2a03:400::/32montre une allocation 2a03:400::/29 sous TR-MEDYABIM-20110107 et une entrée route6 pour 2a03:400::/32 avec l'origine AS44922. Cela semble solide jusqu'à ce qu'on le compare à la visibilité de routage actuelle.

Lepoint de terminaison d'aperçu de préfixe de RIPEstat pour 2a03:400::/32a marqué le préfixe comme non annoncé au moment de la vérification. Lavue du statut de routagea signalé aucune origine actuelle, zéro pair RIS le voyant, et un événement de dernière observation pour AS44922 le 1er avril 2026. Ce n'est pas une conclusion d'échec en soi. Certains clients peuvent ne pas acheter de service IPv6; certains opérateurs peuvent avoir des plans IPv6 dormants; certains blocs d'adresses sont conservés pour une utilisation ultérieure. Mais cela change ce qui peut être prouvé publiquement. Un fournisseur de centre de données dont les pages officielles actuelles commercialisent des services d'hébergement et de serveur mais dont l'extrémité AS visible n'a pas d'annonce IPv6 actuelle devrait être interrogé sur le support de l'IPv6, son indisponibilité, sa disponibilité sélective, ou sa fourniture via un autre fournisseur.

L'image des préfixes dormants IPv4 est également mitigée. Le résultat de recherche RIPE pour37.247.117.0/24montre NET-MEDYABIM-DC5 et une entrée de route RIPE avec l'origine AS44922 créée en juin 2025. Pourtant, la vérification de cohérence de RIPEstat ne l'a pas vu dans le BGP actuel. Cela pourrait représenter une capacité réservée, une migration planifiée, une route récemment retirée, une plage de secours ou simplement un espace d'adressage inutilisé. Les preuves publiques ne peuvent pas choisir parmi ces explications.

La distinction importante est entre la capacité attribuée et la capacité opérationnelle. Une allocation RIPE, une entrée de route ou une attribution d'adresse peut montrer un contrôle administratif ou une préparation. Cela ne prouve pas que la plage d'adresses sert des clients aujourd'hui, qu'elle est joignable via plusieurs opérateurs, ou qu'elle peut être activée pendant une panne.

Un acheteur qui a besoin de capacité récupérable devrait demander à Medyabim quels préfixes sont en production, lesquels sont réservés, lesquels sont migrés vers d'autres origines, lesquels sont orientés client, lesquels sont réservés à la gestion, et lesquels sont couverts par des processus testés de DDoS, de pare-feu et de RPKI.

Les pages de service propres de Medyabim sont concrètes, mais elles ne publient pas la résilience des installations

Lapage centre de donnéesde Medyabim est plus détaillée qu'une page d'accueil d'hébergement générique. Elle indique que les modèles de serveurs dédiés sont livrés après validation du paiement et que le matériel est prêt dans les baies Medyabim. Elle dit que Medyabim a plus de 15 ans d'expérience avec les serveurs dédiés Linux et utilise activement DirectAdmin depuis 2003. Elle dit que l'entreprise sert avec son propre matériel serveur basé en Turquie, tandis que les services de serveurs dédiés peuvent être choisis en Turquie ou à l'étranger selon la demande. Elle décrit également une « capacité de ligne élevée » et une haute disponibilité comme raison pour proposer rapidement du matériel serveur réel.

La même page fait une grande revendication de connectivité. Elle dit que les connexions Internet principales du centre de données ont été sélectionnées pour fournir un accès rapide depuis la Turquie et le monde, nomme Türk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent Communications, AMS-IX et ECIX Duesseldorf, et indique une capacité totale de sortie de ligne de 50 000 Mbit, soit 50 Gbit/s. Elle dit que les clients de serveurs dédiés peuvent entrer dans un panneau de gestion réseau pour surveiller leur propre trafic 24h/24 et 7j/7 et dit que le centre de données utilise du matériel réseau Foundry Networks et HP Procurve.

C'est une preuve utile, mais elle doit être lue comme un texte de marketing et d'exploitation publié par l'entreprise, pas comme un audit de transporteur en direct. La page ne divulgue pas lesquels des fournisseurs nommés sont des transporteurs physiques actuels, lesquels sont des fournisseurs de transit, lesquels sont des relations d'échange ou de route, lesquels sont des options de transit historiques, lesquels soutiennent les services turcs, et lesquels soutiennent le placement à l'étranger. Elle ne montre pas de salle de rencontre d'installation, d'entrée de fibre diversifiée, de carte d'interconnexion ou d'inventaire de port en direct.

Le BGP public au moment de la vérification a montré un voisin AS44922 observé, pas une carte publique visible de tous les noms de fournisseurs sur la page.

La page est encore plus mince sur l'ingénierie des installations. Elle ne publie pas d'alimentation électrique double, de capacité UPS, d'autonomie de batterie, d'autonomie de carburant du générateur, de redondance de refroidissement, de classe de suppression d'incendie, de charge au sol, de densité des baies, de couches de sécurité physique, de règles de fenêtre de maintenance ou d'exercices de reprise après sinistre. Ces omissions ne sont pas la preuve que les contrôles n'existent pas. De nombreux petits fournisseurs ne publient pas de tels détails.

Mais un client évaluant la résilience d'un centre de données ne devrait pas supposer ces contrôles à partir du mot « centre de données ».

Lapage colocationde Medyabim ajoute des revendications opérationnelles orientées client. Elle dit que Medyabim offre une garantie de disponibilité ou de continuité de service de 99 % avec bande passante pour son service de colocation; dit que les entreprises avec des serveurs dans le centre de données Medyabim peuvent recevoir un support d'entreprise 24h/24 et 7j/7; dit que les statistiques de trafic peuvent être observées en ligne; dit que les serveurs sont derrière un pare-feu; dit qu'un port de redémarrage gratuit sera attribué; dit que la connexion attribuée est dédiée et non limitée; et dit que cinq adresses IP sont attribuées gratuitement pour les serveurs dans le centre de données.

Ce sont de vraies revendications de service, et elles précisent les questions que les acheteurs devraient poser avant de compter sur le service. Une promesse de continuité de service de 99 % n'est pas la même chose qu'un SLA moderne de haute disponibilité, et 99 % peut encore permettre une quantité importante de temps d'arrêt sur une année. Un port de redémarrage n'est utile que si la distribution d'énergie, l'accès à distance, les informations d'identification de la console et les procédures de support survivent à l'incident.

Le placement derrière un pare-feu peut protéger les clients, mais il peut aussi devenir un point d'étranglement partagé. Cinq adresses IP peuvent être suffisantes pour un hébergement simple, mais cela ne dit rien sur la portabilité des sous-réseaux routés ou le basculement. La page donne aux clients des éléments sur lesquels poser des questions, pas une preuve complète de résilience.

Le site officiel prouve l'étendue de l'offre, pas la capacité récupérable

L'étendue de l'offre publique est large. Lapage des packs d'hébergement webde Medyabim annonce des packs d'hébergement avec espace web, trafic, FTP, MySQL, webmail, DirectAdmin, SSL en option, produits de sauvegarde de messagerie, un service IP supplémentaire pour serveur, un service de sauvegarde de serveur de 300 Go, un transfert FTP illimité 24h/24 et 7j/7, des sauvegardes automatiques hebdomadaires et mensuelles, des statistiques avancées, un filtrage anti-spam et un rapport de transfert. Sapage revendeurpropose des packs revendeur avec espace web, quotas de messagerie POP3, trafic mensuel, bases de données MySQL, panneau de contrôle turc, webmail, contrôle DNS en option, options SSL, filtres anti-spam et rapports de trafic.

Lapage VDSexplique les serveurs dédiés virtuels comme des serveurs logiquement séparés sur du matériel physique et liste les fonctionnalités des packs VDS. Lapage d'information du panneau de contrôledit que DirectAdmin est installé sur les serveurs lorsque le serveur est dans le DC Medyabim, décrit la gestion proactive des serveurs, la configuration de sécurité et le suivi des listes noires de spam, et dit que PHP, MySQL, Linux, ionCube et DirectAdmin sont installés et configurés sur tous les serveurs.

Prises ensemble, ces pages montrent que Medyabim vend une pile classique de petit fournisseur: domaines, hébergement partagé, hébergement revendeur, VDS, serveurs dédiés, colocation, stockage de messagerie, SSL, sauvegarde et support Linux/DirectAdmin géré. Ce mélange crée deux types de dépendances. L'une est physique: baies, alimentation, refroidissement, liaisons montantes, pare-feu, ports de redémarrage, serveurs de rechange et accès technicien. L'autre est administrative: portail client, facturation, statut du compte, tickets de support, contrôles de domaine, DNS, messagerie et processus de sauvegarde.

L'offre publique ne dit pas à l'acheteur quelles dépendances sont dans le même domaine de défaillance. Un client pourrait acheter un pack d'hébergement web dont le site web, la messagerie, les sauvegardes, le DNS et l'accès aux tickets dépendent tous des mêmes systèmes du fournisseur. Un revendeur pourrait dépendre du panneau de contrôle et des systèmes de messagerie de Medyabim même si les clients finaux ne voient que la marque du revendeur.

Un acheteur de serveur dédié pourrait avoir un redémarrage à distance mais avoir quand même besoin d'un technicien si la machine ne parvient pas à POST, si un contrôleur de disque tombe en panne, ou si la politique de pare-feu bloque l'accès de récupération. Un client de colocation pourrait posséder le serveur mais dépendre quand même du bâtiment, de l'alimentation, de la liaison montante, du pare-feu et de la réponse du support de Medyabim.

C'est pourquoi la capacité installée ne suffit pas. La revendication de capacité de plus de 500 serveurs de la page à propos et la revendication de capacité de sortie de 50 Gbit/s de la page centre de données décrivent une échelle possible. La capacité récupérable demande ce qui se passe après qu'une alimentation électrique, un chemin UPS, un commutateur, un pare-feu, une liaison montante, un chemin d'authentification ou un canal de support ait disparu. Les pages publiques ne répondent pas à cela.

La surface DNS propre de Medyabim pointe en dehors d'AS44922

L'une des vérifications les plus révélatrices est le domaine propre de Medyabim. Une recherche DNS publique pour medyabim.com.tr a montré que l'apex et le nom www se résolvent en 185.7.83.213, que mail.medyabim.com.tr se résout également en 185.7.83.213, que les serveurs de noms sont ns1.medyabim.com et ns2.medyabim.com, et qu'un enregistrement SPF fait référence à 37.247.112.0/24 et 185.7.83.0/24. Ces faits DNS doivent être traités comme des preuves adjacentes à l'exploitation car ils montrent comment Medyabim présente sa propre surface de service à Internet.

RIPEstat change alors l'interprétation. L'aperçu du préfixe pour 185.7.83.0/24a montré le préfixe annoncé par AS58212, et lepoint de terminaison du statut de routage pour 185.7.83.0/24a listé l'origine actuelle AS58212, tout en notant que le préfixe avait été vu pour la première fois depuis AS44922 en 2012 et avait été vu pour la dernière fois au moment de la vérification depuis AS58212. L'aperçu AS de RIPEstat pour AS58212identifie cette origine comme DATAFOREST dataforest GmbH. De même, l'aperçu du préfixe pour 37.247.112.0/24a montré l'origine actuelle AS29141, et sonaperçu AS29141identifie Bradler & Krantz GmbH & Co. KG.

Cela ne signifie pas que Medyabim dénature son service. L'espace d'adressage peut être attribué, loué, migré, routé par des fournisseurs de transit, hébergé à l'étranger ou utilisé pour des services hérités. Les résultats de recherche RIPE pour Medyabim montrent plusieurs blocs d'adresses étiquetés Medyabim, notamment 37.247.115.0/24, 37.247.118.0/24, 185.7.82.0/24 et 185.7.83.0/24, dont certains sont actuellement attribués par le routage public à d'autres ASN d'origine. La conclusion correcte n'est pas le scandale; c'est la cartographie des dépendances.

Si les surfaces web, de messagerie ou DNS de Medyabim dépendent de préfixes actuellement annoncés par d'autres réseaux, alors les clients doivent savoir quelles parties de leur service sont sur AS44922, quelles parties sont sur un espace d'adressage d'origine externe, et quelles parties sont à l'étranger. Cela importe pour l'analyse des pannes. Si AS44922 a un problème, le site web public ou le courrier de support de Medyabim pourraient encore être joignables via un autre fournisseur. Si le chemin d'origine externe a un problème, la surface de marque Medyabim pourrait tomber en panne même si la route Bursa AS44922 reste active.

Si un client achète un placement « Turquie » mais que le support, la sauvegarde, le DNS ou la dépendance de messagerie se trouvent ailleurs, le client a besoin que cela soit indiqué dans la conception du service.

Le point plus large est que le DNS et le BGP racontent des histoires différentes. Le domaine de marque peut être en ligne tandis que l'extrémité AS est étroite. Un titulaire RIPE peut avoir des plages d'adresses attribuées qui ne sont pas actuellement annoncées par son propre ASN. Un fournisseur peut vendre de l'hébergement tout en dépendant d'origines de route tierces pour des parties de sa propre pile. Aucun de ces faits n'est disqualifiant. Tous signifient qu'une analyse de défaillance doit être précise.

Le silence sur PeeringDB importe car le site nomme de nombreux chemins

PeeringDB est un répertoire volontaire, donc l'absence d'un objet réseau n'est pas la preuve qu'un réseau manque d'interconnexion. Pourtant, cela importe pour Medyabim car la page officielle du centre de données nomme de nombreuses relations de connectivité et une revendication de capacité de sortie totale de 50 Gbit/s. Unerequête API PeeringDB pour l'ASN 44922n'a retourné aucun objet réseau au moment de la recherche. Cela supprime une source publique qui pourrait autrement montrer la présence sur les points d'échange, la présence dans les installations, la politique de peering, les ratios de trafic, les préfixes informationnels et les emplacements d'interconnexion autodéclarés.

Sans profil PeeringDB, un acheteur se retrouve avec les enregistrements RIPE/RDAP, les observations BGP de RIPEstat, les propres pages de Medyabim, le DNS et le langage contractuel. C'est faisable, mais cela ne suffit pas à prouver un accès diversifié aux salles de rencontre des opérateurs. Le BGP public a montré AS16276 comme le voisin actuel observé. La page centre de données de Medyabim nomme Turk Telekom, Superonline, Level3, Tinet, Lambdanet, Cogent, AMS-IX et ECIX Duesseldorf. L'article ne peut pas réconcilier ces couches en une topologie physique actuelle à partir des seules preuves publiques.

La bonne question d'approvisionnement n'est pas de savoir si chaque fournisseur nommé est faux. C'est de savoir si le service de production actuel a plus d'un chemin provisionné indépendamment et si ces chemins sont diversifiés de manière pertinente. Y a-t-il plusieurs fournisseurs de transit payants actifs pour le service client, ou un seul fournisseur amont visible? Certains noms listés sont-ils historiques? Certaines routes sont-elles livrées via un fournisseur amont, un revendeur ou une interconnexion distante? L'installation de Bursa a-t-elle des entrées de fibre diversifiées? Les chemins turcs et européens sont-ils physiquement séparés?

Quelle quantité de trafic le chemin survivant peut-il transporter pendant une panne? Le chemin du pare-feu est-il redondant, et le chemin du port de redémarrage est-il indépendant du routage de production client?

Les preuves publiques ne peuvent pas répondre à ces questions. Elles peuvent identifier le besoin de les poser. Une revendication de 50 Gbit/s est une hypothèse de capacité jusqu'à ce qu'il y ait des preuves de ports actuels, de contrats, de marge d'utilisation et de basculement. Les logos ou textes de fournisseurs nommés ne sont pas équivalents à la diversité de route. Un seul voisin AS observé n'est pas une preuve de raccordement unique, mais c'est suffisant pour exiger une confirmation directe.

Le contrat de service reporte le risque sur le client

Lecontrat de servicede Medyabim est important car il montre comment les promesses techniques publiques rencontrent le risque contractuel. Le contrat indique que Medyabim fournira les services commandés après paiement et acceptation, mais il place également la responsabilité sur les clients pour les informations d'identification du compte, le contenu hébergé, la conformité légale, les taxes et l'utilisation des services. Plus important encore pour la résilience, il dit que les obligations de sauvegarde et de stockage des données du client appartiennent au client sauf indication contraire dans le texte du contrat, tout en disant également que Medyabim sauvegarde et maintient régulièrement les données des clients mais n'est pas responsable des erreurs, pertes ou dommages découlant des interruptions de service ou de la perte de données.

Cette combinaison est courante dans les contrats d'hébergement, mais elle est lourde de conséquences. Les pages d'hébergement publiques peuvent annoncer des sauvegardes automatiques hebdomadaires et mensuelles, des services de sauvegarde optionnels, des rapports de trafic et un support géré. Le contrat de service peut encore limiter la responsabilité du fournisseur si le client n'a pas acheté ou configuré le bon processus de sauvegarde et de restauration.

Un client devrait donc demander la portée exacte de la sauvegarde, la rétention, le test de restauration, le temps de restauration, l'isolement des sauvegardes et si les sauvegardes se trouvent dans la même installation, le même réseau de fournisseur, le même plan de contrôle de compte ou le même domaine de défaillance.

Le même contrat donne à Medyabim des droits de suspension pour les problèmes de paiement, le contenu illégal, le spam et d'autres violations du contrat. Cela est attendu pour un fournisseur d'hébergement protégeant son réseau. Cela signifie également que la continuité du service dépend de l'état administratif ainsi que des systèmes physiques. Un client peut perdre le service par non-paiement, traitement des abus, incident de spam, verrouillage de compte, perte d'identifiants ou litige de support même lorsque les baies et les routes sont saines.

Pour les charges de travail critiques, la facturation, les contacts en cas d'abus et les procédures d'escalade sont des contrôles opérationnels, pas des détails administratifs.

Lapage d'aide du système de supportde Medyabim et lapage d'aide en lignemontrent une posture de support axée sur les tickets. La page centre de données dit que le support téléphonique est disponible pendant les heures de bureau, de 09h00 à 18h00, et en dehors de ces heures, les clients peuvent joindre le fournisseur via un système de support 24h/24 et 7j/7 par ticket et courrier. La page colocation dit que les entreprises avec des serveurs dans le centre de données Medyabim peuvent recevoir un support d'entreprise 24h/24 et 7j/7. Ces déclarations devraient être converties en procédures d'incident avant qu'un client ne fasse confiance au service: qui peut appeler, qui peut ouvrir des tickets d'urgence, s'il y a une escalade téléphonique en dehors des heures, et comment le fournisseur distingue les incidents de redémarrage, réseau, matériel, pare-feu, DNS et abus.

L'alimentation et le refroidissement sont les plus grands angles morts publics

La mission pour cette entreprise est un examen de l'infrastructure du centre de données, et la principale dépendance physique est l'alimentation, le refroidissement, l'accès à la salle de rencontre de la fibre, les opérations de l'installation et les permis locaux. Les pages publiques de Medyabim donnent quelques revendications de type installation mais pas assez de détails d'ingénierie pour soutenir une note de confiance élevée en matière de résilience. La page à propos dit que l'entreprise a construit un centre de données à Bursa d'une capacité de plus de 500 serveurs avec ses propres ressources.

La page centre de données dit que le matériel est prêt dans les baies Medyabim et que l'entreprise utilise son propre matériel serveur. La page colocation dit que les serveurs sont derrière un pare-feu, ont des statistiques de trafic et reçoivent un port de redémarrage gratuit.

Ces déclarations laissent encore l'installation physique presque inobservée. Il n'y a pas de revendication publique d'alimentation électrique double. Il n'y a pas de topologie UPS ou d'autonomie de batterie publiée. Il n'y a pas de nombre de générateurs, de capacité de carburant ou de contrat de ravitaillement. Il n'y a pas de conception de redondance de refroidissement. Il n'y a pas de détail sur la fumée, la suppression d'incendie ou la détection de fuite d'eau. Il n'y a pas de plan d'étage ou de certification de l'installation. Il n'y a pas de déclaration sur les entrées de fibre diversifiées ou la conception de la salle de rencontre.

Il n'y a pas de politique de fenêtre de maintenance qui distingue les travaux planifiés, d'urgence et demandés par le client. Il n'y a pas d'historique d'incidents public montrant une récupération mesurée.

Pour un petit fournisseur de Bursa, une partie de ce silence est compréhensible. Publier trop de détails sur l'installation peut créer un risque de sécurité. Les petits opérateurs peuvent également compter sur des installations en amont, des salles louées, des arrangements d'alimentation de bureau, ou des placements de serveurs mixtes locaux et à l'étranger. Mais le risque pour le client reste le même. Une revendication de « capacité de plus de 500 serveurs » n'est pas équivalente à la capacité d'alimentation utilisable après la défaillance d'un chemin de distribution.

Une revendication de « haute disponibilité » n'est pas équivalente à une autonomie de générateur testée. Un « port de redémarrage » ne remplace pas l'accès à la console distante, les disques de rechange, les procédures de remplacement à chaud ou la disponibilité d'un technicien.

Le test pratique consiste à séparer quatre capacités. La capacité installée est ce que le fournisseur a construit ou dit pouvoir héberger. La capacité vendue est ce que les clients utilisent déjà. La capacité utilisable est ce qui reste après la charge normale, les limites thermiques, les réservations d'énergie, la maintenance et la sursouscription. La capacité récupérable est ce qui reste après la défaillance d'un composant. Les pages publiques décrivent généralement la capacité installée. Les clients ont besoin de la capacité utilisable et récupérable.

Les preuves publiques actuelles de Medyabim ne peuvent pas régler cette question. Elles peuvent seulement définir la demande de preuves: schémas électriques, autonomie de l'UPS et du générateur, conception du refroidissement, politique de densité des baies, contrôles d'incendie et d'eau, diversité des entrées de transporteurs, historique de maintenance, procédure de télémanipulation, politique de pièces de rechange et au moins un exercice documenté de basculement ou de restauration.

Qui est affecté lorsque Medyabim tombe en panne

Les utilisateurs affectés ne sont pas seulement les titulaires de compte directs de Medyabim. Un fournisseur qui vend des domaines, de l'hébergement, des packs revendeur, des VDS, des serveurs dédiés, de la colocation, du stockage de messagerie et des sauvegardes peut se trouver sous de nombreux services en aval. Un pack revendeur peut prendre en charge des dizaines ou des centaines de petits sites web dont les propriétaires peuvent ne pas savoir que Medyabim existe. Un serveur dédié peut porter une application d'entreprise, une base de données, un portfolio d'agence, un service de messagerie ou une boutique en ligne.

Un client de colocation peut posséder le matériel mais dépendre de Medyabim pour l'alimentation, l'accès aux baies, le chemin du pare-feu, la surveillance du trafic et le contrôle du redémarrage.

Le chemin de défaillance n'est pas non plus unidimensionnel. Un événement d'alimentation peut arrêter les serveurs même si les routes amont sont saines. Un événement de refroidissement peut forcer un arrêt ou réduire la densité de baie autorisée. Une panne de pare-feu peut isoler de nombreux clients à la fois. Une seule panne de fournisseur amont peut affecter AS44922 si aucun chemin alternatif n'est actif pour le préfixe concerné. Une panne de support ou de ticket peut ralentir la récupération même si l'installation est intacte.

Une panne DNS ou de messagerie sur un espace d'adressage d'origine externe peut rendre Medyabim plus difficile à contacter tandis que le trafic de production ailleurs fonctionne encore. Une suspension contractuelle ou pour abus peut supprimer le service sans panne physique.

C'est pourquoi la découverte DNS importe. Si le domaine de marque public et le service de messagerie utilisent 185.7.83.213 sous un préfixe actuellement annoncé par DATAFOREST, et si le SPF fait référence à un préfixe 37.247.112.0/24 actuellement annoncé par Bradler & Krantz, alors les clients ne devraient pas supposer que « réseau Medyabim » signifie un AS, une ville, une installation ou une juridiction. Le service peut être plus résilient parce que certains composants se trouvent en dehors de AS44922. Il peut aussi être plus complexe parce que la propriété des incidents traverse les frontières des fournisseurs.

Les personnes qui ont besoin de réponses sont les équipes d'approvisionnement, les agences web, les opérateurs revendeurs, les propriétaires de petites entreprises, les administrateurs système, les responsables de la conformité et les intervenants en cas d'incident. Ils doivent savoir si un service hébergé par Medyabim dispose d'un second chemin, d'un test de restauration récent, d'un canal de support hors bande, de sauvegardes actuelles, d'un accès au transfert de domaine, d'une exportation DNS, d'une continuité de messagerie et d'une autorisation d'origine de route. Ces questions ne sont pas hostiles.

Elles sont le travail minimum requis pour transformer une relation d'hébergement en une dépendance d'infrastructure capable de survivre à une mauvaise journée.

Ce que les clients devraient demander à Medyabim de prouver

Premièrement, demandez une carte réseau actuelle. Elle devrait identifier AS44922, 37.247.116.0/24, tous les préfixes AS44922 réservés ou dormants tels que 37.247.117.0/24, tous les plans IPv6 pour 2a03:400::/32 ou l'allocation plus large, et tous les services clients routés sous AS29141, AS58212 ou d'autres origines. Elle devrait identifier si AS16276 est le seul fournisseur amont actif pour la route AS44922, si d'autres fournisseurs sont actifs via des accords privés ou non observés, et si les noms de fournisseurs sur la page centre de données sont actuels, historiques, indirects ou spécifiques au produit.

Deuxièmement, demandez la résilience de l'installation. La réponse devrait inclure les alimentations électriques, la conception de l'UPS, l'autonomie de la batterie, l'autonomie du générateur, la redondance du refroidissement, les limites de densité des baies, la sécurité physique, les contrôles d'incendie et d'eau, les fenêtres de maintenance, la disponibilité de la télémanipulation, la politique de pièces de rechange et ce que couvre réellement la revendication de continuité de colocation de 99 %. Si le service est à Bursa, demandez quelles sont les dépendances du bâtiment et des services publics.

Si le service est à l'étranger, demandez quel pays, quelle installation, quel fournisseur et quelles conditions légales s'appliquent.

Troisièmement, demandez des preuves de basculement au niveau du client. Medyabim devrait être en mesure de montrer ce qui se passe lorsqu'un fournisseur amont tombe en panne, un pare-feu tombe en panne, un serveur perd l'alimentation, un disque tombe en panne, le client ne peut pas atteindre le portail, la file d'attente de support est occupée, le compte est signalé pour abus, ou le client a besoin d'une migration d'urgence. Les pages publiques mentionnent la surveillance du trafic, les sauvegardes, les ports de redémarrage et les tickets. L'acheteur doit savoir comment ces outils se comportent pendant une panne.

Quatrièmement, demandez les contrôles de données et de sortie. La page d'hébergement mentionne des sauvegardes automatiques hebdomadaires et mensuelles, une sauvegarde optionnelle, des produits de sauvegarde de messagerie et un service de sauvegarde de serveur. Le contrat de service limite la responsabilité de Medyabim pour les interruptions de service et la perte de données, sauf indication contraire dans le contrat.

Les clients devraient exiger des tests de restauration, la portée des sauvegardes, la rétention, le statut hors site, le chiffrement, le contrôle d'accès, le processus d'exportation, le processus de transfert de domaine, l'exportation DNS et la continuité de la messagerie.

Cinquièmement, demandez la preuve que le support peut être joint lorsque le site web ou le courrier habituel est indisponible. La page de contact donne des numéros de téléphone et des e-mails. La page centre de données décrit le support téléphonique pendant les heures de bureau et le support par ticket/courrier en dehors des heures. Les clients critiques devraient exiger une escalade d'urgence nommée, des contacts authentifiés, une procédure téléphonique hors bande et un moyen d'autoriser la télémanipulation sans compter uniquement sur le portail normal.

Un dossier de preuves raisonnable n'aurait pas à révéler de plans d'étage sensibles. Medyabim pourrait fournir une annexe spécifique au client indiquant quelle installation dessert la charge de travail, quels préfixes et ASN d'origine sont utilisés, quels services DNS et de messagerie sont concernés, quels fournisseurs amont sont actifs, quels composants sont des points de défaillance uniques, et quels services sont en dehors de la Turquie.

Il pourrait fournir un schéma unifilaire expurgé qui sépare les serveurs clients, le pare-feu partagé, le contrôleur de redémarrage, la cible de sauvegarde, le portail de support, le DNS faisant autorité et le site web public. Il pourrait également fournir des dates récentes pour les tests de générateur, la maintenance de l'UPS, la maintenance du refroidissement, les tests de basculement amont, les tests de restauration de sauvegarde et les changements d'origine de route. Ces artefacts répondraient à la question opérationnelle sans exposer les noms de clients ou les configurations de sécurité sensibles.

La même annexe devrait distinguer l'hébergement standard de la colocation et des serveurs dédiés. En hébergement partagé, l'acheteur dépend des choix de plateforme et de la politique de sauvegarde de Medyabim. En hébergement revendeur, les clients en aval peuvent dépendre de Medyabim même lorsqu'ils achètent auprès d'une autre marque. Pour les serveurs dédiés, l'acheteur peut contrôler le système d'exploitation mais pas le baie, le routeur, le chemin d'alimentation ou les pièces de rechange.

En colocation, l'acheteur peut posséder le serveur mais dépendre quand même de Medyabim pour le bâtiment, l'alimentation, l'accès au support et l'extrémité réseau. Ces différences déterminent qui agit en premier pendant une panne.

La note de preuve

Medyabim obtient une note de preuve de réseau public Moyenne, avec une rétrogradation pour les preuves d'installation et de résilience. La couche d'identité est solide pour un petit fournisseur: les enregistrements RIPE RDAP et RIPE organisation lient AS44922 et ORG-MIH2-RIPE à Emre Erim exerçant sous le nom de Medyabim centres de données, et l'adresse de Bursa correspond à la page de contact de Medyabim. La couche de route AS44922 actuelle est également réelle: RIPEstat marque l'AS comme annoncé, liste 37.247.116.0/24 comme actuel, montre une visibilité RIS IPv4 complète à l'instantané vérifié, et valide la route sous RPKI.

La note ne peut pas être Élevée car la preuve opérationnelle s'amincit immédiatement après cela. RIPEstat n'a montré qu'un seul /24 IPv4 actuel, aucune annonce IPv6 actuelle et un seul voisin AS44922 observé. PeeringDB n'a retourné aucun objet réseau pour AS44922. La vue de cohérence de RIPEstat a montré une entrée de route IPv4 et une entrée route6 IPv6 qui n'étaient pas actuelles dans le BGP. La surface DNS propre de Medyabim pointe vers un espace d'adressage actuellement annoncé par d'autres réseaux.

Les pages officielles de Medyabim publient des revendications de service utiles mais ne publient pas les preuves d'alimentation, de refroidissement, de rencontre des transporteurs, de maintenance et de basculement nécessaires pour faire confiance à la capacité de centre de données commercialisée sous contrainte.

La conclusion pratique n'est pas de rejeter Medyabim. Les preuves soutiennent un véritable opérateur d'hébergement et de centre de données basé à Bursa avec des enregistrements RIPE de longue date, une extrémité AS visible, des pages de service officielles et une offre client concrète. La conclusion n'est pas non plus d'accepter les revendications de plus de 500 serveurs et de 50 Gbit/s comme preuve de résilience.

Les clients devraient traiter ces revendications comme des hypothèses à valider par des diagrammes de transporteurs actuels, des preuves d'installation, une cartographie des préfixes, des vérifications RPKI, des tests de restauration et des procédures de support spécifiques au contrat.

L'empreinte publique de Medyabim est la plus forte là où elle nomme l'identité, les services et une route actuelle. Elle est la plus faible là où un client a le plus besoin de preuves pendant une panne: alimentation électrique, refroidissement, diversité de fibre physique, redondance de transporteur active, IPv6 actuel, escalade de support, sauvegardes, sortie et récupération testée. C'est exactement là que la diligence raisonnable devrait se concentrer avant que des charges de travail critiques ne soient placées derrière la marque.