Comment améliorer l’observabilité, la surveillance et la sécurité du serverless

Les fonctions ont souvent une durée de vie courte, sont déployées en grand nombre et sont invoquées de plus en plus fréquemment à mesure que votre activité évolue. Pour ces raisons, il est facile de perdre le fil des événements ou de déterminer la cause première d’une erreur donnée.

De plus, à mesure que l’adoption du serverless progresse au sein d’une organisation, il devient aussi plus complexe de surveiller les flux non sécurisés et les tentatives malveillantes d’attaquants qui cherchent à forcer une fonction à emprunter un chemin d’exécution non sécurisé.

Pour déployer des fonctions tout en préservant la sécurité, nous vous recommandons de :

• Documenter les environnements dans lesquels les fonctions sont déployées

• Surveiller les vulnérabilités de sécurité et les accès aux ressources

• Utiliser des journaux tout en protégeant les données sensibles

J’ai partagé d’autres conseils sur la sécurité du serverless dans un précédent article : 10 bonnes pratiques de sécurité pour le serverless. Vous voudrez probablement l’ajouter à vos favoris pour le lire plus tard. Mais pour l’instant, poursuivons avec les pratiques de surveillance et de journalisation que vous pouvez appliquer à vos projets serverless dans le cloud.

Améliorer la visibilité sur les environnements auxquels appartiennent les fonctions

Les fonctions sont pratiquement gratuites, puisqu’elles ne coûtent que lorsqu’elles sont invoquées. Nous en déployons donc beaucoup. Cependant, au fil du temps, chaque fonction devient un risque pour la sécurité, car elle peut donner accès à notre réseau et à nos données. De plus, les bibliothèques utilisées par chaque fonction peuvent devenir obsolètes et vulnérables. Enfin, une fois déployée, une fonction est difficile à supprimer : la visibilité sur son propriétaire et sur les responsabilités de l’organisation à son égard peut être floue, voire inexistante.

Pour ne pas perdre de vue les fonctions, leur objectif et les environnements correspondants, définissez :

• des règles strictes pour les fonctions que vous déployez, afin de déterminer facilement lesquelles sont destinées à la production à long terme, lesquelles sont expérimentales, lesquelles sont utilisées par les services administratifs, etc.

• des consignes claires indiquant quand une fonction doit être supprimée

AWS a récemment introduit la possibilité d’ajouter des balises aux fonctions Lambda afin de faciliter leur suivi et leur regroupement. Avec le framework Serverless, nous pouvons ajouter des balises aux fonctions dans leurs fichiers YAML, soit de manière globale (pour toutes les fonctions du fichier serverless.yml), soit individuellement :

1 service:
2  name: hello-world
3
4 provider:
5  name: aws
6  runtime: nodejs8.10
7  stage: ${opt:stage, 'dev'}
8  region: ${opt:region, 'us-east-1'}
9  profile: production
10  tags:
11    foo: bar
12    baz: qux
13  functions:
14    helloWorld:
15      handler: helloworld.get
16      name: helloworld
17      description: My function
18      tags:
19        foo: bar

Le code ci-dessus présente deux types de balises disponibles pour les fonctions Lambda sur AWS :

• La ligne 10 présente des balises globales dans le déploiement serverless.yml, associées à toutes les fonctions

• La ligne 18 présente une balise foo associée uniquement à la fonction helloWorld

Surveiller les vulnérabilités de sécurité des fonctions

Il existe de nombreuses façons de déployer des fonctions, et leur nombre peut rapidement devenir incontrôlable. Au fil du temps, le code et les dépendances de ces fonctions peuvent devenir obsolètes et vulnérables, à mesure que les efforts de maintenance diminuent et que l’attention se porte sur d’autres projets.

Vous devez utiliser une solution intégrée à votre fournisseur de fonctions en tant que service (FaaS) afin de surveiller les fonctions déployées et de veiller à leur sécurité. Vous pourrez ainsi traiter les vulnérabilités connues tout au long du cycle de développement logiciel, en ce qui concerne les fonctions et leur utilisation de dépendances open source.

