Sécurité des environnements sans serveur et des fonctions

L’informatique sans serveur (Functions as a Service, FaaS) permet aux développeurs de déployer des fonctions individuelles déclenchées par des événements — requêtes HTTP, messages de file d’attente, déclencheurs de base de données ou minuteries planifiées — sans gérer les serveurs sous-jacents. Les principales plateformes incluent AWS Lambda, Google Cloud Functions et Azure Functions. Le fournisseur cloud gère l’application des correctifs, la mise à l’échelle et l’infrastructure. Si cela réduit la charge opérationnelle, la répartition des responsabilités en matière de sécurité est modifiée : le fournisseur sécurise l’environnement d’exécution, mais le développeur est seul responsable du code des fonctions, des autorisations et de la configuration.

Les fonctions sans serveur présentent une surface d’attaque distincte de celle des applications traditionnelles : elles sont généralement à courte durée de vie (de quelques secondes à quelques minutes), ce qui rend la surveillance réseau et les solutions EDR traditionnelles moins efficaces ; elles sont pilotées par les événements, ce qui signifie que de nombreuses sources d’entrée différentes (événements S3, API Gateway, SNS) peuvent déclencher leur exécution ; elles s’exécutent souvent avec des autorisations IAM permettant d’accéder à d’autres ressources cloud ; et elles utilisent des dépendances tierces (paquets npm et pip) susceptibles de contenir du code malveillant. La surface d’attaque est définie par les entrées d’événements, les autorisations IAM et les chaînes de confiance des dépendances.

La vulnérabilité de sécurité la plus courante dans l’informatique sans serveur concerne les rôles IAM trop permissifs. Lorsqu’un développeur doit permettre à une fonction d’accéder à un seul compartiment S3, il peut être tentant de lui attribuer s3:* (accès complet à S3) pour éviter les erreurs d’autorisation. Une fonction compromise ou vulnérable dotée de ce rôle peut alors lire, écrire ou supprimer n’importe quel compartiment du compte. La défense consiste à appliquer strictement le principe des rôles IAM avec le moindre privilège : chaque fonction doit disposer d’un rôle dédié accordant uniquement les autorisations minimales nécessaires à ses tâches précises. Des outils comme AWS IAM Access Analyzer et Cloudsplaining détectent automatiquement les rôles Lambda trop permissifs.

Une injection d’événement se produit lorsque des données contrôlées par un attaquant et contenues dans la charge utile d’un événement sont traitées de manière non sécurisée par le code de la fonction. Comme les fonctions sans serveur peuvent être déclenchées par de nombreuses sources d’événements — en-têtes HTTP, paramètres de requête, enregistrements de modification de base de données, corps de messages de file d’attente et contenu d’e-mails — chacune d’elles peut transporter une charge utile malveillante. Les types d’injection courants incluent : l’injection SQL si la fonction interroge une base de données à partir de données d’événement, l’injection NoSQL (opérateurs MongoDB dans des charges utiles JSON), l’injection de commandes si les données d’événement sont utilisées dans des commandes du système d’exploitation, et la SSRF (falsification de requête côté serveur) si des URL provenant des données d’événement sont récupérées. La validation des entrées et les requêtes paramétrées sont des défenses essentielles.

Les fonctions sans serveur dépendent fréquemment de dizaines de paquets tiers. Ces dépendances introduisent un risque pour la chaîne d’approvisionnement : un paquet malveillant ou compromis peut exécuter du code arbitraire dans l’environnement d’exécution de la fonction, accéder aux variables d’environnement (qui contiennent souvent des secrets), établir des connexions réseau sortantes et utiliser le rôle IAM de la fonction pour accéder aux ressources cloud. Des attaques très médiatisées, comme la compromission du paquet npm event-stream en 2018, ainsi que de nombreux paquets pratiquant le typosquattage, illustrent ce risque. Les défenses incluent le verrouillage des dépendances, l’analyse SCA dans l’intégration et la livraison continues, ainsi qu’un nombre minimal de dépendances.

Les fonctions sans serveur reçoivent souvent des secrets par l’intermédiaire de variables d’environnement configurées dans la console cloud. Ces variables d’environnement sont visibles par toute personne disposant d’un accès IAM à la configuration Lambda et peuvent être consultées par tout code exécuté dans la fonction. Bonnes pratiques : évitez de stocker directement les secrets sous forme de texte en clair dans les variables d’environnement ; stockez plutôt des ARN ou des noms de secrets, puis récupérez les secrets lors de l’exécution depuis AWS Secrets Manager ou Parameter Store ; activez le chiffrement KMS des variables d’environnement Lambda au repos ; et ne journalisez jamais les variables d’environnement (de nombreux outils de journalisation de débogage consignent toutes les variables d’environnement en cas d’erreur).

