keynet-cloud Swiss IT Security AG vend une capacité hébergée qui dépend toujours des racks, du transit et des fenêtres de réparation

Résumé

• Swiss IT Security AG est une société suisse active et propose actuellement de l'hébergement managé, du cloud privé, de la sauvegarde, de la reprise et de l'hébergement physique. Un compte client de première main décrit un centre de données à Lucerne, un accès MPLS, des lames Cisco UCS et du stockage Pure Storage, ce qui constitue une preuve opérationnelle significative plutôt qu'un simple nom.
• L'identité réseau appeléekeynet-cloud, AS48575, est enregistrée mais actuellement non annoncée. L'historique des routes de RIPE a vu ses derniers préfixes en février 2025. Une identité d'entreprise distincte, AS44911keynet-ag, annonce actuellement un IPv4/24et un IPv6/30via un réseau voisin observé.
• Le registre public n'établit pas si le service cloud privé annoncé occupe un ou plusieurs sites, si le site de Lucerne est possédé ou loué, quelle quantité de calcul et de stockage de rechange est immédiatement utilisable, ou si les systèmes clients ont effectué une restauration mesurée sur un deuxième site.
• Les clients doivent donc évaluer une chaîne de dépendances: entité contractante, domaines de rack et d'alimentation, CKW Fiber Services ou tout autre transporteur, portabilité des adresses, matériel de rechange, couverture de support nominée, isolation de la sauvegarde, priorité de reprise, continuité de facturation et une route testée hors du service.

Une identité cloud a survécu à une fusion d'entreprise, mais pas sa route

Keynet Cloud n'est ni une étiquette inventée ni une entreprise clairement séparable aujourd'hui. Le nom est attaché à AS48575 dans le registre RIPE, dont le champ organisation identifie désormais Swiss IT Security AG. Le même objet de registre conserve les mainteneurs de l'époque Keynet, des contacts à Lucerne et l'adresse d'abus[email protected]. Pourtant,l'aperçu actuel de RIPEstat pour AS48575indique que le numéro n'est pas annoncé. Sonrésultat de statut de routagene montre aucun espace IPv4 ou IPv6 visible, aucun voisin observé et aucune visibilité parmi les collecteurs RIPE RIS interrogés le 12 juillet 2026.

Il s'agit d'un changement significatif, pas une preuve que toute l'entreprise a disparu.L'historique des routes de RIPEstatenregistre un long passé opérationnel et indique que185.156.220.0/23et185.156.222.0/24ont été vus pour la dernière fois en février 2025. Des plages d'adresses plus anciennes étendent l'historique jusqu'en 2009. Le registre soutient donc un réseau qui a autrefois originait un espace pertinent pour les clients puis a retiré ses dernières routes. Il ne révèle pas si les charges de travail ont été retirées, renumérotées, déplacées derrière un autre ASN de l'entreprise, transférées à un fournisseur ou conservées sur une connectivité privée.

L'identité légale est beaucoup moins ambiguë. Leregistre UID officielde la Suisse liste Swiss IT Security AG, UID CHE-114.608.384, comme une société active et un assujetti TVA actif à Etzelmatt 3 à Wettingen. Ce n'était pas l'entité légale originale de Keynet. Des rapports contemporains indiquent que la société lucernoise Keynet AG, fondée en 1996 et déjà partie du groupe plus large,a fusionné dans Swiss IT Security AG en juillet 2021. Les employés et les contacts clients étaient censés continuer, tandis que les activités suisses se dirigeaient vers un seul nom.

Cette histoire crée une erreur d'analyse facile. L'ASN sombre peut être traité comme une preuve que Swiss IT Security AG a cessé ses activités, ce qui est trop large. La société active et les pages de service actuelles peuvent être traitées comme une preuve que chaque ancienne dépendance de Keynet Cloud continue inchangée, ce qui est aussi trop large.

La conclusion défendable se situe entre les deux: l'entreprise opère et commercialise des services d'infrastructure, mais le chemin du réseau Keynet Cloud hérité vers la capacité vendue en 2026 a changé et n'est pas cartographié publiquement de manière assez détaillée pour qu'un acheteur puisse en déduire la résilience.

La continuité d'entreprise est importante parce que la partie contractante, les factures, les obligations de support et la responsabilité relèvent désormais de Swiss IT Security AG. La continuité technique importe séparément car les adresses IP, le DNS, les pare-feu, les réseaux de machines virtuelles et les référentiels de sauvegarde peuvent conserver des noms plus anciens longtemps après une fusion. Un client a besoin des deux récits reconciliés. Un contrat signé par l'entreprise actuelle devrait identifier la plateforme de service actuelle, ne pas se fier à une marque obsolète comme substitut des faits d'installation et de réseau.

La meilleure preuve opérationnelle est une installation cliente à Lucerne

Le compte public le plus fort de ce que Keynet Cloud signifiait en pratique est un cas client Swiss IT Security concernant Woodpecker Holding. Lecompte anglais de l'entrepriseindique que six sites étaient connectés par MPLS à un centre de données Swiss IT Security Cloud à Lucerne. Il décrit des applications métier, Microsoft Active Directory, des services de sécurité, un Exchange hybride, des systèmes de sauvegarde et un environnement de bureau virtuel Citrix. Il nomme également du matériel Cisco UCS blade et un tableau Pure Storage full-flash au cœur de la nouvelle infrastructure.

Ces détails améliorent matériellement le niveau de preuve. Ils localisent au moins une fourniture de service à Lucerne et relient le produit virtuel à des classes identifiables d'équipement physique. Ils montrent que le service était utilisé pour des charges de travail de production sur plusieurs sites clients, pas seulement annoncé comme une offre future. Ils identifient aussi qui souffrirait si la plateforme centrale tombait: 180 utilisateurs de bureau, six sites connectés et les fonctions métier derrière les applications hébergées.

Le cas n'est pas un certificat de capacité actuel. Il ne précise pas quand chaque composant est entré en service, combien de châssis de lames ont été installés, quel modèle Pure Storage a été utilisé, combien d'espace restait, où les sauvegardes étaient conservées, ou si un deuxième site de production pouvait prendre le relais. Il qualifie l'arrangement de centre de données centralisé. La centralisation peut réduire le coût et l'incohérence des équipements sur six sites, mais elle déplace aussi plus de conséquences vers le site central, ses circuits d'accès et son équipe de support.

