Tutorials

Stocker vos clés API CaptchaAI dans Azure Key Vault

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é

  1. Créez un coffre par environnement — kv-captchaai-dev, kv-captchaai-staging, kv-captchaai-prod — plutôt qu'un coffre unique cloisonné par nommage.
  2. Activez la suppression réversible et la protection contre la purge : sans elles, un az keyvault delete malheureux vous laisse sans recours.
  3. 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

  1. Générez la nouvelle clé et publiez-la comme nouvelle version du secret.
  2. 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.
  3. 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

Sortez vos secrets du code source avant la prochaine mise en production. – Obtenez votre clé CaptchaAI.

Les commentaires sont désactivés pour cet article.