Principaux éléments à prendre en compte lors du déploiement d’une solution SSL

Introduction

En tant qu’êtres sociaux, les humains ont du mal à garder des secrets. C’est grâce au partage d’informations que nous survivons — et prospérons. Cependant, certaines informations doivent rester confidentielles, raison pour laquelle la cryptographie existe sous une forme ou une autre depuis que l’armée spartiate a utilisé un chiffrement par transposition pour protéger des informations militaires lors de ses guerres contre les Grecs.

Mais si la science visant à préserver la confidentialité des données privées relevait autrefois des services de renseignement gouvernementaux, l’omniprésence d’Internet a fait de la protection de la vie privée une préoccupation pour tous. Face à la multiplication constante des violations de données, la question de la protection en ligne des données personnelles et professionnelles est devenue une priorité absolue pour les entreprises du monde entier.

L’essor du SSL et le paysage actuel de la cybersécurité

Il y a seulement dix ans, les grandes institutions financières et les organismes gouvernementaux étaient les principales organisations à utiliser le protocole cryptographique autrefois appelé Secure Sockets Layer (SSL) et désormais connu sous le nom de Transport Layer Security (TLS). Aujourd’hui, le SSL est omniprésent. Les analystes prévoient que le trafic chiffré représentera près de 64 % de l’ensemble du trafic Internet nord-américain en 2016, contre seulement 29 % en 2015.^{1 (https://www.f5.com/resources/white-papers/key-considerations-in-deploying-an-ssl-solution#footnote01)} Les organisations s’efforcent de chiffrer la majeure partie du trafic, qu’il s’agisse des e-mails, des réseaux sociaux ou encore des vidéos en streaming. Cette évolution renforce la sécurité du trafic web, mais elle a un coût. La croissance du trafic SSL contraint les organisations à mettre en œuvre une solution SSL efficace permettant à leur infrastructure réseau de faire face à la charge de travail accrue qu’exige une sécurité renforcée.

Les entreprises sont séduites par le niveau de sécurité offert par SSL, mais son déploiement en tant que protocole de sécurité omniprésent et permanent présente certaines difficultés. Parallèlement, SSL est devenu un vecteur de vulnérabilité, car les attaquants ont commencé à l’utiliser pour dissimuler des logiciels malveillants aux dispositifs de sécurité incapables d’analyser le trafic chiffré. Les attaques par déni de service distribué (DDoS) sont particulièrement problématiques, car elles tirent parti des coûts de calcul relativement élevés liés à l’hébergement du trafic des serveurs SSL. En outre, des problèmes de mise en œuvre, tels que l’incident Heartbleed, peuvent entraîner des failles de sécurité.

Déployer correctement SSL est une tâche ardue, même pour les administrateurs chevronnés. Il est toutefois possible d’anticiper les changements — en privilégiant des stratégies proactives plutôt que des mesures réactives — en se tenant informé des options et tendances les plus récentes en matière de déploiement de SSL sur différents sites.

Considérations fondamentales lors de l’adoption d’une stratégie SSL

Protection des données et respect de la vie privée

L’objectif principal de SSL est de sécuriser les données en transit entre les applications. Lorsqu’elles sont sécurisées par SSL, les communications entre un client, tel qu’un navigateur web, et un serveur restent confidentielles, et l’identité des deux parties peut être authentifiée. Cependant, tout trafic chiffré à l’aide d’une clé privée est susceptible d’être déchiffré ultérieurement, comme l’ont révélé les fuites très médiatisées d’Edward Snowden concernant la National Security Agency (NSA) américaine. Sécuriser l’ensemble des communications web ne suffit pas.

Mettre en œuvre la confidentialité persistante parfaite

SSL dispose d’une mesure de protection contre la surveillance passive appelée confidentialité persistante (PFS), qui ajoute un échange supplémentaire au protocole d’établissement de clés entre les deux parties de la connexion SSL. En générant une clé de session unique pour chaque session initiée par l’utilisateur, la PFS garantit qu’un attaquant ne peut pas simplement récupérer une seule clé et déchiffrer des millions de conversations enregistrées précédemment.

L’adoption de la PFS semble simple : il suffit de l’activer sur le dispositif de terminaison SSL, tel qu’un contrôleur de mise à disposition d’applications (ADC). Toutefois, les organisations qui utilisent des dispositifs de sécurité passifs, tels qu’un système de prévention des intrusions (IPS) ou un système de détection des intrusions (IDS), rencontreront des difficultés, car ces dispositifs doivent souvent être configurés avec une clé privée persistante, que la PFS n’utilise pas. Les organisations sont donc confrontées à un choix : désactiver leur IPS/IDS ou désactiver la PFS. Dans les deux cas, leur posture globale de sécurité s’en trouve compromise.

Il existe une autre solution. Laissez l’IDS/IPS remplir le rôle pour lequel il a été conçu en transférant l’ensemble du trafic SSL vers un proxy inverse, tel qu’un pare-feu d’applications web ou un contrôleur de mise à disposition d’applications (ADC). Le proxy inverse peut alors gérer les algorithmes de chiffrement avant de transmettre le trafic déchiffré à l’IDS/IPS à des fins d’inspection et d’assainissement.

Ce que vous pouvez faire : Activez la PFS pour protéger l’intégrité des données. En outre, envisagez de déployer un proxy inverse afin de décharger le trafic SSL et d’optimiser le fonctionnement des dispositifs de sécurité réseau. 

Utilisez HTTP Strict Transport Security

L’activation de HTTP Strict Transport Security (HSTS) est l’un des moyens les plus simples et les plus efficaces de renforcer la sécurité des applications. En ajoutant un en-tête au trafic HTTPS, HSTS offre une couche de protection contre plusieurs vecteurs d’attaque courants, notamment le détournement de cookies, les attaques de l’homme du milieu et les attaques par rétrogradation. Tous les principaux navigateurs prennent désormais en charge HSTS, ce qui en fait un excellent moyen de garantir que l’ensemble du trafic reste chiffré.

Ce que vous pouvez faire : Assurez-vous que toutes les pages de tous les domaines disposent de l’en-tête HSTS en activant HSTS pour les sous-domaines. Vérifiez que ces sous-domaines prennent bien en charge l’utilisation de SSL. Assurez-vous également que la solution SSL permet de configurer rapidement et facilement les paramètres HSTS à l’échelle du système. Veillez à ce que la durée de validité de l’en-tête HSTS soit d’au moins six mois. 

Visibilité et contrôle

La gestion des applications et la garantie de leur sécurité nécessitent une visibilité sur le trafic — ou la capacité de fournir cette visibilité à des dispositifs de sécurité tels qu’un pare-feu d’applications web (WAF), un système IPS/IDS ou un pare-feu de nouvelle génération (NGFW) — afin de détecter les menaces connues. Toutefois, par définition, le protocole SSL masque les données échangées, y compris aux solutions de sécurité. Plusieurs approches permettent néanmoins de préserver la sécurité tout en mettant efficacement en évidence le trafic malveillant.

Utiliser le déchargement et la transformation SSL

Le chiffrement et le déchiffrement du trafic SSL nécessitent une puissance de calcul supplémentaire. Avec l’essor du SSL, la latence et le ralentissement des performances peuvent nuire au réseau et à l’expérience utilisateur. En outre, certains protocoles exigeant une puissance de calcul importante ne sont pas pris en charge par certains dispositifs de sécurité actuellement utilisés. Un ADC peut alléger cette charge de calcul en faisant office de proxy complet pour les protocoles TCP, HTTP et SSL. Il établit ainsi une connexion avec le client (navigateur) et une autre, distincte, avec le serveur. Grâce à la capacité de transformation d’un proxy SSL, un site peut proposer des fonctionnalités SSL indépendamment des capacités des serveurs d’applications.

Ce que vous pouvez faire : Déployez une solution évolutive. Le transfert de la terminaison SSL vers un ADC facilite l’application d’une politique SSL cohérente sans compromettre les performances, la protection des clés ni la visibilité. Cette approche offre davantage de flexibilité en permettant à l’ADC de convertir l’interface avec les serveurs web dans n’importe quel protocole qu’il prend en charge, quelles que soient les options de transport du back-end. Les appareils et applications existants stratégiques pour l’entreprise peuvent ainsi continuer à fonctionner sans modification sur le back-end, tout en maintenant un niveau de sécurité robuste pour les services exposés au public.

En outre, disposer d’un point de contrôle centralisé simplifie le processus de mise à jour d’un site afin de le protéger contre les nouvelles vulnérabilités. Enfin, dans le cadre d’une architecture hybride, privilégiez une solution permettant de décharger le traitement SSL des machines virtuelles (VM) vers un équipement matériel afin de réduire les besoins en ressources de calcul de l’infrastructure et de tirer le meilleur parti d’un déploiement virtuel.

Neutralisez les logiciels malveillants grâce à l’interception SSL

Les analystes en sécurité estiment que d’ici 2017, 100 % des nouveaux logiciels malveillants utiliseront le protocole SSL pour dissimuler leurs traces aux dispositifs de sécurité conçus pour les détecter et les neutraliser. Les entreprises doivent surveiller et assainir leur trafic web sortant afin de limiter les menaces persistantes avancées (APT), telles que le harponnage et les activités liées aux logiciels malveillants.

De nouveaux dispositifs de sécurité sont constamment développés pour aider les administrateurs à détecter ces menaces. Dans le cadre d’une stratégie dite de défense en profondeur, de nombreux administrateurs déploient des dispositifs de sécurité en chaîne afin qu’ils puissent se compléter mutuellement. Cependant, les opérations SSL nuisent à l’efficacité, à la sécurité et aux performances de ces dispositifs. Bon nombre de ces nouvelles technologies sont soit incapables d’analyser le trafic chiffré, soit confrontées à une dégradation importante de leurs performances lorsqu’elles doivent l’inspecter. Par exemple, les pare-feu de nouvelle génération peuvent subir une baisse de performances allant jusqu’à 80 % lorsque SSL est activé. Les auteurs de logiciels malveillants et d’attaques de harponnage le savent et s’empressent de chiffrer toutes les communications entre leurs logiciels malveillants et le monde extérieur.

Ce que vous pouvez faire : Une façon de lutter contre ces menaces chiffrées consiste à déployer une solution d’isolation SSL, en plaçant un contrôleur de mise à disposition d’applications (ADC) de part et d’autre de la chaîne de visibilité. L’ADC le plus proche des utilisateurs déchiffre le trafic sortant et transmet les communications déchiffrées aux dispositifs de sécurité. Ces dispositifs, qui peuvent désormais accéder au contenu, appliquent les politiques et les contrôles nécessaires afin de détecter et de neutraliser les logiciels malveillants. À l’autre extrémité de la chaîne, un autre ADC chiffre à nouveau le trafic à sa sortie du centre de données. Le déploiement de cette solution permet de conserver les dispositifs de sécurité en ligne tout en garantissant qu’ils puissent remplir la fonction pour laquelle ils ont été conçus.

Une dernière remarque : lorsque vous utilisez un outil d’analyse de la visibilité tel que FireEye ou Cisco Sourcefire pour protéger le réseau contre les exploits zero-day et autres attaques malveillantes, assurez-vous que la solution SSL s’intègre étroitement à ces produits de sécurité afin d’optimiser son efficacité.

Atténuer les attaques DDoS par force brute

La complexité du déploiement de SSL, associée aux difficultés rencontrées par de nombreux équipements réseau pour analyser le trafic chiffré, fait de SSL une cible idéale pour les attaques DDoS — un fait que les attaquants ne connaissent que trop bien. À mesure que le volume global du trafic SSL légitime augmente rapidement, les équipements de sécurité ont de plus en plus de mal à identifier le trafic DDoS malveillant.

Ce que vous pouvez faire : Atténuez les attaques DDoS, telles que les attaques par renégociation SSL et les floods SSL, à l’aide d’une solution SSL complète capable d’identifier efficacement le trafic DDoS suspect et de l’empêcher de nuire à la disponibilité des sites web. Envisagez d’étudier les services de protection DDoS basés dans le cloud qui peuvent contribuer à atténuer l’impact des attaques DDoS reposant sur SSL.

Vérifiez votre sécurité dès maintenant

Alors, comment savoir si votre niveau de sécurité SSL est à la hauteur ? Qualys SSL Labs propose un précieux outil qui vous permet de tester les certificats et la configuration de vos sites avant de subir une attaque. Vous pouvez également évaluer l’implémentation SSL de votre navigateur et voir comment d’autres sites — ainsi que ceux de vos concurrents — font face à ces enjeux liés au SSL qui évoluent rapidement.

Agilité cryptographique

Depuis l’apparition du protocole SSL dans les années 1990, le cryptosystème RSA constitue le principal choix pour l’échange de clés. Au fil du temps, à mesure que les attaques par force brute devenaient plus réalisables, il a fallu augmenter la longueur des clés RSA. Aujourd’hui, les clés RSA sont si longues que l’échange de clés est une opération nécessitant une puissance de calcul considérable.

Afin de réduire cette charge de calcul tout en maintenant des contrôles stricts en matière de confidentialité, de nouveaux protocoles cryptographiques gagnent en popularité. Par exemple, la cryptographie sur les courbes elliptiques (ECC) offre le même niveau de sécurité que les algorithmes précédents tout en nécessitant moins de puissance de calcul, ce qui permet également de mieux préserver l’autonomie des appareils mobiles. Bien que ces options cryptographiques soient prometteuses, les organisations s’inquiètent à juste titre de devoir reconfigurer des centaines de serveurs pour prendre en charge ces nouveaux protocoles.

Ce que vous pouvez faire : Il n’est pas rare de devoir changer d’algorithme au fil du temps. Assurez-vous donc que la solution SSL offre une certaine agilité cryptographique, c’est-à-dire qu’un dispositif SSL puisse prendre en charge simultanément plusieurs protocoles cryptographiques, tels qu’ECC, RSA2048 et DSA, y compris au sein d’une même application web. En outre, face à la diversité croissante des algorithmes de chiffrement, il est essentiel que la solution SSL ait fait ses preuves en matière de mise à jour de leur prise en charge.

Gestion des clés

Les clés SSL comptent parmi les actifs les plus précieux d’une organisation. Un attaquant qui parviendrait à s’emparer de clés SSL privées pourrait usurper l’identité des applications de la cible et créer le portail d’hameçonnage ultime. Il existe toutefois plusieurs moyens de protéger ces clés essentielles.

Protégez les clés de grande valeur

Un module matériel de sécurité (HSM) est un dispositif de sécurité matériel et logiciel distinct qui respecte les directives strictes de conception cryptographique FIPS 140-2 afin de protéger et de gérer les clés cryptographiques. Comme les clés ne sont jamais transférées hors du HSM, les vulnérabilités SSL telles que la faille Heartbleed ne présentent aucun risque.

Ce que vous pouvez faire : Le moyen le plus sûr de protéger les clés SSL consiste à utiliser un HSM. Plusieurs possibilités s’offrent à vous, comme l’achat d’un HSM interne, tel que celui intégré à certains ADC. Certaines organisations centralisent la gestion de leurs clés en utilisant des dispositifs HSM comme référentiels de clés centralisés (par exemple, une paire par centre de données). Ces HSM réseau sont accessibles via le réseau interne aux services qui doivent déchiffrer des clés, ce qui permet à de nombreux points de terminaison SSL d’utiliser le même HSM réseau. Une réserve toutefois : assurez-vous simplement que la solution SSL peut s’intégrer de manière transparente au HSM réseau.

Les entreprises mettent en œuvre les bonnes pratiques de gestion des clés et des certificats d’entreprise (EKCM) afin de garantir la sécurité des clés SSL. Envisagez d’utiliser un système de stockage chiffré des clés sécurisé par du matériel, qui permet de stocker les phrases secrètes sous forme chiffrée dans le système de fichiers réseau.

Gérez efficacement les certificats SSL

La mise en œuvre de bonnes pratiques efficaces en matière d’EKCM repose avant tout sur la création d’un inventaire exhaustif de tous les certificats de l’entreprise, de leur emplacement et des personnes chargées de les gérer. Chaque site web utilisant SSL possède son propre certificat, assorti d’une date d’expiration spécifique. Chaque semaine, un ou plusieurs certificats peuvent arriver à expiration, rendant le site web ou l’application associé indisponible. La gestion de tous ces certificats peut s’avérer fastidieuse, mais elle est essentielle pour garantir la haute disponibilité des sites critiques. En outre, les certificats SSL doivent également faire l’objet d’un audit portant sur la longueur des clés (2 048 bits ou plus), la signature numérique (SHA-2 ou mieux) et les certificats non autorisés qui n’ont pas été générés au sein de l’infrastructure PKI interne ou par une autorité de certification racine publique. Enfin, la conformité à la norme PCI DSS exige la mise en place d’un processus documenté de gestion des certificats et des clés.

Ce que vous pouvez faire : La plupart des administrateurs d’organisations de moyenne ou grande taille préfèrent utiliser un système externe de gestion des certificats, car les clés et les certificats de leur organisation sont répartis dans de nombreux emplacements. Beaucoup ont notamment obtenu de bons résultats avec deux solutions externes : Venafi et Symantec. Quelle que soit la solution retenue, il est important qu’elle dispose d’API ouvertes afin d’automatiser la gestion et de réduire la charge opérationnelle.

Conformité complète

La conformité est souvent le principal moteur de l’adoption du protocole SSL. Les applications conformes à la norme PCI DSS devront cesser d’utiliser SSLv3 et TLSv1 au cours des deux prochaines années afin de rester conformes à PCI 3.0. Les nouveaux déploiements PCI DSS doivent d’ores et déjà désactiver SSL 3.0 et TLS 1.0.

Ce que vous pouvez faire : Tout d’abord, assurez-vous que le pare-feu réseau est certifié par ICSA Labs. En outre, les services de transformation SSL permettent de garantir la conformité à une politique SSL pour les services accessibles sur Internet, sans avoir à appliquer cette politique sur chaque serveur. Assurez-vous que la solution SSL est compatible avec la prochaine version de TLS 1.3. Par ailleurs, il est possible de réaliser de véritables gains d’efficacité opérationnelle en centralisant la conformité au moyen d’un service réseau déchargé sur un contrôleur de mise à disposition d’applications (ADC), plutôt que de tenter de la gérer séparément pour chaque application.

Conclusion

Qu’on le veuille ou non, le monde en ligne est un environnement dangereux, et la protection des informations sensibles des entreprises contre d’éventuels attaquants est devenue une priorité absolue pour les organisations de toutes tailles. Face à la multiplication des atteintes à la vie privée, de nombreuses organisations se tournent vers SSL pour préserver l’intégrité de leurs données en ligne. Toutefois, la mise en œuvre d’une stratégie SSL complète présente ses propres défis en matière de visibilité, de performances et de capacité à monter en charge.

Grâce à une planification et à un déploiement appropriés, une stratégie SSL robuste réduit le risque de violations de données. Une fois cette stratégie mise en place, le site sera paré pour répondre aux futurs besoins en matière de sécurité, d’évolutivité et de fiabilité, ce qui permettra de se concentrer sur l’essentiel : faire progresser l’entreprise.

¹ Sandvine, Pleins feux sur les phénomènes Internet mondiaux : chiffrement du trafic Internet, 2015.

PUBLIÉ LE 26 MAI 2016