Sécurité des clés API
Cette page documente les pratiques recommandées pour stocker, faire pivoter et révoquer les clés API MCP Cryptohopper. Ces conseils s'appliquent à tout environnement où le MCP est utilisé — postes de travail locaux, systèmes CI, déploiements d'agents et clients MCP tiers.
Ce qu'une clé MCP accorde
Une clé API MCP Cryptohopper est un jeton porteur qui authentifie les requêtes contre un seul compte Cryptohopper.
| Ce que la clé peut faire | Ce que la clé ne peut pas faire |
|---|---|
| Lire les données de marché (ticks, carnets d'ordres, chandeliers) au niveau autorisé par le tier | Accéder aux bots Cryptohopper |
| Interroger l'utilisation et le quota du compte | Placer des transactions ou modifier des positions |
| Lister les exchanges et paires supportés | Accéder à l'interface du compte |
| — | Autoriser les appels à l'API de trading Cryptohopper |
Les clés sont en lecture seule. Une clé MCP compromise ne permet pas à un attaquant de trader. Elle permet cependant une consommation de quota, ce qui peut perturber les flux de travail légitimes.
Consulte la vue d'ensemble du compte pour comprendre la relation entre les clés, le compte et l'abonnement.
Stockage
Les clés doivent être traitées comme des secrets. Les pratiques standard de gestion des secrets s'appliquent.
Recommandé
- Stocke les clés dans un gestionnaire de secrets dédié (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault, ou équivalent).
- Lis les clés depuis des variables d'environnement au moment de l'exécution. Préfère les variables d'environnement aux fichiers de configuration commités dans le contrôle de source.
- Limite les permissions de fichiers : les fichiers de configuration client contenant des clés doivent être lisibles uniquement par l'utilisateur propriétaire.
- Utilise des fichiers de configuration par client (~/.config/...) plutôt que des emplacements à l'échelle du système.
Non recommandé
- Commiter les clés dans des dépôts git, même dans des dépôts privés.
- Coller les clés dans des messages de discussion, des trackers de problèmes ou des conversations de support.
- Partager les clés entre développeurs ou machines. Crée plutôt une clé par consommateur.
- Stocker les clés dans des fichiers en texte brut dans des dossiers synchronisés dans le cloud (par exemple Dropbox, iCloud Drive) sans chiffrement supplémentaire.
Si une clé est accidentellement commitée dans git, révoque-la immédiatement et génère-en une nouvelle. L'historique git est durable et considéré comme compromis.
Rotation
Faire pivoter les clés — révoquer une ancienne clé et en émettre une nouvelle — est le mécanisme défensif qui limite le rayon d'impact d'une compromission.
Cadence suggérée
| Contexte | Cadence de rotation |
|---|---|
| Poste de travail personnel, client MCP local | Tous les 90 jours |
| Flux de travail planifié dans CI / cloud | Tous les 60 jours |
| Partagé entre plusieurs environnements | Tous les 30 jours |
| Clé avec un historique d'exposition (commitée dans un dépôt, collée dans une discussion, etc.) | Immédiatement, puis tous les 30 jours |
L'allocation de clés du tier détermine combien de clés peuvent exister simultanément. Consulte les tiers d'abonnement.
Procédure de rotation
- Génère une nouvelle clé API dans l'interface du compte Cryptohopper.
- Déploie la nouvelle clé sur tous les consommateurs (clients MCP, secrets CI, configurations d'agents).
- Vérifie que chaque consommateur utilise la nouvelle clé en émettant une requête de test.
- Révoque l'ancienne clé depuis l'interface du compte Cryptohopper.
Les clés sont indépendantes. Révoquer l'une n'affecte pas les autres.
Segmentation des clés
Lorsque le tier autorise plus d'une clé (Adventurer : 3 clés ; Hero : 10 clés), utilise-les pour segmenter l'utilisation.
Modèles de segmentation suggérés
- Une clé par agent. Chaque agent IA distinct obtient sa propre clé. Si un agent se comporte mal et consomme un quota excessif, il peut être identifié et limité sans affecter les autres.
- Une clé par environnement. Clés séparées pour la production, le staging et le développement. Révoquer ou faire pivoter la clé de développement laisse la production intacte.
- Une clé par utilisateur. Dans une petite équipe, une clé par membre de l'équipe fournit une attribution pour l'utilisation du quota et permet une révocation individuelle lorsqu'un membre de l'équipe part.
Rappelle-toi que toutes les clés partagent le quota hebdomadaire unique du compte. La segmentation sert à l'attribution, la révocation et la limitation — pas à l'expansion du quota.
Révocation
Révoque une clé lorsque :
- La clé a été exposée (commitée dans un dépôt, envoyée via un canal non chiffré, présente sur un appareil perdu ou volé).
- Un consommateur n'a plus besoin d'accès (flux de travail décommissionné, membre de l'équipe parti).
- Dans le cadre d'une rotation planifiée.
La révocation via l'interface du compte Cryptohopper prend effet immédiatement. Les requêtes ultérieures utilisant la clé révoquée retournent UNAUTHORIZED. Consulte la référence des erreurs.
Défense en profondeur
Au-delà de l'hygiène de base :
- Restrictions réseau. Si ton client MCP s'exécute dans un environnement fixe (runner CI, serveur de production), envisage de restreindre le trafic sortant spécifiquement vers mcp-data.cryptohopper.com.
- Journaux d'audit. Maintiens des journaux locaux indiquant quelle clé a effectué quelle action. Faire correspondre les modèles d'utilisation MCP avec la télémétrie d'utilisation par compte de Cryptohopper aide à détecter les anomalies.
- Surveille l'utilisation. Un pic soudain de volume d'appels est souvent le premier signe d'une clé compromise. Consulte utilisation et limites.
- Sépare des identifiants de l'API de trading. L'API REST de trading Cryptohopper utilise des identifiants séparés. Ne co-localise pas les clés MCP et les identifiants de l'API de trading dans un seul fichier non chiffré — une compromission de l'un ne devrait pas impliquer l'autre.
Réponse aux incidents
Si une clé est soupçonnée d'être compromise :
- Révoque immédiatement. N'attends pas de confirmer. Le coût d'une révocation inutile est mineur ; le coût d'une révocation retardée est une consommation de quota, et — si la clé est associée à des identifiants de l'API de trading dans la même compromission — potentiellement plus.
- Vérifie l'utilisation. Interroge l'endpoint d'utilisation pour rechercher des modèles anormaux dans le cycle actuel. Documente tout ce qui est suspect.
- Examine la source de l'exposition. Comprends comment la clé a été exposée. Une clé divulguée est souvent le symptôme d'un manque de contrôle plus large.
- Fait pivoter les identifiants adjacents. Si le même environnement contenait des identifiants de l'API de trading, fais-les également pivoter.
- Génère une nouvelle clé et redéploie-la vers les consommateurs.