La même architecture qui simplifie la gestion rend la conception des domaines de défaillance plus importante.

Lapage de services managésactuelle de Swiss IT Security confirme que l'infrastructure reste dans l'offre. Elle fait la promotion de Azure managé et centre de données, sauvegarde et reprise managées, hébergement managé, cloud privé managé et services d'hébergement. La page indique que des environnements dédiés et des services web peuvent fonctionner dans le propre centre de données de l'entreprise; le matériel client peut y être hébergé avec alimentation, refroidissement et sécurité; et les environnements de cloud privé offrent virtualisation, libre-service et gestion du cycle de vie. Elle annonce également une opération et une surveillance 24/7, des niveaux de service définis, une sauvegarde automatisée, une reprise après sinistre et des tests de restauration réguliers.

Ce sont des affirmations actuelles du fournisseur et doivent être lues comme telles. Elles ne nomment pas le bâtiment du centre de données, ne divulguent pas son propriétaire, n'énumèrent pas les alimentations de services publics, n'identifient pas l'endurance du générateur, ne listent pas les entrées de transporteurs, ne déclarent pas la densité de puissance des racks et ne publient pas de mesures de récupération récentes. L'expression singulière « notre centre de données » est particulièrement importante. Elle confirme une limite physique du service, mais elle n'établit pas plusieurs sites indépendants.

Un acheteur ne devrait pas transformer une affirmation large de haute disponibilité en une hypothèse de basculement géographique.

Les preuves publiques soutiennent donc une capacité d'hébergement en direct au niveau de l'entreprise, un site opérationnel documenté historiquement à Lucerne et un catalogue de services qui inclut encore l'infrastructure privée. Elles ne soutiennent pas un inventaire précis de la capacité vendable actuelle. Cette différence est le cœur du problème d'approvisionnement: un fournisseur peut exploiter un centre de données tout en ayant une marge limitée pour l'expansion urgente ou la récupération d'un client.

AS48575 est sombre, tandis qu'AS44911 porte une étroite bordure active

L'image de routage de l'entreprise devient plus informative lorsqu'AS48575 n'est pas vu seul. RIPE enregistre également AS44911 sous le nomkeynet-agpour Swiss IT Security AG.RIPEstat marque actuellement AS44911 comme annoncé. Savue de statut de routagemontre un préfixe IPv4 avec 256 adresses, un préfixe IPv6, une visibilité complète ou presque complète des collecteurs et un voisin observé. Laliste des préfixes annoncésidentifie185.156.223.0/24et2a07:a200::/30.

Cette bordure active est rassurante à un égard. Elle montre que les ressources réseau enregistrées pour la même organisation légale ne sont pas entièrement dormantes. Une adresse dans la plage IPv4 apparaît également dans l'enregistrement SPF pourkeynet.ch, reliant au moins une autorisation de messagerie de domaine public de l'entreprise à l'espace actif. Le domaine hérité lui-même redirige les visiteurs vers le site SITS, cohérent avec l'intégration d'entreprise plutôt que la disparition.

Mais un ASN frère ne peut pas silencieusement remplacer l'ancien.Le résultat actuel de voisin d'AS44911montre seulement AS198433. RIPE identifie ce réseau comme CKW Fiber Services AG. Un collecteur public observe l'adjacence de routage, pas le contrat commercial derrière, et il peut manquer une interconnexion privée. Même avec cette mise en garde, un voisin observé n'est pas une preuve de chemins amont diversifiés. L'entreprise n'a actuellement aucune entrée PeeringDB pour AS48575 ou AS44911, donc il n'y a pas d'inventaire public auto-maintenu d'installations, d'échanges ou de peering pour clarifier l'image.

Le préfixe IPv4 actif a également un historique d'enregistrement révélateur. L'allocation plus large185.156.220.0/22appartient à Swiss IT Security AG. Les trois premières parties/24étaient associées à l'ancien nomkeynet-cloud, tandis que185.156.223.0/24reste globalement visible depuis AS44911. Cela semble cohérent avec une consolidation ou une renumérotation partielle, mais les données de route ne peuvent pas prouver le motif opérationnel. Elles ne peuvent pas non plus établir quels systèmes clients utilisent quelle partie de l'allocation.

Pour un acheteur, les questions pratiques sont directes. Le service acheté utilisera-t-il l'espace IPv4 ou IPv6 du fournisseur, des adresses portables du client, un adressage MPLS privé, ou des adresses appartenant à un transporteur ou un cloud public? Quel ASN originira les routes publiques? Si AS44911 est la bordure, CKW est-elle le seul chemin de transit payant, ou y a-t-il des chemins supplémentaires cachés de l'observation publique? Les circuits de transporteur sont-ils physiquement diversifiés du bâtiment vers des points de présence séparés? Le service peut-il rester joignable lorsque le seul voisin visible retire ses routes?

Les données de route fournissent une rétrogradation utile sans fournir de verdict. Elles disent que l'ancienne bordure publique s'est éteinte après des années d'activité et que la bordure de remplacement visible est petite et apparaît topologiquement concentrée. Elles ne disent pas que les racks sont vides. Une offre crédible devrait expliquer la transition et fournir des diagrammes actuels, des commandes de transporteur, des preuves de politique de route et des résultats de test de basculement sous confidentialité.

Les domaines publics exposent la même transition

Le comportement des domaines renforce la scission entre l'identité maintenue et l'infrastructure de production.keynet.chreste configuré et dirige les utilisateurs web vers le site SITS suisse. Son DNS utilise des serveurs de noms Azure DNS et ses enregistrements de messagerie incluent des points de terminaison de protection Microsoft. Cela est cohérent avec une organisation fusionnée centralisant la communication publique sur de plus grands fournisseurs.

keynet-cloud.chse comporte différemment. Son apex résout vers149.126.4.46, espace d'adresses enregistré chez l'hébergeur suisse Cyon, et la page retournée dit en allemand que le domaine demandé n'est pas configuré sur le serveur. Sa délégation faisant autorité utilise des serveurs de noms Amazon Route 53. Ses enregistrements d'échange de messagerie pointent encore vers des hôtes nommésspamhunter1.keynet-cloud.chetspamhunter2.keynet-cloud.ch, tandis que son enregistrement SPF fait référence à185.156.220.12, dans un espace d'adresses qui n'est actuellement pas visible dans la table de routage globale.

