Ein Börsen-API-Key besteht aus API Key und API Secret. Mit diesem Key arbeiten Programme und Services über die API mit einem Konto: Sie lesen Salden, öffnen und schließen Trades und führen andere für diesen Key erlaubte Operationen aus, ohne sich im Web-Dashboard anzumelden.
Ziel des Materials: die Einschränkungen zu beschreiben, die eine Börse auf API-Anfragen anwendet: Signaturprüfung über API Secret, Key-Permissions, Bindung der Anfragequelle an eine IP whitelist, Auszahlungsbeschränkungen über eine withdrawal address whitelist und Saldenisolation über sub-accounts. Diese Einschränkungen reduzieren das Risiko, dass ein Leak des API Key + API Secret-Paares zu einer Auszahlung von Assets oder zu Verlusttrades führt.
🧭 Wie Kryptobörsen den API-Zugriff kontrollieren
API-Keys werden von Trading-Bots, Terminals, Reporting-Services und internen Integrationen genutzt. Eine Börse führt eine API-Anfrage erst aus, nachdem sie die Signatur (API Secret), die Operationsrechte (permissions), die Quell-IP-Adresse (IP whitelist) und die Anfragezeit (timestamp und recvWindow) geprüft hat. Die Zeitprüfung blockiert eine spätere Wiederholung der Anfrage, selbst wenn die Anfrage abgefangen wurde.
API-Risiko wird durch Key-Einstellungen reduziert. IP whitelist akzeptiert Anfragen nur von festgelegten IP-Adressen. Permissions begrenzen den Satz an Operationen, die die Börse mit dem Key ausführt. Eine withdrawal address whitelist begrenzt die Liste der Empfänger. Sub-accounts trennen Salden und Keys zwischen sub-accounts, sodass ein Key keinen Zugriff auf alle Kontoassets hat.
🔍 Wie eine Börse eine API-Anfrage prüft: Signatur, Rechte, IP und Zeit
Ein API-Key besteht aus einem API Key (dem Key-Identifier) und einem API Secret (dem Secret für die Signierung). Die Signatur bestätigt der Börse, dass die Anfrage mit dem API Secret erstellt und unterwegs nicht verändert wurde.
- Erstellung von Anfrageparametern für den API endpoint der Börse (die API-Adresse, die eine konkrete Operation annimmt)
- Die Anfrage definiert die Operation: einen Auftrag öffnen oder stornieren, einen Saldo abrufen, einen Transfer ausführen oder eine Auszahlung starten.
- Die Anfrage enthält einen timestamp und manchmal ein zulässiges Zeitfenster (recvWindow). Die Börse vergleicht diese Werte mit ihrer eigenen Zeit und lehnt die Anfrage ab, wenn sie außerhalb des zulässigen Intervalls liegt.
- Signieren der Anfrageparameter über HMAC
- HMAC ist eine hashbasierte Signatur, die mit einem Secret Key erzeugt wird. Die Parameterzeichenfolge wird mit dem API Secret signiert.
- Die Börse berechnet den HMAC mit denselben Parametern neu und vergleicht die Signatur. Eine Abweichung bedeutet, dass der Absender das API Secret nicht besitzt oder dass die Parameter verändert wurden.
- Prüfung der Key-Einschränkungen und Entscheidung über die Ausführung
- Permissions definieren, welche Operationen für den Key erlaubt sind (read/trade/transfer/withdraw bei den meisten zentralisierten Börsen, CEXs).
- IP whitelist beschränkt die Anfragequellen. Die Börse lehnt eine Anfrage ab, wenn die IP des Absenders nicht in der Whitelist des Keys enthalten ist.
- Ausführung der Operation und Rückgabe des Ergebnisses
- Wenn Rechte nicht ausreichen, gibt die Börse eine Ablehnung zurück und führt die Operation nicht aus, selbst bei gültiger Signatur.
- Wenn die IP nicht übereinstimmt, gibt die Börse in der Autorisierungsphase eine Ablehnung zurück und fährt nicht mit einer Trading- oder Auszahlungsoperation fort.
API-Zugriffskomponenten, die von der Börse kontrolliert werden
Die Börse reduziert API-Risiko durch drei Prüfungen in jeder Anfrage: Signatur über API Secret, permissions für Operationen und IP whitelist für die Anfragequelle.
- API Secret wird nur in einem Secrets Vault und im Speicher des Prozesses gespeichert, der Anfragen signiert.
- Permissions werden für die Aufgabe des Keys aktiviert: Lesen für Reporting, Trading für einen Bot und Auszahlung nur für operative Auszahlungen.
- IP whitelist enthält nur die IP-Adressen von Servern, die tatsächlich Anfragen senden, damit die Liste die Angriffsfläche nicht erweitert.
Wenn ein Angreifer einen API Key ohne API Secret erhält, lehnt die Börse die Anfrage wegen einer ungültigen Signatur ab. Wenn ein Angreifer sowohl API Key als auch API Secret erhält, lehnt die Börse die Anfrage ab, wenn permissions die Operation nicht erlauben oder die IP nicht in der Whitelist enthalten ist.
🎯 Welche Verluste über API möglich sind: Auszahlungen, Transfers und Trading-Verluste
API-Schaden hängt von den aktivierten permissions und vom Saldo ab, der diesem Key zur Verfügung steht. Ein trade-only Key trägt ein geringeres Risiko auf einem sub-account mit kleinem Arbeitssaldo und ein höheres Risiko auf einem sub-account mit Kernkapital.
Drei Szenarien, die eine Börse über API ausführt
API-Verluste entstehen durch Auszahlung, internen Transfer oder Trades, die zum Ausführungspreis einen Verlust erzeugen.
- Direkte Auszahlung: Ein Key mit withdraw permission startet eine Auszahlung an eine Adresse, die die Börse nach ihren Prüfungen und Whitelist-Regeln zulässt.
- Interner Transfer: Ein Key mit transfer permission bewegt Assets zwischen Produkt-Wallets oder zwischen sub-accounts, wenn die Börse solche Operationen über die API erlaubt.
- Trading-Verlust ohne Auszahlung: Ein Key mit trade permission platziert Orders auf einem Markt mit niedriger Liquidität und führt Trades zu einem schlechteren Preis aus, wodurch ein Verlust aus Slippage, Spread und Gebühren entsteht.
Deaktivierte withdraw permission entfernt die direkte Auszahlung. Trade permission bleibt eine Verlustquelle, wenn im Trading-Wallet ein großer Saldo gespeichert ist und der Key nicht nach IP und Instrumenten eingeschränkt ist.
Signale, nach denen eine API-Prüfung notwendig wird
- Orders sind erschienen, die nicht zur Logik des Trading-Systems und zum Startplan passen.
- Transfers zwischen Wallets oder sub-accounts sind ohne operativen Grund erschienen.
- In den Key-Einstellungen sind neue permissions erschienen oder IP whitelist wurde entfernt.
- In den Logs des Trading-Systems sind Signaturfehler erschienen und die Anfragefrequenz ist gestiegen, obwohl der Code unverändert blieb.
🌐 IP whitelist: Bindung eines Keys an den Server, der Anfragen sendet
IP whitelist zwingt die Börse, Anfragen nur von vorab festgelegten IP-Adressen anzunehmen. Wenn API Secret in Code, Logs, Backups oder einen Drittanbieter-Service gelangt, kann ein Angreifer keine Anfrage von einer IP senden, die nicht in der Whitelist steht.
Auswahl einer stabilen Quelle für API-Anfragen
- Ein VPS (Virtual Private Server) mit statischer öffentlicher IP eignet sich für IP whitelist und für den kontinuierlichen Betrieb eines Trading-Systems.
- Ein Heimanschluss mit dynamischer IP eignet sich nicht, weil ein IP-Wechsel API-Anfragefehler verursacht, bis die Whitelist aktualisiert ist.
Konfiguration der IP whitelist für einen API-Key
- IP whitelist enthält die IP des Trading-System-Servers und des Backup-Servers, wenn der Backup-Server tatsächlich verwendet wird.
- Wenn die Börse CIDR unterstützt (Subnetznotation, zum Beispiel 203.0.113.10/32), wird der kleinste Bereich festgelegt, damit die Liste der Quellen nicht erweitert wird.
Prüfung der Ausfallsicherheit des API-Zugriffs
- Ein Backup-API-Key auf einer separaten IP wird bei Infrastrukturmigration und Änderungen der Serveradresse verwendet.
- Das Verfahren zur Aktualisierung der IP whitelist wird im Voraus dokumentiert, damit ein IP-Wechsel nicht mit dem Verlust der Orderkontrolle zusammenfällt.
In Cloud-Infrastruktur können Anfragen über NAT (Adressübersetzung am Netzwerkrand) ins Internet ausgehen. In diesem Fall kann sich die externe IP, die die Börse sieht, von der IP des Containers oder der virtuellen Maschine unterscheiden. Die IP whitelist sollte die egress IP (die externe IP des ausgehenden Traffics) enthalten, andernfalls lehnt die Börse Anfragen ab.
IP whitelist schützt nicht vor einer VPS-Kompromittierung. Wenn der Server übernommen wird, sendet ein Angreifer Anfragen von derselben IP, daher bleiben Schutz des VPS-Zugriffs und Update-Kontrolle Teil des API-Schutzes.
IP whitelist blockiert Anfragen von nicht autorisierten Servern, weil die Börse die Quell-IP mit der Whitelist vergleicht und die Anfrage vor der Ausführung einer Trading- oder Auszahlungsoperation ablehnt.
🔑 Permissions: welche Rechte einem Key für eine konkrete Aufgabe zugewiesen werden
Permissions definieren, welche API endpoints die Börse diesem Key zum Aufruf erlaubt. Die Namen der Rechte hängen von der Börse ab, aber das Modell ist meist ähnlich: read für Lesen, trade für Orders, transfer für interne Transfers und withdraw für Blockchain-Auszahlungen.
| Aufgabe | Erlauben | Blockieren | Blockierte Operation |
|---|---|---|---|
| Screener/Analytics | Read | Trade; Transfer; Withdraw | Platzieren von Orders und Bewegen von Assets |
| Trading-Bot | Read; Trade | Withdraw | Direkte Auszahlung von Mitteln über API |
| Reporting | Read | Trade; Transfer; Withdraw | Operationen bei Kompromittierung des Reporting-Services |
| Operative Transfers | Read; Transfer | Trade; Withdraw | Trading-Operationen und Blockchain-Auszahlungen |
Read-only Key für Monitoring und Reporting
Ein read-only Key wird verwendet, wenn ein System Salden, Trade-Historie und Positionsstatus lesen muss, aber den Kontostatus nicht verändern darf.
- Ein read-only Key blockiert das Platzieren und Stornieren von Orders, weil die Börse Trading-Endpoints für diesen Key ablehnt.
- IP whitelist begrenzt den Datenzugriff auf einen bestimmten Server und blockiert Anfragen von nicht autorisierten IPs, wenn das API Secret leakt.
- Ein separater read-only Key für Reporting isoliert das Risiko des Reporting-Services vom Risiko des Trading-Keys.
Ein read-only Key legt Salden und Historie offen, erlaubt aber keine Auszahlungen oder Trades, weil die Börse trade/transfer/withdraw endpoints ablehnt.
Trade Key für ein Trading-System ohne Auszahlungen
Ein trade Key wird zum Platzieren und Stornieren von Orders verwendet. Withdraw permission ist für Trading-Operationen nicht erforderlich.
- Trade permission gibt Zugriff auf Order- und Positionsverwaltung innerhalb der Märkte des Kontos.
- Deaktivierte withdraw permission blockiert Auszahlungen, weil die Börse Withdrawal-Endpoints für diesen Key ablehnt.
- IP whitelist bindet den Key an den Server des Trading-Systems und blockiert Anfragen von nicht autorisierten Maschinen, wenn das API Secret leakt.
Ein trade-only Key erzeugt Risiko für Mittel im Trading-Wallet, daher hält der Trading-sub-account normalerweise einen Arbeitssaldo und nicht das Kernkapital.
Transfer Key für interne Bewegungen
Ein transfer Key wird für Transfers innerhalb der Börse verwendet: zwischen Produkt-Wallets oder zwischen sub-accounts, wenn die Börse solche Operationen über die API erlaubt.
- Transfer permission erlaubt interne Transfers, die nicht auf die Blockchain gehen.
- Deaktivierte trade permission schließt Trades aus, weil der Transfer Key keine Orders erstellen kann.
- Deaktivierte withdraw permission schließt Blockchain-Auszahlungen aus, wenn der Transfer Key kompromittiert wird.
Die Trennung von transfer und trade auf verschiedene Keys reduziert den Schaden durch einen Leak, weil ein Key nicht gleichzeitig Zugriff auf Trades und Asset-Bewegungen bietet.
Permissions definieren, welche Operation die Börse für diesen Key erlaubt. Zusätzliche permissions erweitern den Satz von Aktionen, die die Börse mit einem kompromittierten Key ausführt, daher werden Rechte nur für einen konkreten Prozess aktiviert.
🏷️ Auszahlungsschutz: Adress-Whitelist, Bestätigungen und Limits
Withdraw permission erlaubt einem API-Key, eine Auszahlung von Mitteln aus einem Börsensaldo auf eine Blockchain zu starten. Auszahlungsschutz stützt sich auf eine Empfängeradress-Whitelist, Kontrolle über Whitelist-Änderungen und Auszahlungslimits.
In Trading-Integrationen ist withdraw permission normalerweise deaktiviert. Orders, Stornierungen und Saldoabfragen werden innerhalb der Börse ausgeführt und erfordern keine Netzwerk-Auszahlungen. Read permission reicht für Monitoring und Reporting. Trade permission reicht für algorithmisches Trading.
Beispiel: Ein Trading-Bot arbeitet über einen Key mit trade permission und ohne withdraw permission. Wenn der Key kompromittiert wird, kann ein Angreifer Trades über Trading-Endpoints öffnen und schließen. Die Börse lehnt eine Auszahlungsanfrage ab, weil der Key keine withdraw permission hat.
Eine withdrawal address whitelist begrenzt den Auszahlungsempfänger: Die Börse sendet Mittel nur an vorab hinzugefügte Adressen. Auf vielen Börsen erfordert das Hinzufügen einer Adresse zur Whitelist 2FA (Zwei-Faktor-Authentifizierung) und eine Bestätigung über einen separaten Kanal, etwa E-Mail, App oder Hardware-Key. In diesem Fall hängt die Auszahlung an eine neue Adresse nicht nur vom API-Key ab, sondern auch von der Kontrolle über diese Bestätigungskanäle.
Eine Verzögerung bei Whitelist-Änderungen (security lock oder hold) aktiviert die hinzugefügte Adresse nicht sofort. Wenn die Verzögerung aktiviert ist, wird die Auszahlung an eine neue Adresse für die Hold-Periode blockiert, sodass die hinzugefügte Adresse vor der ersten Auszahlung erkannt werden kann.
API-Anbindung für Trading-Bots, trade-only Keys und IP whitelist werden im Material „Verdienen mit Krypto-Trading-Bots“ behandelt.
Auszahlungslimits begrenzen die Verlustsumme, wenn ein Angreifer einen Key erhält, der Whitelist- und Bestätigungsprüfungen besteht. Das Tageslimit wird für regelmäßige operative Auszahlungsbeträge festgelegt, nicht für den gesamten Kontosaldo, damit ein Auszahlungszyklus nicht die gesamte Einlage leeren kann.
E-Mail-Kompromittierung erhöht das Risiko, weil viele Börsen E-Mail für Bestätigungen von Adresshinzufügungen und Sicherheitsresets nutzen, einschließlich Bestätigungslinks und Benachrichtigungen über Whitelist-Änderungen.
Withdraw permission ohne withdrawal address whitelist macht einen API-Key-Leak zu einem direkten Kanal für Blockchain-Auszahlungen. Withdraw permission mit withdrawal address whitelist und einer Verzögerung bei Whitelist-Änderungen verschiebt das kritische Risiko auf die Kompromittierung von Bestätigungskanälen. Auszahlungslimits begrenzen die Verlustsumme, wenn die anderen Einschränkungen umgangen werden.
🛡️ Sub-accounts: Salden, Keys und Prozesse isolieren
Sub-accounts trennen Salden und API-Keys innerhalb einer Börse. Wenn ein Key leakt, sind Operationen auf die Assets eines bestimmten sub-account begrenzt.
- Trennung von Storage und Trading über verschiedene sub-accounts
- Der Storage-sub-account hält Kernkapital und nutzt keine permanenten Trading-API-Keys.
- Trading-sub-accounts halten Arbeitssalden für bestimmte Bots und Strategien.
- Kontrolle interner Transfers über API
- Das Deaktivieren von transfer permission auf Trading-Keys reduziert die Möglichkeit, Assets zu bewegen, wenn ein Trading-Key leakt.
- Ein dedizierter transfer Key wird verwendet, wenn interne Transfers Teil des operativen Prozesses sind.
- Einschränkung der Key-Instrumente, wenn Trading-Pair-Whitelist unterstützt wird
- Trading-Pair-Whitelist blockiert Trades in Instrumenten, die nicht zum Trading-System gehören.
- Pair-Einschränkungen reduzieren das Verlustrisiko auf Märkten mit niedriger Liquidität.
Isolationsmodell für mehrere Trading-Systeme
Das Isolationsmodell trennt Salden über sub-accounts und trennt Zugriff über API-Keys, permissions und IP whitelist.
- Ein Trading-System auf einer Börse arbeitet über einen separaten sub-account und einen trade-only Key, der an die VPS-IP gebunden ist.
- Reporting wird mit einem read-only Key auf einem separaten Server verbunden, damit ein Reporting-Leak den Trading-Key nicht offenlegt.
- Operative Transfers werden mit einem transfer Key ohne trade und withdraw permissions ausgeführt.
Wenn ein Key des Trading-Systems leakt, führt die Börse Operationen nur innerhalb des Saldos seines sub-account aus, sodass Verluste auf den Arbeitssaldo begrenzt sind.
🗄️ Secret-Speicherung und Rotation: wie API Secret aus Infrastruktur leakt
API Secret leakt häufiger nicht über die Börse, sondern aus der Infrastruktur des Trading-Systems: Code-Repositories, CI/CD-Pipelines (automatisierte Build- und Deployment-Prozesse), Anwendungslogs, Datenbank-Dumps, Screenshots und Backups. Secret Management definiert, wo das API Secret gespeichert wird und welche Rollen darauf zugreifen können.
API Secret wird nicht im Anwendungscode gespeichert. Der Secret-Wert wird beim Start des Services aus geschütztem Speicher injiziert und nicht in Projektdateien oder im Repository gespeichert. Code und Konfiguration behalten eine Referenz auf das Secret, nicht seinen Wert.
Beispiel: Ein Trading-Bot wird über CI/CD deployt. Im Repository wird nur der Secret-Name gespeichert, und der API Secret-Wert wird in der Deployment-Phase aus geschütztem Speicher injiziert. Wenn Code und Commit-Historie leaken, ist das API Secret dort nicht vorhanden.
In production wird API Secret in einem secret manager gespeichert — einem Service, der Secrets verschlüsselt hält und sie nur Prozessen mit Berechtigung über IAM (rollenbasierte Zugriffskontrolle) ausgibt. Dieses Modell trennt production secrets von Entwicklungsumgebungen und Testservices.
Verhaltensbedingte Fehlerursachen im Risikomanagement und in Trading-Plänen werden im Material „Trading-Psychologie“ behandelt.
API-Key-Rotation reduziert das Risiko eines langlebigen Leaks. Rotation umfasst das Erstellen eines neuen Keys auf der Börse, das Umschalten des Systems auf das neue API Secret und das Widerrufen des alten Keys, damit die Börse keine Signaturen mit dem alten Secret mehr akzeptiert.
Die Umschaltung wird für einen Zeitraum ohne offene Positionen und aktive Limit-Orders geplant, damit die Änderung des API Secret das Order- und Risikomanagement nicht unterbricht.
Mindestregeln für die Speicherung von API Secret
- API Secret wird in einem secret manager oder verschlüsseltem Speicher mit Zugriffskontrolle gespeichert.
- API Secret gelangt nicht im Klartext in Git, Docker image, CI artifacts oder Backups.
- Das production secret ist aus der Entwicklungsumgebung nicht zugänglich und für Rollen, die das Trading-System nicht ausführen, nicht zugänglich.
- Rotation umfasst das Widerrufen des alten Keys nach der Umschaltung, damit das alte Secret auf Börsenseite nicht mehr funktioniert.
Permissions, IP whitelist und withdrawal address whitelist schützen auf Börsenseite, während Secret Management das Risiko reduziert, dass API Secret aus Code und Logs auf Infrastrukturseite leakt.
🧩 Drittanbieter-Terminals und Bots: wie die Verbindung das Risiko beeinflusst
Ein Drittanbieter-Service erhält API Key und API Secret, um Anfragen im Namen des Kontos zu signieren. Wenn der Service den Key in einem Web-Dashboard annimmt, wird das API Secret in der Infrastruktur des Providers gespeichert. Bei einem Provider-Incident kann ein Angreifer möglicherweise Anfragen signieren und die Signaturprüfung auf Börsenseite bestehen.
✅ Anzeichen für kontrolliertes Risiko
- Der Service arbeitet mit read-only und trade-only Keys und verlangt keine withdraw permission für Trading und Reporting.
- Der Service zeigt ein API-Aktionslog: erstellte Orders und aufgerufene Endpoints.
- Der Service unterstützt die Verbindung über einen separaten sub-account mit begrenztem Arbeitssaldo.
❌ Anzeichen für erhöhtes Risiko
- Der Service verlangt withdraw permission für Funktionen, die nicht mit operativen Auszahlungen verbunden sind.
- Der Service verlangt das Deaktivieren von IP whitelist und bietet kein Modell mit einem nutzerseitigen Agent und einer festen IP.
- Der Service stellt keine API-Aktionshistorie bereit, daher stützt sich die Untersuchung auf indirekte Signale.
Konfigurationsbeispiel: Signale und Reporting nutzen einen read-only Key, Trading-Operationen nutzen einen trade-only Key auf einem sub-account mit Arbeitssaldo, und API-Auszahlungen sind deaktiviert.
Ein Drittanbieter-Service hebt Börseneinschränkungen nicht auf. Ein sub-account, IP whitelist, minimale permissions und deaktivierte withdraw permission begrenzen das Risiko auf den Arbeitssaldo.
🧯 Reaktion auf einen Key-Leak: Ausführung stoppen und Spuren sichern
Wenn ein Leak des API Key + API Secret-Paares vermutet wird, entwickelt sich Risiko schnell, weil die Börse Operationen direkt nach Prüfung von Signatur, Rechten, IP und Anfragezeit ausführt. Die Reaktion beginnt mit dem Stoppen der Autorisierung für den Key und dem Sichern von Operationsspuren.
- Widerruf des Keys auf Börsenseite
- Das Deaktivieren oder Löschen des Keys stoppt die Annahme signierter Anfragen für diesen API Key.
- Das Deaktivieren aller sub-account Keys wird verwendet, wenn die Quelle des Leaks nicht identifiziert ist.
- Sichern von Operationsspuren
- Die Liste offener Orders und die Trade-Historie für den Anomaliezeitraum zeigen, welche Operationen ausgeführt wurden.
- Auszahlungshistorie und Änderungen der withdrawal address whitelist zeigen Auszahlungsversuche und Adressvorbereitung.
- Schließen zusätzlicher Konto-Zugriffskanäle
- Passwortänderung und 2FA-Prüfung reduzieren das Risiko eines Webinterface-Zugriffs.
- E-Mail-Sicherheitsprüfungen sind erforderlich, weil Auszahlungsbestätigungen und Whitelist-Änderungen oft an E-Mail gebunden sind.
- Wiederherstellung des Arbeitszugriffs
- Ein neuer Key wird mit minimalen permissions und IP whitelist für den aktuellen Server erstellt.
- API Secret wird im secret manager aktualisiert, damit das alte Secret nicht mehr verwendet wird.
Der Key-Widerruf stoppt die Ausführung von Aktionen, weil die Börse keine Signaturen für diesen API Key mehr akzeptiert, selbst wenn weiter Anfragen eintreffen.
✅ Konfiguration, die Auszahlungsrisiko nach einem Key-Leak reduziert
Das Auszahlungsrisiko nach einem Leak des API Key + API Secret-Paares wird reduziert, wenn der trade Key keine withdraw permission hat, Anfragen durch IP whitelist eingeschränkt sind und Kernkapital vom Trading-sub-account getrennt ist.
Mindestparameter für einen trade Key eines Trading-Systems
- Das Trading-System läuft auf einem VPS mit fester IP, und diese IP ist zur IP whitelist des Keys hinzugefügt.
- Der Key hat read + trade permissions und keine withdraw permission.
- Der Trading-sub-account enthält den Arbeitssaldo, während Kernkapital separat ohne permanente Trading-Keys gespeichert wird.
- API Secret wird in einem secret manager oder verschlüsseltem Speicher gespeichert und gelangt nicht in Repositories oder Logs.
IP whitelist, minimale permissions, withdrawal address whitelist für seltene Auszahlungen und Isolation über sub-accounts begrenzen Schaden auf den Arbeitssaldo und reduzieren das Risiko einer Blockchain-Auszahlung über einen kompromittierten Key.
❓ FAQ zur API-Key-Sicherheit
Warum schützt IP whitelist selbst dann, wenn API Secret leakt?
Die Börse vergleicht die Quell-IP der Anfrage mit der IP whitelist des Keys und lehnt die Anfrage ab, wenn die IP nicht übereinstimmt. Die HMAC-Signatur kann gültig sein, aber die Operation wird nicht ausgeführt, weil die IP-Prüfung auf Börsenseite stattfindet.
Wann wird withdraw permission tatsächlich benötigt?
Withdraw permission wird für automatisierte operative Auszahlungen auf die Blockchain benötigt. Für Trading, Monitoring und Reporting ist withdraw permission nicht erforderlich, weil diese Prozesse Trading- und Read-Endpoints innerhalb der Börse nutzen.
Warum kann ein trade-only Key Verluste ohne Auszahlung verursachen?
Ein trade-only Key erlaubt das Platzieren von Orders. Mit Zugriff auf einen trade-only Key kann ein Angreifer Trades zu einem schlechteren Preis auf einem Markt mit niedriger Liquidität ausführen und Verluste aus Slippage, Spread und Gebühren erzeugen, wenn im Trading-Wallet ein großer Saldo liegt.
Warum einen separaten sub-account für jedes Trading-System verwenden?
Ein sub-account begrenzt den Saldo, der dem Key zur Verfügung steht. Wenn ein Key des Trading-Systems leakt, ist der Schaden auf die Assets dieses sub-account begrenzt, weil die Börse Operationen innerhalb des Saldos des konkreten sub-account ausführt.
Wie lassen sich Keys rotieren, ohne die Orderkontrolle zu verlieren?
Rotation umfasst das Erstellen eines neuen Keys, das Umschalten des Trading-Systems auf das neue API Secret und das Widerrufen des alten Keys. Die Umschaltung wird für einen Zeitraum ohne offene Positionen und aktive Limit-Orders geplant, damit die Key-Änderung die Orderverwaltung nicht unterbricht.
Wie wird das Risiko beim Anschluss eines Drittanbieter-Terminals begrenzt?
Das Risiko wird durch einen trade-only Key auf einem sub-account mit Arbeitssaldo, IP whitelist (wenn Anfragen über einen nutzerseitigen Agent laufen) und deaktivierte withdraw permission begrenzt, wenn das Terminal nicht an operativen Auszahlungen beteiligt ist.
🧷 Wie API-Einschränkungen Auszahlungs- und Trading-Schadensrisiko reduzieren
API-Risiko hängt von erlaubten Operationen und von den Prüfungen ab, die die Börse auf jede Anfrage anwendet: Signatur (API Secret), permissions, IP whitelist und Parameter der Anfragezeit.
- Deaktivierte withdraw permission blockiert Blockchain-Auszahlungen über API, weil die Börse Withdrawal-Endpoints für einen Key ohne dieses Recht ablehnt.
- Eine withdrawal address whitelist begrenzt den Empfänger, weil die Börse Mittel nur an vorab hinzugefügte Adressen sendet.
- IP whitelist begrenzt die Anfragequelle, weil die Börse Anfragen von IPs ablehnt, die nicht in der Key-Liste stehen, selbst bei gültiger Signatur.
- Sub-accounts begrenzen die Verlusthöhe, weil der Key Zugriff auf den Saldo eines bestimmten sub-account erhält und nicht auf alle Kontoassets.