Considérations pratiques sur le Cloud : Sécurité
Le calcul dans le cloud peut être bon marché, mais il n’est pas gratuit.
La grande majorité des applications actuelles sont diffusées via HTTP sécurisé. Cela signifie TLS ou le SSL de plus en plus mal vu. Cela signifie cryptographie, ce qui a traditionnellement été traduit par problèmes de performances.
Grâce aux progrès technologiques, les processeurs sont aujourd’hui incroyablement rapides et de nombreux matériels clients (et côté serveur) intègrent nativement ce qui était autrefois du matériel cryptographique spécialisé. Cela signifie que, au niveau de chaque connexion, la vitesse n’est plus un problème aussi important au niveau individuel pour la cryptographie qu’elle l’était autrefois.
Mais cela ne signifie pas que la cryptographie ne génère plus des coûts en termes de performance et d’exploitation.
La plupart des analyses qui rejettent l'idée que la cryptographie cause des problèmes majeurs de performance se basent sur des scénarios simples impliquant un client et un serveur. Cela correspond à un processus de chiffrement et un processus de déchiffrement. Dans ces cas, les sceptiques ont souvent raison. La latence apportée par le chiffrement et le déchiffrement reste minimale, généralement moins problématique que la surcharge liée au TCP et au réseau.
Mais les applications d’aujourd’hui ne sont pas constituées d’un seul point de terminaison. Il existe de nombreux intermédiaires et proxys par lesquels un message doit transiter avant d'atteindre ce « point de terminaison unique ». Il s'agit des points de terminaison de sécurité et de contrôle d'accès, d'équilibrage de charge et de routage. Chacun doit inspecter le message - en clair - afin d'exécuter le rôle qui lui est assigné dans la danse complexe qu'est le chemin des données moderne.
C'est ici que l'argument selon lequel la cryptographie n'est pas si coûteuse commence à s'effondrer. À lui seul, un seul point de terminaison introduit très peu de retard. Mais lorsqu'ils sont répétés plusieurs fois à chaque point de terminaison du chemin des données, ces retards individuels s'additionnent pour donner lieu à quelque chose de plus perceptible et, en particulier dans le cas du cloud public, de plus coûteux sur le plan opérationnel.
La cryptographie est naturellement un processus coûteux en termes de calcul. Cela signifie qu'il faut beaucoup plus de cycles CPU pour crypter ou décrypter un message que pour exécuter la logique métier. Dans le cloud, les cycles CPU sont comparables à de l’argent dépensé. En général, il s’agit d’un coût accepté car l’objectif est de transférer les coûts d’investissement vers les dépenses opérationnelles.
Mais les coûts commencent à s’accumuler si vous décryptez et cryptez un message plusieurs fois. En réalité, vous payez plusieurs fois pour le même processus cryptographique. Ce qui pourrait être calculé comme ne coûtant qu’un centime lorsqu’il est exécuté une fois coûte soudainement cinq centimes lorsqu’il est exécuté cinq fois. Si l’on fait le calcul des centaines de milliers de transactions au cours d’une journée (ou d’une heure), les coûts qui en résultent sont stupéfiants.
N’oubliez pas également que chaque cycle CPU consommé par le traitement cryptographique est un cycle CPU non consacré à la logique métier. Cela signifie que vous devrez évoluer plus tôt que vous ne le souhaiteriez, ce qui entraîne encore plus de coûts à mesure que chaque instance supplémentaire est lancée pour gérer la charge.
Il suffit de dire que « SSL partout » ne doit pas aboutir à des architectures « décrypter partout » dans le cloud.
Décrypter une fois
Pour réduire les coûts et maximiser l'efficacité des processeurs pour lesquels vous payez, il vaut la peine de prendre le temps de concevoir votre architecture basée sur le cloud selon le principe de « décryptage unique ». « Décrypter une fois » signifie que vous devez minimiser le nombre de points de terminaison dans le chemin des données qui doivent décrypter et recrypter les messages en transit.
Pour cela, réfléchissez à l’avance et examinez attentivement les seize services applicatifs différents que vous utilisez aujourd’hui pour sécuriser et faire évoluer vos applications. Si aucune réglementation ne vous oblige à appliquer un chiffrement de bout en bout, concevez votre chemin des données pour déchiffrer les messages le plus tôt possible, afin d’éviter des cycles inutiles consacrés au déchiffrement par la suite. Si vous devez impérativement maintenir un chiffrement de bout en bout, combinez les services autant que possible pour optimiser l’usage des ressources de calcul.
En combinant les services que vous pouvez utiliser (par exemple, l'équilibrage de charge avec un pare-feu application Web) sur une seule plateforme, vous réduisez le nombre de fois où vous devez décrypter les messages en transit. Il 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 des avantages en termes de performances pour les utilisateurs et les consommateurs. Mais les véritables économies se situent au niveau des cycles CPU qui ne sont pas consacrés à des décryptages et recryptages répétés.
Il peut sembler une perte de temps de considérer l’impact du cryptage et du décryptage pour une application peu utilisée aujourd’hui. Les centimes ne couvrent certainement pas le coût de l’effort. Mais à mesure que les applications grandissent, évoluent et vivent au fil du temps, ces quelques centimes vont s'accumuler pour former des sommes qui auront un impact. Sans compter que, tout comme les centimes, les microsecondes s’additionnent. En considérant l’impact de la cryptographie sur l’ensemble du chemin des données, vous pouvez obtenir des avantages à long terme, tant pour les utilisateurs que pour l’entreprise.