Enjeux de sécurité du serverless : de l’infrastructure à l’OWASP

Par nature, le serverless (FaaS) répond à certaines des principales préoccupations de sécurité actuelles. En supprimant la gestion de l’infrastructure, il transfère les enjeux de sécurité au fournisseur de la plateforme. Malheureusement, les attaquants ne vont pas simplement renoncer : ils vont plutôt s’adapter à ce nouveau monde. Plus précisément, le FaaS va détourner leur attention des serveurs vers les problématiques applicatives mises en avant par l’OWASP — et les défenseurs doivent adapter leurs priorités en conséquence.

Cet article aborde les enjeux de sécurité auxquels le serverless répond et ceux qu’il ne résout pas. Chacun de ces points mériterait probablement un article à part entière (que j’écrirai peut-être plus tard !), mais je vais ici limiter les détails sur la remédiation et la gestion des risques pour privilégier une vue d’ensemble.

Voici un aperçu rapide des principaux domaines de préoccupation.

Entrons maintenant dans le détail !

Comment le serverless renforce-t-il la sécurité ?

Le serverless transfère la responsabilité de la gestion des serveurs du propriétaire de l’application au fournisseur de la plateforme. Ces serveurs pénibles sont notoirement difficiles à sécuriser, mais les experts qui gèrent les plateformes s’en chargent plutôt bien. Voici donc les trois principales menaces de sécurité que le serverless atténue considérablement.

1. Plus de serveurs non corrigés ni de binaires vulnérables

Avant tout, le serverless élimine pratiquement la principale source d’exploits réussis aujourd’hui : les serveurs non corrigés. Ces serveurs exécutent des binaires présentant des vulnérabilités connues, car ils n’ont pas reçu les dernières mises à jour de sécurité de leurs dépendances. Selon la plupart des estimations, les dépendances présentant des vulnérabilités connues sont responsables de la grande majorité des exploits réussis aujourd’hui.

Le serverless ne vous dispense pas de maintenir vos serveurs à jour, mais transfère cette responsabilité au fournisseur de la plateforme. La gestion des serveurs fait partie de ses compétences clés ; il est donc peu probable que les machines ne soient pas à jour.

2. Le déni de service devient un problème de facturation

Les attaques par déni de service empêchent un serveur de traiter les requêtes légitimes, et se répètent jusqu’à ce que tous les serveurs capables de répondre deviennent indisponibles. Avec le FaaS, les serveurs sont provisionnés à la demande puis supprimés (je ne tiens pas compte ici des optimisations de performances propres aux plateformes), ce qui rend la notion de « mettre un serveur hors service » dénuée de sens. À chaque nouvelle requête, légitime ou non, la plateforme provisionne un serveur et exécute la fonction demandée.

À noter : si, en théorie, le serverless élimine le déni de service en tant que menace pour la disponibilité, les plateformes imposent des limites de concurrence à connaître. Par défaut, AWS Lambda plafonne actuellement à 600 exécutions simultanées de fonctions. De plus, une attaque par déni de service peut toujours faire grimper considérablement votre facture, ce qui est presque aussi désagréable que l’attaque elle-même. Ne baissez donc pas la garde concernant le temps d’exécution ou les vulnérabilités ReDoS.

3. L’immutabilité élimine les serveurs compromis

Dans de nombreuses attaques, l’exploitation d’une vulnérabilité n’est qu’une première étape. Plutôt que de répéter les attaques, les attaquants cherchent à compromettre le serveur et à y installer un agent malveillant, à partir duquel ils mèneront des attaques plus poussées. Les attaques les plus dommageables, comme les violations de données chez Sony et Target, impliquent ce type de serveurs compromis.

Avec le FaaS, les serveurs sont immuables et éphémères, ce qui élimine de fait la possibilité qu’un serveur compromis le reste durablement. Cette protection réduit peu les chances de réussite d’une attaque, mais limite considérablement les possibilités d’action après l’exploitation et, par conséquent, les dommages qu’une telle attaque peut causer.