La page non configurée est un signal faible, pas une preuve que les machines virtuelles clients sont indisponibles. Un domaine de service peut devenir un espace réservé après que le marketing s'est déplacé ailleurs, tandis que la production continue sous des noms non liés. Les choix DNS montrent néanmoins que l'ancienne marque publique n'est pas une vitrine ordinaire.

Ils illustrent également comment les dépendances peuvent traverser les frontières organisationnelles: pages publiques chez Cyon, DNS faisant autorité chez Amazon, messagerie d'entreprise chez Microsoft et hébergement de production potentiellement dans une installation de l'entreprise.

Cette diversité peut améliorer la résilience si elle est délibérée. Une page de statut hébergée loin du réseau de production peut rester disponible pendant une panne du centre de données. Un DNS faisant autorité externe peut continuer à répondre si une bordure de fournisseur tombe en panne. Une livraison de messagerie séparée peut préserver la communication en cas d'incident. Pourtant, la diversité des fournisseurs ne crée pas automatiquement un canal d'incident efficace.

L'espace réservé public ne dirige pas les clients vers une page de statut, un numéro d'urgence ou un avis de service, et les anciens hôtes de messagerie semblent dépendre d'un espace d'adresses retiré.

Les clients devraient confirmer les canaux hors bande exacts qu'ils utiliseront. Le portail de support, le site de statut, le téléphone d'urgence et le DNS faisant autorité ne devraient pas tous nécessiter l'environnement de production défaillant. Les coordonnées devraient être testées depuis une connexion externe, et l'autorité d'escalade devrait être suffisamment claire pour qu'un ingénieur de nuit puisse ordonner une intervention à distance ou une escalade de transporteur sans attendre un contact commercial.

Les preuves de domaine plaident également contre le traitement des noms comme des cartes d'infrastructure.keynet-cloud.chest hébergé chez un fournisseur web suisse externe;sits.chest hébergé chez un autre; et la route active de l'entreprise est ailleurs. Aucun n'identifie seul l'emplacement de calcul client. La localité des données doit être établie au niveau de la charge de travail, de la réplique, de la sauvegarde, des journaux et de l'accès de support, pas déduite d'un suffixe.ch.

Un emplacement de centre de données n'est pas la même chose qu'une limite de propriété

Le compte Woodpecker localise un centre de données à Lucerne. La page de service actuelle appelle l'emplacement d'hébergement le propre centre de données de l'entreprise. Aucune déclaration ne règle la chaîne de propriété et d'exploitation. « Propre » peut signifier un bâtiment possédé par le fournisseur, une suite dédiée dans une installation de colocation, des racks loués contrôlés par le fournisseur, ou simplement un environnement géré opérationnellement par le fournisseur. Chaque modèle peut fournir un service solide, mais chacun attribue la responsabilité de maintenance et de défaillance différemment.

Si Swiss IT Security possède l'installation, elle peut contrôler directement l'appareillage, les générateurs, le refroidissement, l'accès physique et l'approvisionnement en transporteurs. Elle supporte également le coût en capital et le risque qu'un site devienne sous-utilisé ou obsolète. Si elle loue une suite, le propriétaire peut contrôler la maintenance des services publics et les équipements majeurs tandis que Swiss IT Security contrôle les racks et les serveurs. Si elle loue des racks, le service dépend plus fortement des règles d'accès, de la densité de puissance et des interventions à distance de l'opérateur de colocation.

Si elle revend de la capacité, l'entreprise peut contrôler le support client et la virtualisation mais pas le matériel ou le bâtiment.

Le registre public n'identifie pas quel arrangement s'applique à l'environnement de Lucerne en 2026. Le siège enregistré à Wettingen et les plusieurs sites de bureau suisses du groupe ne doivent pas être confondus avec des sites de centre de données. Une adresse de bureau prouve où une organisation peut être contactée; elle ne prouve pas que les systèmes de production y sont installés. Inversement, une référence de centre de données à Lucerne ne prouve pas que l'ancien bureau Keynet à Staldenhof 18 contient la salle des serveurs.

L'acheteur devrait demander le nom légal de l'opérateur de l'installation, la municipalité, l'identifiant du site et la division des responsabilités. Les preuves peuvent inclure un résumé de contrat de colocation, un schéma unifilaire d'alimentation, une matrice de maintenance, des conditions d'accès physique et un périmètre de certification actuel. La réponse n'a pas besoin d'exposer des plans d'étage sensibles publiquement. Elle doit montrer qui peut rétablir l'alimentation, approuver l'accès, remplacer une unité de refroidissement défaillante et contacter chaque transporteur.

Cette limite importe surtout pendant la maintenance. Un opérateur d'installation peut annoncer une fenêtre de maintenance pour l'appareillage. Swiss IT Security doit alors évaluer quels chemins d'alimentation sont affectés, si les équipements en rack ont des alimentations doubles connectées à des unités de distribution séparées, si les générateurs et les systèmes sans interruption restent disponibles, et si le risque client nécessite une migration. Si un sous-traitant contrôle la fenêtre, le vendeur de cloud ne peut pas éliminer cette dépendance par une clause de niveau de service.

Il peut seulement concevoir autour, la communiquer et prouver que la conception fonctionne.

Le matériel installé n'est pas la même chose qu'une capacité prête pour un client

Les lames Cisco UCS et un array Pure Storage sont des actifs concrets, mais une liste de matériel ne révèle pas la capacité qui peut être vendue en toute sécurité. Le calcul installé comprend des processeurs et de la mémoire déjà engagés pour les clients, réservés pour le basculement, maintenus pour la maintenance, consommés par la couche de virtualisation ou indisponibles en raison d'un défaut. Le stockage installé comprend des répliques, des instantanés, de la parité, des métadonnées, de l'espace libre et de la marge de performance. Un téraoctet nominal n'est pas nécessairement un téraoctet disponible pour une nouvelle charge de travail.

L'offre actuelle de cloud privé du fournisseur ajoute une autre couche. Le libre-service et la virtualisation peuvent rendre l'allocation rapide, mais ils ne peuvent pas créer de mémoire physique, d'endurance flash, de ports réseau ou de logiciels sous licence. L'élasticité à l'intérieur d'un petit cloud privé dépend d'hôtes de rechange et de stockage partagé. Lorsque ces réserves s'épuisent, le fournisseur doit installer du matériel, déplacer des charges de travail ou demander aux clients d'attendre.

C'est là que l'économie de l'hébergement rencontre la fiabilité. La capacité inutilisée protège la récupération mais génère peu de revenus directs. Une utilisation élevée améliore le rendement des actifs mais laisse moins de marge lorsqu'un hôte tombe en panne. Un équipement de rechange réduit le temps de réparation mais immobilise du capital et vieillit sur l'étagère. Plusieurs sites répartissent les risques mais dupliquent les coûts de réseau, de sécurité et d'exploitation. Un petit fournisseur peut faire des choix sensés, mais les clients ne peuvent pas déduire ces choix de l'expression « infrastructure évolutive ».

Une divulgation utile de capacité sépare l'allocation normale, la réserve de défaillance et la marge commercialisable. Pour le calcul, elle devrait montrer combien de pannes d'hôte le cluster peut absorber tout en préservant les réservations clients. Pour le stockage, elle devrait montrer l'espace utilisable après les frais généraux de protection et l'effet sur les performances d'une panne de contrôleur ou de baie. Pour le réseau, elle devrait identifier la sursouscription et le goulot d'étranglement partagé le plus petit.

Pour la sauvegarde, elle devrait déclarer la consommation du référentiel, la rétention, les limites d'ingestion et la bande passante de restauration.

La capacité a aussi une dimension temporelle. Un fournisseur peut être capable de se procurer une autre lame en six semaines mais incapable de satisfaire une demande de récupération ce soir. « Disponible » devrait donc signifier installé, sous tension, sous licence, connecté et assignable dans l'objectif de récupération du service. Du matériel en commande, un rack vide ou des emplacements de châssis théoriques sont des options futures, pas une capacité de récupération présente.

Les preuves publiques ne contiennent aucun chiffre à ce niveau. Cette absence ne doit pas être convertie en affirmation que l'entreprise manque de marge. Cela signifie que l'acheteur doit obtenir une déclaration de capacité datée et comprendre sa mesure. Pour les systèmes critiques, le contrat devrait protéger la capacité de récupération réservée contre une double vente à plusieurs clients susceptibles d'en avoir besoin lors du même incident régional.

L'électricité est la première dépendance physique partagée

Les machines virtuelles disparaissent lorsque leurs hôtes perdent l'alimentation. La chaîne commence en dehors du rack: connexion au réseau électrique, transformateurs, appareillage, onduleurs, batteries, commutateurs de transfert, générateurs, approvisionnement en carburant, panneaux de distribution et unités d'alimentation de rack. Un centre de données nominalement redondant peut encore contenir un composant partagé ou un état de maintenance qui met les deux chemins en risque.

L'analyse annuelle des pannes 2026 d'Uptime Intelligence indique que l'électricité reste la première cause de pannes impactantes. Elle met en évidence les onduleurs, les commutateurs de transfert et les générateurs, tout en pointant les contraintes du réseau et la pression des charges de travail plus denses. La conclusion est à l'échelle de l'industrie et ne dit rien sur un incident chez Swiss IT Security. Elle établit pourquoi un examen d'approvisionnement devrait aller au-delà d'un pourcentage de disponibilité générique.

Pour le service de Lucerne, les faits publics manquants incluent le nombre d'alimentations électriques, si elles sont vraiment indépendantes, la topologie du générateur, l'autonomie en carburant, la priorité de ravitaillement, la technologie des batteries, la conception de dérivation de maintenance et la distribution A/B au niveau du rack. Le cas Woodpecker identifie une plateforme de lames et un array full-flash, qui peuvent tous deux avoir des alimentations redondantes internes, mais des alimentations redondantes n'aident que si leurs cordons atteignent des chemins actifs séparés.

Un serveur à double cordon connecté deux fois à une seule unité de distribution a toujours un seul domaine d'alimentation.

Le refroidissement appartient à la même analyse. Une installation peut conserver l'alimentation électrique et encore arrêter l'équipement si l'eau glacée, la détente directe, les pompes ou les contrôles tombent en panne. Les systèmes denses de lames et flash concentrent la chaleur. Le fournisseur devrait déclarer la charge de conception, la charge actuelle, la redondance de refroidissement et les conditions dans lesquelles les systèmes sont limités ou arrêtés. Un rack vide déclaré n'est pas une marge utile si la salle manque de refroidissement ou d'alimentation pour sa pleine charge.

Les fenêtres de réparation exposent la conception opérationnelle. Le client devrait voir les avis de maintenance suffisamment tôt pour évaluer le risque, comprendre si la redondance est réduite pendant les travaux et savoir ce qui se passe si le composant restant tombe en panne. Le fournisseur devrait identifier les périodes de blocage où les modifications client sont restreintes et expliquer si la migration en direct est disponible. Si un site entier doit être mis en risque, les charges de travail critiques ont besoin d'un emplacement alternatif ou d'une décision commerciale acceptée.

Les preuves qui amélioreraient la confiance sont opérationnelles: tests intégrés récents des systèmes, démarrages de générateurs sous charge, maintenance de batteries, événements de basculement et rapports post-maintenance. Les certifications peuvent aider à établir la discipline de contrôle, mais elles ne remplacent pas le chemin d'alimentation exact utilisé par le rack d'un client.

La concentration du transit peut isoler des machines saines

Le serveur physique peut être sain tandis que le service est injoignable. Les coupures de fibre, les pannes de routeur, les défaillances optiques, les fuites de routes, les attaques par déni de service, la maintenance des transporteurs et les litiges contractuels interrompent tous la couche réseau. La topologie visible d'AS44911 soulève ce problème car RIPE RIS observe un seul réseau adjacent, CKW Fiber Services.

CKW est un transporteur régional plausible pour une opération lucernoise.RIPEstat identifie AS198433comme CKW Fiber Services AG, et le registre lui donne une adresse à Lucerne. Cette cohérence géographique renforce l'interprétation qu'AS44911 a un chemin d'accès régional réel. Elle n'établit pas un deuxième chemin indépendant. Un deuxième circuit acheté auprès du même fournisseur peut partager des conduits, des équipements optiques ou une route amont.

