Séparez la publication HTTP de l'exécution de l'application et des données persistantes. Un proxy inverse peut organiser le routage et les limites, mais l'accès à l'origine, l'autorisation applicative, la capacité en amont et la récupération nécessitent chacun leurs propres contrôles.
Une requête web traverse plusieurs responsabilités
Un serveur web reçoit les requêtes HTTP et peut servir des fichiers statiques. Un processus applicatif exécute le comportement dynamique du projet, comme la vérification d'un compte ou l'interrogation d'une base de données. Un proxy inverse reçoit les requêtes pour le compte de ce processus et les transmet à un amont. Un programme peut remplir plusieurs rôles, mais séparer les responsabilités facilite le raisonnement sur la configuration et la récupération.
Suivez une requête depuis la résolution du nom d'hôte jusqu'à la réponse. Notez où se termine TLS, quel processus choisit la route et quel composant peut lire les données applicatives. Faites de même pour une requête administrative. Cet exercice révèle souvent un écouteur ou un nom d'hôte créé pour les tests et resté accessible par accident. Le schéma doit décrire le chemin déployé plutôt que l'architecture que vous espériez construire.
Utilisez la bordure pour organiser le comportement de HTTP
NGINX documente à la fois le service de contenu statique et la transmission des requêtes à un amont. Son architecture de workers et ses modules HTTP fournissent des mécanismes de configuration, mais une configuration particulière détermine toujours le comportement. Définissez délibérément les noms d'hôtes, les amonts et les racines de système de fichiers. Restreignez les fichiers pouvant être servis afin que la configuration, les identifiants et les métadonnées du dépôt ne deviennent jamais téléchargeables parce qu'ils se trouvent près de l'application.
Définissez des limites appropriées pour les corps de requête, les délais d'expiration et les connexions selon l'application. Traitez les caches comme une décision de données : le contenu lié à un utilisateur ou à une autorisation ne peut pas hériter en toute sécurité d'une règle de cache partagée sans examen. Testez ensemble l'authentification et le comportement du cache. Conservez une configuration reproductible et validez les changements avant de recharger le service, avec un chemin de retour connu vers la version fonctionnelle précédente.
| Couche | Responsabilité utile | Vérifier avant le lancement |
|---|---|---|
| Bordure web publique | TLS, routage par nom d'hôte et limites HTTP | Certificats, racines et noms d'hôtes prévus |
| Processus applicatif | Logique métier et autorisation | Authentification, contrôles des entrées et défaillance des dépendances |
| Service de données interne | État applicatif persistant | Accès restreint et restauration testée |
| Réseau du fournisseur amont | Le service réseau sous contrat | Périmètre de protection et voie d'escalade |
Un proxy inverse ne supprime pas l'exposition de l'origine
Si l'origine reste accessible publiquement, un client peut l'atteindre sans utiliser la route proxy prévue. Restreignez l'accès à l'origine via la conception du réseau et la configuration de l'application lorsque le déploiement exige cette frontière. Sur une même machine, un backend peut souvent écouter sur la boucle locale ou un socket local. Entre machines, utilisez des routes restreintes explicites et une protection adaptée pour la connexion amont.
Les en-têtes transférés nécessitent aussi une règle de confiance. Acceptez les informations sur le client d'origine uniquement de la part d'intermédiaires de confiance et empêchez des appelants arbitraires de fournir des valeurs que l'application traite comme faisant autorité. Décidez ce qui apparaît dans les journaux d'accès et les rapports d'erreur. Un proxy peut modifier les informations disponibles à chaque couche ; il n'efface pas les identifiants de compte et ne rend pas l'application anonyme pour son propre opérateur.
Appliquez les décisions d'accès à l'intérieur de l'application
L'architecture Zero Trust du NIST privilégie les décisions d'accès aux ressources plutôt qu'une confiance implicite fondée uniquement sur l'emplacement réseau. Appliquez ce principe concrètement : authentifiez l'appelant, autorisez l'opération demandée et n'accordez aux comptes de service que le périmètre dont ils ont besoin. Une requête provenant d'un sous-réseau interne ne doit pas devenir automatiquement une requête d'administrateur.
Séparez les fonctions publiques et administratives lorsque c'est possible. Revérifiez les autorisations lorsqu'un utilisateur accède à un enregistrement plutôt que de vous fier uniquement à la connexion initiale. Gardez des identifiants distincts pour le proxy, l'application et la base de données. Introduisez les changements par étapes testables, en commençant par un chemin sensible restreint. Qualifier un déploiement de Zero Trust est moins utile que de démontrer qu'une action interdite est réellement refusée au niveau du composant responsable.
Planifiez le déni de service à plusieurs niveaux
Une liaison réseau saturée et une requête applicative coûteuse échouent à des endroits différents. La limitation de débit en périphérie web peut aider à encadrer les schémas de requêtes, tandis que les limites applicatives peuvent borner des travaux tels que les recherches, les téléversements ou les exports. Le module de limitation de requêtes de NGINX fournit un mécanisme ; la clé et les seuils doivent correspondre aux utilisateurs réels et être testés pour éviter de rejeter du trafic légitime.
Les recommandations de l'OWASP sur le déni de service traitent aussi de l'épuisement des ressources dans le comportement applicatif. Encadrez les travaux coûteux par des limites de temps et de taille, utilisez des files d'attente bornées et surveillez les signaux de défaillance. Les contrôles locaux ne peuvent pas créer de capacité sur une liaison amont déjà saturée. Confirmez la protection réseau spécifique incluse dans l'offre choisie et préparez une procédure d'escalade. Ne supposez jamais qu'une protection de couche 3–4 annoncée dans un catalogue prouve aussi la protection de chaque charge de travail HTTP.
Intégrez la récupération à la publication
Vérifiez le site depuis un client externe en utilisant son nom d'hôte prévu. Contrôlez HTTPS, les redirections, les ressources statiques, les connexions et une transaction applicative représentative. Confirmez que les écouteurs administratifs et les fichiers privés restent inaccessibles. Simulez un amont arrêté et vérifiez que la périphérie renvoie une erreur contrôlée plutôt que d'exposer des détails internes ou d'attendre sans limite.
Pour Canvas, consultez les contrôles disponibles dans le compte d'hébergement. Pour un VPS, maintenez la périphérie web et l'application dans le cadre de votre propre plan d'exploitation. Un port réseau de grande capacité est une spécification de capacité, pas la preuve que l'application peut soutenir ce débit. Consignez la surveillance, la restauration et les contacts du fournisseur dans le runbook. Ne publiez qu'après avoir vérifié le chemin de requête réel et un chemin de rétablissement pratique.
Votre liste de contrôle pratique.
- Tracez une requête publique et une requête administrative.
- Définissez les racines servies et les écouteurs amont.
- Ne faites confiance aux en-têtes transférés que depuis des intermédiaires approuvés.
- Testez l'autorisation et les limites du cache.
- Préparez des limites et une escalade pour les défaillances réseau et applicatives.
Les détails qui comptent.
Un serveur web peut-il aussi servir de proxy inverse ?+
Oui. NGINX en est un exemple documenté. Ses rôles dépendent de la configuration, et l'application a toujours besoin de sa propre autorisation et de sa propre maintenance.
Un proxy inverse masque-t-il automatiquement l'origine ?+
Non. L'origine peut rester joignable si le routage, le pare-feu et les paramètres des écouteurs n'appliquent pas la frontière prévue.
La limitation de requêtes arrêtera-t-elle toutes les attaques DDoS ?+
Non. Elle traite certains schémas de requêtes HTTP. La saturation réseau et d'autres défaillances de ressources nécessitent des contrôles amont et applicatifs appropriés.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- NGINX : guide du débutant nginx.org
- NGINX : limitation de requêtes HTTP nginx.org
- NIST SP 800-207 : architecture Zero Trust nvlpubs.nist.gov
- OWASP : prévention du déni de service cheatsheetseries.owasp.org
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.