Votre hébergeur cloud fait partie de votre surface d'attaque, piraté ou non

Qui est exactement responsable de la sécurité du serveur que vous louez ? La plupart des équipes répondraient « nous, surtout », puis supposeraient tacitement que l'entreprise propriétaire du matériel, de l'hyperviseur et de la console d'administration a mis de l'ordre chez elle. Cette hypothèse tacite est la véritable histoire derrière les récents avis de sécurité de Linode.

Soyons précis, car le cadrage des gros titres peut induire en erreur. La documentation dont nous disposons ne décrit pas une intrusion confirmée chez Linode, qui fait partie d'Akamai. Elle montre deux avis de sécurité destinés aux clients sur sa page d'état. Le premier, sur des vulnérabilités d'exécution de code à distance dans PHP, a débuté le 21 octobre 2026. Le suivant, sur des failles critiques de F5/NGINX publiées hors cycle, est arrivé le 22 octobre. Dans ce dernier, Akamai indiquait que ses équipes « enquêtaient activement » sur l'impact potentiel de trois CVE sur sa plateforme et son infrastructure.

La confiance par défaut est la vraie vulnérabilité

Ce n'est pas un scandale. Publier des avis est ce que doit faire un fournisseur. Mais observez la formulation: l'entreprise elle-même cherchait encore à mesurer l'exposition de sa propre plateforme. Si ceux qui font tourner les machines ont besoin de temps pour le savoir, le client qui en loue une portion devrait lui aussi poser des questions.

La plupart d'entre nous évaluent un hébergeur une seule fois, à l'inscription, sur le prix, la région et la disponibilité. Ensuite, il devient un élément du décor. Nous corrigeons notre propre application, faisons tourner nos propres clés et considérons tout ce qui se trouve en dessous comme le problème de quelqu'un d'autre. À notre avis, c'est l'inverse qu'il faudrait faire. Les serveurs web de votre fournisseur, son API de gestion, ses outils de support et les accès de son personnel sont autant de chemins vers vos charges de travail, et vous n'en contrôlez aucun.

Ce schéma n'est pas propre à l'hébergement. Coinbase a affirmé que les fonds de ses clients étaient en sécurité après un incident chez un prestataire d'analyse touchant des données de contact, d'après le titre de cet article. Autre couche, même leçon: votre exposition inclut chaque fournisseur à qui vous avez confié des données ou des privilèges, que vous vous souveniez ou non de l'avoir inscrit.

La transparence est le produit à rechercher

Lorsqu'un incident survient, la qualité de la communication du fournisseur compte presque autant que le correctif. Comparez deux comportements. L'avis sur F5/NGINX nomme les CVE précises et indique ce qui fait l'objet d'une enquête. À l'inverse, chez Applebee's, selon TechCrunch, un chercheur n'a trouvé aucun moyen de signaler un problème de sécurité, et l'entreprise n'a pas voulu dire si elle disposait de journaux pour vérifier d'éventuels accès non autorisés. Applebee's n'est pas un hébergeur, mais le contraste est instructif: l'une des organisations vous dit ce qu'elle sait, l'autre vous laisse deviner.

Posez donc à votre fournisseur les questions ennuyeuses avant d'avoir besoin des réponses:

• Existe-t-il un contact de sécurité public et une procédure de divulgation ?
• À quelle vitesse les avis sont-ils publiés, et nomment-ils les failles précises ?
• À quoi le fournisseur peut-il accéder dans votre environnement, et cet accès est-il journalisé ?
• Serez-vous prévenu si un incident interne touche vos données, et dans quel délai ?

Si les réponses sont vagues, c'est une information en soi. Nous lui donnerions au moins autant de poids qu'au prix mensuel.

Partez du principe que le fournisseur peut être compromis, puis concevez en conséquence

Notre recommandation n'est pas de fuir le cloud. L'auto-hébergement a ses propres modes de défaillance, et la plupart des petites équipes feraient sans doute moins bien. Il s'agit d'adopter une posture: supposer que la couche située sous vous peut défaillir, et limiter le coût de cette défaillance.

En pratique, cela signifie chiffrer les données avec des clés que le fournisseur ne détient jamais, conserver les sauvegardes ailleurs et traiter les jetons d'API et les clés SSH comme des éléments que l'on peut renouveler en un après-midi. Cela signifie aussi surveiller les flux d'état et de sécurité de votre fournisseur comme vous surveillez vos propres dépendances. Une faille NGINX ou PHP ne concerne pas seulement vos instances; elle peut aussi concerner l'infrastructure qui les héberge. Rien de tout cela n'exige de la paranoïa. Il s'agit de faire passer le fournisseur de « de confiance » à « de confiance, vérifié et remplaçable ».

Notre verdict: ne voyez pas dans les avis de Linode une raison de paniquer ou de changer de fournisseur. Voyez-y un exercice d'évacuation gratuit. Si un avis comme celui-ci vous a fait réaliser que vous ne savez pas ce que votre hébergeur peut voir, qui vous contacteriez ou comment vous reconstruiriez ailleurs, cette lacune est la vraie découverte. Comblez-la ce trimestre, tant qu'elle reste une tâche à faire et non un rapport d'incident.