API-Schlüssel-Sicherheit

Diese Seite dokumentiert empfohlene Praktiken für die Speicherung, Rotation und Widerruf von Cryptohopper MCP API-Schlüsseln. Die Hinweise gelten für jede Umgebung, in der das MCP verwendet wird — lokale Workstations, CI-Systeme, Agent-Deployments und MCP-Clients von Drittanbietern.

Was ein MCP-Schlüssel gewährt

Ein Cryptohopper MCP API-Schlüssel ist ein Bearer-Token, das Anfragen gegen ein einzelnes Cryptohopper-Konto authentifiziert.

Was der Schlüssel kann	Was der Schlüssel nicht kann
Marktdaten (Ticker, Orderbücher, Candles) auf der erlaubten Ebene des Tarifs lesen	Auf Cryptohopper-Bots zugreifen
Nutzung und Kontingent für das Konto abfragen	Trades platzieren oder Positionen ändern
Unterstützte Börsen und Paare auflisten	Auf die Konto-Oberfläche zugreifen
—	Cryptohopper Trading API-Aufrufe autorisieren

Schlüssel sind schreibgeschützt. Ein kompromittierter MCP-Schlüssel erlaubt es einem Angreifer nicht zu handeln. Er erlaubt jedoch Kontingentverbrauch, was legitime Workflows stören kann.

Siehe Kontoübersicht für die Beziehung zwischen Schlüsseln, Konto und Abonnement.

Speicherung

Schlüssel sollten als Secrets behandelt werden. Standardpraktiken für die Handhabung von Secrets gelten.

Empfohlen

• Speichere Schlüssel in einem dedizierten Secrets-Manager (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault oder ähnlich).
• Lies Schlüssel zur Laufzeit aus Umgebungsvariablen. Bevorzuge Umgebungsvariablen gegenüber Konfigurationsdateien, die in die Versionskontrolle eingecheckt werden.
• Beschränke Dateiberechtigungen: Client-Konfigurationsdateien, die Schlüssel enthalten, sollten nur für den besitzenden Benutzer lesbar sein.
• Verwende Client-spezifische Konfigurationsdateien (~/.config/...) statt systemweite Speicherorte.

Nicht empfohlen

• Schlüssel in Git-Repositories einzuchecken, auch in privaten Repositories.
• Schlüssel in Chat-Nachrichten, Issue-Tracker oder Support-Konversationen einzufügen.
• Schlüssel zwischen Entwicklern oder Rechnern zu teilen. Erstelle stattdessen einen Schlüssel pro Verbraucher.
• Schlüssel in Klartext-Dateien in Cloud-synchronisierten Ordnern (z. B. Dropbox, iCloud Drive) ohne zusätzliche Verschlüsselung zu speichern.

Wenn ein Schlüssel versehentlich in Git eingecheckt wurde, widerrufe ihn sofort und generiere einen neuen. Die Git-Historie ist dauerhaft und gilt als kompromittiert.

Rotation

Schlüssel rotieren — einen alten Schlüssel widerrufen und einen neuen ausstellen — ist der Abwehrmechanismus, der den Explosionsradius einer Kompromittierung begrenzt.

Vorgeschlagene Kadenz

Kontext	Rotationskadenz
Persönliche Workstation, lokaler MCP-Client	Alle 90 Tage
Geplanter Workflow in CI / Cloud	Alle 60 Tage
Geteilt über mehrere Umgebungen	Alle 30 Tage
Schlüssel mit jeglicher Historie von Offenlegung (in Repo eingecheckt, in Chat eingefügt, etc.)	Sofort, dann alle 30 Tage

Das Schlüsselkontingent des Tarifs bestimmt, wie viele Schlüssel gleichzeitig existieren können. Siehe Abonnement-Tarife.

Rotationsverfahren

1. Generiere einen neuen API-Schlüssel in der Cryptohopper-Konto-Oberfläche.
2. Stelle den neuen Schlüssel für alle Verbraucher bereit (MCP-Clients, CI-Secrets, Agent-Konfigurationen).
3. Überprüfe, dass jeder Verbraucher den neuen Schlüssel verwendet, indem du eine Testabfrage durchführst.
4. Widerrufe den alten Schlüssel in der Cryptohopper-Konto-Oberfläche.