La véritable diversité nécessite des preuves à plusieurs niveaux. La fibre devrait entrer par des chemins de construction séparés. Les circuits d'accès devraient se terminer sur des équipements fournisseur séparés. Les routeurs de bordure ne devraient pas partager une seule unité d'alimentation ou un seul défaut logiciel. Les chemins amont devraient éviter un point d'étranglement régional commun dans la mesure du possible. Le DNS et l'accès à distance devraient rester disponibles pendant un retrait de route.

Le client devrait aussi savoir si les adresses publiques sont originaires directement par Swiss IT Security ou transportées à l'intérieur d'un réseau de fournisseur.

Le retrait d'AS48575 ajoute un risque de migration. Si les clients utilisaient autrefois des adresses de185.156.220.0/23ou185.156.222.0/24, ils peuvent avoir eu besoin d'une renumérotation lorsque ces routes ont cessé. La renumérotation affecte les listes d'autorisation de pare-feu, le DNS, les certificats, les intégrations partenaires, la réputation de messagerie et les journaux. Un changement bien géré peut être sans incident, mais il devrait laisser un historique de communication client et de restauration. Les clients potentiels devraient demander si des adresses Keynet Cloud héritées restent dans des configurations privées ou de la documentation.

La sécurité des routes mérite également l'attention. Le point de terminaison de validation RPKI de RIPEstat ne signale aucune autorisation d'origine de route valide pour les deux préfixes actuellement annoncés d'AS44911, laissant leur statut « inconnu » plutôt que valide. Cela ne rend pas les routes illégitimes; de nombreuses routes légitimes n'ont toujours pas d'autorisation publiée. Cela signifie qu'un contrôle utile contre les changements d'origine accidentels ou malveillants n'est pas publiquement démontré pour ces préfixes.

Un test de défaillance de transit devrait donc être concret. Retirez ou désactivez un chemin de bordure dans des conditions contrôlées, mesurez la convergence, confirmez le trafic de retour, testez IPv4 et IPv6, et observez les applications client depuis l'extérieur du réseau du fournisseur. S'il n'existe qu'un seul amont, la description du service devrait le dire et la conception de récupération devrait en tenir compte plutôt que d'impliquer une diversité de transporteurs.

Le stock de matériel et la main-d'œuvre de réparation déterminent le véritable temps de récupération

Lorsqu'une lame, un contrôleur de stockage, un commutateur ou un pare-feu tombe en panne, la récupération dépend de plus qu'une garantie du fabricant. Quelqu'un doit détecter le défaut, diagnostiquer le composant, obtenir un accès physique, trouver une pièce de rechange compatible, la remplacer, restaurer la configuration et vérifier le service client. Chaque transfert ajoute du temps. De nuit ou lors d'une perturbation régionale, le personnel et les pièces deviennent plus rares.

La page actuelle de services managés du fournisseur annonce une surveillance continue, des alertes automatiques et une gestion des incidents. Ce sont des engagements utiles, mais la page publique ne spécifie pas quels niveaux de service incluent une réponse en personnel 24 heures sur 24, quelles gravités déclenchent une présence physique, ou où les pièces de rechange sont conservées. « Surveillance 24/7 » peut signifier qu'une alarme est générée à toute heure; cela ne signifie pas nécessairement qu'un technicien qualifié et un contrôleur de remplacement sont sur site.

L'installation Woodpecker montre également une concentration de fournisseurs au sein de la plateforme. Cisco UCS et Pure Storage sont des produits d'entreprise matures, mais chacun nécessite un firmware compatible, un droit de support et des composants de remplacement. Un serveur générique de rechange ne peut pas toujours remplacer une lame défaillante sans reconfiguration. Un array de stockage peut rester en ligne après une panne de composant, mais fonctionner avec une protection réduite jusqu'au remplacement de la pièce.

L'objectif de réparation devrait mesurer le temps jusqu'à la restauration de la redondance, pas seulement le temps jusqu'à ce que l'application réponde à nouveau.

La concentration de la main-d'œuvre est un risque égal. Keynet a apporté environ 30 employés dans Swiss IT Security en 2021, selon les rapports de fusion. L'entreprise plus large présente désormais une base de spécialistes beaucoup plus large, ce qui peut améliorer l'escalade et la profondeur du personnel. Cela ne prouve pas que de nombreuses personnes détiennent des droits d'accès et une expertise actuelle pour la plateforme de Lucerne. Un service critique peut encore dépendre de deux ingénieurs qui connaissent une ancienne conception réseau.

Les clients devraient demander une couverture par rôle plutôt que des totaux d'employés: réseau, virtualisation, stockage, sauvegarde, sécurité, accès à l'installation et commandement des incidents. Chaque rôle critique a besoin d'une couverture primaire et suppléante. Les identifiants d'accès devraient être récupérables sans une seule personne. Les contacts de support fabricant et les droits de série devraient être à jour. Un départ ou une maladie ne devrait pas suspendre le seul chemin vers une console.

La question du stock de pièces de rechange devrait distinguer les pièces chaudes, les pièces froides sur site, le stock régional du fabricant et l'approvisionnement au mieux. Elle devrait identifier les composants avec de longs délais et l'âge du matériel supporté. Pour une réserve de récupération client, le fournisseur devrait dire si un hôte inutilisé est réellement compatible et sous licence. Une fenêtre de réparation étayée par ces faits est beaucoup plus crédible qu'une promesse générale de réponse rapide.

La sauvegarde n'a d'importance que si elle peut être restaurée en dehors de la panne

Swiss IT Security annonce la sauvegarde automatisée, la reprise après sinistre et des tests de restauration réguliers. Un compte séparé de première main d'une réponse à un rançongiciel en 2022 décrit la reconstruction d'un environnement propre, la récupération de machines virtuelles et de stockage avec Veeam et Commvault, la reconstruction des services d'identité et le durcissement de l'environnement restauré. Lecompte de récupération publiémontre une expérience pratique des incidents, bien qu'il n'identifie pas Keynet Cloud comme la plateforme affectée ni ne publie des temps de récupération mesurés.

