Par Simon Bonin, expert cybersécurité IMS Networks

Disposer d’une protection anti-DDoS ne permet pas nécessairement de savoir comment elle se comporte, lorsqu’une attaque survient. Une bonne prise en main commence par une connaissance précise des flux, des applications exposées et des réglages de protection. Elle passe ensuite par la simulation, les tests et la capacité à ajuster les mécanismes de mitigation en fonction de la réalité du trafic.

De nombreuses entreprises partent du principe que leur protection DDoS, souvent fournie dans le cadre d’un bundle d’offres réseau ou sécurité, fonctionne en mode « plug & play ». En place, elle serait là pour agir comme un airbag et peu importe si les détails sur son fonctionnement exact ou ce qui se passe au quotidien sont limités. Pourtant, en cas d’attaque et de crise, ce parti pris peut vite poser un problème.

Comment faire pour éviter cet écueil et se sentir vraiment en maîtrise de sa défense anti-DDoS ? La première étape consiste à organiser des ateliers techniques au moment du déploiement. Il s’agit notamment de cartographier les flux : quelles applications sont exposées, quels types de trafic, comment les regrouper ou les isoler, quels modules sont associés…

Il faut prendre le temps de mener deux ou trois ateliers avant de placer la solution en mode « simulation » pendant sept à quatorze jours. Cette période permet d’identifier les faux positifs, de retrouver des applications oubliées ou encore de repérer des flux qui devraient être séparés.

La phase de déploiement peut d’ailleurs faire apparaître des éléments inattendus dans le système d’information. C’est un moment où l’on peut découvrir qu’une application censée être décommissionnée est toujours utilisée, par exemple. Le travail autour de l’anti-DDoS devient alors également un exercice plus large de connaissance du SI.

Tester, améliorer, paramétrer avec finesse

Après la phase de simulation vient la mise en protection, de manière coordonnée avec le client. Les protections robustes sont souvent celles qui ont été testées plusieurs fois et améliorées. Cette logique de test reste encore peu répandue. Pour de nombreux responsables de la sécurité de grands groupes, le stress test apparait comme une préoccupation particulièrement importante. Un dispositif qui n’est pas testé n’est pas « combat proof », résumait avec justesse l’un des participants.

Le principe est simple : une organisation peut difficilement savoir si sa protection est correctement adaptée lorsqu’elle n’a jamais observé son comportement dans une situation proche d’une attaque réelle. Les entreprises régulièrement ciblées disposent d’un retour d’expérience direct. Pour les autres, la simulation et les tests permettent de mettre en évidence les éventuels angles morts.

En revanche, si une attaque a bien eu lieu, il est nécessaire de comprendre en profondeur ce qui s’est réellement passé. Si un serveur DNS est tombé, nous pouvons par exemple constater que le seuil configuré était trop élevé. Sur le papier, le serveur devait peut-être tenir 6 000 requêtes par seconde, mais dans la réalité, il peut ne pas en être capable ou encore recevoir en parallèle du trafic venant d’un second opérateur. Dans ce cas, il devient possible d’abaisser le seuil de tolérance pour bloquer plus tôt et au plus proche de la réalité du trafic que le serveur peut supporter.

Dans d’autres cas, il devient nécessaire d’activer un module qui ne l’était pas parce qu’il pouvait générer des faux positifs. Certaines entreprises choisissent un fonctionnement où un module reste en simulation au quotidien et bascule automatiquement en protection lorsque le volume devient inhabituel. À ce moment-là, la politique devient volontairement beaucoup plus stricte. La finesse de la réponse vient de la capacité à s’adapter à la criticité des applications. Sur un service particulier, l’entreprise peut ainsi accepter qu’une petite part de trafic légitime soit rejetée pendant l’attaque pour garantir la disponibilité globale. Sur un autre, aucun faux positif ne sera acceptable. Nous pouvons aussi utiliser de la GeoIP dans certains scénarios, par exemple pour n’autoriser temporairement que des IP françaises. C’est précisément l’intérêt d’un réglage application par application.

Mesurer le temps nécessaire pour réagir

Un autre paramètre mérite une attention particulière : le « time to mitigate », c’est-à-dire le temps qui s’écoule entre le début de l’attaque et le moment où le trafic est effectivement nettoyé. Dans une architecture inline, l’équipement se trouve en permanence sur le chemin du trafic, à l’entrée du backbone opérateur. Il voit donc immédiatement ce qui arrive. Sur des pics volumétriques importants, le temps de réaction peut être de l’ordre de quelques secondes.

Cependant, d’autres architectures fonctionnent avec une phase de détection suivie d’une redirection du trafic vers un centre de scrubbing. Le délai peut alors être plus long, certaines solutions annonçant une à deux minutes. Cette différence devient importante face aux attaques dites « hit and run ». Un pic extrêmement violent de trente secondes va faire tomber ou redémarrer un firewall ou un équipement réseau, puis recommencer dix ou quinze minutes plus tard. Si la mitigation démarre après une minute, le pic est déjà terminé alors que l’équipement a pu subir le choc.

La question de la capacité doit donc être associée à celle de la vitesse de réaction. Une entreprise ne peut évidemment pas absorber seul tous les volumes. L’opérateur doit lui-même dimensionner son infrastructure en fonction du nombre de clients protégés, du risque d’attaques simultanées et des volumes plausibles.

Au fond, pour être certain qu’une solution anti-DDoS protège correctement, il faut comprendre comment elle fonctionne, ce qu’elle voit, à quelle vitesse elle agit, ce qu’il est possible d’ajuster et si son niveau de protection correspond réellement à la criticité des services exposés.

L’essor de l’intelligence artificielle redéfinit les besoins en infrastructures numériques. Pour les datacenters, il ne s’agit plus seulement d’héberger davantage de serveurs, mais de répondre à des besoins de puissance et de densité croissants, tout en conciliant résilience, souveraineté, performance et enjeux environnementaux. Dans cette optique, il est désormais indispensable de concevoir des datacenters répondant aux besoins actuels tout en intégrant la flexibilité nécessaire pour évoluer avec les usages à venir.

S’appuyer sur des conceptions de nouvelle génération

Avec l’essor de l’IA, certaines infrastructures atteignent désormais 100 à 140 kW par baie, un niveau où le refroidissement par air montre ses limites et où le Direct Liquid Cooling devient incontournable. Ces densités restent aujourd’hui l’exception : la plupart des charges d’entreprise demeurent bien en deçà. D’où l’enjeu d’une conception by design, capable d’accueillir les deux, sans figer des choix technologiques appelés à évoluer rapidement. 

Garder la maîtrise sans s’enfermer

La souveraineté ne se résume pas à héberger les données en France. Elle se joue à plusieurs niveaux : le site, l’exploitation, la sécurité, l’actionnariat, mais aussi les choix logiciels et matériels. Un hébergement opéré en France, aligné sur les exigences françaises et européennes comme SecNumCloud, répond aux besoins des secteurs sensibles. L’enjeu est aussi la réversibilité : l’architecture doit permettre de remplacer une solution stratégique sans remettre en cause l’ensemble de l’infrastructure.

Concilier écologie, performance et ancrage régional

Le datacenter de demain doit optimiser quatre paramètres : l’électricité, l’eau, la chaleur fatale et l’accès à la puissance. Le raccordement au réseau et les délais pour obtenir des mégawatts font désormais partie des contraintes de conception à part entière. Plutôt que de dépendre d’un mode de refroidissement unique, le site devra combiner Free Cooling, refroidissement mécanique ou liquide et solutions hybrides. L’IA pourra aider à arbitrer en temps réel en croisant météo, production photovoltaïque locale, réserves d’eau sans prélèvement d’eau potable et charge IT. Exemple : lorsque l’énergie solaire est abondante, privilégier temporairement le refroidissement mécanique pour économiser l’eau, puis basculer vers le Free Cooling dès que les conditions extérieures le permettent.

Cette optimisation s’inscrit dans une approche territoriale plus large. Consommations d’énergie et d’eau, préservation de la biodiversité et des écosystèmes, réseaux électriques locaux, nuisances sonores et valorisation de la chaleur (réseaux de chaleur urbains, bâtiments voisins, activités agricoles ou industrielles) doivent être anticipés dès la conception, en concertation avec les collectivités, les acteurs économiques et les riverains. Le datacenter devient un système dynamique, conçu et piloté en interaction avec son environnement.

S’appuyer sur des équipes expertes

Plus un datacenter est résilient, dense et automatisé, plus son exploitation exige de compétences.  Le refroidissement liquide, par exemple, introduit des enjeux propres (étanchéité, maintenance, continuité du refroidissement) qui imposent une collaboration étroite entre énergie, IT, sécurité et continuité d’activité. Formation continue, participation aux audits, maîtrise des référentiels, veille réglementaire et échanges avec constructeurs et intégrateurs en sont les conditions.

Modulaire, prêt pour l’IA, résilient, souverain et piloté par la donnée : tel est le cahier des charges du datacenter de demain. Pour les organisations qui hébergent des données de santé ou des applications critiques, il se traduit par une exigence concrète : bénéficier de ces évolutions sans compromis sur la confidentialité ni la continuité de service.

Par Frédéric Le Guillou – DSI du Groupe Cegedim, Président de cegedim.cloud