Aller au contenu
Sécurité medium

Surface d'attaque : ce que votre système expose

11 min de lecture

La surface d'attaque, c'est l'ensemble des points par lesquels un attaquant peut essayer d'entrer dans votre système : un port réseau ouvert, un service accessible depuis Internet, une page de connexion, une API, un compte utilisateur ou une bibliothèque tierce que vous utilisez. Chaque point exposé est une porte de plus à surveiller et à défendre. Réduire cette surface, c'est fermer les portes dont vous n'avez pas besoin. Cette page explique ce que recouvre la notion, quels sont les points d'entrée typiques et comment les diminuer, sans aucun prérequis autre que la notion de système informatique.

Cette page pose un modèle mental simple, réutilisable quel que soit votre environnement (serveur, application, cloud). Concrètement, vous saurez :

  • Définir la surface d'attaque avec une analogie concrète, celle d'une maison et de ses ouvertures.
  • Reconnaître les points d'entrée typiques : ports ouverts, services exposés, API, formulaires, comptes, dépendances.
  • Comprendre pourquoi une surface plus petite signifie moins de risques à gérer.
  • Appliquer des gestes concrets de réduction : fermer, retirer, limiter.
  • Relier cette notion à la minimisation, aux menaces qui ciblent ces points et au modèle de menaces SOCLE, qui liste les vecteurs d'attaque par domaine.

La surface d'attaque désigne la somme de tous les points d'entrée exposés d'un système, c'est-à-dire tous les endroits où quelqu'un d'extérieur peut interagir avec lui pour tenter de le compromettre. Ce n'est pas une faille précise : c'est la taille de la cible offerte à un attaquant.

La surface d'attaque : l'ensemble des points d'entrée exposés qu'un attaquant peut viser

L'analogie la plus parlante est celle d'une maison. Les portes et les fenêtres sont vos points d'entrée : chaque ouverture est un endroit qu'un cambrioleur peut tenter de forcer. Une maison avec une seule porte bien verrouillée est plus simple à protéger qu'une maison avec dix portes, cinq fenêtres et une porte de garage restée entrouverte. La surface d'attaque, c'est le nombre et l'état de ces ouvertures.

En informatique, un système accumule vite ces ouvertures : un service qu'on a installé pour tester et jamais retiré, un port laissé ouvert par défaut, un compte créé pour un ancien collègue. Chacun paraît anodin, mais additionnés, ils forment une surface bien plus grande qu'on ne l'imagine. La bonne nouvelle : contrairement à une faille, une surface se mesure et se réduit volontairement.

Un point d'entrée est n'importe quel endroit où le monde extérieur peut envoyer une requête, une donnée ou une tentative de connexion à votre système. Voici les catégories les plus courantes, définies une par une.

Un port ouvert est un numéro de canal réseau sur lequel une machine écoute et accepte des connexions. Le port 22 sert à l'administration à distance (SSH), le port 443 au web sécurisé (HTTPS). Un port ouvert que personne n'utilise reste une porte accessible aux scanners automatiques.

Un service exposé est un logiciel qui écoute sur un port et répond aux demandes : un serveur web, une base de données, un outil d'administration. Exposé signifie ici « joignable depuis l'extérieur », par exemple depuis Internet et pas seulement depuis le réseau interne.

Une API (interface de programmation, un ensemble d'adresses qu'un programme peut appeler pour dialoguer avec un autre) multiplie les points d'entrée : chaque endpoint (chaque adresse d'appel de l'API) est une porte de plus. Un endpoint de débogage ou de mesures laissé accessible en production révèle souvent des informations internes précieuses pour un attaquant.

Un formulaire (champ de saisie, page de connexion, zone de recherche) accepte des données venues de l'utilisateur. Mal filtrées, ces données ouvrent la voie à des attaques par injection, où l'attaquant glisse du code là où le système attendait un simple texte.

Un compte utilisateur est un point d'entrée humain : chaque identifiant, chaque mot de passe, chaque jeton d'accès (une clé numérique qui prouve une identité) est une clé qui peut être volée, devinée ou réutilisée. Les comptes oubliés d'anciens employés sont un classique.

Une dépendance est une bibliothèque de code écrite par d'autres et intégrée à votre logiciel. Vous héritez de ses éventuelles failles sans les avoir écrites. C'est le terrain des attaques dites de supply chain, où l'on compromet un composant en amont pour toucher tous ceux qui l'utilisent.

Le raisonnement est simple : moins de points d'entrée, moins de risques. Chaque porte ouverte est une chose de plus à maintenir à jour, à surveiller et à défendre. Fermer une porte inutile supprime d'un coup tout le travail qu'elle imposait et toute la menace qu'elle portait.

