Exposer un service sur Internet : l’architecture qui tient

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.

Le principe : ce qui est exposé ne détient rien

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 :

• La zone exposée : ce qui reçoit les connexions depuis Internet. Elle traite, filtre, relaie. Elle ne stocke pas.
• La zone applicative : la logique métier, joignable uniquement depuis la zone exposée, sur des flux précisément définis.
• La zone de données : bases et stockages, joignables uniquement depuis la zone applicative.

Aucun flux ne saute un niveau. Un serveur exposé qui parle directement à la base est une architecture à deux niveaux déguisée en trois.

La rupture protocolaire

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.

Exposer le minimum

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.

Ce qui ne doit jamais être exposé directement

• Les interfaces d’administration, quelles qu’elles soient. Elles passent par un accès distant authentifié, jamais par une publication directe.
• Les bases de données et les services de stockage.
• Les protocoles de partage de fichiers internes.
• Les environnements de recette — voir le cloisonnement test/production.
• Les équipements techniques : imprimantes, caméras, sondes, automates.

Cette liste paraît évidente. Elle correspond pourtant à ce qu’on retrouve exposé dans la majorité des audits de surface externe.

Les flux sortants, angle mort classique

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.

La gestion des certificats

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.

La disponibilité comme composante de sécurité

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.

Journaliser 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.

Le cas de l’hébergement externalisé

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.

Ce que demandent les référentiels

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.

Les sept vérifications

1. Un composant exposé détient-il des données ou des identifiants d’accès aux données ?
2. Existe-t-il un flux direct entre la zone exposée et la zone de données ?
3. Que voit-on réellement depuis l’extérieur, comparé à ce qu’on pense exposer ?
4. Les interfaces d’administration sont-elles accessibles depuis Internet ?
5. Les flux sortants depuis les zones exposées sont-ils restreints ?
6. Quand expire le prochain certificat, et qui sera prévenu ?
7. La façade est-elle journalisée, et les traces conservées ailleurs ?

La troisième question est celle qui produit le plus de surprises, et elle se traite en une demi-journée.

Sources

• ISO/IEC 27002:2022, mesures 8.20 à 8.23 et 8.26
• ANSSI — recommandations relatives à l’architecture des systèmes d’information
• OWASP Web Security Testing Guide
• Directive (UE) 2022/2555 (NIS 2), article 21

Aller plus loin

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.