certit-hosting Certit Hosting Handelsbolag vend une capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• Certit Hosting Handelsbolag est lié à AS43021 dans les registres RIPE. Le RDAP de RIPE indique le nom du système autonome commecertit-hosting, et la vue d'ensemble AS de RIPEstat liste le détenteur comme certit-hosting Certit Hosting Handelsbolag.
• Les preuves de routage public actuelles sont faibles. Le statut de routage RIPEstat pour AS43021 a indiqué qu'aucun pair RIS v4 ou v6 ne voyait d'annonces au moment de la requête, et les préfixes annoncés par RIPEstat n'ont retourné aucun préfixe actuel pour AS43021.
• Les ressources réseau historiques comptent mais ne doivent pas être surinterprétées. Les registres RIPE lient 193.200.208.0/24 et 2001:678:cbc::/48 à l'organisation Certit, tandis que l'historique RIPEstat montre que ces ressources ont été vues par le passé et que le statut de routage dernier vu de RIPEstat pointe vers le préfixe IPv6 en avril 2026.
• Le récit de service côté entreprise est divisé.www.certit.seexpose encore des pages Certit Hosting pour l'hébergement cPanel et la messagerie KerioConnect, tandis que le domaine apexcertit.seaffiche du contenu Ayaa IT-konsult pour l'informatique gérée, l'hébergement web, les VPS, la sauvegarde, les services réseau et le support depuis Borlange.
• La question du risque opérationnel n'est pas de savoir si la marque a vendu de l'hébergement par le passé. C'est de savoir si les charges de travail actuelles des clients disposent d'un placement d'installation actif, d'une diversité de transit, d'un matériel de rechange, de tests de restauration, de chemins d'escalade et d'une portabilité des données capables de survivre à une panne de baie, de réseau amont, de support, de facturation ou de migration.
• Le niveau de preuve réseau est Faible. Les registres publics établissent l'identité et le fonctionnement historique, mais la visibilité BGP publique actuelle ne prouve pas une capacité hébergée active.

La facture cloud finit toujours dans une baie

Une facture d'hébergement peut donner à l'infrastructure un aspect ordonné. Elle transforme les serveurs, le stockage, les systèmes d'exploitation, les panneaux de contrôle, les files d'attente de messagerie, les adresses IP, la surveillance, les sauvegardes et le travail de support en un service commercial unique. L'utilisateur se connecte, télécharge des fichiers, crée des boîtes aux lettres, démarre un serveur virtuel ou demande au support de restaurer des données.

En dessous, le service dépend toujours de sites physiques, d'alimentation électrique, de baies, de disques, de ports de routeur, de réseaux amont, d'administration de domaine et de personnes ayant l'autorité d'agir.

C'est la bonne façon de lire Certit Hosting Handelsbolag. Le dossier public est suffisamment réel pour être étudié. Le RDAP de RIPE répertorieAS43021avec le nomcertit-hostinget une entité déclarante pour Certit Hosting Handelsbolag. Lavue d'ensemble ASde RIPEstat donne le détenteur comme certit-hosting Certit Hosting Handelsbolag. Ces enregistrements ancrent l'identité.

Ils ne prouvent pas, à eux seuls, qu'un client d'hébergement web donné se trouve aujourd'hui dans une salle de données suédoise particulière. Ils n'indiquent pas si le service actuel est toujours transporté via AS43021, via l'espace d'adressage d'un fournisseur amont, via une plateforme tierce ou via une pile de services gérés sous la marque Ayaa. Les données de routage publiques nous disent où commencer à poser des questions, pas où s'arrêter.

Cette distinction est centrale car l'empreinte publique actuelle de Certit est mitigée. L'ancien site Certit àwww.certit.seprésente toujours une marque Certit Hosting et renvoie vers des pages d'hébergement, KerioConnect, à propos et contact. Sapage d'hébergementdécrit l'hébergement basé sur cPanel, les comptes de messagerie, les contrôles d'accès, les domaines, la gestion de fichiers, les bases de données MySQL, les utilitaires de journaux et les packages d'hébergement annuels avec des limites de stockage, de transfert et de boîtes aux lettres. Sapage KerioConnectdécrit la messagerie et la collaboration hébergées, y compris le chiffrement SSL, S/MIME, l'anti-spam, l'antivirus et la sauvegarde bi-quotidienne de toutes les données.

En même temps, le domaine apexcertit.seaffiche une page Ayaa IT-konsult. Le contenu Ayaa décrit des services informatiques d'entreprise, Microsoft 365, la sauvegarde, l'hébergement web, les VPS, les services réseau et le support personnel depuis Borlange; le même site Ayaa a des pages dédiées pourl'hébergement web,les VPS,la sauvegarde,le réseau en tant que serviceetles coordonnées. Cela ne prouve pas une transaction d'entreprise, une migration ou une plateforme d'exploitation partagée. Cela montre pourquoi un acheteur ne peut pas considérer le nom sur l'ASN, l'ancien site d'hébergement Certit et le site de service Ayaa comme une preuve ininterrompue de la capacité hébergée actuelle sans un contrat en direct et une carte technique.

Le risque est ordinaire mais important. Un petit fournisseur peut offrir un bon service s'il est honnête sur ses dépendances, maintient une capacité de réserve, teste les restaurations et escalade rapidement. Un grand fournisseur peut décevoir les clients s'il cache des arrangements physiques fragiles derrière un portail bien poli. Certit appartient au premier type de question: les preuves publiques sont suffisamment minces pour qu'un acheteur doive vérifier la machinerie avant de se fier à l'abstraction.

Ce que les pages de l'entreprise disent, et ce qu'elles ne disent pas

