Il me semble que la question est "faites-vous confiance à votre propre centre de données". En d'autres termes, il semble que vous essayez de tracer finement la ligne où se trouvent les réseaux non fiables , et la confiance commence.

À mon avis, la confiance SSL / TLS devrait se terminer au niveau du périphérique de déchargement SSL, car le service qui gère ce périphérique gère souvent également le réseau et l'infrastructure. Il y a là une certaine confiance contractuelle. Il est inutile de chiffrer les données sur un serveur en aval, car les mêmes personnes qui prennent en charge le réseau y ont généralement également accès. (à l'exception possible des environnements multi-locataires ou des exigences métier uniques qui nécessitent une segmentation plus approfondie).

Une deuxième raison pour laquelle SSL devrait se terminer au niveau de l'équilibreur de charge est qu'il offre un emplacement centralisé pour corriger les attaques SSL telles que CRIME ou BEAST. Si SSL est interrompu sur divers serveurs Web, fonctionnant sur différents systèmes d'exploitation, vous risquez davantage de rencontrer des problèmes en raison de la complexité supplémentaire . Restez simple, et vous aurez moins de problèmes à long terme.

Cela étant dit

1. Oui, terminez au niveau de l'équilibreur de charge et déchargez SSL ici. Restez simple.
2. L'équilibreur de charge Citrix Netscaler (par exemple) peut refuser l'accès non sécurisé à une URL. Cette logique de politique, combinée aux fonctionnalités de TLS, doit garantir que vos données restent confidentielles et sans falsification (étant donné que je comprends bien votre exigence d'intégrité)

Edit:

Il est possible (et courant) de

• d'externaliser l'équilibreur de charge (Amazon, Microsoft, etc.)
• Utiliser un CDN tiers (Akamai , Amazon, Microsoft, etc.)
• Ou utilisez un proxy tiers pour empêcher les attaques DoS

... où le trafic de ce tiers serait envoyé à vos serveurs via des liens réseau que vous ne gérez pas. Par conséquent, vous ne pouvez pas faire confiance à ces liens non chiffrés. Dans ce cas, vous devez rechiffrer les données, ou à tout le moins faire voyager toutes ces données via un VPN point-point.

Microsoft propose un tel produit VPN et permet l'externalisation sécurisée du périmètre.

Oui, je dirais que TLS devrait être déchargé. J'ai fait tout ce que je mentionne ci-dessous spécifiquement avec le Citrix Netscaler, mais je pense que F5 devrait pouvoir faire les mêmes choses.

Premièrement, vous devez toujours vous assurer de rechiffrer de l'autre côté de l'équilibreur de charge, mais l'appareil qui déchiffre TLS devrait être en mesure d'inspecter ce qui se passe du point de vue de la sécurité. L'intégrité des données ne doit pas être compromise par cette approche.

Beaucoup de gens m'ont dit que le rechiffrement en back-end le rendait tout aussi coûteux en calcul, mais ce n'est pas vrai. La dépense avec TLS est la création et la fermeture de la connexion, que le déchargeur TLS gère. Sur le backend, vous avez une connexion plus persistante aux serveurs et, par conséquent, les ressources requises sont beaucoup plus faibles.

De plus, si vous n'avez pas de déchargement TLS, même une petite attaque DDoS via TLS anéantirait complètement vos serveurs. Je connais très bien cette situation et le déchargement TLS est une aide incroyable d'un point de vue informatique, et vous permet également de bloquer les attaques plus haut dans la chaîne. Pour les attaques DDoS extrêmement importantes, vous pouvez même diviser votre stratégie d'atténuation entre votre déchargeur TLS et vos serveurs.

Pour inspecter les données qui vont dans une connexion SSL, alors l'une ou l'autre de ces conditions doit être vraie:

• Le tunnel se termine sur la machine qui effectue l'inspection, par exemple votre "load balancer".
• Le système d'inspection connaît une copie de la clé privée du serveur, et la connexion SSL n'utilise pas l'éphémère Diffie-Hellman (c'est-à-dire que le serveur n'autorise pas les suites de chiffrement qui contiennent "DHE "dans leur nom).

Si vous suivez la première option, les données voyageront non chiffrées entre le système d'inspection (l'équilibreur de charge) et les clusters, à moins que vous ne les cryptiez à nouveau avec un autre SSL tunnel: la connexion SSL principale est entre le navigateur client et l'équilibreur de charge, et l'équilibreur de charge maintient un lien SSL (ou une autre technologie de cryptage, par exemple un VPN avec IPsec) entre lui-même et chacun des nœuds du cluster .