L’image suivante montre le projet GitHub lirantal/bazz-serverless après son analyse. Le projet présente plusieurs vulnérabilités de gravité élevée, moyenne et faible. Il s’agit du code source de mon projet serverless, qui déploie plusieurs fonctions. Sous le dépôt du projet GitHub, vous pouvez voir les six fonctions AWS Lambda que j’ai déployées. Ce sont les fonctions réelles, telles qu’elles sont déployées et exécutées par AWS.

Snyk a analysé chacune de ces fonctions pour détecter les vulnérabilités de sécurité connues. Comme elles utilisent toutes le même arbre de dépendances, nous pouvons voir qu’elles sont déployées avec des bibliothèques vulnérables.

Il est intéressant de constater que quatre vulnérabilités de faible gravité sont détectées dans le dépôt du projet, mais pas dans les fonctions individuelles. Cela s’explique par le fait que la version déployée diffère de celle stockée dans le dépôt Git. Plus précisément, la fonction déployée est obsolète : elle ne comprend pas une bibliothèque que j’avais ajoutée au code source.

Si je n’avais pas suivi la sécurité de mon projet, j’aurais pu continuer à déployer en production des bibliothèques vulnérables et ainsi élargir la surface d’attaque de l’application que je développe.

Surveiller les accès aux ressources

Imaginez qu’un attaquant exploite une vulnérabilité dans une fonction Node.js qui bloque la boucle d’événements en la contraignant à effectuer pendant longtemps des calculs intensifs sur le processeur. Ce problème peut être difficile à détecter en raison du fonctionnement du modèle des fonctions en tant que service : les fonctions sont lancées à la demande pour traiter de nouvelles requêtes. Cette fonctionnalité semble excellente, et elle l’est sans doute à certains égards, mais elle peut aussi faire grimper votre facture cloud, puisque les fonctions sont facturées à l’utilisation.

Élaborez une stratégie de surveillance : mettez en place des politiques, des alertes et des mesures d’application pour repérer et bloquer les invocations de fonctions non souhaitées. Pensez à surveiller les ressources suivantes :

• Processeur

• Mémoire

• Consommation et opérations d’entrée et de sortie

• Accès aux fichiers, notamment en lecture et en écriture

• Durée d’exécution des fonctions

• Flux d’invocation des fonctions et anomalies par rapport aux sources d’invocation attendues

• Exécutions de processus enfants

Les fournisseurs cloud intègrent souvent des fonctionnalités de surveillance des ressources des applications et des fonctions, qui permettent d’obtenir ces informations. Microsoft propose Azure Monitoring, tandis qu’Amazon propose AWS X-Ray. À titre d’exemple, la documentation officielle d’AWS présente la console AWS X-Ray, qui fournit des informations sur les flux de données entre les fonctions et les autres ressources cloud, ainsi que sur des métriques telles que la durée d’exécution.

Une fois la surveillance en place, appliquez des limites aux fonctions afin de mieux prévenir l’épuisement des ressources financières.

Journaliser les fonctions

Les journaux sont logiquement regroupés par ensemble de fonctions, ce qui fournit des informations précieuses supplémentaires. Toutefois, s’ils sont mal gérés, ils peuvent aussi entraîner des problèmes de sécurité supplémentaires.

Pour tirer le meilleur parti des journaux :

• Privilégiez une journalisation détaillée des événements, de leur contexte et des informations sur les défaillances

• Tirez parti des services de journalisation cloud

• Mettez en place un système centralisé de gestion des journaux pour permettre à votre équipe de déboguer facilement et de trouver les événements

• Associez les journaux et les événements particuliers à des seuils et à des alertes. Ainsi, au-delà de leur rôle de piste d’audit, les journaux permettent également d’envoyer des alertes lorsque des problèmes nécessitent une intervention immédiate.

Cela dit, veillez à ne pas journaliser d’informations sensibles, comme des identifiants, ni à journaliser excessivement des données telles que les variables d’environnement. Veillez également à respecter la réglementation locale en matière de RGPD afin qu’aucune donnée à caractère personnel ne soit journalisée.

En résumé

Je vous invite à lire cette liste plus détaillée de 10 bonnes pratiques de sécurité pour le serverless pour en savoir plus sur les enjeux de sécurité liés au développement et au déploiement de fonctions serverless.