Nous vivons dans un monde dominé par les applications. Cela commence à sembler banal et cliché, mais c’est toujours vrai. En matière de sécurité, cela signifie que nous devons d’abord nous concentrer sur l’application, puis progresser vers l’extérieur jusqu’à l’utilisateur.
Mais ce n’est pas ainsi que nous concevons les architectures de sécurité aujourd’hui.
Aujourd’hui, nous concevons les architectures de sécurité en tentant d’ériger un mur (pare-feu) impénétrable autour du périmètre. À mesure que nous progressons vers l’intérieur, en direction de l’application, les lignes de défense que nous mettons en place sont de moins en moins granulaires, jusqu’à ce que nous atteignions enfin l’application, où il ne reste pratiquement plus rien. Les dispositifs de sécurité les plus étroitement liés à l’application sont les plus éloignés de celle qu’ils doivent protéger, alors que ce devrait être l’inverse. Nous sommes ainsi contraints de déployer des capacités considérables à la périphérie du réseau — où des équipements matériels coûteux sont nécessaires pour prendre en charge la bande passante et la densité de ports requises — plutôt que des capacités plus modestes à proximité de l’application, où des logiciels et des « équipements » virtualisés, moins coûteux et plus faciles à gérer, pourraient être déployés plus aisément.
Nous devons inverser cette architecture et repenser la sécurité afin de mieux l’adapter aux modèles applicatifs et économiques actuels.
Nous devons cesser de chercher à prendre en compte les spécificités des applications au niveau du périmètre de l’entreprise, afin de mieux évoluer et de tirer davantage parti de l’infrastructure de sécurité. Nous devons cesser d’être aussi indifférents aux applications à proximité de celles-ci et commencer à décaler cette approche vers la gauche, du côté du développement et des opérations, ainsi que vers un modèle logiciel capable d’évoluer tant sur le plan économique qu’architectural. Nous avons besoin d’une infrastructure de sécurité d’entreprise générique à la périphérie traditionnelle du réseau, et d’une architecture de sécurité spécifique à chaque application au niveau du nouveau périmètre : l’application.

C’est particulièrement vrai lorsque l’on considère l’impact du cloud sur les applications. Pas sur le centre de données, mais sur les applications. Ce sont les applications que nous devons protéger, et non le réseau, ce qui est impossible si notre stratégie de sécurité repose sur un contrôle total du réseau (et des personnes qui y accèdent). Nous devons réfléchir à la manière de protéger l’application, qu’elle se trouve ou non dans le centre de données, et élaborer une stratégie de sécurité fondée sur ce principe, plutôt que sur celui auquel nous nous fiions avant que le cloud ne bouleverse le centre de données.
Imaginez le raz-de-marée d’applications que vont engendrer l’Internet des objets et l’adoption d’architectures de microservices. Si chaque « nouvelle » technologie multiplie généralement par dix le nombre d’applications, combien d’applications deux « nouvelles » technologies adoptées simultanément vont-elles générer ? Combien de nouvelles politiques de sécurité faudra-t-il mettre en place à la périphérie du réseau pour prendre en charge chacune de ces applications ?
Oui. Beaucoup. Un ou deux ordres de grandeur de plus qu’aujourd’hui.
Et si nous les décalions vers la gauche (dans le pipeline de déploiement ; vers la droite si l’on considère un schéma réseau traditionnel) et les transférions vers un environnement davantage déployé et défini par logiciel ? Et si nous faisions appel aux personnes qui développent les applications et les connaissent parfaitement pour contribuer à l’élaboration des politiques destinées à les sécuriser, puis intégrions ces politiques au processus de déploiement ? Au pipeline CI/CD ? Et si nous regroupions les applications de la même manière, avec les mêmes services de sécurité dont elles ont besoin, qu’elles soient dans le cloud public ou sur site ? Et si nous parvenions ainsi à assurer une sécurité cohérente dans l’ensemble des infrastructures informatiques, ce que 60 % des entreprises considèrent comme le facteur le plus important pour protéger les environnements cloud [Pleins feux sur la sécurité du cloud] ?
Cette approche serait-elle évolutive ?
Je suppose que oui, avec moins de perturbations et une gestion plus aisée qu’avec le modèle actuel.
Le cloud est source de bouleversements. La mobilité est source de bouleversements. L’Internet des objets le sera également. Ce n’est pas toujours une mauvaise chose, surtout lorsque cela nous donne l’occasion de repenser et de réévaluer la manière dont nous déployons, fournissons et sécurisons les applications.
Alors, peut-être est-il temps de repenser entièrement notre modèle de sécurité et de faire de l’application le nouveau périmètre, afin de mieux faire évoluer la sécurité, protéger les applications et préserver l’intégrité de nos données.
À propos de l’auteur

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 VittieArticles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.