F5 Vendredi : Comment la normalisation permet une approche personnalisable par application (microservices) de la sécurité des applications
J'ai parlé , parlé et encore parlé du besoin croissant de services adaptés aux applications pour rendre plus confortables les applications qu'ils protègent, font évoluer et optimisent. Tout comme les développeurs d’applications constatent qu’il est plus efficace et plus agile à grande échelle de décomposer les monolithes en microservices plus ciblés et granulaires, l’ infrastructure doit également refléter cette évolution pour continuer à fournir le même niveau et la même qualité de service à grande échelle.
Mais cette approche ne concerne pas uniquement les architectures de microservices. Il est également destiné aux organisations qui doivent mettre en œuvre des politiques par application à grande échelle et le faire rapidement. Considérez une étude qui a révélé que « 85 % des entreprises ont un arriéré mobile compris entre une et 20 applications, et une majorité (50 %) ont un arriéré compris entre 10 et 20 applications ». Cela s'ajoute à la pléthore d'applications existantes (notre recherche a montré que près de la moitié des organisations ont entre 1 et 200 applications, l'autre moitié, bien plus de 200, y compris les 10 % quelque peu ahurissants avec plus de 3 000 applications à gérer) qui nécessitent des mises à jour pour être déployées.
La plupart d’entre eux nécessitent des politiques très spécifiques pour garantir leur évolutivité, leur sécurité et leurs performances. Il faut évoluer, mais il faut évoluer rapidement pour tout gérer.
L’un des inconvénients d’une approche de service par application est bien sûr que chacun d’entre eux doit être adapté pour répondre aux exigences uniques de l’application qu’il fournit. C’est bien sûr l’objectif, mais sans une approche stratégique pour adapter les opérations derrière la création et le déploiement des politiques pour répondre à cette demande, une telle approche pourrait potentiellement conduire à des délais de déploiement plus lents, et non plus rapides.
C'est pourquoi DevOps et sa philosophie d'infrastructure en tant que code, combinée à une attention portée à l'automatisation, doivent être considérés non seulement comme appropriés, mais souhaitables, pour les opérations de sécurité. Car c'est seulement en déplaçant la sécurité Web vers la gauche qu'une approche holistique des microservices couvrant à la fois les applications et les services d'application peut réussir. Il est en effet essentiel que la sécurité soit en mesure de s’adapter à la vitesse à laquelle l’informatique est aujourd’hui censée fournir ses services aux clients qu’elle prend en charge.
C'est ce qui a poussé Catholic Education South Australia (CESA), qui fournit des services informatiques à plus de 98 écoles réparties dans toute l'Australie du Sud, à adopter la plateforme F5. CESA était confrontée à des défis découlant des méthodes traditionnelles d'approvisionnement et de déploiement qui ne lui fournissaient tout simplement pas l'évolutivité horizontale nécessaire pour répondre à la demande. Ce dont ils avaient besoin, c’était d’un cadre personnalisable pour déployer des applications et automatiser les tâches associées. Et cela incluait finalement la sécurité Web.
Simon Sigre, ingénieur réseau senior chez CESA, explique pourquoi ils ont dû procéder à un changement : « Nous avons dû commencer à créer des politiques de sécurité de couche 7 (L7) qui s'enroulaient comme un gant autour de chaque application Web . »
CESA devait fournir des politiques par application, mais il fallait le faire rapidement et à grande échelle. Cela signifie qu’ils avaient besoin d’automatisation pour accomplir cet exploit. Mais ce n’était pas tout ce dont ils avaient besoin. L’adaptation des politiques – en particulier celles qui sont étroitement liées à l’application qu’elles protègent – prend du temps. Mais tout ce qui concerne une application n’est pas unique. Il existe des éléments communs, notamment ceux liés aux protocoles (comme TCP et HTTP) et aux plateformes (comme le logiciel serveur Web ou d'applications) qui restent les mêmes dans de nombreuses applications. La configuration des politiques pour sécuriser ces aspects prend également du temps ; un temps qui est dupliqué sur plusieurs applications.
C’est là que la normalisation vient à la rescousse. L’une des caractéristiques de la normalisation est la capacité à tirer parti des points communs entre les API, les modèles, les systèmes de commande et de contrôle et les scripts pour améliorer l’efficacité, ce qui se traduit par une réduction des coûts d’exploitation et une mise sur le marché plus rapide. C'est exactement ce que CESA a fait lorsqu'il a profité de la programmabilité de F5 non seulement pour automatiser l'évolutivité mais aussi pour standardiser les politiques de sécurité en créant des modèles de haut niveau pour les technologies courantes utilisées, puis en les personnalisant pour s'adapter aux différences de chaque nouveau service. Ils ont pu créer les politiques de sécurité par application dont ils avaient besoin sans encourir les coûts généralement associés à la personnalisation en traitant l'infrastructure (sécurité Web) comme du code (modèles), éliminant ainsi efficacement les coûts associés à la recréation de la politique de base à chaque fois qu'ils doivent déployer un nouveau service.
Vous pouvez en savoir plus sur l'expérience de CESA avec F5 et ses technologies ici même dans ce témoignage client.