2017-04-16 3 views
2

Nous utilisons l'infrastructure AWS suivante:charge le déchargement SSL sur le niveau AWS CloudFront

Route53-> CloundFront -> Elasticbeanstalk (+ LoadBalancer = ELB) -> instances EC2

Maintenant, nous avons des certificats ssl mis en place sur CloudFront niveau et le même sur le niveau ELB nous fournissant ainsi un cryptage de bout en bout entre CF et ELB. End2End entre AWS CF et l'origine est décrit comme la meilleure pratique here.

Cela fait référence à Full SSL (strict) sur ce picture (ceci est pour la pile CloudFlare mais c'est pour une meilleure illustration, alors peu importe). Nous voulons décharger SSL au niveau AWS CF pour éviter les allers-retours entre CF et ELB en passant à Flexible SSL tel que représenté sur l'image.

Est-ce une bonne idée de décharger SSL au niveau CF? Y aura-t-il des améliorations de performances qui valent la peine d'abandonner le cryptage end2end après le niveau CF? Peut-on en quelque sorte empêcher ELB d'accepter les connexions uniquement de certains AWS CF?

De plus, il y a des problèmes de performance au sujet de ELB SSL performance (semble être prouvé pour être bon mais j'ai encore des inquiétudes). En général, il est également intéressant si AWS CF fonctionne mieux au travail de décryptage SSL qu'ELB.

Répondre

2

Déchargez SSL à CF ou non en fonction de la nature de votre application et des exigences de conformité.

Normalement, si toutes les entités accèdent à l'application via CF (par exemple, ne pas avoir de connexions VPN de certains clients vers VPC backend), le déchargement à CF est suffisant. La différence de performance d'avoir SSL à la fois n'est pas significative.

Pour autoriser uniquement l'entrée CF à ELB, aucune approche directe n'est disponible pour le moment. Une approche possible consiste à mettre à jour le groupe de sécurité d'ELB à l'aide d'une fonction Lambda, en obtenant la plage IP CF à partir de l'URL JSON fournie par AWS.

Le déchargement SSL à CF est également plus rapide comparé à ELB, car il y a beaucoup de serveurs qui opèrent à l'emplacement périphérique acceptant votre connexion alors que ELB a des serveurs pour chaque AZ (habituellement 2 ou 3).

+1

* "Une approche possible consiste à mettre à jour le groupe de sécurité d'ELB à l'aide d'une fonction Lambda, obtenant la plage IP CF à partir de l'URL JSON fournie par AWS." * Ceci n'est pas particulièrement utile. un créé par quelqu'un d'autre) pour contacter votre ELB. –

+1

Il est vrai que d'autres CF peuvent également accéder lorsque le groupe de sécurité est listé en blanc pour la plage d'adresses IP des FC, mais cela réduit la surface d'attaque puisque CF n'autorise que le trafic de couche 7. Cependant, si vous voulez le limiter à un seul CF, vous pouvez utiliser des groupes de sécurité combinés avec un en-tête CF généré qui est validé sur votre serveur. – Ashan

+1

Une raison supplémentaire pour laquelle l'impact de SSL sur ELB devrait être minime lorsque CloudFront est déployé derrière CloudFront. persister et réutiliser les connexions entre lui-même et l'ELB, en minimisant les frais généraux de mise en place de ces connexions, ce qui est une partie longue et coûteuse de SSL. –