Présentation

La sécurisation des communications sur Internet repose en grande partie sur le protocole SSL/TLS, qui garantit l'intégrité et la confidentialité des données échangées entre un client et un serveur. Parmi les stratégies clés pour gérer efficacement ce chiffrement se trouve la terminaison SSL, un procédé où le chiffrement d'une connexion est interrompu à un point défini du réseau. Ce point de terminaison est souvent un équilibreur de charge ou un proxy inverse, qui prend en charge le déchiffrement des données, libérant ainsi les serveurs d'application de cette charge de travail. L'offloading SSL, quant à lui, étend cette fonction en déléguant non seulement le déchiffrement mais aussi d'autres tâches de traitement du trafic réseau. Ces techniques sont essentielles pour améliorer les performances des serveurs et pour gérer les certificats SSL de manière centralisée, tout en assurant la sécurité des données utilisateur.

Fonctionnement

La terminaison SSL est un mécanisme réseau qui intervient à la frontière entre Internet et le réseau interne d'une organisation. Concrètement, elle se produit lorsqu'un équilibreur de charge, un pare-feu d'application web (WAF) ou un reverse proxy intercepte le trafic chiffré SSL/TLS venant d'un client externe. À ce point, le dispositif procède au déchiffrement des données en utilisant la clé privée associée au certificat SSL/TLS. Ce processus permet aux données de continuer leur chemin en clair ou rechiffrées au sein du réseau interne jusqu'au serveur d'application.

sequenceDiagram participant C as Client participant P as Reverse Proxy participant S as Service C->>P: Requête HTTPS P->>C: Handshake SSL/TLS P->>P: Décryptage de la requête P->>S: Requête HTTP S->>P: Réponse HTTP P->>P: Chiffrement de la réponse P->>C: Réponse HTTPS

Cette opération se déroule typiquement dans des environnements où le volume de trafic est conséquent ou où les inspections et manipulations du trafic sont nécessaires pour des raisons de sécurité ou de performances. La terminaison SSL permet alors de réduire la charge sur les serveurs d'application, qui n'ont plus à gérer le coût en ressources du chiffrement et du déchiffrement, tout en centralisant la gestion des certificats SSL/TLS, simplifiant ainsi les opérations de maintenance et de renouvellement.

Dans l'écosystème de Kubernetes, la terminaison SSL est souvent gérée par l'Ingress Controller, une composante qui régule le trafic entrant destiné aux applications tournant dans le cluster. Lorsqu'une requête HTTPS arrive, l'Ingress Controller, configuré avec le certificat SSL/TLS adéquat, s'occupe du processus de terminaison en décryptant la requête avant de la router vers le service approprié à l'intérieur du cluster. Ce service reçoit alors la requête en HTTP clair, ce qui lui permet de se concentrer sur le traitement de la requête sans la surcharge liée au déchiffrement SSL/TLS.

Ré-encryption

Une fois l'offloading SSL effectué, le trafic est souvent ré-encrypté avant de poursuivre sa route vers les serveurs d'application. Cette étape de ré-encryption est essentielle dans les cas où la sécurité de bout en bout est une exigence, notamment pour les données sensibles qui doivent rester chiffrées pendant tout leur transit à travers le réseau interne.

sequenceDiagram participant C as Client participant P as Reverse Proxy participant S as Service C->>P: Requête HTTPS P->>C: Handshake SSL/TLS P->>P: Dé-chiffrement de la requête P->>P: Chiffrement de la requête P->>S: Requête HTTPS S->>P: Réponse HTTPS P->>P: Dé-chiffrement de la réponse P->>P: Chiffrement de la réponse P->>C: Réponse HTTPS

La ré-encryption sert plusieurs objectifs critiques. Premièrement, elle renforce la confidentialité des données en garantissant que les données demeurent chiffrées même au sein d'un réseau considéré comme sécurisé. Cela crée une couche de sécurité supplémentaire contre les écoutes indiscrètes ou les fuites de données potentielles en cas de compromission du réseau interne. Deuxièmement, dans les architectures distribuées où les services peuvent être hébergés sur des infrastructures multiples, souvent géographiquement dispersées, la ré-encryption assure que les données restent chiffrées durant leur transfert entre différents domaines de confiance.

La ré-encryption après offloading est également une réponse aux exigences réglementaires et aux politiques de conformité qui dictent que les données doivent être chiffrées à chaque étape de leur traitement. En somme, elle permet de concilier les impératifs de performance apportés par l'offloading SSL avec les nécessités de sécurité et de conformité imposées par la gestion des données sensibles.

