Sécuriser un load balancer cloud et la terminaison TLS

Un load balancer cloud concentre les connexions entrantes, termine souvent Transport Layer Security (TLS) et décide quels services voient le trafic. Ce point de passage améliore la disponibilité et l’observabilité, mais il devient aussi l’endroit où une mauvaise confiance dans les en-têtes, les certificats ou les journaux transforme une protection en décor de PowerPoint.

→ Lire l’explication complète de la marmotte

Terminaison TLS : le compromis entre contrôle et exposition

La terminaison TLS en périphérie déchiffre le trafic au niveau du load balancer avant de l’envoyer vers les services internes. Le gain est net : inspection applicative, règles de Web Application Firewall (WAF), limitation de débit, journalisation uniforme, renouvellement centralisé des certificats et réduction de la charge cryptographique sur les backends.

Le prix est tout aussi net : le load balancer voit le contenu en clair. Il devient un actif de sécurité de niveau élevé, pas un tuyau réseau avec une option HTTPS cochée à la va-vite. La clé privée du certificat, ou la permission de la faire utiliser par un service managé, mérite une protection équivalente à celle d’une identité d’administration.

La recommandation est de terminer TLS au load balancer, puis de rechiffrer systématiquement vers les backends avec TLS. Cette architecture donne au périmètre les moyens d’inspecter le trafic tout en empêchant une interception sur le réseau interne, les réseaux virtuels partagés n’étant pas soudainement devenus des sanctuaires parce qu’un fournisseur les appelle privés.

Le chiffrement entre load balancer et backend doit vérifier le certificat du backend. Accepter n’importe quel certificat interne pour « éviter les incidents de chaîne de confiance » supprime l’authentification serveur. Le chiffrement reste alors présent, mais un proxy interne compromis peut intercepter le trafic. C’est une serrure sans contrôle de la clé, grand classique des architectures qui se découvrent une passion tardive pour le mot zero trust.

Le passage TLS de bout en bout sans terminaison, parfois appelé passthrough, ne doit être retenu que lorsque l’application doit elle-même établir la session chiffrée : authentification mutuelle TLS (mTLS), exigences cryptographiques applicatives, ou inspection interdite par le modèle de menace. Cette option déplace les contrôles vers chaque backend et réduit fortement la capacité du WAF à analyser les requêtes HTTP (Hypertext Transfer Protocol). Elle ne constitue pas une version « plus sécurisée » par défaut, seulement une autre frontière de confiance.

La gestion des certificats dépend du fournisseur, mais les invariants restent les mêmes :

utiliser des certificats distincts par environnement et par domaine de sécurité ;
interdire l’export de clés privées lorsque le service managé le permet ;
stocker les clés exportables dans un HSM (Hardware Security Module) ou un KMS (Key Management Service) avec journalisation des usages ;
automatiser le renouvellement avant expiration et alerter sur l’échec du déploiement ;
prévoir les certificats de secours, y compris leur chaîne intermédiaire ;
désactiver TLS 1.0 et TLS 1.1, imposer TLS 1.2 au minimum et préférer TLS 1.3.

La révocation d’un certificat ne ferme pas les sessions déjà établies. Une compromission de clé impose donc la rotation du certificat, l’invalidation des mécanismes de reprise de session si le fournisseur le permet, et l’analyse des journaux d’accès sur la période d’exposition. La révocation est un filet, pas un bouton rouge magique.

Les choix de certificats, d’autorités de certification et de rotation relèvent d’une architecture PKI et TLS, pas d’une liste de paramètres propre au load balancer. Cette séparation évite de confondre un service de distribution de trafic avec une autorité de confiance.

Répartition de charge et identité réelle du client

Après terminaison TLS, le backend ne voit plus forcément l’adresse réseau du client. Il voit l’adresse du load balancer. Pour restaurer le contexte, ce dernier ajoute généralement Forwarded ou X-Forwarded-For, ainsi que X-Forwarded-Proto et parfois l’hôte demandé.