L'ancienne page d'hébergement Certit est précise sur les fonctions orientées client. Elle indique que le service d'hébergement utilise cPanel comme panneau de contrôle. Elle décrit la création de comptes de messagerie, le transfert, les répondeurs automatiques et le filtrage; la protection par mot de passe des répertoires, les listes d'accès au niveau IP, SSL/TLS et GnuPG; les sous-domaines, les domaines supplémentaires, les domaines parqués et la gestion DNS; la gestion des fichiers; la création de bases de données MySQL et l'administration avec phpMyAdmin; et la visibilité des journaux avec Webalizer et AWStats.

La même page énumère les tailles de forfaits: petits, moyens et grands plans avec différents niveaux de stockage, de domaines, de boîtes aux lettres, de transfert et de bases de données MySQL.

Ces détails comptent parce qu'ils décrivent la surface de dépendance du client. Un client d'hébergement cPanel ne dépend pas seulement d'un serveur web. Le client dépend du DNS, de la messagerie, du stockage de base de données, de la gestion des certificats TLS, de l'état du compte, de la disponibilité du panneau de contrôle, de la rétention des journaux, de la politique de sauvegarde et de l'accès au support.

Si l'une de ces couches échoue, le client peut percevoir l'échec comme « le site web est hors service » même si la véritable pièce cassée est une file de boîte aux lettres, un disque de base de données, une règle de pare-feu, un compte suspendu ou un chemin de renouvellement de certificat.

La page KerioConnect ajoute une deuxième surface de dépendance: la messagerie hébergée et le travail collaboratif. Elle décrit la messagerie, les contacts, les calendriers, les rappels et le webmail sur tous les appareils, ainsi que le chiffrement, l'anti-spam, l'antivirus et les sauvegardes deux fois par jour. C'est plus sensible que l'hébergement web statique. Une plateforme de messagerie contient la correspondance commerciale, l'état du calendrier, les contacts, les avis juridiques, les chemins de réinitialisation de mot de passe et parfois les files d'attente de support client.

Si elle échoue, le rayon d'impact dépasse largement une page d'accueil.

Les pages Ayaa élargissent l'offre. Lapage d'accueild'Ayaa présente l'informatique gérée, le réseau, Microsoft 365, la sécurité, la sauvegarde, l'IA, le développement de systèmes et l'hébergement web. Lapage d'hébergement webrépète une proposition d'hébergement cPanel et indique que le service comprend une exploitation suédoise, une sauvegarde quotidienne et un support personnel. Lapage VPSdécrit des serveurs virtuels avec une disponibilité de 99,9 %, un pare-feu, des sauvegardes automatiques, une protection DDoS, une surveillance, des options gérées ou auto-gérées, un accès root, un stockage SSD et des ressources dédiées. Lapage de sauvegardeindique qu'Ayaa utilise Acronis Cyber Protect, mentionne la sauvegarde de serveur, d'environnement virtuel, de NAS, de serveur de fichiers et de client, et cadre la récupération en termes de RTO et RPO. Lapage de service réseaudécrit des pare-feux gérés, le WiFi, la surveillance, les mises à jour et un arrangement de service mensuel.

Cette collection est utile, mais elle reste de la copie de produit. Elle ne nomme pas le centre de données. Elle ne publie pas le nombre de baies. Elle n'indique pas si les serveurs détenus par Certit, les baies louées, l'hébergement revendeur, le cloud hyperscale ou un autre fournisseur d'infrastructure suédois héberge chaque produit. Elle ne montre pas de carte de chemins BGP, les contrats amont actuels, la diversité d'interconnexion, les alimentations électriques, l'emplacement des pièces de rechange, la taille du cluster hyperviseur ou les preuves de sauvegarde-restauration.

Un acheteur devrait le traiter comme un menu de services revendiqués, puis demander la preuve opérationnelle derrière le service qu'il a l'intention d'acheter.

Ce n'est pas une critique propre à Certit. La plupart des petits et moyens fournisseurs informatiques ne publient pas de diagrammes d'installation sur un site web public. Le fait est qu'un article d'hébergement ne devrait pas combler ce silence par des suppositions. Si une page dit « sauvegarde quotidienne », la bonne question suivante est la portée de la restauration, la rétention, l'isolation, la cadence des tests et le temps d'exportation.

Si une page dit « disponibilité de 99,9 % », la question suivante est de savoir si cela s'applique au calcul VPS, au panneau de contrôle, au stockage, à l'accessibilité du réseau, à la réponse du support ou à l'ensemble de ces éléments.

AS43021 est un point d'ancrage d'identité utile, pas une preuve de capacité actuelle

AS43021 est l'identifiant réseau qui rend Certit visible dans les bases de données de routage publiques. Le RDAP de RIPE pourAS43021montre un statut actif, le nomcertit-hosting, un enregistrement en 2007 et des données modifiées pour la dernière fois en 2018. Lavue whoisde RIPEstat ajoute des lignes de politique de routage: importations depuis AS13189 et AS8473 acceptant tout, plus importations depuis AS9088, AS15893, AS39708 et AS16117; les exportations annoncent AS43021 à ces ASN. Elle montre également le statut comme assigné et la même référence à l'organisation Certit.

Ces lignes d'importation et d'exportation sont importantes mais datées. Elles indiquent une politique de routage déclarée dans la base de données publique RIPE, pas nécessairement la topologie commerciale ou physique actuelle. Un fournisseur peut laisser une ancienne politique de routage inchangée après avoir changé de fournisseurs amont, cessé l'annonce publique, déplacé les clients vers un autre opérateur ou transféré la livraison sur un réseau fournisseur. C'est pourquoi la politique de routage doit être comparée à la visibilité BGP actuelle.