Schlüssel sind unabhängig. Der Widerruf eines Schlüssels beeinflusst andere nicht.

Schlüsselsegmentierung

Wenn der Tarif mehr als einen Schlüssel erlaubt (Adventurer: 3 Schlüssel; Hero: 10 Schlüssel), verwende sie zur Segmentierung der Nutzung.

Vorgeschlagene Segmentierungsmuster

• Ein Schlüssel pro Agent. Jeder unterschiedliche KI-Agent erhält seinen eigenen Schlüssel. Wenn ein Agent sich fehlverhält und übermäßig Kontingent verbraucht, kann er identifiziert und gedrosselt werden, ohne die anderen zu beeinflussen.
• Ein Schlüssel pro Umgebung. Separate Schlüssel für Produktion, Staging und Entwicklung. Der Widerruf oder die Rotation des Entwicklungsschlüssels lässt die Produktion unberührt.
• Ein Schlüssel pro Benutzer. In einem kleinen Team bietet ein Schlüssel pro Teammitglied Attribution für Kontingentverbrauch und ermöglicht individuellen Widerruf, wenn ein Teammitglied ausscheidet.

Denke daran, dass alle Schlüssel das einzelne wöchentliche Kontingent des Kontos teilen. Segmentierung dient der Attribution, dem Widerruf und der Drosselung — nicht der Kontingenterweiterung.

Widerruf

Widerrufe einen Schlüssel, wenn:

• Der Schlüssel offengelegt wurde (in ein Repository eingecheckt, über einen unverschlüsselten Kanal gesendet, auf einem verlorenen oder gestohlenen Gerät vorhanden).
• Ein Verbraucher keinen Zugriff mehr benötigt (stillgelegter Workflow, ausgeschiedenes Teammitglied).
• Als Teil einer geplanten Rotation.

Der Widerruf über die Cryptohopper-Konto-Oberfläche wird sofort wirksam. Nachfolgende Anfragen mit dem widerrufenen Schlüssel geben UNAUTHORIZED zurück. Siehe Fehler-Referenz.

Verteidigung in der Tiefe

Über die grundlegende Hygiene hinaus:

• Netzwerkbeschränkungen. Wenn dein MCP-Client in einer festen Umgebung läuft (CI-Runner, Produktionsserver), erwäge, ausgehenden Traffic speziell auf mcp-data.cryptohopper.com zu beschränken.
• Audit-Logs. Pflege lokale Logs darüber, welcher Schlüssel welche Aktion durchgeführt hat. Das Abgleichen von MCP-Nutzungsmustern mit der Cryptohopper-Nutzungstelemetrie pro Konto hilft, Anomalien zu erkennen.
• Überwache die Nutzung. Ein plötzlicher Anstieg des Aufrufvolumens ist oft das erste Zeichen eines kompromittierten Schlüssels. Siehe Nutzung und Limits.
• Trenne von Trading API-Zugangsdaten. Die Cryptohopper REST Trading API verwendet separate Zugangsdaten. Lagere MCP-Schlüssel und Trading API-Zugangsdaten nicht in einer einzigen unverschlüsselten Datei zusammen — eine Kompromittierung des einen sollte nicht den anderen betreffen.

Vorfallreaktion

Wenn ein Schlüssel im Verdacht steht, kompromittiert zu sein:

1. Widerrufe sofort. Warte nicht auf Bestätigung. Die Kosten eines unnötigen Widerrufs sind gering; die Kosten eines verzögerten Widerrufs sind Kontingentverbrauch, und — wenn der Schlüssel mit Trading API-Zugangsdaten in derselben Kompromittierung gepaart ist — potenziell mehr.
2. Prüfe die Nutzung. Frage den Nutzungsendpunkt ab, um nach anomalen Mustern im aktuellen Zyklus zu suchen. Dokumentiere alles Verdächtige.
3. Überprüfe die Quelle der Offenlegung. Verstehe, wie der Schlüssel offengelegt wurde. Ein geleakter Schlüssel ist oft ein Symptom einer breiteren Kontrolllücke.
4. Rotiere benachbarte Zugangsdaten. Wenn dieselbe Umgebung Trading API-Zugangsdaten enthielt, rotiere diese ebenfalls.
5. Generiere einen neuen Schlüssel und stelle ihn für Verbraucher bereit.