Sécuriser les fonctions serverless FaaS

Sécuriser les fonctions serverless FaaS

Le serverless, ou FaaS (Function as a Service), retire les serveurs de la liste des responsabilités directes, pas les risques de la liste des incidents. Chaque fonction devient une frontière de sécurité autonome, avec son événement, son rôle IAM (Identity and Access Management), ses dépendances et ses secrets.

Explication de la marmotte

Une fonction hébergée ressemble à un employé recruté pour une tâche très précise, appelé seulement quand un dossier arrive sur son bureau. Si cet employé possède les clés de tous les bureaux et accepte n’importe quel dossier, une erreur minuscule devient vite une fuite beaucoup moins minuscule.

→ Lire l’explication complète de la marmotte

Le compromis de sécurité du serverless

Le modèle change la répartition des responsabilités. Le fournisseur opère l’hyperviseur, le système d’exploitation hôte, le réseau physique et généralement le mécanisme d’isolation des exécutions. Le client reste responsable du code, de la configuration réseau de la fonction, des événements reçus, des identités attachées, des données manipulées et des bibliothèques embarquées.

Le gain est réel : pas de serveur applicatif à corriger, pas de démon à surveiller, pas de compte administrateur système à déléguer. Le prix est une multiplication des unités de sécurité. Une application composée de vingt fonctions ne possède pas une identité technique : elle devrait en posséder vingt, avec vingt politiques d’accès et vingt surfaces d’entrée à examiner.

La recommandation est nette : considérer chaque fonction comme un microservice exposé, même lorsqu’elle contient trente lignes de code. Une fonction courte n’est pas une fonction inoffensive. C’est souvent l’inverse : le code paraît trop petit pour mériter une revue, alors qu’il porte un rôle capable de lire un coffre de secrets ou d’effacer un préfixe de stockage.

La sécurité de l’infrastructure du fournisseur ne garantit ni la sécurité du code, ni l’autorisation métier, ni la confidentialité des données journali­sées. Une plateforme FaaS ne transforme pas une politique IAM trop large en politique raisonnable. Elle exécute très efficacement l’erreur demandée, ce qui est déjà beaucoup pour une erreur.

Les principes généraux de responsabilité partagée restent détaillés dans la page cloud et exploitation. Ici, le point non négociable est la granularité : une fonction, un objectif métier, une identité, un jeu de permissions minimal.

Rôles IAM par fonction et privilèges cumulés

Un rôle IAM partagé entre plusieurs fonctions est un raccourci de développement, pas une architecture. Il agrège progressivement les droits nécessaires à tous les cas d’usage : lecture d’un compartiment de stockage, publication dans une file, accès à une base de données, lecture de secrets, invocation d’autres fonctions. Après quelques itérations, chaque fonction hérite des permissions de toutes les autres. Le blast radius devient collectif.

Une politique doit autoriser une action sur une ressource nommée, sous des conditions vérifiables. Autoriser storage:* sur * parce que la fonction traite des fichiers revient à donner un passe-partout à un processus qui lit une entrée externe. Le nom du service n’est pas une frontière d’autorisation.

Séparer les rôles par fonction impose davantage de déclarations d’infrastructure, mais réduit les chemins d’escalade. Une fonction de conversion de document n’a aucune raison d’écrire dans le compartiment contenant les exports comptables. Une fonction de notification n’a aucune raison de lire le secret d’accès à la base applicative. Si elle en a une, l’architecture mélange des responsabilités qu’il faut séparer avant l’incident.

Les permissions doivent aussi porter sur les opérations. Lire un objet, écrire un objet et supprimer un objet ne sont pas trois variantes de la même autorisation. Pour les services de chiffrement, autoriser le déchiffrement doit être limité à la clé attendue et, lorsque le fournisseur le permet, à un contexte de chiffrement imposé par la fonction appelante.