La vérification de la visibilité actuelle est faible. Lestatut de routagede RIPEstat n'a rapporté aucun pair RIS v4 ni aucun pair RIS v6 voyant AS43021 au moment de la requête, avec zéro préfixe v4 annoncé, zéro /48 v6 annoncé et zéro voisin observé. Lespréfixes annoncésde RIPEstat ont renvoyé une liste de préfixes vide pour la dernière fenêtre de deux semaines. Lesvoisins ASNde RIPEstat n'ont également montré aucun voisin visible dans la dernière vue. Larequête ASNde PeeringDB n'a renvoyé aucune entité réseau pour AS43021.

Cela ne signifie pas qu'il n'y a pas de service. Une entreprise d'hébergement peut servir des clients en utilisant des adresses provenant d'un fournisseur amont, des adresses à l'intérieur du réseau d'un opérateur de centre de données, une plateforme cloud ou une pile gérée détenue par un fournisseur. Le BGP public ne révèle pas toujours la livraison revendeur. Mais cela signifie qu'AS43021 ne devrait pas être cité comme preuve que Certit exploite actuellement une capacité de périphérie Internet orientée client sous son propre ASN visible.

Pour les acheteurs, cela change le test d'approvisionnement. Au lieu de demander « le fournisseur a-t-il un ASN? », demandez « quel ASN transporte ma charge de travail aujourd'hui, quels préfixes seront annoncés, qui les origines, que se passe-t-il si ce chemin amont échoue, et quels contrôles d'origine de route existent? » Si la réponse est « nous n'utilisons pas AS43021 pour ce produit », cela peut être acceptable. Le client a alors besoin des mêmes preuves pour le transporteur et la plateforme réels.

Les ressources IPv4 et IPv6 montrent l'historique et les limites

La ressource IPv4 associée à l'organisation Certit est193.200.208.0/24. Le RDAP de RIPE nomme le réseaugong-networks, le marque comme espace d'adressage assigné indépendant du fournisseur, et inclut Certit Hosting Handelsbolag comme organisation. Lavue whois du préfixede RIPEstat montre le pays SE, la même référence d'organisation, créé en 2007 et modifié pour la dernière fois en 2016. L'aperçu du préfixede RIPEstat, cependant, indique que le préfixe n'est actuellement pas annoncé dans la vue publique vérifiée.

La ressource IPv6 est2001:678:cbc::/48. Le RDAP de RIPE le nommeSE-LIDEN-20200312, le marque comme espace IPv6 assigné indépendant du fournisseur, et inclut Certit Hosting Handelsbolag comme organisation. Lavue whois du préfixe IPv6de RIPEstat montre le pays SE, la référence à l'organisation Certit et une date de création en 2020. L'aperçu du préfixede RIPEstat indique également que le préfixe n'est actuellement pas annoncé dans la vue filtrée, tout en notant qu'une route à faible visibilité a été filtrée. Une vérification publique secondaire surbgp.toolsa également signalé que le préfixe IPv6 n'était pas dans la table de routage globale et a listé AS43021 avec une date de dernière visibilité en avril 2026.

Le RPKI ajoute une autre limite. La validation d'origine de route RIPEstat pour193.200.208.0/24 originaire de AS43021a renvoyé un état inconnu sans ROA de validation. La même chose était vraie pour2001:678:cbc::/48 originaire de AS43021. Inconnu n'est pas la même chose qu'invalide, et une route qui n'est actuellement pas visible ne peut pas être jugée de la même manière qu'une route de production en direct. Néanmoins, si un fournisseur a l'intention d'originer à nouveau ces ressources pour le service client, l'autorisation d'origine de route devrait faire partie des exigences de préparation.

L'historique est donc crédible mais pas suffisant. L'historique de routagede RIPEstat montre une longue visibilité historique pour le /24 IPv4 et une visibilité ultérieure pour le /48 IPv6. Le statut de routage RIPEstat montre une première activité AS43021 vue avec 193.200.208.0/24 en 2007 et un dernier élément vu pour 2001:678:cbc::/48 en avril 2026. C'est la preuve que les ressources numériques de Certit ont existé et ont été observées au fil du temps. Ce n'est pas la preuve que les charges de travail des clients sont actuellement joignables, redondantes ou récupérables via ces ressources.

En termes d'infrastructure, c'est la différence entre l'historique installé et la capacité utilisable. Un /24 dans un registre est un actif utile. Une attribution /48 IPv6 peut prendre en charge une architecture double pile moderne. Mais le client n'en bénéficie que si ces ressources sont actives, surveillées, autorisées, routées sur suffisamment de liaisons amont et connectées aux serveurs qui hébergent la charge de travail. Les ressources dormantes ou à faible visibilité sont une raison de vérification, pas un substitut à celle-ci.

La diversité de transit doit être actuelle, pas héritée

Les lignes de politique de routage RIPE publiques pour AS43021 nomment plusieurs contreparties potentielles. Sur le papier, cela semble plus large qu'un réseau monoconnecté. En pratique, la vue actuelle des voisins RIPEstat ne montre aucun voisin visible. La différence est importante car la politique de routage peut rester dans une base de données après les changements de topologie physique et commerciale.

Il existe quatre types de diversité qu'un client devrait distinguer. La diversité de route signifie que le plan de contrôle BGP a des chemins alternatifs. La diversité d'opérateur signifie que ces chemins sont avec des fournisseurs commerciaux distincts. La diversité physique signifie que les câbles, les interconnexions de salle de rencontre, les entrées de bâtiment, les barrettes d'alimentation et les étagères de routeur ne tombent pas en panne ensemble. La diversité de capacité signifie que le chemin restant peut supporter la charge du client après la défaillance du premier chemin. Un objet AS public prouve rarement les quatre.

Pour Certit, la politique de routage déclarée pourrait raconter une histoire historique sur les anciens fournisseurs amont et pairs. Elle ne prouve pas que les produits d'hébergement actuels de Certit ou d'Ayaa disposent de deux liaisons amont actives, de deux routeurs, de deux installations ou d'une capacité de réserve suffisante pour résister à une panne. L'absence actuelle de voisins publics signifie que la lecture la plus sûre est « non vérifié ».

C'est là que les normes de sécurité du routage fournissent un contexte utile. LaRFC 7454décrit les pratiques opérationnelles pour la sécurité et le filtrage BGP. LaRFC 6811décrit la validation d'origine de route.MANRSencadre la sécurité du routage comme un ensemble d'engagements opérationnels pour les opérateurs de réseau. Ces sources ne certifient pas Certit. Elles expliquent pourquoi un acheteur devrait demander des filtres de préfixes, une validation d'origine de route, une diversité amont, des contacts d'incident et des contrôles de fuite si le fournisseur doit transporter des charges de travail de production.

La diversité de transit a également une composante de support. Si le fournisseur utilise l'espace d'adressage d'un fournisseur amont plutôt que son propre ASN, le client doit savoir qui peut ouvrir un ticket opérateur, qui peut demander un reroutage, qui peut voir la télémétrie de perte de paquets et qui décide si une panne est à l'intérieur du fournisseur, de l'opérateur, du centre de données ou de la propre configuration du client. Un petit fournisseur avec une forte escalade peut surpasser un plus grand fournisseur avec une chaîne confuse. Mais cette force doit être démontrée, pas déduite.

Le test pratique est simple. Demandez les préfixes publics actuels, les ASN d'origine, les fournisseurs amont, les preuves de miroir de routage ou de surveillance de route, l'état RPKI, la politique de fenêtre de changement et le dernier test de basculement réussi. Si le fournisseur ne peut pas partager tous les détails publiquement, il peut toujours les partager sous contrat. S'il ne peut pas les partager du tout, le client devrait dimensionner le service comme une couche de commodité, pas comme une couche de résilience critique.

Les preuves d'installation et d'alimentation sont le centre manquant

La plus grande lacune publique est l'emplacement des installations. Les pages Certit donnent des informations de contact suédoises. L'anciennepage à proposliste Certit Hosting Handelsbolag, une adresse à Borlange et le numéro d'organisation 969730-3809. L'anciennepage de contactliste Certit Hosting, Box 811, 781 28 Borlange et[email protected]. Lapage de contactAyaa liste Vattugatan 3, 784 33 Borlange, un numéro de téléphone et un cadre de support. Ces détails aident à situer l'entreprise en Suède et à Borlange. Ils ne situent pas les serveurs.

Pour l'hébergement web et les VPS, les faits d'installation déterminent l'horloge de réparation. Un disque défaillant n'est pas une abstraction cloud; c'est une pièce qui doit être remplacée ou contournée. Un commutateur de haut de baie défaillant peut déconnecter de nombreux clients à la fois. Une interconnexion défaillante peut rendre un serveur sain injoignable. Un contrôleur de stockage défaillant peut casser à la fois les fichiers web et les bases de données. Une alimentation électrique défaillante peut révéler si la redondance est réelle ou seulement un langage de brochure.

Le matériel public Certit et Ayaa n'indique pas si les charges de travail des clients s'exécutent dans une salle en propriété, une baie louée, une armoire de colocation, une plateforme revendeur, un locataire cloud hyperscale ou un environnement d'hébergement géré par un fournisseur. Chaque arrangement peut être raisonnable. Chacun a un chemin de défaillance différent. Les baies en propriété créent une responsabilité directe pour les pièces de rechange, l'accès et l'alimentation. La colocation louée crée une dépendance envers l'opérateur d'installation et les interventions à distance.

L'hébergement revendeur crée une dépendance envers la plateforme et la relation de compte du fournisseur amont. La livraison cloud crée une dépendance envers le choix de la région, l'accès au plan de contrôle, l'état de facturation et la discipline de configuration.

Le client devrait demander la limite d'installation en langage clair. Où se trouve la charge de travail principale? Où se trouve la sauvegarde? Où se trouve le plan de gestion? Qui possède les serveurs? Qui possède les commutateurs? Qui possède les adresses IP utilisées par mon service? Quelles parties Certit ou Ayaa peuvent-elles réparer directement, et lesquelles nécessitent un ticket fournisseur? Quel est le pire délai crédible entre l'alarme et l'intervention qualifiée sur le composant défaillant?

Cet ensemble de questions n'est pas excessif pour l'hébergement de petites entreprises. Une petite entreprise qui utilise la messagerie hébergée, les bases de données hébergées ou un VPS pour la comptabilité, les réservations, le commerce électronique ou le support client peut être matériellement lésée par une longue panne. Plus l'empreinte publique est petite, plus les preuves privées deviennent importantes.

La capacité installée n'est pas la même que la capacité utilisable

Les anciens forfaits d'hébergement Certit décrivent le stockage, les domaines, les boîtes aux lettres, le transfert de données et le nombre de bases MySQL. Les pages Ayaa décrivent les ressources VPS, le stockage SSD, l'accès root, le pare-feu, la surveillance et la maintenance gérée. Ce sont des unités de service, pas des preuves de capacité. Un client voit les limites du forfait; le fournisseur doit gérer la sursouscription, le stockage sous-jacent, les cibles de sauvegarde, la file d'attente de support et l'inventaire de réparation derrière ces limites.