Le Centre national suisse pour la cybersécurité avertit queles services cloud offrent une protection limitée contre les rançongicielslorsque les données sont stockées uniquement dans le cloud. La protection dépend de la récupération de versions et de contrôles plus stricts autour de l'accès à ces versions. Le même principe s'applique à une défaillance du fournisseur. Une sauvegarde dans le même compte administratif, le même array de stockage, le même bâtiment ou le même domaine de support peut être perdue ou verrouillée avec la production.

L'acheteur a besoin d'une carte de chaque copie. Cela inclut les données de production, les instantanés locaux, les référentiels de sauvegarde, les copies hors site, les sauvegardes de configuration, les clés de chiffrement, les services d'identité et les journaux. Pour chaque copie, la carte devrait identifier la municipalité ou la région, l'opérateur de l'installation, le chemin réseau, l'administrateur, la rétention, l'immuabilité et l'autorité de suppression. « Géoredondant » ne suffit pas à moins que la deuxième géographie et les dépendances partagées ne soient connues.

Les tests de récupération doivent également correspondre à l'unité de récupération promise. Restaurer un fichier ne prouve pas qu'une application d'entreprise, un annuaire, une politique de pare-feu et une base de données dépendante peuvent être restaurés ensemble. Démarrer une machine virtuelle ne prouve pas que les utilisateurs peuvent s'authentifier ou que les partenaires externes peuvent se connecter. Un test significatif enregistre la perte du point de récupération, le temps de récupération écoulé, les vérifications d'intégrité des données, la validation de l'application et la capacité consommée sur le site alternatif.

Le guide de planification de contingence du NIST recommande un stockage alternatif, un traitement alternatif, une résilience des télécommunications, des sauvegardes et des exercices alignés sur l'impact commercial. Il s'agit de directives fédérales américaines, pas d'une exigence légale suisse, mais les questions d'ingénierie sont universelles. Le site alternatif devrait être suffisamment éloigné pour éviter la même perturbation et équipé pour respecter le temps de restauration requis.

La priorité lors d'un sinistre partagé est particulièrement importante. Un fournisseur peut tester la récupération d'un client avec succès lorsque la plateforme est calme, puis découvrir que de nombreux clients ne peuvent pas tous basculer en même temps. Les contrats devraient préciser si la capacité est dédiée ou mutualisée et comment l'ordre de restauration est décidé. Un client avec un objectif strict a besoin de calcul, de stockage et de bande passante réservés, pas seulement d'une place dans une file d'attente.

La souveraineté des données nécessite une carte, pas une étiquette suisse

Une société suisse, un domaine.chet une référence de centre de données à Lucerne soutiennent tous un récit de service suisse. Rien ne prouve que chaque activité de traitement reste en Suisse. Le DNS public utilise l'infrastructure Amazon et Microsoft; les sites web publics utilisent des hébergeurs suisses externes; les produits de support et de sécurité peuvent impliquer d'autres fournisseurs. Les sauvegardes, la télémétrie, la gestion des tickets et l'administration à distance peuvent traverser les frontières même lorsque la machine virtuelle principale ne le fait pas.

Le Préposé fédéral à la protection des données et à la transparence décrit l'utilisation du cloud comme un traitement sous-traité. Ses orientations sur le cloud indiquent que le client reste responsable du traitement licite et doit prêter une attention particulière aux sous-traitants, à la sécurité et aux transferts vers des pays tiers. Ses orientations sur l'externalisation disent que les responsables du traitement doivent sélectionner soigneusement les sous-traitants, leur donner des instructions et les surveiller si nécessaire.

Pour Swiss IT Security, cela signifie qu'un client devrait obtenir une liste actuelle des sous-traitants et un calendrier des lieux. Le calendrier devrait séparer le calcul primaire, les répliques, les sauvegardes, les journaux de sécurité, les tickets de support, les données de surveillance et l'accès administratif. Il devrait nommer les composants cloud publics plutôt que de laisser la large expression « cloud hybride » les cacher. Il devrait également définir comment les changements sont annoncés et si le client peut s'y opposer ou se retirer.

Le chiffrement change l'exposition mais pas l'emplacement. Les clés détenues par le client peuvent réduire l'accès du fournisseur aux données stockées. Elles ne suppriment pas les métadonnées, ne garantissent pas la disponibilité et ne résolvent pas la récupération si les clés sont perdues. Un service de gestion de clés dans le même domaine administratif peut tomber en panne avec la charge de travail. Les clients sensibles devraient identifier qui peut déchiffrer, où les sauvegardes de clés résident et comment les clés sont transférées lors de la sortie.

La page de confidentialité actuelle de SITS identifie Swiss IT Security AG comme l'entreprise responsable de ses sites web suisses et fournit un contact de protection des données. C'est utile pour le traitement des sites publics mais ne remplace pas un accord de traitement spécifique au service. Les rôles, finalités, rétentions et sous-traitants d'un client hébergé diffèrent de ceux d'un visiteur de site web.

Les clients réglementés ont également besoin d'une communication d'incident suffisamment rapide pour répondre à leurs obligations. Depuis avril 2025, les opérateurs d'infrastructures critiques suisses couverts doivent signaler les cyberattaques qualifiantes au NCSC dans les 24 heures suivant la découverte. L'avis de mise en œuvre du NCSC rend le chemin d'information client-fournisseur conséquent. Un contrat d'hébergement devrait exiger des faits en temps utile, la préservation des preuves et un interlocuteur d'incident nommé, sans supposer que chaque client hébergé est lui-même couvert.

La souveraineté des données est donc une propriété opérationnelle: l'emplacement, l'accès, le droit, la sous-traitance et la sortie doivent tous s'aligner. L'expression « propre centre de données » ne répond qu'à une partie de ce test.

Les défaillances de facturation et de contrat de fournisseur peuvent être aussi perturbatrices qu'un matériel cassé

L'infrastructure peut rester techniquement saine tandis que l'accès échoue pour des raisons commerciales. Un litige de facture, un droit de support expiré, un désaccord avec le propriétaire, une facture de transporteur impayée ou une suspension de compte erronée peuvent interrompre le service. Les fusions d'entreprises ajoutent un autre risque: les anciens bons de commande, les noms de marque et les contacts techniques peuvent ne pas correspondre à l'entité légale qui émet désormais les factures et contrôle les actifs.

