NGINX : serveur web & reverse proxy

Avant notre intervention, les applications du centre hospitalier étaient exposées directement sur le réseau, sans intermédiaire sécurisé et sans chiffrement. Nous avons mis en place deux instances NGINX : un reverse proxy interne pour les applications accessibles depuis le réseau de l'établissement, et un reverse proxy en DMZ pour les applications exposées vers l'extérieur. Les applications ne sont plus exposées directement, et un certificat SSL wildcard couvre l'ensemble du parc sans que chaque application ait à gérer le sien.

Qu'est-ce que NGINX ?

NGINX est un serveur web et reverse proxy open source, réputé pour ses performances. Il sert des contenus web, répartit la charge et fait office de point d'entrée sécurisé devant les applications.

Le problème : des applications exposées directement et sans certificat

Avant la mise en place de NGINX, la situation était courante mais préoccupante :

• Applications exposées directement : chaque application était accessible directement depuis le réseau, sur son propre port. La surface d'exposition était aussi large que le nombre d'applications déployées.
• Aucun certificat SSL : les applications communiquaient en HTTP clair, sans chiffrement. Les données échangées entre le navigateur de l'utilisateur et l'application transitaient en clair sur le réseau.
• Pas de point d'entrée unifié : il n'existait pas de composant central pour appliquer des règles de sécurité homogènes, filtrer les requêtes ou journaliser les accès.

Exposer une application directement sur le réseau sans reverse proxy, c'est ouvrir une porte par application. NGINX permet de n'avoir qu'une seule porte, sécurisée, derrière laquelle toutes les applications sont protégées.

NGINX comme reverse proxy central

Nous avons positionné NGINX comme point d'entrée unique devant toutes les applications web du centre hospitalier. Chaque utilisateur passe désormais par NGINX pour accéder à une application : NGINX reçoit la requête, la traite et la transmet à l'application cible. Les applications elles-mêmes ne sont plus directement accessibles depuis le réseau.

Ce positionnement apporte plusieurs bénéfices immédiats :

• Réduction de la surface d'exposition : seul NGINX est exposé. Les applications sont en retrait, inaccessibles directement depuis l'extérieur.
• Point d'application centralisé des règles de sécurité : les en-têtes de sécurité, les restrictions d'accès et les règles de filtrage sont configurés une seule fois dans NGINX et s'appliquent à toutes les applications.
• Journalisation centralisée des accès : tous les accès applicatifs sont tracés au niveau de NGINX, quelle que soit l'application cible.

Deux instances NGINX : interne et DMZ

Nous avons déployé deux instances NGINX distinctes, chacune dans une zone réseau adaptée à son rôle :

• NGINX interne : positionné sur le réseau interne de l'établissement, il sert de point d'entrée pour toutes les applications accessibles uniquement depuis l'intérieur du SI - outils de gestion, applications métier internes, interfaces d'administration. Les utilisateurs internes (agents, soignants, informaticiens) passent par ce NGINX pour accéder à leurs applications.
• NGINX en DMZ : positionné dans la zone démilitarisée, il expose uniquement les applications qui doivent être accessibles depuis l'extérieur - portails de connexion à distance, applications partenaires, accès prestataires. La DMZ isole ces services exposés du réseau interne : une compromission d'une application en DMZ ne donne pas accès au réseau interne.

Cette séparation en deux zones est une bonne pratique de sécurité réseau : elle limite la surface d'attaque et contient l'impact d'un éventuel incident sur les seules applications exposées, sans mettre en danger le reste du SI.

Un NGINX pour l'intérieur, un NGINX pour l'extérieur. Ce que les utilisateurs externes peuvent voir ne peut pas atteindre ce que les applications internes hébergent.

Un certificat SSL wildcard pour toutes les applications

Avant NGINX, aucune application ne disposait de certificat SSL : les communications se faisaient en HTTP. Avec NGINX, nous avons mis en place un certificat SSL wildcard couvrant l'ensemble des sous-domaines du centre hospitalier.

Ce certificat unique protège la totalité des applications exposées via NGINX. Concrètement :

• Toutes les applications passent en HTTPS, sans que chacune ait à gérer son propre certificat.
• La gestion des certificats est centralisée : un seul certificat wildcard à renouveler, via Let's Encrypt, de façon automatique.
• Les équipes applicatives sont soulagées : elles n'ont plus à se préoccuper de la gestion TLS pour leurs applications.

Déploiement conteneurisé, authentification centralisée et mises à jour maîtrisées

Cette application est déployée en conteneur Docker, orchestré et provisionné via Ansible. Cette approche garantit un déploiement reproductible, documenté et homogène d'un environnement à l'autre : la configuration est décrite sous forme de code, ce qui élimine les installations manuelles et fiabilise chaque mise en service.

Nous assurons les mises à jour de manière transparente pour les utilisateurs : les montées de version sont préparées, testées et appliquées de façon contrôlée, sans interruption perceptible du service. L'établissement bénéficie ainsi d'une application toujours à jour et sécurisée, sans avoir à gérer lui-même la complexité technique des mises à jour.

L'accès à cette application repose sur une authentification centralisée par OIDC avec Keycloak. Comme l'ensemble des applications que nous déployons, elle s'appuie sur un fournisseur d'identité unique : les utilisateurs se connectent avec les mêmes identifiants sur tout le parc applicatif, la gestion des accès est mutualisée et les règles de sécurité (mot de passe, second facteur, révocation) sont appliquées de façon homogène. Ce socle d'authentification unifié simplifie l'expérience utilisateur et renforce la maîtrise des accès à l'échelle du système d'information.

Notre déploiement

NGINX est déployé en conteneur Docker, configuré comme reverse proxy devant l'ensemble des applications web du centre hospitalier. Le certificat SSL wildcard est obtenu et renouvelé automatiquement via Let's Encrypt. La configuration de NGINX est gérée par Ansible : l'ajout d'une nouvelle application dans le reverse proxy est une opération standardisée, reproductible et sans risque d'erreur manuelle.

Intégration au système d'information

NGINX est le point d'entrée de toutes les applications de la stack : Keycloak, Nextcloud, HumHub, Vikunja, phpIPAM, Esup-Signature et l'ensemble des autres outils déployés passent par NGINX. La supervision de la disponibilité de NGINX est assurée par Uptime Kuma. Les configurations sont versionnées et déployées par Ansible, garantissant la traçabilité de chaque modification.

Bénéfices concrets

• Surface d'exposition réduite : les applications ne sont plus accessibles directement depuis le réseau.
• HTTPS sur toutes les applications grâce au certificat SSL wildcard centralisé.
• Zéro gestion de certificat par application : un seul certificat wildcard renouvelé automatiquement couvre tout le parc.
• Règles de sécurité homogènes appliquées à toutes les applications depuis un point unique.
• Journalisation centralisée de tous les accès applicatifs.
• Ajout simplifié d'une nouvelle application : la procédure est standardisée et gérée par Ansible.

NGINX s'inscrit dans notre approche d'un système d'information hospitalier open source, souverain et maîtrisé, où chaque brique est déployée et documentée pour rester exploitable en autonomie par les équipes.