La capacité installée est ce qui existe dans des conditions normales. La capacité utilisable est ce qui reste après la défaillance d'un composant. La capacité récupérable est ce qui peut être restauré dans les délais du client. Un hôte peut avoir suffisamment de disque pour les opérations normales mais pas assez de matériel de rechange pour évacuer rapidement un nœud défaillant. Il peut avoir des sauvegardes mais pas assez de bande passante de restauration pour récupérer plusieurs clients à la fois. Il peut avoir deux liaisons amont nominales mais pas assez d'engagement sur la seconde pour gérer le trafic de pointe.

Il peut avoir une promesse de support mais une seule personne autorisée à effectuer le changement clé.

Pour Certit, les preuves de réseau public actuelles ne montrent pas de périphérie ASN active, et les preuves du site web ne montrent pas la plateforme d'hébergement derrière les forfaits. Cela signifie que la question de l'installé par rapport à l'utilisable doit être répondue par la documentation opérationnelle actuelle. Un acheteur devrait demander les pools de ressources actuels: le cluster hyperviseur s'il achète des VPS, le pool de stockage s'il achète de l'hébergement web, la topologie de stockage de messagerie s'il achète Kerio ou un autre service de messagerie hébergé, et la cible de sauvegarde s'il achète une sauvegarde gérée.

Il est également important de demander si la capacité est locale, régionale ou externalisée. Un service suédois peut utiliser un support suédois mais un stockage non suédois. Une adresse de contact à Borlange ne signifie pas nécessairement une salle de données à Borlange. Un service cPanel peut être sur un serveur d'hébergement partagé contrôlé par un tiers. Un VPS peut être une machine virtuelle sur la propre plateforme du fournisseur, un nœud loué ou une instance cloud. Le client n'a pas besoin de rejeter l'une de ces options. Il a besoin de savoir laquelle il achète.

La couche du panneau de contrôle mérite une attention particulière. cPanel peut rendre la gestion de compte efficace, mais il peut aussi devenir un point unique de dépendance pour le client. Si cPanel est indisponible, le support peut-il toujours restaurer des fichiers, faire tourner les informations d'identification, exporter des bases de données, changer le DNS ou désactiver une boîte aux lettres compromise? Si le compte est suspendu ou la facturation contestée, le client peut-il toujours récupérer les données? Si le serveur est compromis, les sauvegardes sont-elles suffisamment isolées pour éviter d'être écrasées?

Ces questions transforment la taille du forfait en résilience. Le chiffre de capacité le plus important n'est pas le nombre de boîtes aux lettres sur un forfait. C'est la quantité de capacité propre et testée qui reste disponible lorsque la première partie de la pile est cassée.

Les affirmations de sauvegarde nécessitent des preuves de restauration

La page KerioConnect de Certit indique que les sauvegardes de toutes les données sont effectuées deux fois par jour. La page de sauvegarde Ayaa parle d'Acronis Cyber Protect, de sauvegarde de serveur et d'environnement virtuel, de sauvegarde NAS et de serveur de fichiers, de sauvegarde client, de sauvegarde cloud, de stratégie 3-2-1, de chiffrement, de surveillance centralisée, de RTO, de RPO, d'archivage à long terme et de planification de reprise après sinistre. Ce sont les bons sujets pour un article sur la dépendance à l'hébergement car la sauvegarde est l'endroit où les allégations marketing rencontrent le plan de survie du client.

Mais les sauvegardes ne sont pas de la résilience tant qu'elles n'ont pas été restaurées. Un calendrier de sauvegarde bi-quotidien dit quelque chose sur les points de récupération possibles. Il ne dit pas si la sauvegarde est hors site, immuable, chiffrée, séparée des informations d'identification de production, testée, complète, assez rapide pour être restaurée, ou disponible après la résiliation du contrat. Une description 3-2-1 est saine en principe, mais le client a encore besoin de savoir où se trouve chaque copie et qui peut y accéder.

Le cas de la messagerie est particulièrement important. La récupération de messagerie n'est pas seulement une récupération de fichiers. Une restauration de messagerie peut nécessiter les boîtes aux lettres, l'état des dossiers, les entrées de calendrier, les contacts, les listes de distribution, les enregistrements DNS, les paramètres d'authentification, les règles de filtre anti-spam et la configuration du client. Une restauration partielle peut maintenir le serveur en marche tout en laissant les utilisateurs incapables de travailler.

La promesse de sauvegarde devrait donc être associée à un exercice de restauration qui inclut le travail réel de l'utilisateur.

Le cas des VPS est différent. Une sauvegarde VPS peut restaurer une image entière, des fichiers sélectionnés ou des données d'application. Le client doit savoir si une restauration renvoie la même adresse IP, si des changements DNS sont nécessaires, si les règles de pare-feu et les instantanés sont préservés, si les bases de données sont cohérentes en cas de plantage ou cohérentes au niveau applicatif, et combien de temps il faut pour passer du support de sauvegarde à un service en cours d'exécution. La réponse peut varier selon le forfait.

Le cas de l'hébergement web est encore différent. La sauvegarde cPanel peut être pratique, mais le client doit savoir si elle inclut la messagerie, les bases de données, les fichiers, les fichiers de zone DNS, les certificats SSL, les tâches cron et les paramètres au niveau du compte. Il doit également savoir si la restauration peut être effectuée si l'instance cPanel elle-même est indisponible.

C'est là qu'un petit fournisseur peut montrer du sérieux. Un court rapport de restauration a plus de valeur qu'une grande revendication de disponibilité. Il peut indiquer: ce qui a été restauré, quand, à partir de quelle sauvegarde, par qui, combien de temps cela a pris, ce qui a échoué, ce qui a été exclu et ce que le client a dû faire après la restauration. Sans cette preuve, la sauvegarde reste une affirmation.

