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 reste pas une source de performances et de dépenses opérationnelles.
La plupart des arguments rejetant l’argument contre la cryptographie comme source importante de problèmes de performances sont basés sur des scénarios simples impliquant un client et un serveur. C'est un processus de cryptage et un processus de décryptage. Et dans de tels scénarios, les sceptiques ont généralement raison. La latence introduite par le chiffrement et le déchiffrement est minime et est généralement moins préoccupante 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 ce faire, il faut réfléchir à l’avance et prendre soigneusement en compte les seize services application différents que vous utilisez aujourd’hui pour sécuriser et faire évoluer les applications . Si vous n'êtes pas soumis à des réglementations ou à des exigences exigeant un chiffrement de bout en bout, concevez votre chemin des données de manière à ce que les messages soient déchiffrés le plus tôt possible afin d'éviter des cycles supplémentaires gaspillés lors du déchiffrement ultérieur. Si vous devez maintenir un chiffrement de bout en bout, la combinaison des services, dans la mesure du possible, vous permettra d'utiliser les ressources de calcul de la manière la plus efficace possible.
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.