Terminaison SSL et sessions persistantes

La terminaison SSL/TLS signifie que l’équilibreur de charge déchiffre le trafic HTTPS entrant, inspecte la requête HTTP en clair (pour prendre les décisions de routage), puis peut éventuellement chiffrer à nouveau la requête avant de la transmettre au serveur principal. Lorsque la terminaison a lieu au niveau de l’ALB, vos serveurs d’application peuvent recevoir du trafic HTTP non chiffré depuis l’équilibreur de charge, ce qui simplifie la configuration du serveur principal.

La terminaison au niveau de l’équilibreur de charge réduit la charge du processeur sur les serveurs d’application (aucune négociation TLS par connexion), permet le routage basé sur le contenu (qui nécessite la lecture des en-têtes HTTP) et centralise la gestion des certificats.

AWS Certificate Manager (ACM) fournit, gère et renouvelle les certificats SSL/TLS sans frais supplémentaires. ALB et NLB s’intègrent directement à ACM : vous sélectionnez un certificat ACM dans la configuration de l’écouteur HTTPS, puis l’équilibreur de charge le présente aux clients qui se connectent.

Les certificats ACM sont renouvelés automatiquement avant leur expiration : aucun renouvellement manuel et aucune interruption due à des certificats expirés. Pour les certificats publics, ACM valide la propriété du domaine au moyen d’une validation DNS (enregistrement CNAME dans Route 53) ou d’une validation par e-mail. Pour un usage interne, ACM Private CA peut émettre des certificats privés.

SNI (Server Name Indication) est une extension TLS qui permet à une seule adresse IP (et donc à un seul écouteur ALB ou NLB) de servir plusieurs certificats TLS pour différents noms de domaine. Le client inclut le nom d’hôte qu’il tente d’atteindre dans le message TLS ClientHello, puis l’équilibreur de charge sélectionne le certificat approprié.

ALB prend nativement en charge SNI : vous pouvez associer plusieurs certificats ACM à un seul écouteur HTTPS. L’ALB sélectionne automatiquement le certificat approprié en fonction du nom d’hôte SNI du client. Cela élimine le besoin d’un écouteur ou d’un équilibreur de charge distinct pour chaque domaine et permet un véritable hébergement virtuel avec SSL.

ALB et NLB prennent en charge des politiques de sécurité SSL configurables qui déterminent les versions du protocole TLS et les suites de chiffrement acceptées par l’équilibreur de charge depuis les clients. AWS fournit des politiques prédéfinies (par exemple, ELBSecurityPolicy-TLS13-1-2-2021-06) qui sont mises à jour lorsque de nouvelles vulnérabilités sont découvertes.

Les exigences de conformité peuvent imposer certaines versions de TLS : PCI-DSS 3.2.1 exige au minimum TLS 1.2 ; de nombreuses normes modernes recommandent de désactiver entièrement TLS 1.0 et 1.1. Utilisez une politique qui exclut les protocoles obsolètes et les suites de chiffrement faibles. Privilégiez les politiques qui incluent TLS 1.3 pour assurer la confidentialité persistante et de meilleures performances.

Deux approches TLS distinctes sont possibles avec ALB :

• Terminaison SSL (la plus courante) : ALB déchiffre le trafic au niveau de l’équilibreur de charge, puis transmet du HTTP en clair aux cibles. Cette approche est simple, permet l’inspection nécessaire au routage et réduit la charge du processeur des serveurs. Le trafic entre le serveur principal et les cibles n’est pas chiffré au sein du VPC.
• TLS de bout en bout : ALB déchiffre le trafic, puis le chiffre à nouveau avant de le transmettre aux cibles (HTTPS entre ALB et la cible). Cette approche consomme davantage de ressources processeur et nécessite des certificats sur les cibles, mais garantit le chiffrement au sein du VPC pour les scénarios soumis à des exigences de conformité strictes.

En mode de transmission TLS directe avec NLB : NLB ne déchiffre rien et transmet le TCP brut à la cible, qui prend en charge TLS. Le serveur d’application gère son propre certificat.

Les sessions persistantes (également appelées affinité de session) garantissent que toutes les requêtes d’un même client sont systématiquement acheminées vers la même cible au sein d’un groupe cible. Cela est nécessaire pour les applications avec état qui stockent les données de session en mémoire sur des serveurs individuels (plutôt que dans un cache partagé comme ElastiCache).

Sans sessions persistantes, un équilibreur de charge sans état peut envoyer la requête 1 au serveur A (qui stocke la session), puis la requête 2 au serveur B (qui ne possède aucune donnée de session). L’utilisateur peut alors sembler déconnecté ou perdre le contenu de son panier. Les sessions persistantes associent un client à une cible donnée pendant toute la durée de la session.

