Bonnes pratiques de gestion des secrets dans les applications serverless

Si vous développez une application serverless, il y a de fortes chances que vos fonctions aient besoin d’accéder à des secrets ou à d’autres informations sensibles que vous stockez, comme des clés API, des jetons ou des mots de passe. Cependant, la gestion adéquate de ces secrets peut parfois s’avérer difficile.

Lorsque les utilisateurs n’adoptent pas de service de gestion des clés, ces secrets finissent malheureusement par être stockés dans le code source ou dans des fichiers manifestes. Les conséquences peuvent être désastreuses : fuite de secrets à la suite de l’exposition ou de la manipulation du code source, ou complexité accrue de la gestion des secrets, notamment pour la rotation et la révocation des clés.

Vous pouvez télécharger le PDF de la fiche pratique sur la sécurité serverless ou lire la version en ligne de cet article.

Voici un exemple de méthode non sécurisée pour gérer les secrets :

service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ABCDEF

  goodbyeWorld:
    handler: goodbye.get

Commençons par examiner les aspects positifs de cette structure. La fonction helloWorld applique efficacement le principe d’isolation des fonctions. La variable d’environnement GITHUB_API_KEY n’est accessible qu’à la fonction appelée, et à aucune autre fonction du code, en l’occurrence goodbyeWorld.

En revanche, le jeton secret de GITHUB_API_KEY est codé en dur dans le fichier manifeste serverless.yml, qui mêle les problèmes de configuration et de gestion des secrets. Cela peut entraîner une exposition des informations si ce fichier manifeste est publié ou partagé avec d’autres utilisateurs.

L’exemple suivant utilise AWS Systems Manager, conçu pour récupérer les secrets chiffrés de manière sécurisée par AWS Parameter Store. Dans notre exemple, la variable SSM sert à accéder à une valeur spécifique créée au préalable, afin de la rendre accessible à une fonction par l’intermédiaire d’une variable d’environnement :

service:
 name: hello-world

provider:
  name: aws

functions:
  helloWorld:
    handler: helloworld.get
    environment:
      GITHUB_API_KEY: ${ssm:/github/api-key}

Notez que ${ssm:/github/api-key} renvoie la valeur chiffrée de cette clé. Pour la déchiffrer et renvoyer sa valeur réelle, vous devez spécifier ${ssm:/github/api-key~true}.

Pour en savoir plus sur Parameter Store et Key Management Service (KMS), consultez la documentation d’Amazon sur Parameter Store.

Pour améliorer encore la sécurité et la flexibilité de la gestion des secrets de vos applications, pensez à accéder aux secrets et aux autres informations de configuration au moment de l’exécution, plutôt qu’à utiliser des variables d’environnement, qui nécessitent le redémarrage d’un processus pour appliquer la nouvelle configuration.

Effectuez régulièrement la rotation des clés et des identifiants

Le stockage de vos secrets réduit le risque de fuite d’une clé, mais ne l’élimine pas complètement. Heureusement, si vous stockez les secrets utilisés par votre fonction, la valeur réelle de la clé importe peu… vous pouvez donc la renouveler régulièrement ! Ainsi, en cas de fuite ou de vol, la clé ne pourra être utilisée que pendant une courte période avant d’expirer.

La rotation des clés est une opération simple qui peut être effectuée régulièrement avec un KMS. Elle peut toutefois s’avérer un peu plus complexe lorsqu’elle implique d’autres systèmes. Si une clé est nécessaire pour accéder à un système tiers, renseignez-vous sur l’API proposée par ce tiers afin de savoir si la rotation de la clé peut être automatisée. Si c’est possible, créez une tâche récurrente qui génère une nouvelle clé, met à jour le jeton dans le KMS et expire ou place l’ancienne clé sur liste noire à l’itération suivante. Ainsi, seules deux clés sont actives à un moment donné. Comme vos fonctions ont une durée de vie très courte, elles adoptent rapidement la nouvelle clé, ce qui vous permet de désactiver l’ancienne et de recommencer la rotation régulièrement, chaque jour ou même chaque heure.

En résumé

En conclusion, nous vous recommandons d’utiliser une solution de stockage sécurisée pour vos secrets et identifiants sensibles, prise en charge par les principaux fournisseurs de cloud et de FaaS. Vous pouvez également déployer votre propre solution, comme Vault de HashiCorp. Stocker les clés dans un coffre de secrets réduit les risques liés à la présence d’informations sensibles dans des fichiers statiques d’un dépôt de code source ou dans des variables d’environnement, et diminue considérablement les risques d’exposition. Pour en savoir plus sur les outils de gestion des secrets et les bonnes pratiques, cliquez ici.

Créez dès maintenant un compte Snyk gratuit pour renforcer la sécurité de vos projets.