Chaque service publié sur Internet est une porte. La question n’est pas de savoir s’il sera sondé — il le sera dans les minutes qui suivent sa mise en ligne — mais ce qu’un attaquant obtient s’il la franchit.
C’est une question d’architecture, tranchée avant le déploiement. Après, on ne fait que du rattrapage.
La règle fondatrice de la zone démilitarisée tient en une phrase : le composant accessible depuis Internet ne doit contenir ni données sensibles, ni identifiants permettant d’atteindre ce qui en contient.
Un serveur web exposé qui héberge sa propre base de données, ou qui porte en clair les identifiants d’une base interne, annule tout l’intérêt du cloisonnement. Sa compromission donne accès aux données.
L’architecture qui tient sépare trois niveaux :
Aucun flux ne saute un niveau. Un serveur exposé qui parle directement à la base est une architecture à deux niveaux déguisée en trois.
Un relais inverse en frontal — qui reçoit la connexion, la termine, et en ouvre une nouvelle vers l’arrière — apporte trois choses qu’un simple filtrage de ports ne donne pas.
Il masque l’architecture interne : l’attaquant dialogue avec le relais, pas avec l’application.
Il permet un contrôle du contenu : validation des requêtes, filtrage applicatif, limitation de débit.
Il concentre la gestion des certificats en un point, ce qui règle la moitié des incidents d’expiration.
Point de vigilance : ce relais devient un actif critique. Il voit les flux en clair et sa compromission est structurante. Il doit être durci, surveillé, et administré depuis un niveau distinct — même logique que pour les comptes à privilèges.
Sur les audits que nous menons, l’écart le plus fréquent n’est pas une faille dans le service exposé : c’est le nombre de services exposés que personne n’avait l’intention de publier.
Interfaces d’administration accessibles depuis Internet, environnements de recette laissés ouverts, anciennes versions d’API toujours actives, services de supervision publiés « le temps d’un dépannage ».
Deux mesures traitent l’essentiel :
Un inventaire de la surface exposée, mis à jour et confronté périodiquement à la réalité observée depuis l’extérieur. L’écart entre ce qu’on croit exposer et ce qu’on expose est toujours instructif — c’est une extension naturelle de l’inventaire des actifs.
Une règle de publication : rien n’est exposé sans décision tracée, avec un propriétaire et une date de réexamen. Sans cette règle, la surface croît par accumulation de décisions temporaires.
Cette liste paraît évidente. Elle correspond pourtant à ce qu’on retrouve exposé dans la majorité des audits de surface externe.
Beaucoup d’architectures filtrent rigoureusement l’entrant et laissent le sortant ouvert.
Or un serveur exposé compromis a besoin de sortir : pour récupérer sa charge, pour joindre son serveur de commande, pour exfiltrer. Un serveur applicatif n’a en principe aucune raison d’initier une connexion vers Internet, sauf besoin identifié.
Restreindre le sortant depuis les zones exposées et applicatives est l’une des mesures les plus rentables, et l’une des moins appliquées. Elle transforme une compromission exploitable en compromission bloquée — et elle génère un signal de détection immédiat, comme décrit dans la chronologie d’une attaque.
Sujet trivial en apparence, cause d’indisponibilité récurrente en pratique.
Trois mesures suffisent : un inventaire des certificats avec leurs dates d’expiration, un renouvellement automatisé lorsque c’est possible, et une alerte à plusieurs semaines pour le reste.
L’expiration d’un certificat sur un service critique produit une interruption totale, un vendredi soir, sans attaquant. C’est un incident de disponibilité pur — et il relève donc aussi de l’article 32 du RGPD.
Une architecture d’exposition doit prévoir la saturation. Un service unique, sans capacité d’absorption ni de bascule, est indisponible dès qu’il est ciblé — sans qu’aucune faille n’ait été exploitée.
Les arbitrages relèvent du bilan d’impact : quel niveau d’indisponibilité est acceptable, et à quel coût. C’est le même raisonnement que pour le plan de continuité, appliqué à la façade.
Ce qui doit remonter, au minimum : les connexions acceptées et refusées en bordure, les erreurs applicatives, les authentifications, les volumes sortants anormaux.
La façade est l’endroit où une attaque se voit en premier. Une zone exposée non journalisée signifie que la reconstitution après incident commencera au deuxième niveau, en ayant perdu l’essentiel — voir ce qu’il faut collecter.
Les mêmes principes s’appliquent, avec une difficulté supplémentaire : les zones sont logiques plutôt que physiques, et les configurations par défaut privilégient la mise en service.
Deux réflexes : vérifier systématiquement les paramètres d’exposition d’un service nouvellement créé, et considérer que les groupes de sécurité et règles de filtrage remplacent les équipements — ils demandent donc la même rigueur de revue. Voir la responsabilité partagée.
ISO/IEC 27002:2022 traite ces sujets par les mesures 8.20 (sécurité des réseaux), 8.21 (sécurité des services réseau), 8.22 (cloisonnement), 8.23 (filtrage web) et 8.26 (exigences de sécurité des applications).
L’article 21 de NIS 2 impose la sécurité des réseaux et des systèmes d’information, et la maîtrise de l’exposition en est la traduction la plus directe.
La troisième question est celle qui produit le plus de surprises, et elle se traite en une demi-journée.
Nous concevons et reprenons ces architectures en sécurité réseau périmétrique. La cartographie de votre surface exposée fait partie de l’audit 360, et sa mise à l’épreuve de nos tests d’intrusion.
L’analyse d’impact relative à la protection des données est l’une des obligations du RGPD les plus mal calibrées en pratique. Certaines organisations en produisent pour tout, y compris des traitements ...
1-3 Rue d’Enghien
75010, Paris
France
Recevez les actualités du site Cyberdian.