Ces en-têtes sont des données non fiables tant que le backend peut être joint autrement que par le load balancer. Un client peut envoyer son propre X-Forwarded-For et se faire passer pour une adresse interne, contourner une règle d’accès ou empoisonner les journaux. La contre-mesure n’est pas de « faire confiance au proxy », formule qui ne veut rien dire techniquement. Il faut :

autoriser les backends uniquement depuis les sous-réseaux ou groupes de sécurité du load balancer ;
supprimer les en-têtes de transfert reçus du client à la périphérie ;
réinjecter les en-têtes normalisés par le load balancer ;
configurer le framework applicatif pour ne faire confiance qu’aux relais explicitement autorisés ;
conserver dans les logs l’adresse source observée et la chaîne d’adresses transmise.

Une application qui accepte X-Forwarded-For depuis Internet possède une fonction de falsification d’identité intégrée. Elle n’est pas cachée, elle est documentée, et elle finit régulièrement activée par une option nommée trust proxy. Le nom est honnête, au moins.

La répartition de charge peut aussi rompre les hypothèses d’état applicatif. Les sessions stockées localement, l’affinité par cookie et les connexions persistantes compliquent les bascules. L’affinité ne remplace pas un stockage de session partagé : elle retarde l’incident jusqu’au redémarrage, ce qui est une stratégie de continuité assez proche de croiser les doigts avec méthode.

Pour HTTP/2 et HTTP/3, via QUIC (Quick UDP Internet Connections), vérifier la compatibilité entre le load balancer, le WAF et les outils de journalisation. Le protocole négocié par ALPN (Application-Layer Protocol Negotiation) doit être visible dans les journaux. Sans cette donnée, une anomalie limitée à HTTP/2 peut être noyée dans des métriques HTTP globales, avec toute la finesse d’un marteau dans une horlogerie.

Visibilité de sécurité après déchiffrement en périphérie

La terminaison TLS rend le contenu observable au bon endroit, à condition d’exporter les bons événements. Les journaux du load balancer doivent contenir au minimum : horodatage synchronisé, nom d’hôte demandé, protocole TLS négocié, suite cryptographique, nom du certificat sélectionné, adresse client, méthode HTTP, chemin ou son empreinte, code de réponse, latence, backend cible et identifiant de corrélation.

L’adresse IP seule ne suffit pas à attribuer une action. Derrière un réseau mobile, un proxy d’entreprise ou une passerelle de traduction, elle décrit une origine réseau approximative. L’identité authentifiée, l’identifiant de requête et le contexte de session applicatif doivent compléter la trace. La gestion des identités cloud reste donc liée à l’exposition web, même quand l’authentification est portée par une application ou une fédération externe.

Un WAF placé après terminaison TLS protège contre des classes connues d’attaques HTTP : injections, traversées de répertoires, requêtes anormalement volumineuses, signatures de scanners et abus de protocoles. Il ne valide pas la logique métier. Une règle WAF ne sait pas qu’un remboursement de 10 000 euros est suspect si la requête est syntaxiquement parfaite et autorisée par l’application. Le contrôle métier doit rester dans le service, avec autorisation explicite et journal d’audit.

La visibilité doit couvrir les refus, pas seulement les succès. Une hausse de réponses 403, d’échecs de négociation TLS, de requêtes sans Server Name Indication (SNI) ou d’erreurs 5xx peut signaler respectivement un scan, une incompatibilité client, un domaine mal configuré ou un backend en panne. SNI est l’information envoyée au début de la connexion pour indiquer le nom de domaine visé.

Exporter les journaux vers un système centralisé de SIEM (Security Information and Event Management), avec rétention alignée sur les besoins d’investigation. Protéger ces journaux contre l’altération : chiffrement au repos, droits d’écriture limités au service d’export et compte de lecture distinct. Un journal modifiable par le même rôle qui modifie les règles réseau ne constitue pas une piste d’audit, seulement un brouillon collectif.

