Considérations pratiques sur le cloud : sécurité

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

La puissance de calcul dans le cloud est peut-être bon marché, mais elle n’est pas gratuite.

Aujourd’hui, la grande majorité des applications sont distribuées via le protocole HTTP sécurisé. Cela implique l’utilisation de TLS ou de SSL, de plus en plus décrié. Cela implique également le recours à la cryptographie, traditionnellement synonyme de problèmes de performances.

Grâce aux progrès technologiques, les processeurs sont aujourd’hui incroyablement rapides, et de nombreux équipements clients (et serveurs) intègrent désormais nativement des fonctions autrefois réservées à du matériel cryptographique spécialisé. Cela signifie qu’à l’échelle de chaque connexion, la vitesse constitue beaucoup moins un problème qu’auparavant pour les opérations cryptographiques.

Mais cela ne signifie pas que la cryptographie ne continue pas d’engendrer des coûts en matière de performances et d’exploitation.

La plupart des arguments qui rejettent l’idée que la cryptographie constitue une source importante de problèmes de performances reposent sur des scénarios simples impliquant un client et un serveur. Cela représente une opération de chiffrement et une seule opération de déchiffrement. Et dans de tels scénarios, les détracteurs ont généralement raison. La latence induite par le chiffrement et le déchiffrement est minime et s’avère généralement moins préoccupante que la surcharge liée à TCP et au réseau.

Mais les applications actuelles ne se résument pas à un seul point de terminaison. Un message doit transiter par de multiples intermédiaires et proxys avant même d’atteindre ce « point de terminaison unique ». Il s’agit de points de terminaison chargés de la sécurité et du contrôle d’accès, de l’équilibrage de charge et du routage. Chacun doit inspecter le message en clair afin de remplir le rôle qui lui est assigné dans le ballet complexe que constitue le cheminement moderne des données.

C’est là que l’argument selon lequel la cryptographie n’est pas si coûteuse commence à s’effondrer. Pris isolément, un seul point de terminaison n’introduit qu’une très faible latence. Mais lorsque l’opération est répétée plusieurs fois à chaque point de terminaison du chemin de données, ces délais individuels s’accumulent et deviennent plus perceptibles et, en particulier dans le cas du cloud public, coûteux sur le plan opérationnel.

La cryptographie est par nature un processus exigeant en ressources de calcul. Cela signifie que le chiffrement ou le déchiffrement d’un message nécessite beaucoup plus de cycles processeur que l’exécution de la logique métier. Dans le cloud, les cycles processeur correspondent à de l’argent dépensé. En général, ce coût est accepté, car l’objectif est de transférer les dépenses d’investissement vers les dépenses d’exploitation.

Mais les coûts commencent à s’accumuler si vous déchiffrez et chiffrez un message à plusieurs reprises. En réalité, vous payez pour le même processus cryptographique plusieurs fois. Une opération dont le coût estimé n’est que d’un centime lorsqu’elle est exécutée une seule fois revient soudainement à cinq centimes lorsqu’elle est exécutée cinq fois. Si l’on fait le calcul pour les centaines de milliers de transactions effectuées au cours d’une journée (ou d’une heure), les coûts qui en résultent sont vertigineux.

N’oubliez pas non plus que chaque cycle processeur consacré au traitement cryptographique est un cycle qui ne l’est pas à la logique métier. Cela signifie que vous devrez procéder à une mise à l’échelle horizontale plus tôt que vous ne le souhaiteriez, ce qui engendre des coûts supplémentaires à chaque nouvelle instance lancée pour absorber la charge.

Il va sans dire que le « SSL partout » ne doit pas conduire à des architectures « déchiffrer partout » dans le cloud.

Déchiffrer une seule fois

Pour réduire les coûts et optimiser l’efficacité des processeurs que vous payez, il est judicieux de prendre le temps de concevoir votre architecture cloud selon le principe du « déchiffrement unique ». Ce principe consiste à réduire au minimum le nombre de points de terminaison du chemin de données qui doivent déchiffrer puis rechiffrer les messages en transit.

Pour ce faire, il faut anticiper et examiner attentivement les seize différents services applicatifs que vous utilisez aujourd’hui pour sécuriser les applications et les faire évoluer. Si vous n’êtes pas soumis à des réglementations ou à des exigences imposant un chiffrement de bout en bout, concevez votre chemin de données de sorte que les messages soient déchiffrés le plus tôt possible afin d’éviter de gaspiller ultérieurement des cycles supplémentaires pour leur déchiffrement. Si vous devez maintenir un chiffrement de bout en bout, regrouper les services chaque fois que possible vous permettra d’utiliser les ressources de calcul de la manière la plus efficace.

Regrouper les services qui peuvent l’être — par exemple, l’équilibrage de charge et le pare-feu d’applications web — sur une même plateforme permet de réduire le nombre de fois où les messages en transit doivent être déchiffrés. Cela présente également l’avantage de réduire le nombre de connexions et le temps passé sur le réseau, ce qui se traduit par de meilleures performances pour les utilisateurs et les consommateurs. Mais les véritables économies résident dans les cycles processeur qui ne sont pas consacrés à des opérations répétées de déchiffrement et de rechiffrement.

Il peut sembler inutile de s’attarder sur l’impact du chiffrement et du déchiffrement pour une application encore peu utilisée aujourd’hui. Les quelques centimes économisés ne couvrent certainement pas le coût des efforts engagés. Mais à mesure que les applications se développent, montent en charge et perdurent, ces centimes finissent par représenter des sommes non négligeables. Sans compter que, comme les centimes, les microsecondes s’additionnent. En tenant compte de l’impact de la cryptographie sur l’ensemble du chemin des données, vous pouvez, à long terme, en tirer des bénéfices tant pour les utilisateurs que pour l’entreprise.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie