Bon, les enfants. Il est temps qu’on ait « cette conversation ». Vous savez, celle dont vous parlez à voix basse avec vos amis, mais au sujet de laquelle vous n’osiez jusqu’ici rien demander parce que, bien sûr, tout le monde est au courant et que vous ne vouliez pas avoir l’air, eh bien, pas cool en avouant que vous ne saviez pas vraiment de quoi il s’agissait.
Sauf que ce n’est pas le cas, ou du moins, si ça l’est, ils n’en parlent pas non plus. Et il est vraiment grand temps de parler des précautions à prendre lorsqu’on utilise le cloud. Vous savez, comment protéger vos applications dans le cloud contre les infections et les attaques.
Oui, aujourd’hui, nous allons enfin parler de la sécurité des applications dans le cloud.
Pas le chiffrement. Ni la gestion des identités et des accès. Ni la sécurité réseau.
Sécurité des applications.
Parmi tous les documents, travaux de recherche, conseils et discussions générales sur la « sécurité du cloud » disponibles aujourd’hui sur le vaste Internet, très peu* mentionnent les termes « sécurité des applications ». Je trouve des études et des statistiques sur l’utilisation du chiffrement, sur les acteurs qui devraient protéger les données dans le cloud — et ceux qui ne le font pas —, ainsi que sur les solutions de gestion des identités et des accès utilisées pour contrôler l’accès aux applications, où qu’elles se trouvent. Mais sur la sécurité des applications ? Nada. Rien. Que dalle. Zéro.
Ce qui est vraiment assez surprenant (et inquiétant), étant donné que les applications web constituent la deuxième cause d’incidents de sécurité dans les services financiers, juste derrière les logiciels criminels au nom sinistre, selon le tout dernier Rapport d’enquête de Verizon sur les violations de données (DBIR). Une brève analyse des 25 principales violations de données de ce siècle révèle également, de façon surprenante, que près de la moitié (44 %) ont été perpétrées par l’intermédiaire d’une application web. C’est également décourageant, car il semble exister une corrélation entre la dégradation du niveau de sécurité et la migration des applications vers le cloud.
En réalité, le chiffrement n’est pas une panacée.
Permettez-moi de le répéter, cette fois en majuscules pour souligner à quel point c’est sérieux : LE CHIFFREMENT N’EST PAS UNE PANACÉE.
La sécurité des réseaux et la gestion des identités et des accès ne le sont pas non plus.
Toutes ces mesures sont utiles, mais prises individuellement, elles ne constituent qu’un élément d’un dispositif de protection bien plus vaste. Un dispositif qui devrait inclure la sécurité des applications, même si ce n’est souvent pas le cas.
Network security ne permettra pas d'arrêter une attaque DDoS HTTP. La gestion des identités et des accès n'empêchera pas l'exploitation d'une vulnérabilité de plateforme web telle que Heartbleed ou Apache Killer.
Le chiffrement n’empêchera pas une injection SQL. Chiffrer du code malveillant ne fait que le dissimuler aux nombreux services du réseau conçus pour le détecter.
De par sa vocation, l’application est une ressource accessible au public. Nous la mettons à disposition et attendons — que dis-je, nous encourageons, nous incitons, nous supplions — les utilisateurs d’interagir avec elle. De l’utiliser. De l’installer. De la consulter souvent. Nous vivons dans un monde régi par les applications, ce qui signifie qu’elles sont essentielles à tous les aspects de l’activité d’une entreprise, qu’elles soient destinées aux clients, aux employés ou au fonctionnement des systèmes internes. De nos jours, nous dépendons des applications pour presque tout ce que nous faisons, et pourtant, lorsque nous parlons de sécurité, nous semblons toujours les oublier.
Il est vraiment temps que nous accordions davantage d’attention à la sécurité des applications et pas seulement à la sécurité des données, à la sécurité des réseaux ou au chiffrement des communications. C’est lorsqu’elles sont traitées par l’application que les données sont les plus vulnérables. En effet, à ce stade, elles sont en clair et entièrement sous le contrôle de l’application. Celle-ci peut les afficher, les modifier et les transmettre à quiconque (ou, de plus en plus souvent, à tout système, compte tenu de l’essor des bots, des robots d’indexation et des logiciels malveillants) parvient à les lui soutirer.
Cela signifie que nous devons accorder davantage d’attention à la sécurisation des applications contre les tentatives d’exploitation et les attaques. De la plateforme (le serveur web ou applicatif) aux protocoles (TCP et HTTP), en passant par le code lui-même. Nous devons analyser, filtrer, détecter et contrer les innombrables méthodes employées par les attaquants pour exploiter l’ensemble de la pile applicative.
Selon F-Secure Labs, la fréquence des attaques contre les applications web a doublé, passant de moins de 20 % en 2012 à 40 % en 2013. En 2014, Neustar a constaté que 55 % des cibles d’attaques DDoS avaient subi une attaque servant d’écran de fumée (une attaque DDoS volumétrique destinée à masquer les véritables attaques visant la couche applicative), près de 50 % d’entre elles ayant été infectées par un logiciel malveillant ou un virus et 26 % ayant perdu des données clients.
Les attaques visant les applications constituent une menace réelle et importante, en particulier à mesure que celles-ci migrent vers le cloud, où les options disponibles pour les protéger peuvent être moins nombreuses.
Les services de sécurité natifs disponibles dans le cloud sont tous axés sur le contrôle des accès et le chiffrement. Aucun d’entre eux n’assure la sécurité de la « couche applicative » ni ne fournit une protection suffisante pour garantir la résistance à une attaque visant à désactiver ou altérer l’application, ou à exfiltrer des données en exploitant l’application elle-même. Il vous faut donc une autre solution, c’est-à-dire un autre service conçu pour protéger les applications et les données qu’elles traitent dans le cloud, comme vous le faites dans le centre de données. Il peut s’agir d’un WAF (pare-feu d’applications web) compatible avec le cloud, d’un WAF en tant que service ou, au minimum, de l’application rigoureuse des bonnes pratiques recommandées par l’OWASP à chaque application déployée dans le cloud.
La sécurité du cloud peut être considérée comme une responsabilité partagée, le fournisseur et le client se chargeant chacun de différents aspects de la sécurisation du « cloud ». Toutefois, la sécurité des applications relève à 110 % de la responsabilité de celui qui les déploie dans le cloud. Prenons cet entretien (publié par The Register) avec Bill Murray, responsable des programmes de sécurité mondiaux chez AWS (c’est moi qui souligne) :
« La sécurité chez AWS est une responsabilité partagée entre AWS et ses clients », a déclaré Murray lors d’un récent entretien. Il est responsable de la sécurité d’AWS, notamment de la sécurité physique des centres de données d’Amazon, et traite également les mandats et assignations émanant des forces de l’ordre.
« Les clients sont responsables de la protection de l’ensemble de leur environnement, depuis le système d’exploitation invité qu’ils exécutent sur AWS jusqu’aux applications qu’ils utilisent », a-t-il déclaré à El Reg. Nous sommes responsables du système d’exploitation hôte, de la machine virtuelle et de tout ce qui se trouve en dessous, jusqu’au béton du sol du centre de données. »
« On nous pose souvent cette question : “Qu’est-ce qui vous empêche de dormir ?” Ce qui nous empêche de dormir, au sein de l’équipe de sécurité d’AWS, ce sont les clients qui ne configurent pas correctement leurs applications pour assurer leur propre sécurité », a déclaré Murray.
C’est vous, et cela signifie que vous devez réfléchir attentivement aux services et aux solutions que vous déployez pour protéger cette application contre l’attaque qui, inévitablement, finira par vous viser.
La sécurité des applications n’est pas comparable à un garde du corps coûteux. Elle ne doit pas être réservée aux applications VIP. Elle s’apparente davantage à une protection personnelle, dont toute application accessible au public devrait bénéficier. Et cela vaut aussi bien pour les applications hébergées dans un centre de données que pour celles dans le cloud.
* Je dis « très peu », mais honnêtement, je n’ai même pas réussi à en trouver un seul. C’est peut-être mon talent pour les recherches Google qui me fait défaut, mais il est plus probable que ce soit parce que personne ne semble vouloir en parler.
À 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.