Points clés
- Les accès techniques accordés aux partenaires — API keys, tokens d'authentification, connexions VPN, accès aux bases de données — constituent une zone de risque critique souvent mal gouvernée.
- Ces accès techniques ont des caractéristiques qui les rendent particulièrement risqués : ils sont souvent permanents, partagés entre plusieurs utilisateurs, et rarement audités.
- Les tokens API représentent la première catégorie de secrets exposés dans les repositories publics selon GitGuardian State of Secrets Sprawl 2023.
- Une étude IBM X-Force 2023 indique que les identifiants compromis — dont les tokens d'accès partenaires — sont impliqués dans 31 % des incidents de sécurité analysés.
- Le standard OAuth 2.0 et les meilleures pratiques de gestion des secrets (rotation automatique, vault, durée de vie limitée) sont les réponses techniques recommandées par NIST SP 800-63.
Les accès techniques accordés aux partenaires — tokens API, clés d'authentification, connexions de base de données, certificats — sont des actifs de sécurité critiques qui méritent le même niveau de protection que les identifiants humains privilegiés. Ils sont souvent traités avec moins de rigueur parce qu'ils ne sont pas associés à une personne identifiable et que leur gestion est perçue comme une responsabilité technique plutôt que organisationnelle.
Cette perception est l'une des sources d'incidents les plus fréquentes dans la gestion des accès partenaires. Les tokens API exposés accidentellement dans des repositories publics, les clés d'API jamais révoquées après la fin d'un partenariat, les connexions de base de données partagées entre plusieurs prestataires — ces situations, communes dans de nombreuses organisations, constituent des vulnérabilités structurelles.
Les risques spécifiques des tokens et clés API
Les tokens API présentent plusieurs caractéristiques de risque spécifiques. Leur durée de vie est souvent illimitée — un token créé pour un projet n'est jamais révoqué, même après la fin du projet. Ils sont souvent intégrés dans du code ou des configurations, ce qui les expose au risque d'exposition via des repositories de code (GitHub, GitLab) ou des outils de collaboration. Ils sont souvent partagés entre plusieurs membres d'une équipe prestataire sans traçabilité individuelle des utilisations.
La détection des tokens et clés exposés accidentellement est un cas d'usage pour lequel des solutions spécialisées existent : GitGuardian, TruffleHog, Gitleaks analysent automatiquement les repositories de code pour détecter les secrets exposés. Ces solutions doivent être intégrées dans les pipelines CI/CD des prestataires et dans les programmes de surveillance des organisations clientes.
Les accès bases de données partenaires
Les connexions de bases de données accordées à des partenaires pour des intégrations de données présentent des risques particulièrement élevés : un accès en lecture sur une base de données clients peut exposer l'ensemble du contenu en cas de compromission. Ces accès doivent être limités au strict nécessaire (lecture seule, tables spécifiques), protégés par une authentification forte, limités en réseau (liste blanche d'IP), et journalisés de manière exhaustive.
Le principe de moindre privilege (least privilege) s'applique avec la même rigueur aux accès techniques partenaires qu'aux comptes d'utilisateurs humains. Les architectures modernes tendent vers des accès par API plutôt que par connexion directe à la base de données — une approche qui permet un contrôle plus fin des données accessibles.
La gestion du cycle de vie des secrets partenaires
Le cycle de vie des secrets partenaires doit être aussi rigoureux que celui des identifiants humains. Création sur demande formelle approuvée avec documentation de la finalité, rotation régulière (tous les 90 jours au maximum pour les accès à des données sensibles), et révocation immédiate à la fin de la relation ou du projet. Les solutions de gestion des secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) automatisent la rotation et la distribution sécurisée des secrets aux systèmes qui en ont besoin.
La violation d'Uber en septembre 2022 a commencé par la compromission d'un prestataire (Teqtivity) dont les identifiants AWS étaient exposés dans un repository GitHub privé. À partir de ces identifiants, le hacker a pu accéder aux systèmes d'Uber via le SSO de l'entreprise, contournant le MFA par une attaque d'ingénierie sociale. Cet incident illustre la chaîne de compromission depuis un secret prestataire mal géré vers le SI d'une grande organisation.
Toyota a découvert que les données de localisation de 2 millions de véhicules étaient accessibles publiquement via une API key exposée dans le code source d'un système partenaire de gestion de flotte. La clé, jamais révoquée depuis sa création pour un projet initial, permettait d'accéder à un bucket de données de localisation en temps réel. Cet incident, révélé par un chercheur en sécurité, a conduit Toyota à effectuer un audit complet de ses API keys partenaires et à mettre en place un processus de rotation systématique.
Suite à plusieurs incidents liés à des API mal configurées dans ses partenariats avec des merchants et des prestataires de paiement, Grab a développé un programme de sécurité des API incluant : une politique d'authentification OAuth 2.0 obligatoire pour tous les accès partenaires, une rotation automatique des tokens toutes les 24 heures pour les accès aux données financières, et un système de surveillance des comportements anormaux sur les API partenaires (taux de requêtes inhabituels, accès à des endpoints non prévus). Ce programme a réduit significativement les incidents liés aux accès API partenaires.