La localisation des données n'est pas résolue par le code pays

La région d'attribution est la Suède, et les registres publics soutiennent une identité suédoise. Les anciennes pages Certit listent des informations de contact à Borlange et un numéro d'organisation suédois. Les enregistrements de préfixes RIPE pour 193.200.208.0/24 et 2001:678:cbc::/48 montrent le pays SE et une référence à l'organisation Certit. Les pages d'Ayaa présentent des services informatiques gérés en langue suédoise depuis Borlange.

Pourtant, la localisation des données n'est pas réglée par le code pays dans un registre ou une adresse postale sur un site web. Les données client peuvent être réparties entre les fichiers web, les bases de données, les stockages de messagerie, les sauvegardes, les tickets de support, les journaux, les fournisseurs DNS, les services de surveillance, les plateformes de sécurité et les systèmes de facturation. Certaines peuvent être en Suède, d'autres ailleurs dans l'UE, et d'autres sur des plateformes mondiales.

Une entreprise peut fournir un support suédois tout en utilisant un dépôt de sauvegarde non suédois ou un fournisseur de filtrage de messagerie tiers.

Pour les clients ayant des exigences de souveraineté des données, la matrice d'emplacement devrait être explicite. Où les données de production sont-elles stockées? Où les sauvegardes sont-elles stockées? Où les journaux sont-ils stockés? Où les tickets de support sont-ils stockés? Quels sous-traitants peuvent accéder aux systèmes clients? Quelle entité juridique signe le contrat? Quelle juridiction régit les litiges et l'accès aux données? Que se passe-t-il si le client demande la suppression, l'exportation ou une preuve de destruction?

L'ancien PDF des conditions générales de Certit est lié depuis la page à propos de Certit àAllmanna_villkor.pdf. Son existence publique importe car les conditions de service contiennent souvent la véritable répartition des responsabilités: utilisation acceptable, paiement, suspension, données client, responsabilité, support et résiliation. Un acheteur devrait examiner les conditions actuelles directement avec le fournisseur, car un lien PDF modifié pour la dernière fois en 2009 et un site web mis à jour en 2024 peuvent ne pas refléter l'arrangement opérationnel actuel.

La portabilité des données fait partie de la localisation. Il ne suffit pas de savoir où les données sont stockées lorsque le service est sain. Le client doit savoir comment partir. Peut-il exporter les boîtes aux lettres dans des formats standard? Peut-il exporter les comptes cPanel, les bases de données, les zones DNS, les matériaux SSL et les journaux? Peut-il obtenir une image VPS complète ou seulement des données au niveau fichier? Combien de temps après la résiliation l'accès reste-t-il? Que se passe-t-il si le compte est suspendu pour des raisons de facturation alors que le client a encore besoin de ses données?

La réponse détermine si la capacité hébergée est un service ou un piège. Un fournisseur peut être petit et digne de confiance, mais le client ne devrait pas découvrir son chemin de sortie pendant une panne.

Le travail de support fait partie de l'infrastructure

Les pages publiques d'Ayaa soulignent à plusieurs reprises le service personnel, un contact dédié et un support rapide. La page de contact Ayaa liste les heures en semaine et indique qu'il y a un support 24/7 pour les systèmes critiques. L'ancienne page de contact Certit indique que le moyen le plus rapide de contacter Certit est l'e-mail. Les deux signaux sont pertinents sur le plan opérationnel car le support n'est pas séparé de l'infrastructure. C'est le mécanisme qui transforme la surveillance en réparation.

Le chemin de support devrait être cartographié avant un incident. Qui reçoit l'alarme? Qui peut se connecter? Qui peut appeler l'opérateur du centre de données? Qui peut approuver un changement d'urgence? Qui peut restaurer une sauvegarde? Qui peut communiquer avec les clients si le même service de messagerie est hors service? Qui peut déverrouiller un compte si l'état de facturation bloque l'accès? Si la réponse dépend d'une seule personne, le client doit comprendre la couverture pendant les vacances, les maladies et en dehors des heures ouvrables.

Le support détermine également si le fournisseur peut distinguer les pannes. Une panne de site web peut être un problème DNS, un problème de base de données, un problème TLS, un problème de stockage, un problème de route, un problème de pare-feu, un compte compromis ou une suspension de paiement. Un support rapide n'est pas seulement une réponse rapide; c'est une classification rapide et l'autorité d'agir.

Pour Certit, l'empreinte publique ne publie pas de page de statut, d'historique d'incidents, de matrice d'escalade ou de détails de niveau de service. C'est normal pour de nombreux petits fournisseurs, mais cela augmente l'importance des preuves de support contractuel. Les clients devraient demander les méthodes de contact, les définitions de gravité des incidents, les objectifs de réponse et de restauration, l'escalade en dehors des heures ouvrables, l'escalade fournisseur, la politique d'avis de maintenance et le rapport post-incident.

Ce n'est pas de la bureaucratie pour elle-même. Les services hébergés échouent souvent à la frontière administrative. Un domaine expire, une boîte aux lettres est verrouillée, un litige de facturation suspend un compte, un mot de passe de panneau de contrôle est perdu, un ticket fournisseur est mal acheminé, ou la personne qui connaît l'environnement est indisponible. Ces pannes sont tout aussi réelles que les disques cassés.

Le plus grand avantage d'un petit fournisseur est la connaissance locale. Un consultant dédié qui connaît le client peut résoudre les problèmes plus rapidement qu'une file d'attente anonyme. Le plus grand risque d'un petit fournisseur est la concentration. La même connaissance personnelle peut devenir un point de défaillance unique. Une bonne conception du support conserve le premier avantage sans accepter le second.

