API-sleutel beveiliging

Deze pagina documenteert aanbevolen praktijken voor het opslaan, roteren en intrekken van Cryptohopper MCP API-sleutels. Het advies geldt voor elke omgeving waarin de MCP wordt gebruikt — lokale werkstations, CI-systemen, agent-implementaties en MCP-clients van derden.

Wat een MCP-sleutel toestaat

Een Cryptohopper MCP API-sleutel is een bearer token dat verzoeken authenticeert tegen een enkel Cryptohopper-account.

Wat de sleutel kan doen	Wat de sleutel niet kan doen
Marktgegevens lezen (tickers, orderboeken, kaarsen) op het toegestane niveau van de tier	Toegang tot Cryptohopper bots
Gebruik en quota opvragen voor het account	Trades plaatsen of posities wijzigen
Ondersteunde beurzen en paren weergeven	Toegang tot de accountinterface
—	Cryptohopper Trading API-aanroepen autoriseren

Sleutels zijn alleen-lezen. Een gecompromitteerde MCP-sleutel stelt een aanvaller niet in staat om te handelen. Het stelt wel quotumverbruik toe, wat legitieme workflows kan verstoren.

Zie accountoverzicht voor de relatie tussen sleutels, account en abonnement.

Opslag

Sleutels moeten worden behandeld als geheimen. Standaard praktijken voor het omgaan met geheimen zijn van toepassing.

Aanbevolen

• Bewaar sleutels in een toegewijde secrets manager (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault of equivalent).
• Lees sleutels uit omgevingsvariabelen tijdens runtime. Geef de voorkeur aan omgevingsvariabelen boven configuratiebestanden die zijn vastgelegd in broncodebeheer.
• Beperk bestandsrechten: clientconfiguratiebestanden met sleutels moeten alleen leesbaar zijn voor de eigenaar.
• Gebruik configuratiebestanden per client (~/.config/...) in plaats van systeembrede locaties.

Niet aanbevolen

• Sleutels vastleggen in git-repositories, zelfs in privérepositories.
• Sleutels plakken in chatberichten, issue trackers of supportgesprekken.
• Sleutels delen tussen ontwikkelaars of machines. Maak in plaats daarvan een sleutel per gebruiker aan.
• Sleutels opslaan in platte-tekstbestanden in cloud-gesynchroniseerde mappen (bijv. Dropbox, iCloud Drive) zonder extra versleuteling.

Als een sleutel per ongeluk is vastgelegd in git, trek deze dan onmiddellijk in en genereer een nieuwe. Git-geschiedenis is duurzaam en wordt als gecompromitteerd beschouwd.

Rotatie

Het roteren van sleutels — het intrekken van een oude sleutel en het uitgeven van een nieuwe — is het defensieve mechanisme dat de schadeomvang van een compromis beperkt.

Voorgestelde frequentie

Context	Rotatiefrequentie
Persoonlijk werkstation, lokale MCP-client	Elke 90 dagen
Geplande workflow in CI / cloud	Elke 60 dagen
Gedeeld over meerdere omgevingen	Elke 30 dagen
Sleutel met enige geschiedenis van blootstelling (vastgelegd in repo, geplakt in chat, enz.)	Onmiddellijk, daarna elke 30 dagen

De sleutellimiet van de tier bepaalt hoeveel sleutels er gelijktijdig kunnen bestaan. Zie abonnementstiers.

Rotatieprocedure

1. Genereer een nieuwe API-sleutel in de Cryptohopper-accountinterface.
2. Implementeer de nieuwe sleutel voor alle gebruikers (MCP-clients, CI-geheimen, agentconfiguraties).
3. Verifieer dat elke gebruiker de nieuwe sleutel gebruikt door een testquery uit te voeren.
4. Trek de oude sleutel in via de Cryptohopper-accountinterface.

Sleutels zijn onafhankelijk. Het intrekken van één sleutel heeft geen invloed op andere.

Sleutelsegmentatie

Als de tier meer dan één sleutel toestaat (Adventurer: 3 sleutels; Hero: 10 sleutels), gebruik ze dan om gebruik te segmenteren.

Voorgestelde segmentatiepatronen

• Eén sleutel per agent. Elke afzonderlijke AI-agent krijgt zijn eigen sleutel. Als één agent zich misdraagt en te veel quota verbruikt, kan deze worden geïdentificeerd en vertraagd zonder de anderen te beïnvloeden.
• Eén sleutel per omgeving. Aparte sleutels voor productie, staging en ontwikkeling. Het intrekken of roteren van de ontwikkelsleutel laat productie onaangetast.
• Eén sleutel per gebruiker. In een klein team biedt één sleutel per teamlid attributie voor quotumgebruik en maakt individuele intrekking mogelijk wanneer een teamlid vertrekt.

Onthoud dat alle sleutels het enkele wekelijkse quota van het account delen. Segmentatie is voor attributie, intrekking en vertraging — niet voor quota-uitbreiding.

Intrekking

Trek een sleutel in wanneer:

• De sleutel is blootgesteld (vastgelegd in een repository, verzonden via een onversleuteld kanaal, aanwezig op een verloren of gestolen apparaat).
• Een gebruiker geen toegang meer nodig heeft (buiten gebruik gestelde workflow, vertrokken teamlid).
• Als onderdeel van geplande rotatie.

Intrekking via de Cryptohopper-accountinterface treedt onmiddellijk in werking. Daaropvolgende verzoeken met de ingetrokken sleutel retourneren UNAUTHORIZED. Zie foutreferentie.

Verdediging in de diepte

Naast basishygiëne:

• Netwerkbeperkingen. Als jouw MCP-client in een vaste omgeving draait (CI-runner, productieserver), overweeg dan om uitgaand verkeer specifiek te beperken tot mcp-data.cryptohopper.com.
• Auditlogs. Onderhoud lokale logs van welke sleutel welke actie heeft uitgevoerd. Het vergelijken van MCP-gebruikspatronen met de per-account gebruikstelemetrie van Cryptohopper helpt afwijkingen te detecteren.
• Monitor gebruik. Een plotselinge piek in het aantal aanroepen is vaak het eerste teken van een gecompromitteerde sleutel. Zie gebruik en limieten.
• Scheid van Trading API-inloggegevens. De Cryptohopper REST Trading API gebruikt aparte inloggegevens. Bewaar MCP-sleutels en Trading API-inloggegevens niet samen in een enkel onversleuteld bestand — een compromis van de ene mag de andere niet impliceren.

Incidentrespons

Als een sleutel wordt verdacht van compromittering:

1. Trek onmiddellijk in. Wacht niet op bevestiging. De kosten van een onnodige intrekking zijn klein; de kosten van een vertraagde intrekking zijn quotumverbruik, en — als de sleutel is gekoppeld aan Trading API-inloggegevens in hetzelfde compromis — mogelijk meer.
2. Controleer gebruik. Raadpleeg het gebruikseindpunt om te zoeken naar afwijkende patronen in de huidige cyclus. Documenteer alles verdachts.
3. Bekijk de bron van blootstelling. Begrijp hoe de sleutel is blootgesteld. Een gelekte sleutel is vaak een symptoom van een bredere lacune in de beveiliging.
4. Roteer aangrenzende inloggegevens. Als dezelfde omgeving Trading API-inloggegevens bevatte, roteer die dan ook.
5. Genereer een nieuwe sleutel en implementeer deze opnieuw voor gebruikers.