Alors que tout le monde débat pour savoir quel modèle écrit le meilleur code, un problème bien plus ancien et bien moins glamour prend discrètement de l’ampleur avec chaque nouveau datacenter d’IA : le contrôleur de gestion de la carte mère, ou BMC. Cette semaine, des chercheurs en sécurité ont présenté des résultats montrant que des milliers de serveurs connectés à Internet, provenant de grands fabricants, peuvent être compromis à distance par des failles dans ces contrôleurs — certaines de ces failles datant de plus de dix ans. Ce n’est pas du tout une histoire d’IA. C’est une histoire de matériel sur lequel fonctionne l’IA, et elle mérite qu’on la comprenne si l’on réfléchit à l’origine de la prochaine vague d’emplois dans la sécurité liée à l’IA.

Ce qu’est réellement un BMC, et pourquoi c’est inquiétant

Un BMC est un petit ordinateur séparé, soudé à pratiquement toutes les cartes mères de serveurs d’entreprise. Il possède son propre système d’exploitation, sa propre pile réseau et sa propre adresse IP — entièrement indépendants du système d’exploitation et des applications qui fonctionnent sur le serveur principal. Les administrateurs utilisent les BMC pour la gestion « lights-out » ou « hors bande » : redémarrer une machine, reflasher le firmware, réinstaller un système d’exploitation, le tout à distance et, surtout, même lorsque le serveur principal est éteint ou complètement inactif.

C’est aussi exactement ce qui rend un BMC compromis si dangereux. Un attaquant qui y accède n’a pas besoin que le système d’exploitation hôte fonctionne, n’a pas besoin de contourner les éventuels outils de sécurité des terminaux qui y sont installés et peut persister après les réinstallations du système d’exploitation, puisque le BMC se trouve sous la couche surveillée par les outils de sécurité informatique ordinaires et en dehors de celle-ci. Selon les recherches couvertes cette semaine, le protocole le plus souvent mis en cause est IPMI, et les chercheurs en sécurité signalent cette catégorie de risques depuis au moins 2013. Autrement dit : il ne s’agit pas d’une nouvelle faille, mais d’une catégorie de failles ancienne, connue et structurellement difficile à corriger, que le secteur tolère depuis bien plus de dix ans.

Pourquoi cela compte davantage aujourd’hui, et non moins

Le déploiement de l’IA constitue, physiquement, l’une des plus grandes vagues d’achat de serveurs de l’histoire — des rangées et des rangées de serveurs équipés de GPU installés dans de nouveaux datacenters ou dans des datacenters agrandis, aussi vite que les fournisseurs peuvent les expédier. Chacun de ces serveurs est livré avec un BMC, car les BMC sont le moyen par lequel les opérateurs de datacenters gèrent des flottes à grande échelle ; il est impossible d’entrer dans un bâtiment de la taille d’un entrepôt et de redémarrer manuellement dix mille machines. L’essor de l’IA n’achète donc pas seulement de la puissance de calcul — il achète aussi, par nécessité, une flotte de taille équivalente de petits ordinateurs hors bande, peu surveillés, ayant un historique documenté de vulnérabilités critiques qui s’étend sur plus de dix ans.

Voilà la dette technique : la vitesse de déploiement est optimisée pour installer les GPU en rack et lancer les entraînements, pas pour auditer le firmware de gestion intégré à chaque carte mère qui se trouve en dessous. Les chercheurs à l’origine de la divulgation de cette semaine auraient décrit les BMC comme une « surface d’attaque parallèle omniprésente, peu surveillée et insuffisamment corrigée » — une description antérieure à l’essor des datacenters d’IA, mais cet essor est précisément ce qui multiplie actuellement le nombre de BMC en production.

Le créneau qui s’ouvre

Si vous cherchez à déterminer vers où évoluent les carrières de la sécurité parallèlement aux infrastructures d’IA, la plupart des voies évidentes — red teaming des modèles, défense contre l’injection de prompts, gouvernance des agents — sont déjà encombrées et déjà largement couvertes ailleurs. L’audit de la sécurité matérielle et de la sécurité hors bande ne l’est pas. C’est un domaine peu glamour et peu séduisant de la sécurité des infrastructures, qui n’apparaît pas dans les présentations consacrées à l’IA, et c’est précisément là que se trouve la lacune : la demande augmente avec chaque nouveau datacenter, tandis que le nombre de personnes qui comprennent les surfaces d’attaque au niveau du firmware et hors bande est faible, car il s’agit véritablement d’un ensemble de compétences différent de celui de la sécurité applicative ou cloud.

À quoi ressemble concrètement le travail :

  • Maîtrise du firmware et des protocoles. Comprendre IPMI (et ses faiblesses connues — comme la suite de chiffrement 0, dépréciée depuis longtemps, que certains appareils livrent encore activée) suffisamment bien pour évaluer si une flotte de serveurs donnée est exposée, et pas seulement vulnérable en théorie.
  • Audits de segmentation réseau. Vérifier si les interfaces BMC/de gestion sont réellement isolées sur un réseau de gestion dédié, ou si elles sont accessibles depuis la production ou depuis Internet en général — un contrôle élémentaire qui s’avère régulièrement absent dans la réalité.
  • Examens de l’hygiène des identifiants et des correctifs. Les BMC sont fréquemment livrés avec des identifiants par défaut ou définis par le fournisseur, ainsi qu’avec un firmware qui ne fait pas partie du cycle normal de correctifs du système d’exploitation d’un datacenter, puisqu’il ne s’agit pas du système d’exploitation — il est facile qu’il échappe à la personne ou à l’équipe responsable du « déploiement des correctifs ».
  • Connaissance des fournisseurs et de la chaîne d’approvisionnement. Le firmware des BMC est généralement écrit par un petit nombre de fournisseurs spécialisés, puis concédé sous licence aux fabricants de serveurs ; une faille dans le code d’un seul fournisseur peut donc se propager à de nombreuses marques de matériel à la fois — c’est exactement le schéma observé dans la divulgation de cette semaine. Savoir quelle pile de firmware se trouve sous telle ou telle marque de serveur fait partie du travail.

Comment vous positionner concrètement dans ce domaine

Il s’agit d’un domaine véritablement spécialisé, et il est légitime de se demander combien de postes dédiés seront créés, plutôt que cette spécialisation ne reste intégrée aux équipes existantes chargées des infrastructures ou de la sécurité — soyez honnête avec vous-même : « auditeur de la sécurité des BMC » pourrait finalement être une compétence que vous ajoutez à un rôle plus large dans la sécurité du matériel ou des datacenters, plutôt qu’un intitulé de poste à part entière. Mais quelques démarches concrètes et vérifiables sont pertinentes dans tous les cas : familiarisez-vous directement avec IPMI et les outils de gestion hors bande si vous avez accès à des serveurs d’entreprise, ou même à du matériel d’occasion pour monter un laboratoire ; lisez les avis de sécurité des fournisseurs concernant le firmware des BMC des principaux fabricants de serveurs et de firmware BMC, puisqu’ils publient de véritables divulgations de vulnérabilités que vous pouvez étudier ; et si vous travaillez déjà dans la sécurité cloud ou des infrastructures, commencez par poser à l’équipe chargée des datacenters ou des achats de matériel de votre organisation une question simple et vérifiable — notre plan de gestion BMC/IPMI se trouve-t-il sur un réseau isolé, et qui est chargé de le corriger ? Si personne n’a de réponse assurée, ce n’est pas seulement un constat, c’est une démonstration exacte de l’expertise dont ce créneau a besoin.