MCP-beveiliging: Wat ik heb geleerd na 95 productiestoringen

Ik dacht dat beveiliging simpel was. Afhankelijkheden bijwerken. HTTPS gebruiken. Geen geheimen hardcoderen.

Ik had het mis.

Na 95 productiestoringen en 1.800 uur ontwikkeling heb ik geleerd dat de beveiliging van het Model Context Protocol (MCP) anders is. Het is niet hetzelfde als standaard REST API-beveiliging.

MCP creëert nieuwe risico's omdat de client een LLM is, geen mens.

Dit is wat je moet weten om je MCP-server veilig te houden.

  1. Het MCP-bedreigingsmodel

In REST weet je precies wie je API aanroept. In MCP fungeert de LLM als tussenpersoon. Dit verandert alles:

  • LLM's kunnen tool-aanroepen of parameters hallucineren.
  • Gebruikers roepen tools niet direct aan. Ze praten met de LLM, en de LLM praat met jouw server.
  • Kwaadwillende clients kunnen je server tijdens de discovery-fase scannen op verborgen tools.

Je grootste bedreiging is niet alleen een hacker. Het is een goedbedoelende LLM die een onbedoelde fout maakt waardoor je systeem crasht.

  1. Beheer van API-sleutels

Veel ontwikkelaars geven API-sleutels mee in queryparameters om het makkelijk te maken. Dit is een fout. Queryparameters verschijnen in elk serverlog en elke proxy.

Volg deze regels:

  • Gebruik header-authenticatie (Authorization: Bearer).
  • Vermijd het meesturen van sleutels in de JSON-body.
  • Maak voor elke client een andere API-sleutel aan. Dit helpt je bij het bijhouden van het gebruik en het intrekken van toegang zonder alles te verstoren.
  1. Strikte inputvalidatie

LLM's zullen fouten maken. Ze zullen verkeerde types en extra parameters sturen. Je moet elke aanroep valideren:

  • Controleer eerst of de naam van de tool in je lijst staat.
  • Weiger aanroepen met extra parameters. Negeer ze niet alleen.
  • Zorg dat de parametertypes exact overeenkomen. Forceer geen datatypes.
  • Stel strikte limieten in voor de grootte van strings en arrays om geheugencrashes te voorkomen.
  • Sanitize alle bestandspaden om directory traversal te voorkomen.
  1. Gelaagde rate limiting

Eén gebruikersprompt kan tien tool-aanroepen tegelijk triggeren. Dit kan je connection pool binnen enkele seconden uitputten.

Gebruik drie lagen van verdediging:

  • Limieten per API-sleutel om het gebruik door clients te beheersen.
  • Limieten per IP om brute force-aanvallen te stoppen.
  • Limieten voor gelijktijdige verbindingen om je server draaiende te houden tijdens pieken.
  1. Risico's op prompt injection

Een gebruiker kan een LLM misleiden om een destructieve tool aan te roepen. Als een gebruiker de LLM vraagt om alle notities te verwijderen, kan de LLM dit daadwerkelijk doen.

Bescherm jezelf:

  • Scheid lees- en schrijfoperaties.
  • Vereis handmatige bevestiging door de gebruiker voor elke verwijder- of updateactie.
  • Gebruik het principe van de minste privileges (least privilege) voor je databasegebruiker.

Beveiliging is een continu proces. Begin met beter sleutelbeheer en strikte validatie. Deze stappen lossen de meeste problemen op.

Bron: https://dev.to/kevinten10/mcp-security-what-i-learned-securing-my-mcp-server-after-95-production-outages-3hc0

Optionele leercommunity: https://t.me/GyaanSetuAi