Introduction : Les exigences de sécurité uniques des sans-serveur

L'informatique sans serveur a transformé la façon dont les équipes construisent et déploient des applications. En abstractionnant les serveurs, les mises à l'échelle et les patchs, les plateformes comme AWS Lambda, Azure Functions et Google Cloud Functions permettent aux développeurs de se concentrer uniquement sur la logique d'affaires. Cependant, ce changement de paradigme introduit également de nouveaux défis de sécurité, notamment en ce qui concerne la gestion des secrets et des données sensibles. Dans une application traditionnelle basée sur un serveur, les secrets résident souvent dans un coffre dédié au système de fichiers ou à l'intérieur d'une base de données protégée.

Cet article fournit un guide complet pour traiter les secrets dans des environnements sans serveur. Nous examinerons les défis fondamentaux, nous plongerons dans les meilleures pratiques, nous marcherons à travers des modèles d'implémentation concrets en utilisant les principaux fournisseurs de cloud, et discuterons comment sécuriser l'ensemble du cycle de vie des données sensibles – du développement à la production.

Comprendre les défis de la gestion secrète dans les sans-serveur

Les architectures sans serveur sont intrinsèquement apatrides. Lorsqu'une fonction est invoquée, elle fonctionne dans un conteneur qui est détruit après exécution (ou réutilisé pour une courte période). Cette nature éphémère signifie que vous ne pouvez pas compter sur des processus à long terme ou des systèmes de fichiers pour stocker des secrets.

  • Exposure in code and logs:[ Les développeurs peuvent par inadvertance commettre des secrets pour contrôler la source ou les enregistrer lors du débogage. Une fois qu'un secret est dans un flux de journaux, il peut être récupéré par toute personne ayant accès au journal – et les journaux sont souvent conservés indéfiniment.
  • Limitations des variables d'environnement:[ Bien que les variables d'environnement soient pratiques, elles sont souvent configurées pendant le déploiement et stockées en texte clair dans la configuration de la fonction. Si un attaquant obtient un accès en lecture à la configuration de la fonction (par exemple, via un pipeline CI/CD compromis), ils obtiennent le secret.
  • Cold starts and caching:[ Récupérer des secrets sur chaque invocation peut introduire la latence et le coût. Les développeurs cachent parfois des secrets en mémoire, mais le conteneur éphémère peut être réutilisé pour de multiples invocations – conduisant à des secrets inexistants ou expirés si la rotation est fréquente.
  • Auditabilité et rotation:[ Sans une voûte centralisée, il est difficile de savoir qui a accédé au secret quand, ou de faire tourner des secrets sans mettre à jour chaque fonction.

Ces défis sont aggravés par la nature distribuée et animée par des événements des applications sans serveur. Une seule fonction pourrait devoir appeler une base de données, une API externe et une file d'attente – chacune nécessitant des références distinctes.

Meilleures pratiques pour gérer les secrets et les données sensibles

La base de toute stratégie de sécurité sans serveur est le principe du moindre privilège : chaque fonction doit avoir accès uniquement aux secrets dont elle a absolument besoin, et pour une durée aussi courte que possible. Ci-dessous sont les pratiques essentielles, organisées par catégorie.

1. Utiliser des services de gestion secrète dédiés

Chaque fournisseur de cloud majeur offre un service conçu pour stocker et accéder aux secrets :

  • AWS Secrets Manager – gère les secrets avec rotation automatique et des politiques d'accès à grain fin.
  • – Azure Key Vault – stocke des secrets, des clés et des certificats, et s'intègre aux fonctions Azure via des identités gérées.
  • Google Cloud Secret Manager – offre des versions, des commandes IAM et une intégration avec les fonctions Cloud et Cloud Run.

Ces services chiffrent les secrets au repos et en transit, fournissent des journaux d'audit de chaque accès et vous permettent de faire pivoter les secrets sans redéployer les fonctions. Ne stockez jamais les secrets dans des fichiers de configuration texte ou un code en ligne.

2. Variables d'environnement de levier – mais avec soin

Les variables d'environnement restent une façon courante d'injecter la configuration dans des fonctions sans serveur. Cependant, elles ne devraient jamais contenir de secrets directement. Au lieu de cela, utilisez des variables d'environnement pour stocker des références aux secrets (par exemple, l'ARN d'un secret dans AWS Secrets Manager ou le nom d'un secret dans Azure Key Vault). La fonction récupère ensuite le secret réel au moment de l'exécution en utilisant le SDK approprié. De cette façon, même si un attaquant lit les variables d'environnement, ils ne reçoivent qu'un pointeur, et non le secret lui-même.

3. Chiffrer tout au repos et en transit

Les secrets doivent être chiffrés partout où ils résident : à l'intérieur du service de gestion secrète, lorsqu'ils sont mis en cache en mémoire (en utilisant des techniques comme le chiffrement dur de mémoire) et lorsqu'ils sont transmis sur le réseau.

4. Mettre en oeuvre des contrôles d'accès stricts et le principe du moindre privilège

Utilisez le contrôle d'accès basé sur le rôle (RBAC) ou le contrôle d'accès basé sur les attributs (ABAC) pour limiter les fonctions qui peuvent lire quels secrets. Dans AWS, joignez les politiques IAM à la fonction uniquement pour des ARN secrets spécifiques. De même, dans Azure, utilisez des identités gérées et assignez des politiques d'accès par défaut clé granulaire.

En outre, limiter l'accès au service de gestion du secret lui-même. Seuls les administrateurs devraient être en mesure de créer, de modifier ou de supprimer des secrets. Les opérateurs et les développeurs devraient se limiter à lire les secrets nécessaires à leur travail, et les journaux d'audit devraient être examinés périodiquement.

5. Rotation des secrets

La rotation automatique des secrets est essentielle pour limiter le rayon de bouffée d'un compromis. AWS Secrets Manager peut faire tourner les secrets sur un horaire (par exemple tous les 30 jours) en appelant une fonction Lambda qui met à jour le secret du service cible (comme une base de données). Azure Key Vault s'intègre à d'autres services Azure pour la rotation, mais elle nécessite une automatisation personnalisée pour les cibles non Azure. Google Cloud Secret Manager prend en charge la version, rendant la rotation manuelle simple, mais la rotation automatique nécessite un travail de fonction Cloud ou Cloud Scheduler.

Même avec la rotation automatique, vous devez vous assurer que les anciennes versions secrètes ne sont pas conservées indéfiniment. Implémentez une politique de conservation qui purifie les anciennes versions après une fenêtre sécurisée (p. ex. 30 jours après la rotation) pour empêcher un attaquant d'utiliser un vieux secret compromis.

6. Utiliser des pouvoirs dynamiques et temporaires lorsque c'est possible

Pour les services qui le supportent, préférez les identifiants temporaires aux secrets de longue durée. Par exemple, les fonctions AWS Lambda peuvent assumer des rôles IAM qui délivrent des identifiants temporaires (via STS) pour accéder aux services S3, DynamoDB ou autres AWS. Cela élimine la nécessité de tout identifiant codé dur. De même, Azure Functions peut utiliser des identités gérées pour authentifier les services Azure sans stocker de secrets.

7. Vérification et contrôle de l'accès secret

Activez la connexion à votre service de gestion secrète et expédiez ces journaux sur une plateforme centrale de gestion d'informations et d'événements de sécurité (SIEM). Surveillez les schémas d'accès inhabituels, comme une lecture de fonctions plus fréquente que prévu, ou l'accès à partir d'adresses IP inconnues.

Mise en oeuvre de la gestion des secrets : modèles du monde réel

Connaître les pratiques est une chose; les appliquer correctement en est une autre. Ci-dessous, les modèles d'implémentation pour les trois principaux fournisseurs de cloud, ainsi que les considérations multiplateforme.

AWS Lambda avec AWS Secrets Manager

Pour intégrer AWS Secrets Manager à une fonction Lambda, suivez les étapes suivantes :

  1. Créez le secret – Conservez votre mot de passe de base de données, clé API ou autre chaîne sensible comme un secret dans Secrets Manager. Activez la rotation automatique si le service cible le supporte.
  2. Générer l'accès au rôle d'exécution Lambda[ – Ajouter une politique qui permet sur l'ARN secret spécifique. En option, permettre également pour les métadonnées.
  3. Retrait le secret à l'exécution – Dans votre code de fonction (Node.js, Python, etc.), importez le SDK AWS et appelez . Cachez le secret dans une variable globale pour réduire la latence et le coût sur les invocations répétées. Par exemple (code simplifié):
const AWS = require('aws-sdk');
const secretsManager = new AWS.SecretsManager();
let cachedSecret;

exports.handler = async () => {
 if (!cachedSecret) {
 const data = await secretsManager.getSecretValue({ SecretId: 'arn:aws:secretsmanager:us-east-1:123456789012:secret:MyDbPassword-abc123' }).promise();
 cachedSecret = data.SecretString;
 }
 // use cachedSecret securely, never log it
};

Notez que le secret n'est récupéré qu'une fois par démarrage à froid. Lors des invocations chaudes subséquentes, la valeur cache est réutilisée. Si vous faites souvent tourner des secrets, envisagez de mettre un court Time-to-Live (TTL) sur le cache, ou vérifiez la version secret , avant de réutiliser.

Fonctions Azure avec la faille Azure Key

Azure offre une intégration plus transparente par Références de la faille clé dans la configuration de l'application ou dans les paramètres de la fonction. Au lieu d'appeler manuellement le SDK, vous pouvez définir une variable d'environnement à cette syntaxe spéciale:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbPassword/)

Lorsque la fonction s'exécute, Azure résout automatiquement la référence et injecte la valeur secrète comme variable d'environnement. Cette approche simplifie grandement le code et garde les secrets hors de tout fichier de configuration. Cependant, vous devez encore accorder la fonction identitaire gérée par système .

Pour les fonctions qui doivent récupérer plusieurs secrets dynamiquement, utilisez les SDK et pour récupérer des secrets par nom. Utilisez toujours pour l'authentification, qui utilisera l'identité gérée dans la production et vos identifiants locaux pendant le développement.

Fonctions Google Cloud avec le gestionnaire secret

Dans la commande de déploiement, vous pouvez spécifier une variable d'environnement comme dont la valeur est définie à . La fonction va automatiquement résoudre la valeur secrète à l'exécution. Sinon, utilisez la bibliothèque cliente de Secret Manager pour récupérer des secrets à la demande.

Une caractéristique unique de Google Cloud Secret Manager est que vous pouvez accorder l'accès au niveau secret en utilisant des fixations IAM, et vous pouvez également utiliser des clés de chiffrement gérées par le client (CMEK) pour une protection supplémentaire.

Au-delà du Cloud : Secrets dans le CI/CD et développement

Les secrets doivent être gérés non seulement dans la production, mais aussi pendant le développement et l'intégration continue/déploiement continu (CI/CD). Les développeurs doivent souvent tester des fonctions sans serveur localement avec des paramètres de service réels. La pratique la plus sûre est d'utiliser des secrets personnels ou des identifiants temporaires qui sont projetés à leur identité et ont des permissions limitées.

  • Développement local:[ Utilisez des outils comme (pour AWS), avec , ou pour injecter des identifiants via des variables d'environnement. Jamais de secrets de code dur dans des fichiers de configuration locaux qui pourraient être engagés.
  • Les pipelines CI/CD:[ Stockent les secrets comme des secrets de pipeline (p. ex., GitHub Actions secrets, GitLab variables CI/CD) et les injectent à la construction ou au déploiement. Évitez d'imprimer des secrets dans les journaux; utilisez des variables masquées lorsque c'est possible.
  • Infrastructure en tant que code (IaC):[ Si vous utilisez Terraform, AWS CloudFormation ou Azure Bicep pour déployer des fonctions sans serveur, jamais de secrets de code dur dans les modèles IaC. Au lieu de cela, utilisez un backend distant sécurisé et des secrets de référence du magasin secret du fournisseur de cloud. De nombreux outils IaC ont dédié des ressources pour lire les secrets en toute sécurité (p. ex., ] source de données dans Terraform).

Conformité et normalisation

De nombreux cadres réglementaires (RGPD, SOC 2, PCI‐DSS) exigent des contrôles stricts sur l'accès aux données sensibles.

  • Les services de gestion secrète enregistrent chaque lecture, écriture et suppression, vous donnant un historique complet de l'accès.
  • Les politiques de l'IAM garantissent que seules les fonctions autorisées et les utilisateurs peuvent accéder aux secrets.
  • Encryptage:[ Les secrets sont chiffrés au repos et en transit, satisfaisant aux exigences de protection des données.

Adopter une politique à l'échelle de l'entreprise pour les noms secrets, les intervalles de rotation et les cycles d'examen.Utiliser des outils comme OWASP=S Secret Management Cheat Sheet (OWASP Secrets Management Cheat Sheet) et NIST SP 800‐57 (NIST SP 800‐57) comme références faisant autorité pour la gestion des clés.

Conclusion : Construire une architecture sans serveur secrète

La gestion des secrets dans les applications sans serveur n'est pas une tâche ponctuelle mais une discipline permanente. La nature éphémère et distribuée de l'absence de serveur exige que vous ne faites jamais confiance au code ou à la configuration pour garder des secrets.

En suivant les meilleures pratiques décrites dans cet article – en tirant parti de AWS Secrets Manager, Azure Key Vault ou Google Cloud Secret Manager ; en utilisant les variables d'environnement uniquement comme pointeurs ; en en tachant sagement ; et en intégrant la manipulation secrète sécurisée dans CI/CD – vous pouvez construire des applications sans serveur qui sont à la fois puissantes et sécurisées.

Pour les plongées plus profondes, consultez la documentation officielle :