La fusion Keynet de 2021 semble ordonnée dans les rapports publics. Les contacts clients et les emplacements devaient rester, et Swiss IT Security AG est démontrablement active aujourd'hui. Le problème n'est pas une preuve de litige actuel. Il s'agit de savoir si le contrat de chaque client a rattrapé le modèle d'exploitation modifié. Un document nommant encore Keynet AG ou se fiant à AS48575 peut décrire des obligations qui ne correspondent plus à la prestation de service.

Les clients devraient vérifier l'entité contractante, le numéro de TVA, le bénéficiaire bancaire, le calendrier de service et la limite des actifs. L'accord devrait identifier les sous-traitants dont la défaillance peut suspendre le service et expliquer si Swiss IT Security peut continuer à fonctionner si un contrat de propriétaire ou de transporteur prend fin. Il devrait également distinguer une identité marketing de groupe de la société d'exploitation suisse.

Le pied de page du site SITS nomme Swiss IT Security Group AG, tandis que les pages de service et de confidentialité suisses identifient Swiss IT Security AG dans des contextes pertinents; les acheteurs devraient s'assurer que l'entité correcte signe l'engagement de service.

Les droits de suspension nécessitent des contrôles proportionnés. Un fournisseur a besoin de protection contre les impayés persistants et les abus, mais un arrêt immédiat des systèmes critiques peut causer des dommages bien au-delà de la facture contestée. Le contrat devrait inclure un préavis, une escalade, une période de remède lorsque légal, la préservation des données et une exportation contrôlée. Les incidents de sécurité peuvent nécessiter une action plus rapide, mais le fournisseur devrait définir qui peut ordonner l'isolement et comment les données non affectées restent récupérables.

Les contrats de support fabricant forment une autre couche commerciale cachée. Cisco, Pure Storage, la virtualisation et les produits de sauvegarde peuvent dépendre d'abonnements ou de support actifs. Si un droit expire, les pièces de rechange, les mises à jour ou l'assistance à la récupération peuvent être retardés. Les acheteurs n'ont pas besoin de chaque facture, mais ils ont besoin de l'assurance que les droits critiques sont à jour et inclus dans le prix.

La résilience financière est difficile à déduire des pages de service. Le registre officiel prouve le statut actif, pas les réserves de trésorerie ou l'économie du centre de données. Les clients critiques devraient utiliser une diligence financière proportionnée et éviter de payer d'avance plus d'exposition que nécessaire. Ils devraient également conserver leurs propres copies à jour des configurations, licences, données et documentation afin qu'un choc commercial ne devienne pas un verrou technique irréversible.

La migration est la voie de récupération pour les pannes que le fournisseur ne peut pas réparer

Chaque service hébergé a besoin d'une sortie qui fonctionne avant que le client ne veuille partir. La migration peut être planifiée en raison du prix ou de la stratégie, ou urgente en raison d'une panne prolongée du fournisseur, d'un litige contractuel ou d'un manque de capacité. Le cas urgent est le plus exigeant: le portail de gestion peut être indisponible, le personnel de support peut être surchargé et le transfert réseau peut être contraint.

Le synopsis et les recommandations du cloud du NIST traitent la portabilité et l'interopérabilité comme des préoccupations matérielles du cloud. Les interfaces standard et les formats de données aident, mais les environnements de cloud privé contiennent souvent des formats de machines virtuelles, des politiques réseau, des instantanés et des services managés qui ne sont pas directement portables. Un client doit savoir ce que le fournisseur peut exporter et ce qui doit être reconstruit.

Le package de sortie devrait inclure les données dans un format documenté, les images de machines virtuelles lorsque contractuellement permis, les configurations de pare-feu et de répartiteur de charge, les enregistrements DNS, les dépendances d'identité, les certificats, les journaux et les catalogues de sauvegarde. Il devrait inclure des sommes de contrôle et suffisamment de métadonnées pour vérifier l'exhaustivité. Les clés de chiffrement doivent être incluses ou transférées selon une méthode séparément testée. Le package ne devrait pas dépendre de la disponibilité continue du portail du fournisseur.

La bande passante rend la portabilité physique. Exporter des dizaines de téraoctets sur un circuit encombré peut prendre des jours. Un acheteur devrait mesurer la vitesse de sortie réaliste et décider si un transport de supports cryptés est disponible. Si le support physique est une option, le contrat devrait spécifier les dispositifs compatibles, la garde, l'expédition, le retour et l'effacement sécurisé. Si seule l'exportation réseau est autorisée, la bande passante devrait être réservée pendant un incident.

L'adressage est une autre barrière. Les clients utilisant des adresses du fournisseur peuvent devoir mettre à jour le DNS, les listes d'autorisation, les pairs VPN et les partenaires. Ceux qui utilisent leurs propres adresses portables ont besoin de confirmation que le routage peut se déplacer proprement. Le retrait d'AS48575 rappelle que les identités réseau changent même lorsqu'une entreprise continue. Un exercice de migration devrait inclure la transition d'adresses et la validation de certificats, pas seulement la copie de disques.

L'assistance à la sortie doit survivre à la résiliation. Le calendrier de service devrait fixer une période de récupération, les tarifs de support, le calendrier de suppression et l'ordre dans lequel les copies sont effacées. Le client ne devrait recevoir une preuve de suppression qu'après avoir confirmé que l'exportation est utilisable. Si le fournisseur fait faillite, la clause de résiliation ordinaire peut être insuffisante; une documentation sous séquestre, des sauvegardes détenues par le client et un contrat de service alternatif peuvent réduire la dépendance.

La preuve la plus solide est une migration partielle effectuée en temps normal. Restaurez une application représentative chez un autre fournisseur ou sur du matériel contrôlé par le client, reconnectez les dépendances d'identité et de réseau, et mesurez le résultat. Cet exercice transforme la portabilité d'une clause en une capacité de récupération.

Qui est affecté lorsqu'un domaine de service tombe en panne