Le déni de service visant des fonctions sans serveur peut prendre la forme d’une saturation par les invocations : un attaquant capable de déclencher une fonction de manière répétée peut épuiser la limite de concurrence du compte (la valeur par défaut de Lambda est de 1 000 exécutions simultanées par région), empêchant ainsi les autres fonctions du compte de s’exécuter. Les fonctions qui traitent des entrées contrôlées par l’utilisateur doivent appliquer une limitation du débit au niveau d’API Gateway, valider les limites de taille des charges utiles et définir des valeurs de délai d’expiration appropriées afin d’empêcher les exécutions incontrôlées. Les fonctions peuvent également être ciblées par des attaques d’expansion de type Billion Laughs lors de l’analyse XML/YAML si la taille des entrées n’est pas limitée.

Par défaut, les fonctions AWS Lambda s’exécutent dans un VPC géré par AWS avec un accès à Internet, mais sans accès aux ressources de votre VPC privé (bases de données RDS, ElastiCache et API privées). Pour accéder aux ressources privées, Lambda doit être configuré pour s’exécuter dans votre VPC, avec des sous-réseaux et des groupes de sécurité précis. Toutefois, les fonctions Lambda rattachées à un VPC n’ont pas accès à Internet par défaut : elles ont besoin d’une passerelle NAT pour accéder à Internet en sortie. Les groupes de sécurité associés aux fonctions Lambda doivent respecter le principe du moindre privilège : n’autorisez que les ports et destinations nécessaires. Évitez d’utiliser des règles sortantes 0.0.0.0/0 dans les groupes de sécurité des fonctions de production.

La surveillance de la sécurité sans serveur nécessite des approches différentes de la surveillance traditionnelle des hôtes. Les fonctions étant éphémères, les agents installés sur les hôtes sont peu pratiques. Une surveillance efficace utilise : AWS CloudTrail pour journaliser tous les appels d’API Lambda (invocations, modifications de configuration et prises de rôle) ; CloudWatch Logs Insights pour interroger les journaux d’exécution des fonctions à la recherche de schémas anormaux ; Amazon GuardDuty pour détecter les menaces, notamment les activités réseau Lambda inhabituelles ; ainsi que des outils commerciaux de sécurité natifs sans serveur comme Protego (qui fait désormais partie de Check Point) ou la surveillance sans serveur de Datadog, qui instrumente les fonctions au moyen de couches afin de fournir une visibilité lors de l’exécution.

Tester la sécurité sans serveur nécessite des outils spécifiques : PureSec CLI (désormais Check Point) et Prowler analysent les configurations cloud à la recherche d’erreurs de configuration sans serveur ; les outils DAST peuvent tester les fonctions déclenchées par HTTP afin de détecter les vulnérabilités d’injection ; l’analyse statique du code des fonctions avec des outils comme Bandit (Python) ou des modules de sécurité ESLint détecte les pratiques de codage non sécurisées ; et les tests manuels doivent répertorier toutes les sources d’événements susceptibles de déclencher chaque fonction, puis tester chacune d’elles avec des charges utiles malformées et malveillantes. L’OWASP Serverless Top 10 fournit une liste complète de vérifications des vulnérabilités propres aux architectures sans serveur.

L’informatique sans serveur étend davantage le modèle de responsabilité partagée vers le fournisseur. Le fournisseur cloud est responsable de l’environnement d’exécution des fonctions, des correctifs du système d’exploitation, de la sécurité de l’infrastructure sous-jacente et des installations physiques. Le client reste responsable de la sécurité du code des fonctions, de la conception des autorisations IAM, de la gestion des secrets, de la validation des entrées, de la gestion des dépendances, de la configuration de la journalisation et des politiques réseau. La réduction de la responsabilité liée à l’infrastructure ne signifie pas une réduction de la responsabilité en matière de sécurité : elle déplace simplement le centre des investissements de sécurité, principalement vers la sécurité au niveau des applications et la sécurité IAM.

Évaluez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les rôles IAM trop permissifs constituent le principal risque de l’informatique sans serveur — chaque fonction a besoin d’un rôle dédié appliquant le principe du moindre privilège ; les attaques par injection d’événements exploitent toute source d’événements transmettant des données contrôlées par un attaquant à des fonctions dépourvues de validation des entrées ; et le risque pour la chaîne d’approvisionnement des dépendances provenant de paquets tiers peut compromettre l’exécution des fonctions, avec un accès aux identifiants IAM et aux secrets. Nous allons maintenant étudier l’analyse de sécurité de l’infrastructure en tant que code afin de détecter les erreurs de configuration avant le déploiement.