La deuxième option est un peu plus légère, puisque l'inspecteur de paquets décrypte simplement les données mais n'a pas à les rechiffrer. Cependant, cela implique que tous les nœuds du cluster sont capables de faire le SSL complet avec le client, c'est-à-dire de connaître une copie de la clé privée du serveur. De plus, ne pas prendre en charge DHE signifie que vous n'obtiendrez pas la fonctionnalité astucieuse de Perfect Forward Secrecy (ce n'est pas fatal, mais PFS semble vraiment bon dans les audits de sécurité, donc c'est une bonne chose à avoir).

Quoi qu'il en soit, le nœud qui effectue une inspection approfondie des paquets doit avoir un accès privilégié dans le tunnel SSL, ce qui le rend plutôt critique pour la sécurité.

Je recommanderais la résiliation de SSL au niveau de l'équilibreur de charge (que ce soit sur votre réseau, ou chez un fournisseur CDN ou autre). Cela signifie que le LB peut inspecter le trafic et peut faire un meilleur travail d'équilibrage de charge. Cela signifie également que votre équilibreur de charge est responsable de la gestion des clients lents, des implémentations SSL défectueuses et de la fragilité générale de l'Internet. Il est probable que votre équilibreur de charge dispose de meilleures ressources pour ce faire que vos serveurs principaux. Cela signifie également que les certificats SSL que le monde voit sont tous sur l'équilibreur de charge (ce qui, espérons-le, les rend plus faciles à gérer).

L'alternative ici est simplement d'équilibrer la charge des connexions TCP des clients vers votre dos serveurs d'extrémité. Comme le LB ne peut pas inspecter ce qui se passe de cette manière, il ne peut pas répartir la charge uniformément sur les serveurs principaux, et les serveurs principaux doivent faire face à toute la fragilité d'Internet. Je n'utiliserais cette méthode que si vous ne faites pas confiance à votre équilibreur de charge, fournisseur de CDN ou autre.

Que vous rechiffriez ou non de l'équilibreur de charge vers vos serveurs principaux est une question personnelle choix et circonstance. Si vous traitez avec des cartes de crédit ou des transactions financières, vous êtes probablement réglementé par le (s) gouvernement (s) et devrez donc rechiffrer. Vous devriez probablement également rechiffrer si le trafic entre l'équilibreur de charge et les serveurs principaux circule sur des réseaux non approuvés. Si vous hébergez uniquement le site Web de votre entreprise, vous pourrez peut-être éviter la surcharge supplémentaire du rechiffrement, si vous ne vous souciez pas vraiment des aspects de sécurité de celui-ci.

Le rechiffrement ne fonctionne pas. N'ajoutez pas autant de charge que vous pourriez penser. Habituellement, l'équilibreur de charge sera en mesure de maintenir des connexions persistantes avec les serveurs, de sorte que le coût SSL sera assez faible pour ce «saut» sur le réseau.

La dernière chose à laquelle il faut penser est l'application sur les serveurs principaux. Si tout le trafic qui y arrive est HTTP, il ne peut pas prendre de décisions en fonction du protocole utilisé par le client. Il ne peut alors pas dire "vous essayez d'accéder à la page de connexion via HTTP, je vous redirige donc vers la version HTTPS de la page", par exemple. Vous pouvez demander à l'équilibreur de charge d'ajouter un en-tête HTTP pour dire "cela vient de HTTPS", mais cet en-tête nécessiterait un traitement spécial dans l'application. En fonction de votre situation, il peut être plus facile de rechiffrer et de laisser l'application fonctionner de manière "par défaut" plutôt que de nécessiter une modification spécifique au site.

En résumé, je dirais: terminer au niveau de l'équilibreur de charge et rechiffrez vos serveurs principaux. Si vous faites cela et remarquez un problème, vous pouvez faire des ajustements si nécessaire.

Vous pouvez choisir de chiffrer le trafic interne avec un certificat de clé inférieure. Et il est également conseillé de positionner votre équilibreur de charge aussi près que possible de vos serveurs pour éviter les attaques de reniflage ou de man-in-middle. L'arrêt SSL peut être effectué au niveau de l'équilibreur de charge pour décharger les tâches gourmandes en ressources processeur des serveurs Web. Si la marque LB que vous avez choisie peut effectuer certaines fonctions telles que l'inspection des connexions de protocole malformées, détecter le comportement DDoS, etc.