Le cas Woodpecker rend la population affectée tangible. Une plateforme centrale supportait des utilisateurs sur six sites et hébergeait des applications métier, l'identité, la sauvegarde, la sécurité et des bureaux virtuels. Si cette plateforme devenait indisponible, le préjudice ne s'arrêterait pas à une équipe informatique. Les employés pourraient perdre ensemble l'accès au bureau, les applications métier et l'authentification. Les clients et les fournisseurs pourraient rencontrer des commandes, des communications ou des exécutions retardées.

La même concentration peut se produire pour tout client d'hébergement managé. Un fournisseur peut exploiter le calcul, le stockage, la sécurité réseau, la sauvegarde et le support comme un seul package pratique. Opérationnellement, cela réduit le nombre de fournisseurs que le client coordonne. Structurellement, cela peut placer plusieurs contrôles de récupération au sein d'une seule entreprise et d'une seule installation. Le client devrait identifier quels contrôles restent indépendants.

Le personnel du fournisseur est également affecté. Lors d'un incident large, ils doivent diagnostiquer l'infrastructure, communiquer avec les clients, coordonner les fournisseurs d'installations et de transporteurs, préserver les preuves de sécurité et gérer la priorité de restauration. Si les outils de support dépendent du service défaillant, leur tâche devient plus difficile. La communication hors bande et la documentation opérationnelle stockée en externe protègent le fournisseur ainsi que les clients.

Les personnes concernées par les données font face à une conséquence différente. L'indisponibilité peut retarder les services; la corruption peut produire des décisions erronées; l'accès non autorisé peut créer un préjudice à la vie privée. La récupération doit préserver l'intégrité, pas simplement redémarrer les machines. Les clients devraient valider la cohérence des transactions et reconcilier les données après la restauration.

La concentration régionale peut affecter plusieurs clients simultanément. Un incident d'alimentation ou de fibre à Lucerne peut créer de nombreux cas urgents. La capacité de rechange mutualisée et le personnel de support font alors face à une demande corrélée. Les niveaux de service rédigés comme si chaque client tombait en panne seul peuvent ne pas décrire cette condition. Le fournisseur devrait expliquer la priorité de sinistre régional et la quantité de capacité réservée pour la récupération simultanée.

Le coût peut dépasser la facture d'hébergement. L'analyse 2026 d'Uptime indique que 57 % des répondants ont déclaré que leur dernière panne majeure a coûté plus de 100 000 dollars, tandis qu'un sur cinq a estimé une panne impactante au-dessus d'un million de dollars. Ces chiffres d'enquête ne sont pas une prévision pour Swiss IT Security ou un client particulier. Ils expliquent pourquoi les acheteurs devraient dimensionner les dépenses de résilience par rapport à l'exposition commerciale plutôt qu'aux frais de service mensuels.

La cartographie des dépendances transforme cela en une décision actionnable. Pour chaque service critique, identifiez les utilisateurs, le processus métier, le temps d'arrêt maximal tolérable, la tolérance à la perte de données, le composant fournisseur, l'installation, la route, la sauvegarde et la méthode alternative. Le résultat montre si un cloud privé dérivé de Keynet est une plateforme principale appropriée, un environnement secondaire ou un service qui a besoin d'une récupération externe plus forte.

Preuves qui justifieraient une meilleure note de confiance

Les preuves actuelles soutiennent un niveau réseau Moyen. L'entreprise est active, l'offre de service est actuelle, un compte client détaillé localise une infrastructure réelle à Lucerne, et AS44911 fournit une bordure réseau d'entreprise active. La confiance reste plafonnée car AS48575 est sombre, la bordure active visible a un seul voisin observé, PeeringDB ne fournit aucune déclaration d'installation indépendante, et les documents publics actuels n'établissent pas de capacité multisite ou de restauration mesurée.

La première amélioration serait une déclaration d'architecture datée. Elle devrait nommer les municipalités de production et de récupération, les opérateurs d'installations, le modèle de propriété, les domaines d'alimentation des racks, les transporteurs, les ASN de bordure et les plages d'adresses. Elle devrait expliquer le retrait d'AS48575 en février 2025 et identifier si les services clients ont été déplacés vers AS44911, un MPLS privé, un autre fournisseur ou la retraite. La déclaration devrait distinguer le cloud public, le cloud privé de l'entreprise et l'équipement appartenant au client.

La deuxième serait une preuve de capacité opérationnelle: calcul et stockage installés, utilisation engagée actuelle, réserve de défaillance, marge commercialisable, matériel de rechange et délai de réapprovisionnement prévu. Les chiffres peuvent être fournis confidentiellement et par plages. Ils devraient toujours être datés et liés au cluster de service réel.

La troisième serait des résultats de résilience. Fournissez des enregistrements récents de basculement d'alimentation et de transporteur, une restauration complète d'application représentative, le point de récupération et le temps mesurés, la capacité du deuxième site et le nombre de clients simultanés inclus. Documentez les échecs et les actions correctives ainsi que les succès. Une affirmation parfaite sans détail de test est moins utile qu'un résultat franc suivi d'une remédiation.

La quatrième serait une clarté contractuelle. L'entité d'exploitation suisse signée, les sous-traitants d'installation et de réseau, les emplacements de données, les heures de service, la voie d'escalade, les conditions de suspension, la priorité de récupération et l'assistance à la sortie devraient s'aligner. Les noms Keynet hérités peuvent rester des identifiants utiles, mais ils ne devraient pas créer d'ambiguïté sur la responsabilité.

La cinquième serait une portabilité vérifiable par le client. Donnez au client des exportations périodiques, des copies de configuration, des options de garde de clés et suffisamment de bande passante ou de support de support pour restaurer ailleurs. Testez au moins un service représentatif loin de l'environnement principal du fournisseur.

Jusqu'à ce que ces éléments soient fournis, l'approvisionnement devrait être proportionné. Les preuves ne justifient pas de déclarer le service indisponible ou l'entreprise inactive. Elles justifient de limiter la concentration, de conserver une sauvegarde indépendante, d'exiger des faits explicites sur l'emplacement et le transporteur, et de traiter la récupération géographique comme non prouvée. L'histoire de Keynet Cloud montre la substance réelle derrière la capacité hébergée: des serveurs, des arrays flash, des circuits MPLS et des ingénieurs.

Son ambiguïté actuelle montre pourquoi ces actifs doivent être cartographiés à nouveau après que les marques, les routes et les contrats changent.