Une politique de sécurité du point d'entrée est la liste écrite de ce que vous autorisez, de ce que vous refusez, et de ce que vous refusez sans qu'on vous le demande. Le point d'entrée est le service qui reçoit les requêtes des clients, le plus souvent un reverse proxy (un serveur placé devant vos applications qui reçoit les requêtes à leur place). Cette leçon vous apprend à décider avant d'écrire la moindre directive : qui a le droit d'appeler quelle route, à quel rythme, en qui l'on a confiance, et ce qui ne doit jamais atteindre le disque. Elle s'adresse à un débutant qui a déjà publié un service et veut le protéger.
La leçon enseigne la politique, pas la syntaxe d'un produit. Cette syntaxe vit dans les guides d'outil : Protéger le point d'entrée Traefik, Protéger et observer Nginx et Protéger et observer HAProxy. Ces pages disent comment écrire une règle ; celle-ci dit laquelle écrire, et comment vérifier qu'elle tient.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Écrire une politique par route, avec un refus par défaut, avant de choisir une directive.
- Distinguer authentification, autorisation, filtrage et limitation de débit.
- Décider à quelles adresses un en-tête d'identité est cru.
- Fermer l'accès direct à l'application, qui contourne tout le reste.
- Choisir ce que le journal efface, sans le rendre muet.
- Vérifier une politique par le statut et le corps des réponses.
Prérequis
Section intitulée « Prérequis »Cette leçon suppose que vous savez publier un service derrière un point d'entrée et lire un échange HTTP. Elle ne réexplique pas ces gestes.
- Lire un échange HTTP : méthode, chemin, en-têtes, code de statut.
- Relier interfaces, ports, pare-feu et exposition : savoir depuis quel réseau un port est joignable.
Pourquoi écrire une politique avant une configuration ?
Section intitulée « Pourquoi écrire une politique avant une configuration ? »Une configuration dit ce que l'outil fait ; une politique dit ce que vous voulez qu'il fasse, et la seconde doit exister avant la première. Une directive de sécurité peut être présente et ne rien protéger : elle peut viser un préfixe qui ne correspond à aucune route, ou protéger une porte que l'on contourne par une autre. Écrire d'abord la politique, c'est se donner une référence pour juger la configuration.
Une politique tient en cinq questions, posées route par route. Qui a le droit d'appeler cette route ? En qui fait-on confiance pour le dire ? Par où peut-on arriver ? À quel rythme ? Que garde-t-on de l'échange ? Le reste de la leçon répond à chacune. Un backend est l'application que le point d'entrée appelle derrière lui ; il ne doit pas être joint directement par un client externe.
| Question | Décision à écrire |
|---|---|
| Qui a le droit ? | Une identité exigée par route, refus par défaut |
| En qui a-t-on confiance ? | La liste des adresses qui peuvent poser une identité |
| Par où arrive-t-on ? | Un seul chemin, celui du point d'entrée |
| À quel rythme ? | Un plafond de requêtes par appelant |
| Que garde-t-on ? | Les en-têtes secrets effacés du journal |
Qui a le droit d'appeler quelle route ?
Section intitulée « Qui a le droit d'appeler quelle route ? »Le droit d'appeler une route se décide route par route, avec une identité
exigée pour chacune et un refus pour tout le reste. Prenez un service qui
publie trois routes : / est publique, /compte est réservée à un
utilisateur connecté, /admin à l'administration. Trois routes, trois
exigences différentes, et une quatrième décision que l'on oublie souvent : que
répond le point d'entrée à une route que personne n'a prévue ?
Deux mots à ne pas confondre. L'authentification répond à « qui êtes-vous
? » : elle vérifie une identité, par exemple un jeton présenté dans l'en-tête
Authorization. L'autorisation répond à « avez-vous le droit de faire
cela ? » : un utilisateur authentifié n'a pas pour autant accès à
l'administration. Les codes de statut HTTP suivent cette distinction, avec une
nuance que la RFC 9110 prend soin de poser. 401 signifie que la requête ne
porte pas d'identifiants valides : ils sont absents, mais aussi expirés ou
erronés, et la réponse doit alors porter un en-tête WWW-Authenticate qui
indique comment s'authentifier. 403 signifie que le serveur a compris la
requête et refuse de l'exécuter : le plus souvent parce que l'identité est
reconnue sans droit suffisant, mais un refus peut aussi n'avoir aucun rapport
avec l'identité, par exemple une adresse source non autorisée.
| Route | Anonyme | Utilisateur | Administrateur |
|---|---|---|---|
/ | autorisé | autorisé | autorisé |
/compte | refusé (401) | autorisé | autorisé |
/admin | refusé (401) | refusé (403) | autorisé |
Ce tableau est la politique, avant tout outil. Lisez-le comme un contrat : il fixe aussi ce qui doit continuer de marcher. Une politique qui refuse tout le monde satisfait tous les refus et supprime le service ; c'est une panne, pas une protection. Le principe du moindre privilège s'applique ici : chaque identité reçoit le strict nécessaire, rien de plus.
Reste le refus par défaut. Une route que la politique ne nomme pas doit
être refusée, pas ouverte. Dans le sens inverse, la règle oubliée est un
trou : le jour où quelqu'un publie /export, rien ne l'arrête. Pour les
routes d'administration, on ajoute souvent un filtrage par adresse source
(n'accepter que les réseaux de l'équipe), qui complète l'authentification
sans la remplacer. Un appelant refusé pour son adresse reçoit un 403 même
s'il est anonyme, puisque ce refus ne dépend pas de son identité ; le tableau
ci-dessus suppose une adresse autorisée.
À qui faire confiance pour dire qui appelle ?
Section intitulée « À qui faire confiance pour dire qui appelle ? »Un en-tête d'identité n'est cru que s'il est posé par un proxy dont vous
avez écrit l'adresse dans la politique. Beaucoup d'architectures déchargent
l'authentification sur un composant amont, qui transmet le résultat à
l'application dans un en-tête, par exemple X-Identite: admin. Le problème
est qu'un en-tête est du texte : n'importe quel client peut l'écrire.
Si l'application croit tout en-tête X-Identite, un appelant anonyme envoie
X-Identite: admin et devient administrateur sans jeton. C'est un en-tête
forgé. La parade est une liste de proxys de confiance : les adresses
dont on accepte l'en-tête. Un en-tête venu d'une autre adresse est ignoré ou
rejeté, comme s'il était absent.
Le même raisonnement vaut pour l'adresse du client. Un proxy placé derrière
un autre ne voit que l'adresse de celui qui le précède ; l'adresse d'origine
voyage dans l'en-tête X-Forwarded-For, que le client peut aussi forger.
On ne lit donc cet en-tête que depuis des proxys explicitement listés. Même
venu d'un proxy de confiance, seule l'adresse que ce proxy a ajoutée est
fiable : la chaîne qui la précède ne l'est pas (RFC 7239, §8.1). La page
Protéger le point d'entrée Traefik
applique la même prudence à ipAllowList derrière un proxy amont.
Un réseau privé n'est pas une preuve de confiance universelle. Une adresse interne dit où se trouve l'appelant, pas qui il est ni ce qu'il a fait de sa machine. Listez des adresses précises, jamais « tout le réseau interne » par paresse.
Comment empêcher le contournement du point d'entrée ?
Section intitulée « Comment empêcher le contournement du point d'entrée ? »Une politique posée devant une porte que l'on peut contourner ne protège rien, donc il faut fermer l'accès direct à l'application. C'est un contournement courant et silencieux : le point d'entrée filtre, mais l'application écoute aussi sur son propre port, joignable depuis le réseau des clients. Un appelant qui connaît ce port ignore le point d'entrée et ses règles.
Deux gestes ferment cette porte, et les deux sont valables. Le premier est de
lier l'application à la boucle locale : elle n'écoute plus que sur
127.0.0.1, adresse qui ne répond qu'à la machine elle-même, donc seul un
proxy placé sur la même machine l'atteint. Le second est de refuser le port
depuis l'extérieur par une règle de pare-feu. Le premier a l'avantage de
ne dépendre d'aucune règle qu'on puisse effacer par erreur : tant que le noyau
garde son réglage par défaut (route_localnet à 0), une application liée à
127.0.0.1 n'est joignable que depuis l'hôte. C'est un avis de prudence, pas
une règle absolue : certaines configurations de conteneur activent
route_localnet, et le pare-feu redevient alors indispensable.
Vérifiez toujours depuis un autre poste. Un test lancé sur la machine elle-même passe par la boucle locale et réussit même quand le port est ouvert au réseau ; la leçon Relier interfaces, ports, pare-feu et exposition explique pourquoi. Le contournement par en-tête forgé de la section précédente est le second chemin de la même famille : on évite la règle au lieu de la franchir.
Quel rythme de requêtes tolérer ?
Section intitulée « Quel rythme de requêtes tolérer ? »La limitation de débit plafonne le nombre de requêtes qu'un appelant peut envoyer sur une période, pour freiner les abus sans gêner l'usage normal. Elle répond à deux risques : les essais répétés de mots de passe (le bourrage d'identifiants, détaillé dans Attaques sur les identifiants et le réseau) et l'épuisement d'une application par un appelant trop zélé.
Trois décisions se prennent. Le seuil : trop bas, il bloque des utilisateurs normaux ; trop haut, il ne protège presque rien. On le fixe à partir du trafic légitime observé, pas au jugé. La clé : le plafond se compte par adresse, par jeton ou par route, mais jamais par une valeur que le client choisit lui-même, car il en changerait à chaque requête et remettrait le compteur à zéro. Les routes sensibles : une route de connexion mérite un plafond bien plus serré que la page d'accueil.
Une limite ne se confond pas avec la protection contre le déni de service (une attaque qui submerge un service pour le rendre indisponible). Un plafond posé sur un seul serveur freine un client trop actif ; il ne sauve pas un lien réseau saturé par des milliers de sources. Il y a aussi les limites de forme : taille maximale d'une requête, durée maximale d'un échange, connexions lentes qui monopolisent des ressources. La politique les nomme, les pages d'outil donnent les directives. Le lab de cette leçon, lui, ne mesure pas le débit : il se concentre sur les accès, la confiance et les journaux.
Quoi écrire, et quoi ne jamais écrire, dans les journaux ?
Section intitulée « Quoi écrire, et quoi ne jamais écrire, dans les journaux ? »Un journal doit garder de quoi comprendre un incident, et jamais de quoi
rejouer une session. Le point d'entrée voit passer des identifiants :
l'en-tête Authorization porte un jeton ou un mot de passe, l'en-tête
Cookie porte une session. Si le journal les copie, ces secrets restent
lisibles sur le disque aussi longtemps que le journal vit, et aussi longtemps
que ses sauvegardes.
La politique liste donc les en-têtes à effacer avant écriture : on les
remplace par une marque (par exemple [efface]) au lieu de les copier. On
garde le reste : date, route, statut, adresse source. Même vigilance pour tout
fichier dérivé, tel qu'un résumé ou un export : un secret recopié dans un
résumé reste un secret en clair.
L'excès inverse est aussi une faute. Un journal vide protège tous les secrets et n'aide plus personne le jour où il faut comprendre une intrusion. Effacer n'est pas ne rien journaliser. La même logique vaut pour les en-têtes de sécurité de la réponse (HSTS, politique de contenu) : ils protègent le navigateur du client, ils se règlent selon l'application, et un réglage trop strict casse des ressources légitimes. Leur détail est dans les pages d'outil.
Comment prouver que la politique tient ?
Section intitulée « Comment prouver que la politique tient ? »Une politique se prouve par ce que le service répond à de vraies requêtes, jamais par ce que le fichier de configuration déclare. Un fichier peut nommer une règle que l'outil n'applique à rien : un préfixe mal écrit, un chemin qui ne correspond à aucune route. La seule preuve est d'envoyer la requête, depuis un poste indépendant, et de lire la réponse.
Lisez deux choses, pas une : le statut et le corps. Un 403 dont le
corps contient la page d'administration a refusé pour la forme et fuit quand
même. À l'inverse, un 200 qui renvoie la page publique sur /admin n'est pas
une fuite, alors qu'un 200 qui renvoie le contenu d'administration en est une.
Le statut seul ne les distingue pas. Repérez donc, dans chaque page, une
phrase qui lui est propre (une marque) et cherchez-la dans le corps.
Une preuve complète associe quatre contrôles :
- Le légitime passe. Chaque identité autorisée obtient son contenu. C'est l'ancrage : refuser tout le monde satisferait les autres contrôles en supprimant le service.
- Les routes sensibles refusent, et le corps du refus ne porte pas le contenu protégé.
- Aucun contournement ne réussit : ni l'accès direct à l'application, ni l'en-tête d'identité forgé.
- Aucun secret semé ne survit. On envoie une valeur sentinelle (une
chaîne unique, tirée au hasard) dans
CookieetAuthorization, puis on la cherche dans le journal. On vérifie aussi que le journal n'est pas vide.
Les deux moitiés d'un contrôle comptent ensemble. « Le service marche » est vrai avant toute politique ; « les refus fonctionnent » est vrai si tout est fermé. Seule leur conjonction prouve quelque chose.
Mettre en pratique
Section intitulée « Mettre en pratique »Le lab publie trois routes, /, /compte et /admin, servies par un
garde paramétrable qui applique à la lettre un fichier de politique, vide
au départ : tout passe, tout en-tête d'identité est cru, le journal conserve tout. Vous
écrivez la politique avec trois clés : les identités exigées par préfixe de
route, les proxys_de_confiance et les en-têtes à effacer sous
journal.effacer. Vous fermez aussi l'accès direct au port de l'application.
La validation envoie de vraies requêtes depuis un client indépendant, lit
statut et corps, et cherche une valeur sentinelle dans le journal et le
dossier. Elle ne mesure ni limitation de débit ni en-têtes de réponse.
À retenir
Section intitulée « À retenir »Ces points résument les décisions de la politique, indépendamment de l'outil.
- Une politique s'écrit route par route, avec une identité exigée et un refus par défaut.
- 401 dit « pas d'identifiants valides » (la réponse porte alors
WWW-Authenticate), 403 dit « compris, mais refusé » : le plus souvent une identité reconnue sans droit suffisant, parfois un refus sans rapport avec l'identité, comme une adresse source non autorisée. Authentification et autorisation sont deux questions. - Un en-tête d'identité n'est cru que depuis un proxy de confiance listé ; sinon, il est forgeable.
- Fermer l'accès direct (boucle locale ou pare-feu) est indispensable : sans cela, la politique se contourne.
- Un plafond de débit se règle sur le trafic légitime et ne remplace pas la défense contre un déni de service volumétrique.
- Le journal efface les secrets sans devenir muet.
- On prouve par statut et corps de vraies requêtes, avec le légitime et le refus ensemble.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Le quiz vérifie les décisions de la politique et la façon de prouver qu'elles tiennent.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Maîtriser délais, tentatives et cache sans altérer les réponses
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications