Dans mes projets serverless (AWS Lambda, Google Cloud Functions, Azure Functions), la question de la protection des API keys et autres secrets revient sans cesse. J'ai appris à la dure que mettre une clé directement dans le code ou dans des variables d'environnement non chiffrées, c'est s'exposer à une fuite qui peut coûter cher en termes de sécurité et de facturation. Ici, je partage les stratégies que j'utilise en production pour minimiser les risques et garder le contrôle sur mes secrets.
Pourquoi les clés API sont si sensibles en environnement serverless
Les fonctions serverless sont pratiques : déploiement rapide, scalabilité automatique, coûts basés sur l'usage. Mais cette nature éphémère et distribuée rend la gestion des secrets plus délicate. Une fuite de clé peut permettre à un attaquant d'accéder à des API, de lancer des instances coûteuses, ou d'exfiltrer des données. De plus, les logs, les dépôts Git et les images container sont des sources fréquentes d'exposition.
Les erreurs courantes que j'ai constatées
Stocker des clés directement dans le code source ou des dépôts Git (même privés).Utiliser des variables d'environnement non chiffrées sans rotation régulière.Donner des permissions excessives à une fonction (role IAM trop permissif).Inclure des secrets dans des logs ou des réponses d'erreur.Partager des clés longues durées entre plusieurs services sans contrôle d'accès granulaire.Principes de base que j'applique systématiquement
Appliquer le principe du moindre privilège : chaque fonction n'a accès qu'aux ressources strictement nécessaires.Éviter les secrets statiques : préférer des identifiants temporaires ou des tokens courts et renouvelables.Centraliser la gestion des secrets dans un service dédié (vault, Secret Manager).Chiffrer au repos et en transit, et s'assurer que les secrets ne sont pas loggés.Automatiser la rotation et le retrait des clés compromises.Options et solutions que j'utilise en production
Voici les approches concrètes que j'emploie selon la plateforme :
AWS (Lambda)
AWS Secrets Manager : mon choix préféré pour stocker des secrets sensibles. Il offre chiffrement géré par KMS, rotation automatique (Lambda pour rotation), et contrôle d'accès via IAM.AWS Systems Manager Parameter Store (SSM) : utile pour des secrets moins critiques ou des paramètres, avec versions SecureString chiffrées par KMS.KMS (Key Management Service) : je m'en sers pour chiffrer les secrets stockés ailleurs ou pour générer des clés maître.IAM Roles pour Lambda : plutôt que d'injecter des clés IAM dans l'environnement, j'attache un role à la Lambda qui lui donne des permissions temporaires et limitées.GCP (Cloud Functions / Cloud Run)
Secret Manager : stockage chiffré, contrôle d'accès via IAM, et intégration simple avec Cloud Functions.Workload Identity / Service Accounts : j'évite d'utiliser des clés JSON statiques ; je préfère attacher des rôles spécifiques aux fonctions via Workload Identity.Azure
Azure Key Vault : gestion centralisée des secrets et intégration avec Managed Identities pour éviter les credentials statiques.Comparatif rapide
| Solution | Chiffrement | Rotation | Intégration serverless |
| AWS Secrets Manager | Oui (KMS) | Automatique possible | Très bonne (Lambda) |
| SSM Parameter Store | Oui (SecureString) | Manuelle/Scriptable | Bonne |
| GCP Secret Manager | Oui | Scriptable/CI | Très bonne |
| Azure Key Vault | Oui | Scriptable/CI | Très bonne |
Comment j'injecte les secrets dans mes fonctions
Je privilégie deux méthodes selon le besoin :
Récupération au démarrage : la fonction récupère le secret depuis le Secret Manager (ou SSM) au cold start et le garde en mémoire pendant l'exécution. Bon pour latence réduite après initialisation.Récupération à la demande : pour les secrets très sensibles, je fais des appels à chaque fois que nécessaire, réduisant la fenêtre d'exposition. C'est plus sûr mais plus coûteux en latence/requests.Dans les deux cas, j'évite d'écrire le secret sur le disque local ou de l'exposer via des logs. Si j'utilise des variables d'environnement, elles sont remplies par le provider (ex : intégration Secrets Manager → variable durant le déploiement) mais chiffrées au repos et contrôlées par IAM.
Utiliser des identités gérées et des credentials temporaires
Une des meilleures pratiques que j'applique est d'éliminer autant que possible les clés statiques en faveur d'identités gérées (IAM Roles for Service Accounts, Managed Identities). Concrètement :
Sur AWS, une Lambda assume un role IAM qui lui donne accès à DynamoDB, S3, etc., sans clé stockée.Sur GCP, j'utilise Workload Identity pour que la fonction obtienne des jetons d'accès temporaires.Pour des APIs externes, je favorise OAuth2 avec short-lived tokens ou l'utilisation de brokers d'identité (ex : Auth0, Okta) plutôt que des clés fixes.Rotation et révocation
Rien n'est plus important que la rotation. J'automatise la rotation des secrets quand la plateforme le permet (AWS Secrets Manager), ou via pipelines CI/CD (GitHub Actions, GitLab CI) qui appellent les API de Secret Manager. En cas de compromission, je révoque immédiatement la clé et j'automatise le déploiement d'une nouvelle configuration.
Monitoring et détection
Je surveille activement :
Les logs d'accès aux Secret Managers (CloudTrail pour AWS, Audit Logs pour GCP) pour détecter des accès suspects.Les anomalies d'usage des APIs (pics de consommation, endpoints inconnus).Les modifications IAM/Policy via alertes (SNS, Cloud Pub/Sub).Gestion des secrets dans CI/CD et local
Les développeurs ont besoin d'accéder aux secrets pour tester, mais je refuse les clés production sur les postes de dev. Ce que je fais :
Utiliser des environnements séparés (dev/staging/prod) avec secrets différents et droits restreints.Stocker les secrets CI dans les outils CI (GitHub Secrets, GitLab CI/CD variables, Azure DevOps) et limiter l'accès aux pipelines autorisés.Fournir des scripts pour récupérer des secrets temporaires via MFA, ou via un vault (HashiCorp Vault, ou Secret Manager) en local pour les tests, avec durée de vie courte.Pratiques complémentaires que j'applique
Scan des dépôts pour secrets (truffleHog, git-secrets) avant chaque merge.Chiffrement côté client pour données sensibles supplémentaires.Examen régulier des permissions IAM et suppression des accès inutiles.Procédures d'incident pour rotation et communication en cas de fuite.En résumé, protéger les clés API en environnement serverless n'est pas une seule action mais une combinaison de choix : centraliser les secrets dans un service sécurisé, utiliser des identités gérées et des credentials temporaires, appliquer le moindre privilège, automatiser la rotation et surveiller les accès. J'essaie d'intégrer ces pratiques dès la conception pour que la sécurité soit une partie naturelle du cycle de vie de mes fonctions, et non une rustine après coup.