Entre le déchiffrement et le re-chiffrement des données, une série de processus critiques peuvent être exécutés pour améliorer la sécurité et la fonctionnalité de l'application. Ces processus comprennent :

  • Inspection de Contenu : Les pare-feu d'applications web (WAF) peuvent examiner le contenu des messages pour détecter des modèles malveillants ou inappropriés, tels que les tentatives d'injections SQL ou de cross-site scripting (XSS).
  • Filtrage et Contrôle d'Accès : Des règles peuvent être appliquées pour contrôler l'accès basé sur des adresses IP, des plages d'adresses, ou d'autres critères spécifiques à la requête.
  • Gestion des Sessions : Les données de session peuvent être extraites ou ajoutées pour gérer l'état de la session utilisateur lors du passage à travers le système de ré-encryption.
  • Load Balancing Intelligent : Les décisions sur la distribution de la charge peuvent être prises en fonction du contenu de la requête, permettant un routage plus intelligent vers les serveurs ou les services les plus appropriés.
  • Transformation des Données : La modification des données de la requête, telles que la transformation de formats, l'ajout ou la suppression d'en-têtes, ou l'ajustement de la charge utile, peut être nécessaire pour correspondre aux attentes des services en aval.
  • Compression et Optimisation : Les données peuvent être compressées pour une transmission plus efficace ou optimisées pour la mise en cache et la livraison accélérée du contenu.

Ci-dessous un exemple d'inspection de la requête et de la réponse par un firewall:

sequenceDiagram participant C as Client participant P as Reverse Proxy participant F as Web Application<br/>Firewall participant S as Service C->>+P: Requête HTTPS P->>P: Déchiffrement SSL P->>+F: Requête HTTP F->>F: Inspection de la requête F->>-P: Requête HTTP P->>P: Chiffrement SSL P->>+S: Requête HTTPS ré-encryptée S->>-P: Réponse HTTP P->>P: Déchiffrement SSL P->>+F: Réponse HTTP F->>F: Inspection de la réponse F->>-P: Réponse HTTP P->>P: Chiffrement SSL P->>+C: Réponse HTTPS ré-encryptée

Chacun de ces processus tire parti de l'accès aux données déchiffrées pour effectuer des opérations qui ne seraient pas possibles si les données étaient chiffrées, ajoutant ainsi une valeur significative avant que les données ne soient rechiffrées et envoyées à leur destination finale.

Environnement Kubernetes

Dans le cadre de Kubernetes, la méthode privilégiée pour exposer des services situés dans un namespace spécifique vers l'extérieur est l'utilisation d'un Ingress Controller. Ce composant agit comme un reverse proxy ou un load balancer au niveau de l'application, gérant le trafic entrant selon des règles définies par des ressources Ingress. L'Ingress Controller offre une abstraction qui permet de définir facilement le routage du trafic HTTP et HTTPS vers les services du cluster, en se basant sur l'URL demandée, le chemin d'accès ou l'hôte.

Même dans un contexte où l'Ingress Controller est utilisé pour la terminaison SSL, il peut y avoir des cas où la ré-encryption est avantageuse. Par exemple, pour les organisations qui traitent des données sensibles ou doivent se conformer à des réglementations strictes de protection des données, la ré-encryption du trafic après la terminaison SSL assure que les données restent chiffrées sur l'ensemble de leur trajet à travers le réseau interne du cluster. Cela crée une couche de sécurité supplémentaire, protégeant contre les failles potentielles de sécurité au sein du réseau interne et assurant que les données sensibles ne sont jamais transmises en clair entre les composants internes de l'infrastructure.

SSL Passthrough

Contrairement à la terminaison SSL et à l'offloading, le SSL Passthrough est une technique qui permet au trafic chiffré de traverser l'Ingress Controller ou le load balancer sans être décrypté. Cette méthode est utilisée lorsque la sécurité de bout en bout est une priorité absolue, car elle assure que le trafic reste entièrement chiffré de l'expéditeur au destinataire final.

Avec le SSL Passthrough, le rôle de l'Ingress Controller se limite à acheminer le trafic sans intervenir dans le processus de chiffrement. Les serveurs d'application doivent donc être équipés pour gérer le chiffrement SSL/TLS eux-mêmes, ce qui inclut la gestion des certificats et des clés privées, ainsi que le surcoût en performance lié au déchiffrement et au rechiffrement des données.

Bien que le SSL Passthrough puisse augmenter la charge sur les serveurs d'application, cette méthode est privilégiée dans des situations où la sécurité ne peut être compromise. En particulier, elle est pertinente pour les applications traitant des données réglementées ou hautement confidentielles, pour lesquelles même le risque minime associé au déchiffrement des données sur l'Ingress Controller doit être évité.

