Qu'est-ce que la sécurité sans serveur ?
Sommaire
Serverless fait référence à un modèle de développement cloud-native dans le cloud computing qui permet aux développeurs de construire et d'exécuter des applications et des services sans avoir besoin de gérer l'infrastructure, ou l'informatique côté serveur. Les applications du modèle sans serveur s'appuient sur une combinaison de services cloud gérés et de fonctions en tant que service (FaaS) qui font abstraction de la nécessité de gérer, de patcher et de sécuriser l'infrastructure et les machines virtuelles.
Avantages de l'architecture sans serveur
D'ici 2020, 40 % des organisations ont déclaré avoir pleinement adopté l'architecture sans serveur, selon O'Reilly. Dans les années qui ont suivi, le serverless est devenu un environnement d'exécution d'applications dominant. Le State of Cloud Native Security Report 2024 montre une nouvelle croissance à l'horizon, puisque 70 % des répondants à l'enquête ont déclaré des augmentations d'utilisation prévues au cours des 24 prochains mois.
L'adoption d'un modèle sans serveur profite au développement d'applications de plusieurs façons :
- Réduction des frais généraux opérationnels : Sans serveurs à gérer, les développeurs et DevOps n'ont pas à se soucier de la mise à l'échelle de l'infrastructure, de l'installation et de la maintenance des agents, ou d'autres opérations liées à l'infrastructure.
- Une plus grande agilité : Étant donné que les applications sans serveur s'appuient fortement sur des services gérés pour des éléments tels que les bases de données et l'authentification, les développeurs sont libres de se concentrer sur la logique métier réelle de l'application, qui s'exécutera généralement sur un FaaS, tel que AWS® Lambda ou Google Cloud Functions.
- Réduction des coûts : Avec la plupart des services utilisés dans les applications sans serveur, le client ne paie que pour l'utilisation. Par exemple, avec AWS Lambda, les clients paient pour les exécutions de leurs fonctions. Cela a généralement un impact significatif sur les coûts, car ils n'ont pas à payer pour la capacité inutilisée comme c'est le cas avec les machines virtuelles.
Les applications sans serveur nécessitent une sécurité sans serveur.
Chaque avancée majeure dans le développement de logiciels et les opérations informatiques s'accompagne d'une modification des vecteurs d'attaque et des risques de sécurité. Au début de la virtualisation vers les conteneurs, les professionnels de la sécurité ont dû s'adapter et trouver de nouvelles façons de durcir, de défendre et de gouverner leur infrastructure. Le concept d'application sans serveur présente l'un des plus grands changements de paradigme jamais vus en matière de sécurité des applications.
Traditionnellement, les organisations protégeaient leurs applications en s'appuyant sur des outils basés sur l'infrastructure et le réseau. Ils inspectent le trafic à l'aide d'un pare-feu, tentent de détecter les activités malveillantes à l'aide d'un système de détection d'intrusion ou protègent les applications à l'aide d'une technologie d'autoprotection des applications d'exécution (RASP). Même avec les conteneurs, les organisations pouvaient encore s'appuyer sur la sécurité de l'infrastructure sous-jacente dans une certaine mesure.
Une application sans serveur se compose de services cloud distribués fonctionnant ensemble, comme un bucket S3 qui déclenche une fonction Lambda, qui à son tour déclenche DynamoDB®. Dans cette architecture, il n'y a pas de place pour les pare-feu, les outils IDS/IPS, les agents d'instrumentation ou les méthodes de protection basées sur les serveurs. Au lieu de se concentrer sur l'inspection du réseau et les listes de contrôle d'accès, le modèle sans serveur déplace le centre d'intérêt de la sécurité vers les permissions IAM, la protection comportementale et le code fort.
Vecteurs d'attaque sans serveur
L'adoption de la sécurité sans serveur donne aux applications une solide longueur d'avance du point de vue de la sécurité, puisque les organisations n'ont plus à se préoccuper de la sécurité de l'infrastructure, du réseau ou de l'hôte. Cependant, de nouveaux vecteurs d'attaque sont apparus, et des attaques familières ont été réimaginées pour les environnements sans serveur. Examinons un exemple (pour la liste complète, consultez le document Top 12 Risks for Serverless Applicationsde la Cloud Security Alliance) :
Injection de données d'événements
Les failles d'injection dans les applications, qui comptent parmi les risques les plus courants à ce jour, ont été traitées en détail dans de nombreux guides de bonnes pratiques en matière de codage sécurisé. À un niveau élevé, les failles d'injection se produisent lorsque des données non fiables sont transmises directement à un interpréteur avant d'être exécutées ou évaluées. Dans le contexte de l'architecture sans serveur, cependant, les injections de données d'événements de fonction ne sont pas strictement limitées à l'entrée directe de l'utilisateur (telle que l'entrée d'un appel d'API Web). La plupart des architectures sans serveur fournissent une multitude de sources d'événements qui peuvent déclencher l'exécution d'une fonction sans serveur.
Les exemples de sources d'injection de données d'événements sont les suivants :
- Événements de stockage dans le cloud (par exemple, AWS S3®, Azure Blob Storage, Google Cloud Storage).
- Événements de base de données NoSQL (par exemple, AWS DynamoDB, Azure Cosmos DB®)
- Événements de la base de données SQL
- Événements de traitement de flux (par exemple, Amazon Kinesis®)
- Modifications du code et nouveaux référentiels des codes
- Appels API HTTP
Chaque entrée d'événement peut inclure différents formats de message, et diverses parties de ces messages d'événement peuvent contenir des entrées contrôlées par des attaquants ou dangereuses d'une autre manière. Le riche ensemble de sources d'événements augmente la surface d'attaque potentielle et introduit des complexités lorsqu'on tente de protéger les fonctions serverless contre les injections de données d'événements. Cela est d'autant plus vrai que les architectures sans serveur ne sont pas aussi bien comprises que les environnements web où les développeurs savent quelles parties du message ne doivent pas être fiables (par exemple, les paramètres GET/POST, les en-têtes HTTP, etc.)
Protéger les applications sans serveur
Une sécurité sans serveur efficace se concentre sur la garantie de l'intégrité du code, des autorisations strictes et de l'analyse comportementale.
- Accès et autorisations : Maintenez un least-privileged access pour les fonctions sans serveur et les autres services. Par exemple, si une fonction AWS Lambda doit accéder à une table DynamoDB, assurez-vous qu'elle ne peut effectuer que l'action spécifique que la logique métier exige.
- Analyse des vulnérabilités : Garantissez l'intégrité du code et du modèle infrastructure-as-code en recherchant régulièrement les dépendances tierces vulnérables, les erreurs de configuration et les rôles trop permissifs.
- Protection de l'exécution : Utilisez la protection de l'exécution pour détecter les entrées d'événements malveillants et les comportements anormaux des fonctions, et limitez si nécessaire la capacité de chaque fonction à accéder aux fichiers, aux hôtes, à l'internet et à engendrer des processus enfants.
FAQ sur la technologie sans serveur
L'informatique sans serveur, également connue sous le nom d'architecture sans serveur, est une approche de la conception de logiciels qui permet aux ingénieurs de construire et d'exécuter des applications sans avoir à gérer l'infrastructure sous-jacente. Au lieu de cela, les fournisseurs de cloud approvisionnent des serveurs pour exécuter des applications, des bases de données et des systèmes de stockage pour les organisations numériques ou natives du cloud.
Function-as-a-Service, est un service de cloud computing qui permet aux clients d'exécuter du code en réponse à des événements, sans gérer les...
L'architecture sans serveur est un FaaS qui implique que les développeurs écrivent le code de l'application comme des ensembles de fonctions uniques conçues pour effectuer des tâches spécifiques en réponse à des requêtes HTTP ou à des événements similaires. Une fois les fonctions déployées sur le compte du fournisseur de cloud, ce dernier exécute la fonction sur un serveur fourni par le fournisseur de cloud.
Parmi les exemples de services sans serveur proposés par les fournisseurs de cloud, on peut citer Google Cloud Functions, AWS Lambda et Microsoft Azure Functions.