ALB prend en charge deux types de cookies de session persistante :

• Persistance fondée sur la durée (cookie généré par LB) : ALB génère un cookie nommé AWSALB (pour ALB) et définit une durée d’expiration. Le cookie contient une référence chiffrée vers la cible. Le client envoie ce cookie lors des requêtes suivantes.
• Persistance fondée sur l’application : utilise un cookie existant défini par votre application. ALB lit le nom du cookie que vous indiquez, en génère une version chiffrée dans son propre cookie et l’utilise pour le routage persistant tout en conservant le cookie d’origine de l’application.

Configurez la persistance pour chaque groupe cible, avec une durée comprise entre 1 seconde et 7 jours.

Bien que les sessions persistantes résolvent le problème des applications avec état, elles présentent certains compromis :

• Répartition inégale de la charge : certaines cibles peuvent recevoir davantage de trafic si certains clients sont exceptionnellement actifs, ce qui va à l’encontre de l’objectif de l’équilibrage de charge
• Limites de la mise à l’échelle : si une cible persistante devient défaillante, les sessions sont interrompues : le client doit démarrer une nouvelle session avec une nouvelle cible et perd les données de session conservées en mémoire
• Élasticité réduite : les sessions persistantes compliquent la mise hors service et la fin des instances lors des opérations de réduction de capacité

Bonne pratique : éliminez le besoin de sessions persistantes en externalisant l’état des sessions vers ElastiCache ou DynamoDB. Votre application devient ainsi véritablement sans état et peut effectuer une mise à l’échelle horizontale complète.

NLB prend en charge les écouteurs TLS sur le port 443 (ou sur n’importe quel port) pour la terminaison TLS, comme ALB. NLB déchiffre le trafic, le rechiffre éventuellement, puis le transmet aux cibles. NLB peut également transmettre directement le trafic TCP chiffré sans le déchiffrer si vous configurez un écouteur TCP : dans ce mode, le serveur d’application gère TLS de bout en bout.

La terminaison TLS de NLB avec ACM offre les mêmes avantages de gestion des certificats qu’ALB, mais sans les fonctionnalités de la couche HTTP. Utilisez la terminaison TLS de NLB lorsque vous avez besoin d’adresses IP statiques avec terminaison TLS ou lorsque votre protocole principal n’est pas HTTP (par exemple, un protocole TCP personnalisé).

Lorsqu’une cible persistante est désenregistrée (par exemple, pendant une réduction de capacité d’Auto Scaling), la fermeture progressive des connexions permet aux requêtes en cours de se terminer. Toutefois, les nouvelles requêtes des clients persistants qui détiennent encore le cookie AWSALB de la cible en cours de retrait sont automatiquement attribuées à une nouvelle cible : le cookie de persistance est invalidé pour ce client.

Cette combinaison du délai de désenregistrement et de l’invalidation du cookie assure des transitions progressives : les requêtes existantes de longue durée se terminent, tandis que les nouvelles requêtes de ces clients sont réacheminées sans heurt vers des cibles saines, sans apparaître comme des erreurs pour l’utilisateur final.

Bonnes pratiques importantes pour l’examen :

• Utilisez des certificats ACM pour le renouvellement automatique : ne gérez jamais manuellement les certificats sur les équilibreurs de charge
• Utilisez des politiques de sécurité TLS 1.2+ et désactivez TLS 1.0/1.1 pour respecter PCI/HIPAA
• Privilégiez les architectures sans état (session dans ElastiCache/DynamoDB) plutôt que les sessions persistantes
• Utilisez SNI sur ALB pour servir plusieurs domaines depuis un seul écouteur, sans plusieurs certificats sur des équilibreurs de charge distincts
• Pour une conformité stricte (les données du VPC doivent être chiffrées) : utilisez des groupes cibles HTTPS avec TLS de bout en bout, et pas uniquement une terminaison au niveau de l’équilibreur de charge

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : la terminaison SSL/TLS d’ALB avec des certificats ACM assure le renouvellement automatique et SNI pour plusieurs domaines ; les politiques de sécurité SSL contrôlent la version de TLS et les suites de chiffrement pour la conformité ; et les sessions persistantes acheminent les utilisateurs vers la même cible pour les applications avec état, mais sont idéalement remplacées par l’externalisation de l’état des sessions vers ElastiCache. Nous allons maintenant étudier les groupes Auto Scaling et les modèles de lancement.