Quels enjeux de sécurité restent inchangés ?

Comme nous l’avons vu, le serverless nous décharge, en tant que propriétaires d’applications, de certaines menaces majeures. Cela signifie-t-il que les attaquants vont tout simplement renoncer aux applications serverless ? Bien sûr que non.

Voici les trois principaux enjeux de sécurité auxquels le serverless ne répond pas. Le FaaS ne les aggrave pas, mais l’élimination des menaces mentionnées précédemment fait naturellement remonter ces problèmes dans la liste des priorités des attaquants. Il est donc plus important que jamais de prendre ces risques en compte et d’y répondre.

4. Les vulnérabilités de votre code sont toujours présentes

Le serverless vous épargne la plupart des tracas liés à l’environnement, mais votre propre code — et ses vulnérabilités — reste sous votre responsabilité. Les vulnérabilités au niveau applicatif (par exemple, le cross-site scripting et l’injection SQL) restent graves lorsqu’elles sont exploitées, et les techniques d’atténuation (par exemple, la validation des entrées et l’accès programmatique à la base de données) sont toujours aussi essentielles.

Les bonnes pratiques restent les mêmes. Utilisez des outils de test de sécurité statique (SAST) et dynamique (DAST), facilitez la validation des entrées et privilégiez autant que possible les listes d’autorisation, etc. Le guide OWASP Top Ten regorge d’excellents conseils sur le sujet, tout comme sa antisèche.

5. Des dépendances applicatives vulnérables sont intégrées

À première vue, les fonctions FaaS semblent se limiter à votre code — mais ce n’est pas tout à fait exact. Elles incluent également des dépendances applicatives provenant de npm (Node.js), PyPI (Python), Maven (Java) ou d’autres plateformes pertinentes. Ces packages de code sont comme de petits éléments d’infrastructure intégrés à votre application.

Les dépendances applicatives ressemblent aux dépendances de serveurs, souvent exploitées. Elles sont omniprésentes et téléchargées des milliards de fois par mois ; il est difficile de suivre les packages que vous utilisez et ils comportent fréquemment des vulnérabilités, régulièrement signalées. Les attaquants exploitent déjà les dépendances applicatives vulnérables. Privés de la voie facile que représentent les dépendances de serveurs vulnérables, ils s’en prendront de plus belle à ces éléments similaires.

Les vulnérabilités connues sont aussi faciles à repérer pour vous que pour les attaquants. Pour sécuriser les dépendances applicatives, vous avez besoin d’accéder à une bonne base de données et à des outils automatisés qui empêchent en continu l’introduction de nouveaux packages vulnérables et vous alertent en cas de nouvelles vulnérabilités signalées. Snyk simplifie considérablement tout ce processus : je vous encourage à essayer ! Sinon, choisissez l’outil le mieux adapté à vos besoins et à votre plateforme, mais ne négligez pas ce problème.

6. Les données « au repos » restent tout aussi accessibles

Enfin, le serverless ne fait rien pour empêcher les attaquants d’accéder à votre base de données. Si un attaquant accède à vos données en exploitant l’une des vulnérabilités mentionnées plus haut, des identifiants divulgués, un initié compromis ou tout autre moyen, le FaaS n’y changera absolument rien.

Si vous stockez des informations sensibles, veillez à les chiffrer correctement. Les algorithmes cryptographiques open source sont largement disponibles : rien ne justifie de ne pas les utiliser. Évitez également de donner à tout le monde accès à votre base de données (même en lecture seule !) et réservez plutôt cet accès aux personnes et aux systèmes qui en ont le plus besoin. Le FaaS permet de mieux contrôler les accès en ne les accordant qu’aux fonctions qui utilisent directement la base de données. Enfin, n’exposez pas directement vos bases de données à Internet : comme l’ont montré le récent piratage de MongoDB et les déclarations explicites de Redis, ces systèmes sont conçus pour rester internes.

