Périmètre sûr : Ce guide s'applique à vos propres applications et environnements, ou à des systèmes que vous êtes autorisé à tester.
Une clé API CaptchaAI vaut ce que vaut le compte qu'elle ouvre : dans un .env versionné, elle finit par sortir de votre périmètre. Azure Key Vault sort le secret du code — l'application le lit au démarrage via une identité managée, et une rotation prend quelques secondes au lieu d'un redéploiement.
Pourquoi un coffre plutôt qu'une variable d'environnement
Une variable d'environnement suffit jusqu'au premier incident. Elle apparaît dans les logs de build, dans un docker inspect, dans l'historique Git dès qu'un développeur commite son fichier local — et rien ne dit qui l'a lue. Pour une équipe QA lyonnaise dont les tests tournent sur une App Service en région France Centrale, le départ d'un prestataire n'oblige plus à fouiller les pipelines.
| Critère | Variable d'environnement | Azure Key Vault |
|---|---|---|
| Contrôle d'accès | Quiconque lit la configuration | Rôle RBAC nominatif |
| Traçabilité | Aucune | Journal d'accès par identité |
| Rotation | Redéploiement | Nouvelle version du secret |
Étape 1 : créer le coffre et y déposer la clé
- Créez un coffre par environnement —
kv-captchaai-dev,kv-captchaai-staging,kv-captchaai-prod— plutôt qu'un coffre unique cloisonné par nommage. - Activez la suppression réversible et la protection contre la purge : sans elles, un
az keyvault deletemalheureux vous laisse sans recours. - Déposez la clé du tableau de bord CaptchaAI sous le nom
captchaai-api-key, jamais dans un modèle Bicep ou Terraform versionné.
Étape 2 : autoriser l'application par identité managée
Protéger la clé derrière un second secret — le mot de passe du client applicatif — ne fait que déplacer le problème. L'identité managée le supprime : Azure attribue une identité à votre App Service, que le coffre reconnaît sans qu'aucun identifiant ne circule.
- Rôle « Key Vault Secrets User » sur le coffre, jamais un rôle d'administration.
- Depuis GitHub Actions ou Azure DevOps, des identifiants fédérés OIDC plutôt qu'un secret de pipeline.
Étape 3 : lire le secret au démarrage, pas à chaque appel
Instanciez DefaultAzureCredential puis un SecretClient au lancement du processus : lisez la clé une fois et gardez-la en mémoire 30 à 60 minutes. Interroger le coffre à chaque résolution ajoute un aller-retour inutile et vous expose au rate limiting. Ci-dessous, CAPTCHAAI_KEY vient du coffre ; la fonction envoie une tâche Cloudflare Turnstile.
import fetch from 'node-fetch';
const API_KEY = process.env.CAPTCHAAI_KEY;
export async function createTurnstileTask(siteKey, pageUrl) {
const res = await fetch('https://api.captchaai.com/createTask', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
clientKey: API_KEY,
task: {
type: 'TurnstileTaskProxyless',
websiteURL: pageUrl,
websiteKey: siteKey,
},
}),
});
const data = await res.json();
return data.taskId;
}
Le token reste à vérifier côté backend : un secret bien rangé ne dispense pas de cette validation.
Rotation : changer de clé sans coupure
- Générez la nouvelle clé et publiez-la comme nouvelle version du secret.
- Laissez les workers la récupérer à l'expiration de leur cache : avec un cache d'une heure, deux heures de recouvrement suffisent. Un plan CORPORATE ($240/mois, 150 threads) répartit ses threads sur plusieurs instances : toutes doivent relire la nouvelle version.
- Désactivez l'ancienne version, puis vérifiez qu'aucune erreur d'authentification ne remonte.
Journalisation, traçabilité et RGPD
| Signal | Où le collecter | Ce qu'il vous donne |
|---|---|---|
| Lecture de secret | Diagnostics du coffre, vers Log Analytics | Qui a lu quelle version, et quand |
| Durée d'obtention du token, code retour | Traces applicatives | Les dérives de latence |
| Données personnelles | Jeux de test | Des valeurs fictives suffisent : vos obligations RGPD couvrent aussi les logs |
Liste de contrôle avant la mise en production
- Un coffre par environnement, suppression réversible et anti-purge activées.
- Aucune clé dans le dépôt, le pipeline ou une image de conteneur.
- Accès en lecture seule, par identité managée ou OIDC.
- Secret lu une fois au démarrage, mis en cache, jamais journalisé.
- Rotation testée en préproduction, fenêtre de recouvrement incluse.
FAQ
Faut-il un coffre séparé par environnement ?
Oui. Il empêche un test de préproduction de consommer la clé de production et permet de révoquer un accès isolément.
Que faire si une clé a fuité ?
Générez une nouvelle clé, publiez-la comme nouvelle version, puis désactivez l'ancienne sans attendre le recouvrement. Vérifiez ensuite les journaux d'accès et le solde.
Peut-on lire un secret Key Vault hors Azure ?
Oui. Un worker chez OVHcloud, Scaleway ou GitHub Actions y accède via un principal de service ou des identifiants fédérés OIDC : vous perdez l'identité managée, pas le journal d'accès.
Garder la clé en mémoire, est-ce risqué ?
Moins que l'écrire sur disque. Limitez la durée du cache, n'exposez jamais la valeur dans un log, relisez le secret au redémarrage.
Guides connexes
- Démarrage rapide CaptchaAI
- Tester les CAPTCHA en environnement autorisé
- Tester l'endpoint API d'un formulaire
- Le CAPTCHA en intégration continue
- Résoudre reCAPTCHA v2 via l'API
Sortez vos secrets du code source avant la prochaine mise en production. – Obtenez votre clé CaptchaAI.