Une revue IAM efficace commence par le graphe réel : événement entrant, fonction, appels sortants, données lues, données écrites, secret consulté. Les politiques sont ensuite dérivées de ce graphe, pas des exemples copiés depuis une console. La page IAM cloud couvre les mécanismes de délégation et les erreurs de confiance entre identités.

Les droits temporaires ne règlent pas le problème d’un rôle excessif. Un jeton valable quinze minutes avec le droit de supprimer toute une plateforme reste une très mauvaise idée, mais plus ponctuelle. Le secteur appelle cela du risque réduit. Les données supprimées, elles, ne font pas cette distinction philosophique.

Événements déclencheurs et validation de frontière

Un événement FaaS est une entrée non fiable, même lorsqu’il vient d’un service interne. Une notification de stockage, un message de file, un webhook ou un événement de base de données transporte des champs contrôlables directement ou indirectement par un acteur externe : nom d’objet, métadonnée, chemin, URL, contenu encodé, identifiant client.

La validation doit se faire dans la fonction, avant tout appel à un service sensible. Faire confiance au fait qu’un événement provient d’une file gérée ne valide ni son contenu ni sa provenance métier. Une file peut contenir un message rejoué, produit par une autre identité autorisée par erreur, ou injecté à travers un flux applicatif compromis.

Contrôler quatre propriétés :

1. La source : vérifier l’identité du service émetteur, le compte ou projet attendu, la ressource exacte et la région lorsque ces attributs existent.
2. Le schéma : imposer les champs admis, leurs types, leurs tailles maximales et refuser les propriétés inconnues pour les événements sensibles.
3. La sémantique : vérifier qu’un chemin cible appartient à un préfixe attendu, qu’un type de fichier est autorisé et qu’un identifiant référence un objet existant dans le domaine métier.
4. La fraîcheur et l’unicité : dédupliquer avec un identifiant persistant et borner l’âge d’un événement lorsque le protocole fournit une date fiable.

La déduplication est obligatoire dès qu’une opération produit un effet externe : débit, envoi de courriel, suppression, création d’identité. La plupart des déclencheurs livrent au moins une fois, pas exactement une fois. En cas de délai, d’erreur transitoire ou de dépassement de durée maximale, le même message peut être retraité. L’idempotence, c’est-à-dire la capacité à rejouer une opération sans modifier davantage le résultat, appartient donc au code métier.

Une fonction qui récupère une adresse fournie dans l’événement doit appliquer les contre-mesures contre la SSRF (Server-Side Request Forgery), ou falsification de requête côté serveur : liste blanche d’hôtes, résolution contrôlée, blocage des adresses privées et refus des services de métadonnées. Le scénario est traité en détail dans SSRF vers IMDS et vol d’identifiants IAM. Une validation de format n’empêche pas un serveur de contacter 127.0.0.1 avec une URL parfaitement bien formée. Le mal fait rarement des fautes de syntaxe.

Exemple de rôle dédié et de filtrage d’événement

L’exemple suivant illustre une fonction Amazon Web Services (AWS) qui lit uniquement les objets déposés sous incoming/ et écrit exclusivement des résultats sous processed/. La politique refuse le raccourci classique consistant à autoriser toutes les actions sur tous les compartiments.