J’ai classé ce problème comme « neutre », car le serverless ne compromet pas la sécurité des données au repos. Toutefois, puisque les fonctions sont toujours sans état, celui-ci — y compris les données sensibles qu’il contient — sera parfois transféré d’un stockage local (par exemple, un système de fichiers ou la mémoire) vers un stockage réseau (par exemple, Redis ou des files d’attente). Appliquez aux stockages temporaires les mêmes pratiques de sécurité des données qu’aux stockages persistants, comme une base de données.

Quels enjeux de sécurité le serverless aggrave-t-il ?

Le serverless ne crée pas de nouveaux enjeux de sécurité, mais il en amplifie certains. L’architecture qu’il favorise nous amène à adopter davantage certaines pratiques, ce qui renforce les enjeux de sécurité qui leur sont associés. Examinons les trois principaux domaines dans lesquels le serverless complique la sécurité.

7. Services tiers et données « en transit »

Le FaaS ne vous oblige pas à stocker davantage de données, mais il vous amène certainement à en déplacer davantage. Des données qui restaient traditionnellement sur la machine circulent désormais entre les fonctions à de nombreuses reprises, souvent avec de légères modifications entre les appels. De plus, leur granularité et leur nature sans état favorisent l’utilisation accrue de services tiers, ce qui nécessite à nouveau d’envoyer et de recevoir des données sur le réseau.

Chaque échange de données comporte un risque de fuite ou d’altération. De plus, chaque fois que nous communiquons, nous accordons implicitement notre confiance à l’autre partie pour les données que nous lui envoyons et celles qu’elle nous transmet, ce qui ouvre la voie à un abus de confiance. Comme les échanges sont plus nombreux avec le FaaS, nous devons accorder davantage d’attention à ce risque et mieux nous en protéger.

La sécurité des données est un vaste domaine, mais je vous conseille de vous concentrer sur deux aspects : le chiffrement et la confiance. D’abord, chiffrez toutes les données à l’aide de HTTPS ou de clés et d’un KMS. Ces deux techniques permettent également de valider en partie l’identité de votre interlocuteur. Ensuite, ne faites confiance à aucune entrée provenant d’une fonction ou d’un service avec lequel vous communiquez, même s’il s’agit d’une autre fonction. Si une fonction fait implicitement confiance à une autre fonction, sans parler d’un service tiers, vous créerez rapidement une chaîne fragile qui cédera dès qu’un composant deviendra malveillant ou sera compromis.

8. Plus de flexibilité, c’est une surface d’attaque plus étendue

L’un des principaux avantages du serverless est sa flexibilité : elle nous permet de déplacer le flux de contrôle vers le client et de prendre en charge davantage de cas d’usage sans toucher au code côté serveur. Malheureusement, une flexibilité accrue donne aussi aux attaquants plus d’occasions de pousser votre système à effectuer des actions imprévues. Pour reprendre les mots de Mark Nunnikhoven : « Les développeurs cherchent à résoudre un problème ; la sécurité s’intéresse à tout ce que ces solutions pourraient permettre de faire d’autre. »

Pour répondre à cette préoccupation, il faut considérer chaque fonction comme un périmètre de sécurité à part entière. Chaque fonction doit donc assainir ses entrées et ses sorties, protéger ses données et veiller à sécuriser son code et ses dépendances. Aujourd’hui, la plupart des systèmes ont un périmètre externe bien défini, mais un intérieur peu protégé. Le FaaS élargit considérablement ce périmètre et exige donc un éventail de protections plus vaste.

Heureusement, le FaaS offre deux excellentes possibilités de mettre en place une protection aussi étendue. Premièrement, les fonctions sont naturellement plus petites. Il est donc plus facile (même si cela reste complexe) de définir précisément ce qu’elles peuvent ou ne peuvent pas faire par rapport à une application complète, puis de faire respecter ces limites dans le code et les tests unitaires. Deuxièmement, les fonctions sont généralement appelées par des acteurs externes via l’API Gateway, qui vous permet de définir un modèle ou un schéma pour les appels, et donc de mieux encadrer les entrées et les sorties autorisées. Ne passez pas à côté de ces possibilités et sécurisez chaque fonction individuellement.