En définitive, le SSL Passthrough est une stratégie clé quand on cherche à maximiser la confidentialité et l'intégrité des données sur l'ensemble du trajet réseau.

Sécurité vs Performance

L'équilibre entre sécurité et performance est un élément crucial de la conception des systèmes informatiques modernes. D'une part, la terminaison SSL et l'offloading permettent d'améliorer les performances en réduisant la charge de traitement sur les serveurs d'application, grâce à la centralisation des opérations de chiffrement et de déchiffrement sur des composants dédiés comme les Ingress Controllers. D'autre part, cette centralisation peut introduire des points de défaillance uniques et potentiellement augmenter le vecteur d'attaque si le dispositif de terminaison SSL est compromis.

De plus, bien que la ré-encryption puisse augmenter la sécurité en maintenant le trafic chiffré sur le réseau interne, elle peut également introduire un surcoût en termes de latence et de charge CPU, influant ainsi sur la performance globale. Les architectes de système doivent donc soigneusement évaluer les besoins de sécurité spécifiques à l'application et à l'organisation, et les mettre en balance avec les impératifs de performance. L'objectif est de trouver un compromis optimal qui offre une sécurité robuste sans dégrader l'expérience utilisateur ou la réactivité de l'application.

Dans certains cas, des mesures comme le SSL Passthrough peuvent être privilégiées pour maximiser la sécurité, en dépit d'une légère réduction de la performance. Dans d'autres, une approche mixte, où seules certaines données sensibles sont soumises à la ré-encryption tandis que d'autres sont traitées avec moins de restrictions, peut aider à maintenir un équilibre sain entre les deux priorités.

Gestion Centralisée des Certificats dans la Terminaison SSL

La centralisation de la gestion des certificats SSL/TLS lors de la terminaison SSL offre une simplification et une amélioration substantielles de la sécurité réseau. En concentrant les certificats en un seul point de gestion, les organisations peuvent assurer une surveillance et un renouvellement cohérents, minimisant les risques d'interruptions dues à des certificats expirés. Cette approche centralisée permet également une mise en œuvre uniforme des politiques de sécurité et de conformité, facilitant ainsi la tâche des administrateurs système qui peuvent déployer, révoquer et renouveler les certificats de manière centralisée et contrôlée.

Optimisation avec Cert-Manager dans Kubernetes

L'adoption de Cert-Manager dans un environnement Kubernetes complète l'efficacité de la terminaison SSL en automatisant la gestion des certificats à travers les clusters. Comme l'Ingress Controller gère souvent la terminaison SSL, l'intégration de Cert-Manager permet un renouvellement automatique des certificats, ce qui est crucial pour maintenir la fiabilité et la sécurité des services exposés. Cert-Manager devient ainsi une pièce centrale de l'infrastructure Kubernetes, en veillant à ce que les certificats soient gérés de manière dynamique et en accord avec les exigences opérationnelles et de sécurité, tout en réduisant la charge administrative et en éliminant les fenêtres de vulnérabilité liées aux certificats.

Conclusion

La terminaison SSL et l'offloading représentent des composants essentiels dans l'arsenal des stratégies de sécurité des infrastructures modernes. En concentrant le déchiffrement et le chiffrement du trafic SSL/TLS sur des dispositifs spécialisés, ces techniques allègent la charge sur les serveurs d'application, améliorant ainsi leur performance et leur capacité à monter en charge. De plus, elles permettent une gestion centralisée des certificats et une mise en place facilitée de services de sécurité avancés tels que les WAF, tout en offrant la flexibilité nécessaire pour effectuer des tâches critiques sur les données déchiffrées, comme les inspections de contenu et les contrôles d'accès.

Toutefois, la décision d'utiliser la terminaison SSL, l'offloading, ou le passthrough doit être guidée par une évaluation minutieuse des besoins en sécurité et des objectifs de performance. Alors que la ré-encryption offre une sécurité de bout en bout pour les données en transit, elle doit être mise en balance avec l'impact potentiel sur les temps de réponse et les ressources système. Dans ce contexte, la ré-encryption peut être vue comme un investissement en sécurité, avec des retours mesurés en termes de conformité et de protection contre les menaces internes.

La terminaison SSL et l'offloading ne sont pas seulement des mécanismes de performance ; ils sont également synonymes de confiance dans un écosystème numérique où la sécurité des données est primordiale. En fin de compte, l'intégration judicieuse de ces pratiques est indicatrice d'une infrastructure réfléchie et robuste, conçue pour offrir à la fois sécurité et performance dans le système d'information de l'entreprise.

Références