Les principaux chemins de défaillance sont ordinaires et testables

Les chemins de défaillance les plus probables pour une capacité hébergée de type Certit ne sont pas exotiques. Le premier est la défaillance de la baie ou de la plateforme: un nœud hôte, une étagère de stockage, un commutateur, une alimentation électrique ou une pile de virtualisation tombe en panne. Le deuxième est la défaillance du réseau amont ou de la route: le trafic ne peut pas atteindre le service parce qu'un opérateur, un préfixe, une session BGP ou un chemin de pare-feu se rompt. Le troisième est la défaillance du stock de matériel: une pièce cassée peut être identifiée mais pas remplacée rapidement.

Le quatrième est la défaillance du support: la bonne personne ou le bon fournisseur ne peut pas être joint à temps. Le cinquième est la défaillance de facturation ou de compte: un service est suspendu, un domaine n'est pas renouvelé ou une relation fournisseur est interrompue. Le sixième est la défaillance de migration: le client essaie de partir ou de déménager en période de stress et découvre que les exportations sont incomplètes, lentes ou indisponibles.

Chaque chemin a un test correspondant. Le risque de baie et de plateforme peut être testé avec des exercices de défaillance de nœud, une marge de capacité et des preuves de pièces de rechange. Le risque de route peut être testé avec la surveillance actuelle des préfixes, le basculement amont et l'état RPKI. Le risque de stock de matériel peut être testé avec l'inventaire des pièces de rechange et les arrangements d'intervention à distance. Le risque de support peut être testé avec des exercices d'escalade et un contact en dehors des heures ouvrables.

Le risque de facturation peut être testé avec des règles de continuité de compte et la clarté du contrat fournisseur. Le risque de migration peut être testé avec des exportations réelles et une restauration dans un environnement séparé.

Les preuves publiques autour d'AS43021 rendent le test de route particulièrement important. Si Certit n'utilise plus AS43021 pour l'hébergement actuel, l'acheteur devrait demander quel réseau transporte le service. S'il utilise AS43021 de manière intermittente ou pour des ressources sélectionnées, l'acheteur devrait demander pourquoi les collecteurs de routes publics actuels ne montrent pas d'annonces stables et comment la joignabilité de la production est surveillée. S'il prévoit de ré-annoncer le /24 IPv4 ou le /48 IPv6, l'acheteur devrait demander des ROA, des filtres, une confirmation amont et un plan de changement.

Les preuves publiques autour des pages de service rendent le test de restauration tout aussi important. cPanel, KerioConnect, VPS et la sauvegarde sont tous des services fortement axés sur la restauration. Un client ne devrait pas accepter « nous avons des sauvegardes » comme réponse finale. Il devrait demander la preuve qu'une boîte aux lettres, un site web, une base de données et un serveur virtuel peuvent être restaurés dans la fenêtre promise.

Les preuves publiques autour de la transition ou de la surface parallèle Ayaa rendent la limite contractuelle importante. Si le client signe avec Ayaa pour un service historiquement associé à Certit, il devrait savoir quelle entité juridique, marque, bureau de support, plateforme et conditions régissent le service. Cette clarté importe lorsque les choses sont saines, et elle devient décisive lorsqu'un fournisseur doit agir sous pression.

Qui est affecté en cas de défaillance

Les parties affectées dépendent du produit. Un petit compte d'hébergement web peut affecter le site web d'une entreprise locale, les soumissions de formulaires, les pages de rendez-vous et la messagerie liée à un domaine. Un compte cPanel avec boîtes aux lettres peut affecter les réinitialisations de mot de passe, les factures, le support client, la livraison de bulletins d'information et les opérations internes. Un compte KerioConnect peut affecter les calendriers, les contacts et la collaboration.

Un VPS peut affecter une application sur mesure, une API, une base de données, un environnement de développement ou un back-end de commerce électronique. Un service de sauvegarde gérée peut affecter la capacité du client à se remettre d'un ransomware ou d'une perte de matériel.

Celles-ci ne sont pas toutes égales. Une panne de site web marketing peut être tolérable pendant des heures. Une panne de messagerie pendant une journée ouvrable peut bloquer les opérations rapidement. Une panne de VPS pour une application métier peut être critique en quelques minutes. Une défaillance de sauvegarde peut ne pas être remarquée avant le jour où elle est nécessaire, ce qui la rend particulièrement dangereuse. Le fournisseur ne devrait pas vendre une seule histoire de résilience générique à tous les clients.

Le client devrait classer les charges de travail par dépendance. Quels services sont orientés vers le public? Lesquels contiennent des données réglementées ou sensibles? Lesquels sont nécessaires pour communiquer pendant une panne? Lesquels ont une solution de contournement manuelle? Lesquels peuvent être reconstruits à partir de code et de configuration, et lesquels contiennent des données générées par l'utilisateur irremplaçables? Quelles exportations ont été testées? Un petit fournisseur peut bien soutenir cette classification s'il connaît l'environnement du client, mais il doit mettre les hypothèses par écrit.

Le fournisseur devrait également indiquer quelles pannes sont hors de son contrôle. Si le client contrôle le DNS, le fournisseur peut ne pas être en mesure de corriger un mauvais changement DNS. Si un centre de données amont contrôle les interventions à distance, le fournisseur peut ne pas être en mesure de raccourcir une réparation physique au-delà de la file d'attente du fournisseur. Si une plateforme cloud tierce héberge le VPS, le fournisseur peut coordonner plutôt que de réparer directement. Des déclarations de limites honnêtes ne sont pas une faiblesse; elles sont la base d'une récupération réaliste.