# Rôle dédié à une seule fonction de traitement de documents.
# Remplacer les valeurs d'exemple avant déploiement.
Version: "2012-10-17"
Statement:
  - Sid: ReadOnlyIncomingDocuments
    Effect: Allow
    Action:
      - s3:GetObject
    Resource: arn:aws:s3:::tt-documents/incoming/*

  - Sid: WriteOnlyProcessedDocuments
    Effect: Allow
    Action:
      - s3:PutObject
    Resource: arn:aws:s3:::tt-documents/processed/*

  - Sid: WriteFunctionLogs
    Effect: Allow
    Action:
      - logs:CreateLogStream
      - logs:PutLogEvents
    Resource: arn:aws:logs:eu-west-3:123456789012:log-group:/aws/lambda/document-handler:*

# Aucun droit de suppression, de listage global ou de lecture de secrets.

Le contrôle applicatif doit compléter cette politique. Une autorisation IAM limite les ressources accessibles, mais ne garantit pas que le fichier reçu est un document acceptable.

# Refuser les événements hors de la source et du préfixe attendus.
def handle(event):
    record = event["Records"][0]
    bucket = record["s3"]["bucket"]["name"]
    key = record["s3"]["object"]["key"]

    if bucket != "tt-documents":
        raise ValueError("Compartiment inattendu")

    if not key.startswith("incoming/") or not key.endswith(".pdf"):
        raise ValueError("Objet hors contrat")

    # Traiter ensuite le contenu avec des limites de taille et de durée.

Le filtre configuré sur le déclencheur réduit le bruit. Le contrôle dans le code protège la frontière. Il faut les deux : le premier limite les invocations facturées et les journaux inutiles, le second reste valable si la configuration dérive ou si une source secondaire apparaît.

Dépendances embarquées et chaîne de livraison

Chaque paquet de fonction transporte un fragment de chaîne logistique logicielle. Une dépendance vulnérable peut être présente dans dix fonctions, avec dix versions et dix cycles de correction. Le gestionnaire de paquets a résolu les versions, pas le risque. Il n’a jamais prétendu faire de la gouvernance, malgré l’optimisme souvent observé autour des fichiers de verrouillage.

L’inventaire doit être produit par paquet déployable sous forme de SBOM (Software Bill of Materials), ou inventaire des composants logiciels. Cet inventaire doit lier : nom de la fonction, version du paquet, empreinte cryptographique, dépendances directes et transitives, environnement d’exécution, date de construction et source de l’artefact.

Scanner le dépôt source ne suffit pas. Le scan doit viser l’archive réellement publiée, y compris les couches partagées, les binaires compilés et les dépendances installées lors de la construction. Une bibliothèque ajoutée par une image de base ou une couche commune reste exploitable avec une grande régularité, indépendamment de son absence dans le manifeste applicatif.

Épingler les versions dans un fichier de verrouillage, vérifier les empreintes des paquets et interdire les dépendances téléchargées durant l’exécution. Une fonction qui télécharge du code au démarrage rend l’analyse de l’artefact décorative. La reproductibilité disparaît, suivie rapidement par la capacité à expliquer un incident.

Les secrets ne doivent jamais être embarqués dans le paquet, dans les variables de construction ni dans les journaux. La fonction récupère un secret à l’exécution depuis un service dédié, avec un droit de lecture limité à ce secret. La rotation doit préserver une période de chevauchement si le protocole aval accepte deux valeurs, puis invalider l’ancienne version. Une rotation qui casse toutes les invocations est une alarme coûteuse déguisée en contrôle de sécurité.

Exploitation, supervision et reprise des fonctions

La journalisation doit permettre de relier un événement entrant à une invocation, aux appels sortants et à la décision prise, sans stocker le contenu brut sensible. Journaliser un jeton d’accès, un mot de passe ou un document complet pour diagnostiquer un échec convertit la plateforme de logs en coffre-fort sans serrure. Les identifiants de corrélation et les empreintes de contenu sont préférables.

Superviser au minimum les refus de validation, les erreurs d’autorisation, les délais d’exécution, les relances, les messages placés en file d’échec et les lectures anormales de secrets. Une hausse d’invocations peut signaler un trafic légitime, une boucle de déclenchement ou une attaque par épuisement de budget. Les trois coûtent de l’argent, mais un seul mérite d’être célébré.

Une file d’échec conserve les messages qui dépassent le nombre de tentatives autorisé. Elle n’est pas une sauvegarde : sans procédure de tri, de correction et de rejeu contrôlé, elle devient une fosse commune de données métier. Prévoir un outil de rejeu qui réapplique la validation courante et utilise une identité distincte, limitée à cette opération.

La reprise exige aussi de sauvegarder les déclarations d’infrastructure, les politiques IAM, les configurations de déclencheurs, les paramètres de chiffrement et les versions de paquets. Restaurer seulement le code ne restaure pas le système. Les fonctions retrouvent alors leurs droits par défaut, leurs sources d’événements oubliées, ou pire, les deux.

🐝 Ce qui arrive si on s’en passe

Sans rôles dédiés ni validation d’entrée, l’analyse post-incident perd sa principale boussole : plusieurs fonctions partageant une même identité technique, rien ne permet de dire laquelle a réellement émis un appel, et la question « quelles données ont été atteintes » reste sans réponse démontrable. La révocation devient tout ou rien, puisque retirer une permission abusive coupe aussi les traitements légitimes qui s’y sont adossés. Sans inventaire des composants par artefact déployé, la publication d’une vulnérabilité dans une bibliothèque courante n’a pas de périmètre : il faut rouvrir chaque paquet pour savoir s’il est concerné, ce qui allonge le délai de correction. Sans déduplication ni file d’échec triée, un message rejoué multiplie des effets externes irréversibles et des invocations facturées, sans qu’aucun compteur ne distingue une boucle de déclenchement d’une charge normale.

🦫 Explication de la marmotte 🍫

Une fonction hébergée est un petit programme lancé quand un événement arrive, par exemple l’ajout d’un fichier ou la réception d’un message. Le fournisseur protège les machines qui exécutent ce programme, mais ne décide pas ce que le programme a le droit de faire. Cette décision reste à la charge de l’équipe qui le configure.

Chaque fonction doit recevoir une autorisation séparée. Une fonction qui transforme un fichier doit pouvoir lire ce fichier et enregistrer son résultat, pas consulter tous les documents ni supprimer des données. Si plusieurs fonctions partagent les mêmes autorisations, une erreur dans une seule peut donner accès à tout ce que les autres utilisent.

Avant de traiter un événement, le programme vérifie sa provenance, sa structure et ses valeurs. Un nom de fichier, une adresse internet ou un message reçu peuvent avoir été préparés pour provoquer une action dangereuse. Si la vérification échoue, le programme s’arrête sans accéder aux données.

Le programme contient aussi des bibliothèques externes. Elles doivent être recensées et contrôlées dans le paquet réellement envoyé, car une faille dans une bibliothèque peut toucher chaque fonction qui l’embarque. Enfin, les accès, les erreurs et les messages rejetés doivent être surveillés. Quand une fonction échoue plusieurs fois, le message est isolé pour analyse plutôt que rejoué indéfiniment.

À lire aussi

• Comment bloquer les requêtes côté serveur et la désérialisationSSRF et désérialisation permettent de détourner une application malgré un pare-feu correctement configuré.
• Comment gouverner les coûts cloud contre un compte compromisLa gouvernance des coûts cloud limite l'impact financier d'un compte compromis en complétant la détection, les identités et la réponse à incident.
• Comment revoir le code de sécurité au-delà du linterUne revue de code orientée sécurité couvre les failles de conception, les hypothèses métier et les chemins d'exploitation qu'un linter ne peut pas déduire.
• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoiDéfinition du cloud computing selon le NIST, modèles de service IaaS, PaaS, SaaS et modèles de déploiement, avec ce que chacun délègue réellement en sécurité et ce qu'il laisse au client.

Pages voisines

La citent

• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
• L'entropie au démarrage

Sécuriser les fonctions serverless FaaS

Elle cite

• Détecter la persistance IAM dans AWS
• Quotas cloud contre le déni de service par coût
• Comment sécuriser les webhooks entrants
• Générer un SBOM CycloneDX dans un pipeline CI
• SSRF vers IMDS et vol d’identifiants IAM