Beveiligingsexperts roepen op om beheerder-sleutels net zo streng te auditen als broncode. Aanleiding is een grote kraak bij Drift Protocol van circa 200 miljoen dollar. Het handelsplatform voor crypto‑derivaten draait op Solana en werd recent getroffen. De oproep is relevant voor alle DeFi‑diensten, ook in Europa waar MiCA en DORA hogere eisen aan governance en risicobeheer stellen.
Sleutels zijn zwakke plek
Een beheerder‑sleutel is een privésleutel met extra rechten, zoals updaten of pauzeren van slimme contracten. Zo’n sleutel kan ook toegang geven tot fondsen of parameters die prijzen en risico’s bepalen. Als die sleutel wordt misbruikt of gestolen, kan schade snel groot zijn. Dat risico geldt zelfs wanneer de code zelf geen fouten bevat.
De aanval op Drift Protocol zet dit punt op scherp. Het incident laat zien dat machtige rechten rond contracten en infrastructuur een aantrekkelijk doelwit zijn. Op het moment van schrijven is de volledige toedracht publiek nog onduidelijk. Wel is duidelijk dat DeFi‑platforms hun sleutelbeheer en besluitvorming transparanter moeten maken.
Beveiliging draait dus niet alleen om code, maar ook om processen. Wie kan wat doen, hoe snel, en met welke controle? Antwoorden op die vragen horen in elke audit. Zonder die checks blijft er een blinde vlek in de verdediging.
Een beheerder‑sleutel is een privésleutel die bijzondere bevoegdheden geeft over een protocol. Misbruik van zo’n sleutel kan directe gevolgen hebben voor fondsen en functies.
Code-audit schiet vaak tekort
Veel projecten laten hun slimme contracten testen door externe auditors. Dat is goed, maar vaak beperkt tot programmeerfouten en logica. Operationale risico’s, zoals sleutelbeheer, upgraderechten en noodpauzes, blijven soms buiten beeld. Juist daar ontstaan vaak lekken.
Tools voor code‑analyse, ook met kunstmatige intelligentie, vinden patronen en bekende fouten. Maar deze systemen zien geen off‑chain processen en menselijk gedrag. Ze kunnen niet beoordelen of een multisig echt goed is ingericht. Of of een timelock in de praktijk steeds wordt omzeild.
Een complete audit legt ook macht en bevoegdheden vast. Wie zijn de ondertekenaars? Hoeveel handtekeningen zijn nodig? En welke acties staan onder tijdslot en welke niet? Zonder zulke antwoorden blijft “geauditeerd” schijnzekerheid.
Transparantie is hier een deel van de oplossing. Documenteer rechten en noodprocedures publiek. Laat kritieke acties on‑chain loggen met duidelijke labels. En publiceer na elk incident een technisch verslag met leerpunten.
Europese regels sturen beheer
In de EU scherpen MiCA en DORA het speelveld aan. MiCA vraagt van crypto‑dienstverleners duidelijke governance, risicobeheer en incidentmeldingen. DORA legt eisen op aan ICT‑risico’s, testen en operationele veerkracht. Samen zetten ze de toon voor volwassen sleutelbeheer en procedures.
Volledig gedecentraliseerde DeFi valt nog grotendeels buiten MiCA. Toch kijken toezichthouders naar praktische effecten voor Europese gebruikers. Diensten met een herkenbare beheerpartij of interface in de EU krijgen eerder te maken met verwachtingen rond interne controles. Goed sleutelbeheer past daarbij.
In Nederland wijzen DNB en AFM al langer op operationele risico’s bij crypto‑diensten. Incidenten zoals bij Drift onderstrepen dat punt, ook als het platform buiten de EU draait. Europese gebruikers ervaren dezelfde gevolgen bij verlies van fondsen. Heldere meldplichten en herstelplannen zijn daarom van belang.
NIS2 en sectorale regels kunnen aanvullend gaan gelden voor aanbieders met kritieke diensten. Dat raakt bijvoorbeeld custodians en gateways die aan DeFi koppelen. Voor hen is sleutelbeheer geen keuze maar een plicht. Denk aan rotatie, scheiding van taken en onafhankelijke controles.
Praktische stappen voor platforms
Maak beheerder‑rechten schaars en controleerbaar. Gebruik multisig (meerdere ondertekenaars) of MPC (meervoudige berekening) in plaats van één sleutel. Zet kritieke acties achter een timelock, zodat de markt kan reageren. En beperk wat een sleutel überhaupt kan, via rol‑gebaseerde rechten.
Beveilig sleutels met hardware en beleid. Denk aan hardware security modules, offline opslag en periodieke rotatie. Leg procedures vast voor verlies, diefstal en ontslag van medewerkers. Laat wijzigingen door een tweede team controleren.
Verhoog de drempel voor misbruik. Log alle beheeracties on‑chain en publiceer notificaties. Stel limieten in voor waarde en frequentie van ingrepen. En gebruik “circuit‑breakers” die automatisch ingrijpen bij abnormaal gedrag.
Test meer dan alleen code. Doe red‑teaming van governance: probeer sleutels te stelen, procedures te omzeilen en timelocks te misbruiken. Laat externe partijen controleren of documentatie klopt met de werkelijkheid. En koppel een reëel bug bounty‑programma aan zowel code als processen.
Wat gebruikers nu kunnen
Controleer of een platform multisig en timelocks gebruikt. Kijk in documentatie en explorers naar beheeracties. Goede signalen zijn heldere schema’s, publieke sleutels van ondertekenaars en duidelijke limieten. Vage of ontbrekende informatie is een risico.
Let op verzekeringsfondsen en noodplannen. Heeft het protocol een insurance fund en hoe wordt die aangevuld? Staat er een plan voor compensatie en herstart? Zulke details bepalen uw herstelkans na een incident.
Diversifieer en beperk blootstelling. Gebruik waar mogelijk self‑custody en splits posities over diensten. Vermijd platforms die één enkele sleutel of onbeperkte admin‑rechten hebben. En monitor communicatiekanalen op incidentmeldingen.
Wees alert op EU‑specifieke bescherming. Diensten die onder MiCA vallen hebben straks strengere plichten rond governance en meldingen. Voor puur DeFi geldt die bescherming vaak niet. Neem dat mee in uw risico‑inschatting.
Incidentmelding en transparantie
Snelle, volledige communicatie is cruciaal na een hack. Publiceer binnen uren wat zeker is, wat nog wordt onderzocht en welke stappen volgen. Deel technische details zodra dat veilig kan. En geef gebruikers concrete instructies.
Platforms kunnen leren van DORA‑praktijken. Richt een incidentrespons in met rollen, draaiboeken en escalaties. Oefen die periodiek, ook met externe partijen. En evalueer na afloop met meetbare verbeteracties.
Transparante post‑mortems helpen vertrouwen te herstellen. Leg uit welke controle faalde en hoe die wordt versterkt. Publiceer bewijs van sleutelrotatie, nieuwe timelocks en aanvullende checks. Laat een onafhankelijke partij dit valideren.
Op het moment van schrijven onderzoekt de sector de gevolgen van het Drift‑incident. De kern blijft echter hetzelfde. Beheerder‑sleutels mogen geen single point of failure zijn. Zonder governance‑audit is geen enkele code‑audit compleet.