9. La surveillance de la sécurité devient extrêmement difficile

Le serverless rend le déploiement de code incroyablement facile. Le déploiement d’une fonction en production est pratiquement gratuit, et les coûts d’exécution sont si faibles et si finement répartis qu’une fonction peu utilisée apparaît à peine sur votre facture. Nous n’avons donc aucune incitation financière à ne pas déployer une fonction ou à la supprimer une fois déployée. Pour ne rien arranger, il n’existe aucun moyen simple de savoir qui utilise une fonction. Il devient donc très risqué de supprimer une fonction après son déploiement, ce qui favorise la prolifération de milliers de fonctions rarement utilisées.

Réduire les obstacles au déploiement est un formidable levier de productivité, mais crée un véritable casse-tête en matière de sécurité. Chaque fonction déployée représente une cible d’attaque potentielle et peut présenter des vulnérabilités exploitables pour pénétrer dans vos réseaux privés, manipuler votre base de données ou lancer des attaques en votre nom. Les dépendances applicatives intégrées à ces fonctions vont devenir obsolètes, et de nouvelles vulnérabilités y seront découvertes, ce qui facilitera l’automatisation de ces exploits. La complexité de la supervision des systèmes explique pourquoi il est si facile d’exploiter des dépendances vulnérables et si difficile de s’en prémunir.

Pour ne rien arranger, les solutions de supervision de sécurité existantes ne fonctionnent pas dans un environnement serverless. La plupart nécessitent un agent sur un serveur persistant (qui n’existe désormais plus), entraînent une surcharge au démarrage et à l’exécution trop élevée pour être raisonnable dans un environnement FaaS, et ne peuvent pas évoluer à la demande comme les plateformes serverless. De plus, elles sont conçues autour d’une application de bout en bout : leur logique et leur interface ne sont pas adaptées à l’extrême granularité du serverless.

Ce défi concerne tout l’écosystème et exige de nouvelles approches. Veillez à suivre de près les fonctions déployées, leurs utilisateurs et les dépendances qu’elles utilisent. Même si le coût opérationnel de l’exécution d’une fonction est faible, gardez à l’esprit le coût total de possession, notamment le risque accru lié à la présence en production de code inutilisé, vulnérable ou obsolète.

Au fil du temps, les solutions de supervision de la sécurité à l’exécution devront évoluer et s’adapter à un fonctionnement sans agents, avec une faible surcharge et une capacité à passer à l’échelle de façon massive. Nous avons également besoin d’alternatives aux solutions de supervision de l’infrastructure, qui permettent de suivre les dépendances applicatives vulnérables dans toutes les fonctions et de vous aider à mettre à jour ou à supprimer les fonctions problématiques. Chez Snyk, nous comptons contribuer à cet effort et travaillons à étendre notre solution CI/CD pour les dépendances applicatives vulnérables afin de superviser directement les fonctions déployées. Faites-nous savoir si vous souhaitez participer à la bêta !

Résumé

Le serverless est formidable et révolutionne la façon dont nous exploitons les applications. Il provoque aussi un bouleversement tout aussi profond dans le domaine de la sécurité : il résout certains problèmes, en accentue d’autres et rebat les cartes pour tous les autres. Dans cet article, j’ai tenté de présenter les trois principaux domaines dans lesquels le FaaS est meilleur, équivalent ou moins performant pour la sécurité web, par rapport à d’autres techniques de cloud computing. Voici un tableau récapitulatif :

Le serverless étant une approche récente, nous avons l’occasion d’intégrer naturellement les pratiques et les outils de sécurité à la conception des applications serverless. Je suis personnellement impatient de voir le serverless se développer et réaliser son immense potentiel, tant pour les opérations que pour la sécurité.