MCP-Sicherheit: Was ich nach 95 Produktionsausfällen gelernt habe
Ich dachte, Sicherheit sei einfach. Abhängigkeiten aktualisieren. HTTPS verwenden. Keine Secrets hartcodieren.
Ich habe mich geirrt.
Nach 95 Produktionsausfällen und 1.800 Entwicklungsstunden habe ich gelernt, dass die Sicherheit des Model Context Protocol (MCP) anders ist. Sie ist nicht wie die Standard-REST-API-Sicherheit.
MCP schafft neue Risiken, da der Client ein LLM ist und kein Mensch.
Hier ist das, was Sie wissen müssen, um Ihren MCP-Server sicher zu halten.
1. Das MCP-Bedrohungsmodell
Bei REST wissen Sie genau, wer Ihre API aufruft. Bei MCP fungiert das LLM als Vermittler. Das ändert alles:
- LLMs können Tool-Aufrufe oder Parameter halluzinieren.
- Benutzer rufen Tools nicht direkt auf. Sie sprechen mit dem LLM, und das LLM spricht mit Ihrem Server.
- Böswillige Clients können Ihren Server während der Discovery nach versteckten Tools durchsuchen.
Ihre größte Bedrohung ist nicht nur ein Hacker. Es ist ein gutmeinendes LLM, das einen versehentlichen Fehler macht, der Ihr System zum Absturz bringt.
2. API-Key-Management
Viele Entwickler übergeben API-Keys in Query-Parametern, um es sich einfach zu machen. Das ist ein Fehler. Query-Parameter erscheinen in jedem Server-Log und Proxy.
Folgen Sie diesen Regeln:
- Verwenden Sie Header-Authentifizierung (
Authorization: Bearer). - Vermeiden Sie die Übergabe von Keys im JSON-Body.
- Erstellen Sie für jeden Client einen eigenen API-Key. Dies hilft Ihnen, die Nutzung zu verfolgen und den Zugriff zu entziehen, ohne alles lahmzulegen.
3. Strikte Input-Validierung
LLMs werden falsch raten. Sie werden falsche Typen und zusätzliche Parameter senden. Sie müssen jeden Aufruf validieren:
- Prüfen Sie zuerst, ob der Tool-Name in Ihrer Liste existiert.
- Lehnen Sie Aufrufe mit zusätzlichen Parametern ab. Ignorieren Sie diese nicht einfach.
- Stimmen Sie die Parametertypen exakt überein. Führen Sie keine Typumwandlungen (Coercion) durch.
- Legen Sie strikte Größenbeschränkungen für Strings und Arrays fest, um Speicherabstürze zu verhindern.
- Bereinigen (Sanitize) Sie alle Dateipfade, um Directory Traversal zu verhindern.
4. Gestaffeltes Rate Limiting
Ein einziger Benutzer-Prompt kann zehn Tool-Aufrufe gleichzeitig auslösen. Dies kann Ihren Connection Pool in Sekundenschnelle erschöpfen.
Nutzen Sie drei Verteidigungsebenen:
- Limits pro API-Key, um die Client-Nutzung zu kontrollieren.
- Limits pro IP, um Brute-Force-Angriffe zu stoppen.
- Limits für gleichzeitige Verbindungen, um Ihren Server bei Lastspitzen am Laufen zu halten.
5. Risiken durch Prompt Injection
Ein Benutzer kann ein LLM dazu verleiten, ein destruktives Tool aufzurufen. Wenn ein Benutzer dem LLM sagt, es solle alle Notizen löschen, wird das LLM dies möglicherweise tatsächlich tun.
Schützen Sie sich:
- Trennen Sie Lese- und Schreibvorgänge.
- Erfordern Sie eine manuelle Bestätigung durch den Benutzer für jede Lösch- oder Aktualisierungsaktion.
- Verwenden Sie das Prinzip der geringsten Berechtigung (Principle of Least Privilege) für Ihren Datenbank-User.
Sicherheit ist ein fortlaufender Prozess. Beginnen Sie mit einem besseren Key-Management und strikter Validierung. Diese Schritte lösen die meisten Probleme.
Optionale Lern-Community: https://t.me/GyaanSetuAi