Clés API stockées chez un prestataire compromis : confinement, remplacement et vérification de la facturation

Objectif

État au 25 octobre 2026. Circonscrire les risques liés à des clés API potentiellement exposées par un service qui les stockait, puis rétablir les accès autorisés et rapprocher les données d’utilisation. Vérifier à nouveau le dernier avis de ce service et la documentation de chaque émetteur sur la révocation, la rotation et la facturation. Ce protocole n’établit pas qu’une compromission particulière a eu lieu.

Prérequis

Disposer d’un environnement d’administration de confiance doté de contrôles des identifiants d’accès côté émetteur, ainsi que des identifiants des projets concernés, de responsables pour les applications et d’un accès aux relevés d’audit et de facturation. Consigner la révision de l’avis et la période d’exposition, avec le fuseau horaire ; indiquer explicitement si le début de cette période est inconnu. Ne pas inclure les valeurs des identifiants d’accès dans le ticket d’incident.

Étapes

1. Cartographier l’exposition. Identifier les clés que détenait le prestataire et toutes les applications légitimes qui les partagent. Consigner leurs identifiants, leurs permissions et leurs responsables. Pour Google Cloud, la commande d’inventaire documentée est gcloud services api-keys list --project=PROJECT_ID ; remplacer le paramètre fictif par l’identifiant du projet. Un inventaire des clés repère celles qui pourraient être concernées, sans prouver leur vol. Référence de la CLI.

2. Contenir l’incident avant de rétablir les accès. Suspendre l’intégration concernée et révoquer les clés exposées auprès de leur émetteur. Supprimer une copie enregistrée ne constitue pas une révocation côté émetteur. La procédure de réponse aux incidents d’OWASP donne la priorité à la révocation immédiate, suivie du remplacement et du nettoyage. Accepter une interruption contrôlée plutôt que de continuer à utiliser un identifiant d’accès exposé. Empêcher le service concerné de recevoir les secrets de remplacement tant que son rétablissement n’est pas établi. Réponse d’OWASP aux incidents sur les secrets.

3. Remplacer par des voies de confiance. Émettre les clés de remplacement et mettre à jour chaque application autorisée. Google Cloud documente aussi une rotation des clés API par étapes : créer la nouvelle clé, mettre à jour les applications, puis supprimer la précédente. Si cette période de chevauchement est utilisée pour préserver la disponibilité, tenir explicitement compte de la période pendant laquelle la clé exposée reste utilisable. Ne pas assimiler implicitement la création d’une nouvelle clé à la révocation de l’ancienne. Procédure de l’émetteur.

4. Examiner le compte. Rechercher dans les enregistrements d’audit disponibles depuis le début plausible le plus ancien de l’exposition jusqu’au confinement. Rechercher les appels inattendus, les nouveaux identifiants d’accès, les nouvelles identités et les modifications de ressources ; Google Cloud oriente cette enquête vers Cloud Logging et Security Command Center. Préserver les preuves pertinentes avant de supprimer les accès non autorisés. Comparer séparément l’utilisation et la facturation aux charges de travail attendues, puis transmettre les identifiants de requêtes contestées, les horodatages et les relevés de frais par un canal d’assistance authentifié. Ne pas présumer d’un remboursement. Conseils d’investigation.

5. Restreindre les accès futurs. Séparer les intégrations et les environnements, n’accorder que les permissions nécessaires et privilégier les identifiants d’accès à courte durée de vie lorsqu’ils sont pris en charge. Google Cloud recommande des restrictions d’API et d’application pour réduire l’utilisation abusive des clés. Adapter les restrictions à l’application légitime et vérifier qu’elle fonctionne toujours. Restrictions des clés, cycle de vie des secrets.

6. Configurer les contrôles de coûts et distinguer leurs effets. Configurer des plafonds de dépenses ou des quotas appliqués par l’émetteur lorsqu’ils existent, ainsi que des alertes envoyées à un canal surveillé. Confirmer quels paramètres bloquent réellement les requêtes. AWS Budgets avertit explicitement que les délais de facturation et de notification peuvent permettre des dépenses au-delà d’un seuil d’alerte. Tester la réception des alertes sans générer délibérément de frais excessifs. Limites des budgets.

7. Vérifier les conditions de clôture. Vérifier l’invalidation côté émetteur, l’utilisation autorisée réussie des clés de remplacement et la poursuite de l’examen de l’utilisation à mesure que les données de facturation arrivent. Consigner les lacunes non résolues dans les journaux et les modifications suspectes du compte. Faire remonter les preuves d’une compromission de l’hôte pour déclencher une enquête distincte en vue de son rétablissement, avant d’y réinstaller des identifiants d’accès.

Résultat attendu

Les identifiants d’accès exposés sont invalides, les applications légitimes utilisent des remplacements restreints et un examen de l’utilisation étayé par des preuves dispose d’un responsable et de constats consignés.

Limites et base de vérification

Il s’agit d’une synthèse opérationnelle proposée, pas d’un rétablissement testé. Des journaux manquants ne permettent pas d’établir l’absence d’utilisation abusive. Google Cloud avertit que les jetons de compte de service déjà émis ont leurs propres durées de vie : examiner les accès dérivés plutôt que de supposer que le remplacement de la clé parente les invalide. Aucune version logicielle affectée ni version corrigée n’est affirmée.