Pour Certit, les preuves publiques étayent une conclusion prudente. L'identité de l'entreprise et l'historique de service sont visibles. Le signal de routage public actuel est faible. Les pages de service indiquent des offres d'hébergement, de messagerie, de VPS, de sauvegarde et de support, mais pas la preuve sous-jacente de l'installation et du réseau. Les clients affectés par une défaillance devraient donc exiger des preuves de résilience actuelles et spécifiques au produit avant de traiter le service comme une infrastructure critique.

Ce qui améliorerait la confiance

Le niveau de preuve pourrait s'améliorer avec un petit ensemble de preuves publiques ou contractuelles. Premièrement, les preuves de route actuelles: préfixes actifs origines, ASN d'origine, fournisseurs amont, ROA RPKI, filtres de route et surveillance indépendante. Deuxièmement, les preuves d'installation: l'arrangement opérationnel pour l'hébergement et les VPS, si les charges de travail s'exécutent dans des baies en propriété, en colocation, en hébergement revendeur ou sur une plateforme cloud, et où les données primaires et de sauvegarde sont situées.

Troisièmement, les preuves de redondance: conception à deux chemins, tests de basculement, marge de capacité et ce qui reste utilisable après la première panne. Quatrièmement, les preuves de restauration: tests de restauration récents et réussis pour les fichiers web, les bases de données, les boîtes aux lettres et les images VPS. Cinquièmement, les preuves de support: contacts d'escalade, couverture en dehors des heures ouvrables, escalade fournisseur et processus de communication d'incident. Sixièmement, les preuves de portabilité: formats d'exportation de données, délais, coûts et accès après résiliation.

Rien de tout cela ne nécessite de publier des diagrammes sensibles sur l'Internet ouvert. Un fournisseur peut partager des détails précis sous contrat et garder des pages publiques simples. Le point important est que le client obtienne des preuves actuelles, pas un confort hérité d'un enregistrement ASN de 2007 ou d'une page d'hébergement actualisée en 2024.

Le dossier public actuel suggère également des tâches de surveillance. Surveillez l'aperçu et le statut de routage RIPEstat d'AS43021. Surveillez 193.200.208.0/24 et 2001:678:cbc::/48 pour les annonces et l'état RPKI. Surveillez siwww.certit.sereste une surface WordPress Certit Hosting tandis quecertit.sereste une surface Ayaa. Surveillez si les conditions, les pages de contact et les pages de service convergent, redirigent ou changent. Surveillez si PeeringDB gagne un profil ou si les collecteurs de routes publics recommencent à voir des fournisseurs amont stables.

Ces tâches de surveillance ne prouvent pas en elles-mêmes la sécurité du client. Elles aident à détecter quand les preuves changent. Si l'ASN revient à une annonce stable, la question passe de « y a-t-il un routage public actuel? » à « le routage est-il sécurisé et redondant? » Si les pages de service se consolident sous Ayaa, la question passe de « quelle marque est actuelle? » à « quelle plateforme et quelles conditions régissent le client? » Si les pages de sauvegarde et de VPS publient plus de détails, la question passe de « qu'est-ce qui est revendiqué? » à « qu'est-ce qui a été testé? »

Le meilleur résultat pour un petit fournisseur est une modestie transparente. Il n'a pas besoin de prétendre être un cloud hyperscale. Il peut dire exactement ce qu'il exploite, ce qu'il loue, ce qu'il surveille, ce qu'il sauvegarde, ce qu'il peut restaurer et où le client doit encore assumer le risque. C'est une meilleure histoire de résilience que de surévaluer une capacité invisible.

La conclusion: allégations de service utiles, preuves réseau faibles

Certit Hosting Handelsbolag doit être traité comme un véritable sujet suédois d'hébergement et de services informatiques avec un historique de service public, pas comme une coquille vide. Les pages Certit décrivent l'hébergement cPanel, la messagerie et la collaboration hébergées, et les coordonnées. Les pages Ayaa décrivent un portefeuille informatique géré plus large qui inclut l'hébergement web, les VPS, la sauvegarde et les services réseau depuis Borlange. Les registres RIPE lient l'organisation Certit à AS43021 et aux ressources IPv4 et IPv6.

Les mêmes preuves limitent également l'allégation. Les vérifications actuelles de RIPEstat ne montrent pas AS43021 comme activement annoncé. La liste des préfixes annoncés est vide. La vue des voisins est vide. PeeringDB n'a pas d'entité réseau pour l'ASN. Les aperçus de préfixes pour les ressources IPv4 et IPv6 liées ne sont actuellement pas annoncés dans la vue publique filtrée. La validation RPKI pour les deux préfixes historiques est inconnue car aucun ROA de validation n'a été trouvé dans les résultats vérifiés.

Cette combinaison indique un faible niveau de preuve réseau actuel. Cela ne dit pas que les clients sont hors service. Cela dit que les preuves publiques ne prouvent pas une capacité hébergée active et redondante sous le propre ASN visible de Certit. Tout client envisageant le service pour la production devrait demander où la charge de travail s'exécute, quel réseau la transporte, comment elle bascule, où se trouvent les sauvegardes, comment les restaurations sont testées, qui peut intervenir en dehors des heures ouvrables et comment les données peuvent être exportées.

La capacité hébergée reste une capacité physique. Pour Certit Hosting Handelsbolag, l'histoire publique est la plus utile lorsqu'elle est lue de cette façon: une marque d'hébergement, une surface de service informatique suédoise, des ressources numériques historiques, et un besoin actuel de vérification directe des baies, du transit, de l'alimentation, des fenêtres de réparation et des chemins de migration avant que le service ne soit traité comme une infrastructure fiable.