Surface d’attaque du load balancer cloud

Le plan de contrôle cloud est la première surface d’attaque. Une identité capable de modifier un listener, un certificat, une cible backend ou une règle de routage peut détourner le trafic sans toucher aux machines. Les permissions doivent séparer création, modification des règles, association des certificats et lecture des secrets. Les droits génériques sur toutes les ressources de réseau constituent un privilège d’administration déguisé.

Les attaques par épuisement de ressources restent possibles avant même l’application : négociations TLS coûteuses, connexions lentes, volumétrie HTTP, saturation des cibles ou attaque par déni de service distribué, DDoS (Distributed Denial of Service). Combiner protection anti-DDoS du fournisseur, limitation de débit par chemin, taille maximale des en-têtes et du corps, délais de lecture et quotas applicatifs. Une limite globale trop basse fait tomber les utilisateurs légitimes avec les attaquants, ce qui est très démocratique mais rarement recherché.

Les contrôles de santé méritent une attention disproportionnée. Un endpoint de santé qui exige une authentification complexe provoque des évictions en cascade. Un endpoint qui retourne toujours 200 masque une panne métier. Il doit vérifier les dépendances critiques sans lancer de transaction destructive, et être inaccessible depuis Internet. Ne jamais exposer /health avec des diagnostics détaillés : un attaquant apprécie énormément qu’on lui fournisse l’état de chaque dépendance dans un format bien rangé.

La configuration de réseau doit interdire l’accès direct aux backends depuis Internet. Les groupes de sécurité, règles de pare-feu ou politiques réseau doivent exprimer une relation précise : load balancer vers port applicatif, administration depuis réseau d’exploitation, rien d’autre. Pour la conception des flux et de leurs points de contrôle, voir l’architecture réseau.

Exemple de terminaison TLS et rechiffrement backend

L’exemple suivant utilise HAProxy comme load balancer de périphérie. Il termine TLS pour api.example.net, normalise l’adresse client et vérifie le certificat présenté par chaque backend. Le fichier d’autorités internes doit contenir l’autorité ayant signé les certificats des services.

global
  # Désactiver les protocoles obsolètes côté client.
  ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
  mode http
  timeout connect 5s
  timeout client  30s
  timeout server  30s

frontend https_in
  bind :443 ssl crt /etc/haproxy/certs/api.example.net.pem alpn h2,http/1.1

  # Supprimer toute identité client fournie par Internet.
  http-request del-header X-Forwarded-For
  http-request del-header X-Forwarded-Proto

  # Réinjecter les valeurs observées par le frontal.
  http-request set-header X-Forwarded-For %[src]
  http-request set-header X-Forwarded-Proto https
  http-request set-header X-Request-ID %[unique-id]

  default_backend api_nodes

backend api_nodes
  # Vérifier la chaîne, puis le nom DNS attendu sur le certificat backend.
  server api1 10.20.1.11:8443 ssl verify required \
    ca-file /etc/haproxy/ca/internal-ca.pem verifyhost api.internal.example.net
  server api2 10.20.1.12:8443 ssl verify required \
    ca-file /etc/haproxy/ca/internal-ca.pem verifyhost api.internal.example.net

Tester la vérification depuis un nœud autorisé avec openssl s_client, en imposant le nom attendu. Un certificat valide pour un autre nom doit échouer, sinon la vérification ne protège pas contre une redirection interne.

# Le nom demandé et le nom vérifié doivent correspondre au certificat backend.
openssl s_client -connect 10.20.1.11:8443 \
  -servername api.internal.example.net \
  -verify_hostname api.internal.example.net \
  -CAfile /etc/haproxy/ca/internal-ca.pem </dev/null

Exploitation : rotation, supervision et reprise