Une grande surface coûte cher en pratique. Chaque service exposé doit recevoir ses correctifs de sécurité, apparaître dans vos journaux de surveillance et être pensé dans votre configuration. Multipliez par des dizaines de services oubliés, et l'équipe se noie : elle n'a plus les moyens de tout suivre, et c'est justement la porte oubliée qui sert d'entrée à l'attaquant.

Il faut aussi abandonner un réflexe dangereux, la sécurité par l'obscurité, l'idée qu'un service non documenté serait invisible. Les scanners automatiques parcourent Internet en permanence et trouvent un port ouvert en quelques minutes, qu'il soit référencé ou non. Un service exposé est un service découvrable, point.

Réduire la surface d'attaque ne demande pas d'outil magique : c'est une discipline de tri, faite de gestes concrets et répétés. Le principe directeur est le deny by default (tout fermer par défaut, n'ouvrir que ce qui est explicitement nécessaire et justifié).

Le premier geste est de fermer les ports inutiles. Faites l'inventaire des ports réellement ouverts sur chaque machine, puis fermez tout ce qui ne correspond pas à un usage actif et connu. Un pare-feu (un filtre qui autorise ou bloque les connexions selon des règles) qui refuse tout sauf le strict nécessaire divise la surface réseau.

Le deuxième geste est de retirer les services dont vous ne vous servez pas. Un service désinstallé ne peut plus être attaqué : c'est la protection la plus solide qui soit. Désactivez de même les fonctionnalités non utilisées d'un logiciel (interface de débogage, module optionnel, endpoint de test).

Le troisième geste est de limiter les dépendances. Chaque bibliothèque ajoutée agrandit la surface : n'intégrez que celles dont vous avez vraiment besoin, gardez-les à jour et surveillez leurs failles connues. Moins de code tiers, moins de portes héritées.

Une petite équipe déploie un serveur de test dans le cloud pour un projet pilote. Pour aller vite, elle ouvre tous les ports « le temps des essais », installe une base de données accessible depuis Internet et conserve les identifiants par défaut fournis à l'installation.

Le projet est ensuite abandonné, mais personne ne pense à éteindre le serveur. Six mois plus tard, il tourne toujours, oublié de tous. Un scanner automatique repère le port de la base de données ouvert, teste les identifiants par défaut, et obtient un accès complet. Les données du pilote contenaient des informations clients réelles.

Rien de sophistiqué dans cette attaque : pas de faille exotique, juste une porte laissée ouverte et oubliée. La leçon tient en une phrase : la surface d'attaque grandit toute seule si personne ne la surveille. Un simple réflexe de décommissionnement (éteindre et supprimer ce qui ne sert plus) aurait fait disparaître le risque.

Comprendre la notion ne suffit pas ; encore faut-il éviter les erreurs de raisonnement qui la vident de son sens. En voici quatre, fréquentes.

Le premier piège est l'inventaire incomplet. On recense les serveurs « officiels » et on oublie les environnements de test, les vieilles machines héritées et les ressources cloud créées à la volée. Or on ne protège que ce qu'on connaît : un actif oublié reste une porte grande ouverte.

Le deuxième piège est de croire la surface figée. Elle change à chaque déploiement, chaque nouvelle dépendance, chaque modification de configuration. Un audit unique donne une photo à un instant donné, jamais une garantie durable. La réduction est un processus continu, pas un projet ponctuel.

Le troisième piège est le shadow IT (les services déployés par des équipes en dehors des procédures officielles : instance cloud personnelle, outil en ligne non validé). Invisible pour la sécurité, il agrandit la surface sans que personne ne le sache.

Le quatrième piège est l'obsession du périmètre extérieur. On blinde la façade Internet et on néglige l'intérieur. Un attaquant qui franchit la première porte découvre alors une surface interne souvent bien plus vaste et bien moins verrouillée.

  1. La surface d'attaque est la somme des points d'entrée exposés d'un système : ports, services, API, formulaires, comptes et dépendances.

  2. Chaque porte ouverte est un coût, elle doit être maintenue, surveillée et défendue ; la fermer supprime le risque et le travail associés.

  3. La sécurité par l'obscurité n'existe pas : les scanners automatiques trouvent un service exposé en quelques minutes, documenté ou non.

  4. Réduire, c'est trier : fermer les ports inutiles, retirer les services non utilisés, limiter les dépendances, selon le principe du deny by default.

  5. La surface évolue en permanence : un audit unique ne suffit pas, la réduction est une discipline continue.

  6. N'oubliez pas l'intérieur : la surface interne, souvent plus large, mérite autant d'attention que le périmètre exposé sur Internet.

  7. Ce concept nourrit votre analyse de menaces : le modèle de menaces SOCLE recense, domaine par domaine, les vecteurs d'attaque qui ciblent justement ces points d'entrée.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn