Comment la componentisation des applications impacte les performances et la sécurité
Autrefois, les entreprises pouvaient compter sur l’utilisation de proxys déployés de manière stratégique pour améliorer les performances des applications. C'est parce que les applications traditionnelles (monolithes et architectures à trois niveaux) utilisent généralement un seul chemin des données entre le client et le serveur.
En termes simples, il n'y avait qu'un seul chemin emprunté pour tout le contenu, qu'il soit statique ou dynamique, basé sur du texte ou des images. Cela signifiait qu'un contrôleur de distribution application (proxy) pouvait se placer entre eux et, avec le bon, optimiser les performances. Cela était - et est toujours, d'ailleurs - souvent réalisé grâce au réglage de divers boutons et boutons IP, TCP et même HTTP. Nous pouvons voir l’utilisation de ces types de techniques à travers le déploiement de services application tels que la mise en cache, la compression et les techniques d’accélération spécifiques au contenu.
Mais les applications modernes ne fonctionnent plus de manière autonome. Elles se composent maintenant, selon Sonatype, principalement (80 à 90 %) d’éléments tiers, souvent issus de l’open source. Vous l’observez dans le nombre de scripts et autres codes injectables présents dans les applications web. Parfois, ces scripts s’exécutent à distance et restituent une image, une publicité ou d’autres contenus comme des polices web ou des sprites. D’autres fois, les scripts sont chargés lors de l’exécution et tournent dans le navigateur, à l’instar de jQuery.
C'est ce qu'on appelle la componentisation - ou l'atomisation, si vous préférez. Il s’agit de décomposer les applications en plusieurs parties plus petites. Nous les appelons composants côté client, car ils s'exécutent généralement dans le même espace. Côté serveur, nous les appelons de plus en plus microservices et les déployons dans des conteneurs. Dans les deux cas, l’impact est similaire : nous nous retrouvons avec un nombre imprévisible de chemins de données qui ont un impact direct sur les performances.
Fondamentalement, vous avez le contrôle sur un chemin des données , qui représente peut-être 20 % de votre application. Cela signifie que vous avez très peu de contrôle sur l’expérience utilisateur, car vous avez très peu de contrôle sur les performances.
C'est également vrai pour la sécurité - merci de l'avoir remarqué. Le fait est que nous apprenons rapidement à tirer parti des techniques de code côté client pour améliorer la sécurité. Cela ne fonctionne pas aussi bien avec les performances, car la plupart des applications sont soit mobiles, soit Web, et aucune des deux n'offre vraiment la possibilité ou la capacité de jouer avec la pile réseau.
L’une des façons de lutter contre ce problème est de reprendre le contrôle. L’avantage de reprendre le contrôle est que vous pouvez également bénéficier des effets secondaires en matière de sécurité.
Gagnant-gagnant : RÉDUIRE LES RISQUES ET AMÉLIORER LES PERFORMANCES
Si vos applications chargent dynamiquement des composants depuis des sites externes, cessez immédiatement. Arrêtez tout de suite. C’est un problème autant de sécurité que de performance. Vous autorisez implicitement un script externe à s’exécuter dans le contexte de votre application. Croyez-moi, en cas de faille de sécurité, l’utilisateur ne différenciera pas vos composants de ceux chargés à l’extérieur. Comme l'illustre la récente crise autour de la vulnérabilité du conteneur runc, injecter du code malveillant via des ressources issues de registres ou sites tiers expose à des risques majeurs.
S'il s'agit d'un script, il est préférable de le cloner et de le diffuser à partir de votre propre infrastructure. Vous bénéficierez d'une réduction des risques en gardant le contrôle et en étant capable de modifier les boutons et les commandes qui améliorent les performances pour vos utilisateurs. Cela inclut le DNS, dont il a été constamment démontré qu’il avait le plus grand impact (souvent négatif) sur les performances des application . Lorsque vous extrayez des composants de sites externes, vous comptez sur leur infrastructure DNS pour fonctionner à la hauteur de vos attentes. L'extraction de composants à partir de vos propres sites peut réduire considérablement l'impact simplement parce que le cache DNS local de l'utilisateur fonctionne pour vous.
L'hébergement de scripts à partir de votre propre site vous permet également d'utiliser des optimisations TCP ou des techniques de déchargement SSL/TLS ou d'accélération générale des applications pour améliorer les performances globales. Cela offre également la possibilité d'effectuer des analyses de sécurité sur ces scripts pour garantir qu'aucune surprise ne se cache au plus profond d'eux-mêmes.
La componentisation est idéale pour le développement et contribue certainement à accélérer le délai de rentabilisation. Mais cela peut avoir un impact négatif sur les performances – et la sécurité. Soyez conscient des risques liés à la sécurité et à la satisfaction des utilisateurs et de ce que vous pouvez faire pour les combattre.