La rotation des certificats doit être testée avec des connexions persistantes et des backends hétérogènes. Les nouvelles connexions reçoivent le nouveau certificat, les anciennes peuvent continuer avec l’ancien jusqu’à expiration ou fermeture. Réduire brutalement les délais de session pendant une rotation limite cette coexistence, mais augmente la charge de négociation.

Superviser quatre couches distinctes : disponibilité du listener, succès des négociations TLS, santé des backends et taux de réponses applicatives. Une sonde qui ne teste que le port 443 confirme qu’un socket écoute. Elle ne confirme ni le certificat, ni le routage, ni l’autorisation, ni le contenu servi. C’est mieux que rien, donc insuffisant.

Sauvegarder la configuration déclarative, les politiques WAF, les associations de certificats, les règles de routage et les listes d’autorisation. Les clés privées ne doivent pas être restaurées depuis une archive non contrôlée : restaurer leur référence KMS ou HSM et vérifier les droits d’utilisation. Une reprise qui réassocie un certificat mais oublie sa politique d’accès produit parfois un service indisponible, parfois un certificat utilisable par trop de rôles. Les deux variantes méritent d’être évitées.

🐝 Ce qui arrive si on s’en passe

Sans configuration soignée du point de terminaison, le répartiteur qui concentre les connexions et termine TLS distribue les problèmes aussi efficacement que le trafic. S’il fait confiance aveuglément aux en-têtes entrants, un client peut usurper son adresse source ou son identité via un X-Forwarded-For forgé, contournant des contrôles d’accès et faussant les journaux dont dépend toute la traçabilité. Une terminaison TLS mal gérée laisse le segment en clair entre la périphérie et les services exposé à l’écoute, et un certificat mal vérifié ouvre la porte à un intermédiaire actif. Comme ce point voit et route tout le trafic, une erreur de confiance s’y répercute partout d’un coup : ce qui devait être une protection centralisée devient un point unique où une fuite ou une usurpation contamine l’ensemble des services situés derrière.

🦫 Explication de la marmotte 🍫

Un répartiteur de charge reçoit les connexions venant d’Internet avant les applications. Lorsqu’une personne ouvre un site sécurisé, son navigateur vérifie le certificat numérique présenté par ce répartiteur, puis crée une communication chiffrée avec lui. Le répartiteur peut alors lire la demande, appliquer des règles de filtrage, enregistrer les informations nécessaires et choisir quel serveur doit répondre.

Après ce contrôle, la demande doit être chiffrée une seconde fois entre le répartiteur et le serveur choisi. Le serveur présente aussi un certificat numérique, que le répartiteur doit vérifier. Sans cette vérification, un serveur frauduleux placé sur le réseau interne pourrait recevoir les données.

Le répartiteur transmet l’adresse de la personne qui a fait la demande dans un en-tête. Le serveur ne doit accepter cet en-tête que s’il provient bien du répartiteur, car un visiteur malveillant peut inventer sa propre adresse dans une demande directe.

Si le certificat expire, si sa clé est compromise ou si le répartiteur tombe en panne, les connexions peuvent échouer avant d’atteindre l’application. Il faut donc renouveler les certificats, surveiller les erreurs de connexion, sauvegarder les règles de filtrage et empêcher tout accès direct aux serveurs internes. Le filtrage bloque des attaques connues, mais il ne remplace pas les contrôles d’accès et les vérifications réalisées par l’application elle-même.

Pages voisines

La citent

Sécuriser un load balancer cloud et la terminaison TLS

Elle cite

Sécuriser un load balancer cloud et la terminaison TLS

Sécuriser un load balancer cloud et la terminaison TLS

Terminaison TLS : le compromis entre contrôle et exposition

Répartition de charge et identité réelle du client

Visibilité de sécurité après déchiffrement en périphérie

Surface d’attaque du load balancer cloud

Exemple de terminaison TLS et rechiffrement backend

Exploitation : rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines