Sécurité applicative (dans le cloud) : le guide ultime

Les applications ne constituent peut-être qu’une seule couche de la pile logicielle, mais elles sont sans doute la couche la plus critique, et, à certains égards, la plus difficile à sécuriser. D’autres couches, comme l’infrastructure qui héberge les applications, tendent à avoir une surface d’attaque réduite et à être plus cohérentes en termes de contenu et de configuration.

En revanche, la plupart des applications sont exposées à l’internet, ce qui signifie qu’elles sont exposées à un risque d’attaque permanent. En outre, comme les applications peuvent utiliser une multitude d’architectures différentes et être écrites dans divers langages de programmation, il est plus difficile de concevoir des protections de sécurité adaptées à chaque application que de sécuriser les autres couches de la pile.

De plus, les défis en matière de sécurité applicative deviennent encore plus complexes lorsque les applications sont transférées dans le cloud et s’intègrent à divers services cloud pour gérer le trafic, stocker les données, appliquer des paramètres de contrôle d’accès, etc. La complexité du cloud signifie qu’il y a encore plus de variables à prendre en compte par les équipes de sécurité, et plus de risques à traiter, lorsqu’elles planifient une stratégie de sécurité applicative cloud.

Cet article passe en revue tous les défis clés liés à la sécurisation des applications sur site et des applications cloud. Il explique les principaux risques de sécurité auxquels les applications sont confrontées, ainsi que les meilleures pratiques que les équipes de sécurité, les équipes DevOps et les équipes informatiques devraient suivre pour minimiser le risque que la couche applicative permette à des attaquants d’exfiltrer des données, d’exécuter des codes malveillants ou de perturber des services critiques.

Qu’est-ce que la sécurité applicative ?

La sécurité applicative dans DevOps est le processus de protection des applications contre les attaques et les abus. Comme indiqué ci-dessus, les applications constituent une partie unique de la pile d’hébergement. Par conséquent, les applications sont confrontées à des risques de sécurité particuliers et nécessitent des outils de sécurité centrés sur les applications.

Pour comprendre en quoi la sécurité applicative diffère des autres types de sécurité, examinons comment une équipe de sécurité mettrait en place des contrôles d’accès pour un serveur qui héberge une application, par opposition à l’application elle-même. Pour sécuriser le serveur hôte, l’équipe pourrait s’appuyer sur les outils de contrôle d’accès intégrés au système d’exploitation du serveur. Sur un serveur Linux, par exemple, elle pourrait utiliser la commande chmod pour définir quels utilisateurs peuvent effectuer quelles actions sur le serveur.

Restreindre l’accès à une application n’est toutefois pas aussi simple, car la manière dont les utilisateurs accèdent à l’application varie beaucoup plus. L’application peut utiliser une logique interne pour authentifier les utilisateurs et définir les privilèges d’accès dont chacun doit disposer. Elle peut également utiliser un cadre d’authentification distribué, tel que OAuth, pour gérer les droits d’accès en externe.

En outre, les règles de contrôle d’accès au sein de la chaîne d’outils CI/CD (intégration et de livraison continues) utilisée pour créer l’application doivent être définies correctement afin de sécuriser l’application. Des privilèges excessifs pour les dépôts GitHub de l’application ou les outils d’intégration continue (CI), par exemple, pourraient permettre à des utilisateurs malveillants de modifier le fonctionnement de l’application en injectant du code malveillant dans la chaîne de livraison.

Cet exemple concerne d’ailleurs les contrôles d’accès aux applications, qui ne sont qu’un des nombreux aspects que les équipes de sécurité doivent prendre en compte pour protéger les applications. Elles doivent également s’assurer que l’application gère les données en toute sécurité, qu’elle résiste aux attaques par débordement de tampon, qu’elle est exempte de vulnérabilités, etc. (Nous examinerons plus loin les principaux types de risques liés à la sécurité des applications.)

En définitive, lorsqu’il s’agit de sécuriser les applications, il y a un grand nombre de variables en jeu et un large éventail de défis que les équipes de sécurité doivent relever. Les outils et les pratiques de sécurité des applications sont conçus pour répondre à ces besoins spécifiques, par opposition aux considérations de sécurité qui affectent d’autres couches de la pile d’hébergement.

Sécurité applicative classique et sécurité des applications cloud

Les défis en matière de sécurité applicative sont encore plus vastes et plus complexes pour les applications hébergées dans le cloud, par opposition aux applications « classiques » qui fonctionnent dans un environnement sur site.

Les principales différences entre les applications conventionnelles et les applications cloud ayant une incidence sur la sécurité sont les suivantes :

Moins de contrôle : Dans le cloud, les équipes informatiques et de sécurité ont généralement moins de contrôle sur l’environnement qui héberge les applications. Ils ne peuvent par exemple pas accéder aux journaux des systèmes d’exploitation des serveurs physiques sous-jacents et leur capacité à définir des contrôles d’accès au niveau du réseau peut être limitée. Cela signifie que les applications cloud peuvent être confrontées à des risques de sécurité encore plus importants et que les protections mises en œuvre dans la couche d’infrastructure de la pile ne sont pas aussi efficaces.
Outils de sécurité spécifiques aux fournisseurs : Les fournisseurs de clouds publics proposent des outils et des cadres tels que des services de gestion des identités et des accès (en anglais, Identity and Access Control ou IAM) pour aider à protéger les applications. Cependant, les outils de chaque cloud fonctionnent un peu différemment, ce qui rend plus difficile la définition de politiques cohérentes et efficaces qui fonctionnent d’un environnement cloud à l’autre. En outre, la mesure dans laquelle les applications peuvent bénéficier d’outils de sécurité au niveau du cloud dépend de la manière dont les applications sont conçues et du degré d’intégration avec l’environnement cloud.
Environnements distribués : Bien que toutes les applications cloud n’aient pas besoin d’utiliser une architecture d’hébergement distribuée, c’est-à-dire une architecture dans laquelle plusieurs instances d’application sont réparties sur un cluster de serveurs hôtes, beaucoup le font afin de tirer pleinement parti de l’évolutivité et de la flexibilité du cloud. Il y a donc plus d’instances d’applications à sécuriser et à surveiller, et le risque de violations potentielles est plus élevé.
Exposition au réseau : Les applications cloud sont presque toujours exposées à internet, ce qui signifie qu’elles sont constamment exposées aux menaces véhiculées par le réseau. Les applications conventionnelles sont plus faciles à sécuriser à l’aide de pare-feu, de réseaux privés ou même d’« air gaps » (qui consiste à séparer entièrement les applications du réseau).

Principaux types de risques liés à la sécurité applicative

Quel que soit le type d’application que vous déployez et qu’elle fonctionne sur site ou dans le cloud, il existe plusieurs grands types de risques de sécurité auxquels elle peut être confrontée.

Attaques par injection de code

Si des attaquants pénètrent dans le pipeline CI/CD de votre application, ils peuvent potentiellement injecter du code source malveillant dans la base de code de l’application (c’est ce qui s’est produit, par exemple, dans l’affaire Codecov breach en 2021). Si vous n’interceptez pas le code malveillant avant de créer et de déployer la prochaine version de votre application, il finira par fonctionner dans votre environnement d’exécution.

Scripts intersites

Une attaque par script intersite se produit lorsque des pirates trouvent un moyen d’injecter des scripts malveillants dans des applications au moment de leur exécution. Les applications web sont le type d’application le plus couramment visé par les scripts intersites, bien que n’importe quel type d’application puisse potentiellement faire l’objet d’une telle violation. Ce type d’attaque est le plus souvent rendu possible par l’absence d’une validation correcte des entrées, que les attaquants exploitent pour « tromper » l’application et lui faire exécuter des scripts qu’ils y injectent.

Erreurs de configuration

Les applications s’appuient généralement sur une variété de configurations pour définir leur comportement. Les développeurs peuvent définir certaines règles de configuration dans le code source, tandis que d’autres sont définies comme des variables d’exécution. Les options de configuration dans l’environnement hôte de l’application, telles que les paramètres de contrôle d’accès définis dans le serveur hôte ou le cloud de l’application, peuvent également avoir une incidence sur le fonctionnement de l’application.

Des erreurs de configuration à tous les niveaux de l’application ou de l’environnement hôte peuvent entraîner des failles de sécurité. Par exemple, les développeurs peuvent créer une variable d’exécution qui donne à tous les utilisateurs de l’application des privilèges de niveau administrateur afin qu’ils puissent tester l’application plus facilement avant le déploiement. S’ils laissent par erreur la variable d’exécution définie en mode excessivement privilégié lorsque l’application est déployée en production, les attaquants pourraient en abuser pour étendre leurs privilèges.

Vulnérabilités du code source

Un grand nombre d’erreurs de codage et d’oublis peuvent s’introduire dans le code source de l’application. Les développeurs peuvent ne pas écrire un code qui valide correctement les entrées, par exemple, ce qui donnerait aux attaquants l’occasion d’exfiltrer des données sensibles en injectant des commandes malveillantes dans l’application. Une mauvaise gestion de la mémoire par l’application peut également permettre une attaque par débordement de tampon, dans laquelle les attaquants utilisent essentiellement une application compromise pour écraser la mémoire du système et exécuter un code malveillant.

Dépendances vulnérables

Il est courant que les développeurs définissent des dépendances pour les applications. Les dépendances sont des modules externes, des bibliothèques ou d’autres ressources dont une application a besoin pour fonctionner. Si les dépendances contiennent des vulnérabilités, celles-ci pourraient être exploitées par des attaquants pour prendre le contrôle de l’application ou pour accéder à des données sensibles contrôlées par l’application.

Meilleures pratiques pour la sécurité applicative et des applications cloud

Les risques liés à la sécurité applicative et des applications cloud se présentant sous de multiples formes, les entreprises doivent déployer un ensemble de moyens de défense pour s’en prémunir.

Sécuriser le pipeline de livraison de logiciels

Comme nous l’avons vu plus haut, des configurations ou des outils non sécurisés dans le pipeline de livraison de logiciels peuvent créer des portes dérobées que les attaquants exploitent. C’est pourquoi il est essentiel de sécuriser tous les outils et ressources sur lesquels les équipes s’appuient pour écrire, tester et déployer des applications, en plus des applications elles-mêmes.

Déployer plusieurs outils de sécurité des applications

Il existe plusieurs types d’outils de test et de validation de la sécurité des applications :

Analyse de la composition de la source (SCA) : Les outils SCA analysent le code source pour détecter les composants et les dépendances vulnérables.
Tests statiques de sécurité des applications (SAST) : Les outils SAST évaluent le code source afin de détecter les failles de sécurité, telles que l’absence d’une validation correcte des entrées.
Test dynamique de sécurité des applications (DAST) : Les outils DAST permettent aux équipes d’effectuer des tests sur des applications réelles afin de découvrir les points faibles que les attaquants pourraient exploiter.
Gestion de la posture de sécurité cloud (CSPM) Les outils CSPM ne sont pas des solutions de sécurité des applications à proprement parler, car ils valident les configurations des services cloud qui hébergent les applications, plutôt que les applications elles-mêmes. Néanmoins, la CSPM peut détecter des oublis de configuration, tels que des paramètres IAM faibles, qui pourraient conduire à des violations d’application.

En exploitant tous ces outils, les équipes maximisent leurs chances de détecter tous les types de risques liés à la sécurité des applications qui peuvent exister dans le code source, les fichiers binaires et les environnements d’exécution des applications.

Éviter les composants d’application inutiles

Plus votre application est simple, plus le risque d’attaque est faible. C’est pourquoi la meilleure pratique consiste à éviter les dépendances inutiles, les extensions ou autres composants qui augmentent inutilement la surface d’attaque de l’application.

Valider les dépendances

Les dépendances non sécurisées étant un des principaux vecteurs de violation de la sécurité des applications, il est essentiel d’utiliser un outil d’analyse de la sécurité des applications pour connaître les dépendances de votre application, ainsi que la version de chacune d’entre elles. Les informations relatives à la version sont essentielles car, dans de nombreux cas, seules des versions spécifiques d’une dépendance sont exposées à des risques de sécurité connus.

Renforcer le système d’exploitation

Certains systèmes d’exploitation proposent des outils de « renforcement », tels que SELinux et AppArmor, conçus pour réduire le risque de violation de la sécurité applicative. Ces frameworks ne remédient pas aux risques de sécurité sous-jacents dans les applications, mais ils peuvent rendre les risques plus difficiles à exploiter, par exemple en empêchant les applications compromises d’écraser la mémoire du système dans le cadre d’une attaque par débordement de tampon.

Le déploiement d’outils de renforcement dans la mesure du possible est une bonne pratique pour sécuriser les applications. Notez toutefois que dans le cas des applications cloud, vous n’avez pas toujours le niveau de contrôle sur l’environnement d’hébergement nécessaire pour installer un framework comme SELinux ou AppArmor.