MCP-Server-Sicherheit: 12 Kontrollen, bevor Sie KI an Ihre Systeme anbinden

Einen KI-Assistenten mit Ihrem CRM, Ihrer Datenbank oder Ihrem ERP zu verbinden, ist gerade deshalb nützlich, weil er in echten Systemen handeln kann. Genau darin liegt auch das Risiko. Ein MCP-Server ist eine neue Tür in Ihr Unternehmen, und sie wird von einem Sprachmodell gesteuert, das sich in die Irre führen lässt.

Die meisten Probleme, die wir sehen, sind nicht exotisch. Es sind bekannte Fehler an einem neuen Ort. Gemeinsam genutzte Admin-Schlüssel. Tools, die zu viel dürfen. Keine Logs. Niemand prüft, was in den Tool-Beschreibungen steht. Jeder dieser Fehler ist günstig zu verhindern und teuer zu beheben.

Was diese Checkliste abdeckt

MCP (Model Context Protocol) ist ein offener Standard, den Anthropic eingeführt hat. Er ermöglicht es KI-Assistenten wie Claude und anderen kompatiblen Clients, sich über kleine Programme, sogenannte MCP-Server, mit Tools und Daten zu verbinden. Die Unterstützung unterscheidet sich je nach KI-Client, prüfen Sie daher vor der Planung eines Rollouts die aktuelle Dokumentation des jeweiligen Clients.

Nutzen Sie die folgende Checkliste, wenn Sie einen neuen MCP-Server bauen, einen kaufen oder einen bereits laufenden prüfen. Jeder Punkt hat eine kurze Erläuterung. Behandeln Sie jedes „Nein“ als Befund mit einem Verantwortlichen und einem Termin.

Die Sicherheits-Checkliste für MCP-Server

1. Jeden Nutzer authentifizieren. Kein anonymer Zugriff und keine gemeinsam genutzten Konten. Nutzen Sie bei Remote-Servern OAuth, wo der Client es unterstützt, damit sich jede Person mit ihrer eigenen Identität anmeldet. Welche Abläufe unterstützt werden, entnehmen Sie der aktuellen MCP-Spezifikation und der Dokumentation Ihres Clients.
2. Pro Nutzer und pro Tool autorisieren. Zu wissen, wer jemand ist, heißt nicht, dass er alles tun darf. Reichen Sie die Identität des Nutzers nach Möglichkeit an nachgelagerte Systeme weiter, damit bestehende Berechtigungen weiterhin greifen. Andernfalls setzen Sie Rollenprüfungen im Server durch.
3. Minimale Rechte anwenden. Servicekonten und API-Tokens erhalten die engsten Berechtigungen, die noch funktionieren. Ein Tool, das Aufträge liest, sollte kein Token besitzen, mit dem sich Kunden löschen lassen.
4. Standardmäßig read-only. Liefern Sie zuerst lesende Tools aus. Fügen Sie schreibende Tools einzeln hinzu, und nur, wenn ein klarer Bedarf und ein Freigabeschritt bestehen.
5. Tools eng fassen. „Auftragsstatus per Auftragsnummer abrufen“ ist sicherer als „beliebigen API-Aufruf ausführen“. Eng gefasste Tools lassen sich leichter validieren, testen und erklären.
6. Jede Eingabe validieren. Verwenden Sie strikte Schemas mit Typen, Längen, Formaten und erlaubten Werten. Lehnen Sie alles andere ab. Geben Sie vom Modell erzeugten Text niemals direkt an SQL, Shell-Befehle oder Dateipfade weiter.
7. Tool-Ausgaben als nicht vertrauenswürdig behandeln. E-Mails, Tickets, Dokumente und Webseiten können Anweisungen an das Modell enthalten. Das ist Prompt Injection. Lassen Sie Tool-Ausgaben nicht unbemerkt schreibende Tools auslösen. Beschränken Sie, welche Tools in derselben Sitzung laufen dürfen, und entfernen oder markieren Sie verdächtige Inhalte, wo es praktikabel ist.
8. Secrets richtig handhaben. Speichern Sie Zugangsdaten in einem Secrets-Manager oder in verschlüsselten Umgebungseinstellungen. Legen Sie sie niemals in Code, Tool-Beschreibungen, Prompts oder Logs ab. Verwenden Sie für jede Umgebung eigene Zugangsdaten und rotieren Sie sie.
9. Rate-Limits und Kontingente setzen. Begrenzen Sie Aufrufe pro Nutzer und pro Tool. Deckeln Sie die Ergebnisgröße und setzen Sie Timeouts. Das schützt nachgelagerte Systeme und bremst eine außer Kontrolle geratene Agentenschleife aus.
10. Audit-Logs führen. Erfassen Sie, wer welches Tool mit welchen Eingaben aufgerufen hat, was passiert ist und wann. Halten Sie personenbezogene Daten nach Möglichkeit aus den Logs heraus. Machen Sie Logs durchsuchbar und legen Sie eine Aufbewahrungsfrist fest.
11. Menschliche Freigabe für Schreibzugriffe verlangen. Jede Aktion, die Datensätze ändert, Nachrichten versendet oder Geld bewegt, zeigt zuerst eine Vorschau. Eine benannte Person gibt sie frei, und die Freigabe wird protokolliert. Unser Leitfaden zu KI-Agenten mit menschlicher Freigabe zeigt praxistaugliche Muster.
12. Tool-Beschreibungen versionieren und prüfen. Das Modell liest Tool-Namen und -Beschreibungen, um zu entscheiden, was es aufruft. Eine geänderte Beschreibung ändert das Verhalten. Verwalten Sie sie in der Versionskontrolle, prüfen Sie Änderungen wie Code und seien Sie vorsichtig bei Servern von Drittanbietern, deren Beschreibungen sich ohne Vorankündigung ändern können.

So führen Sie das Review durch, Schritt für Schritt

1. Alle Tools auflisten mit ihren Ein- und Ausgaben, dem nachgelagerten System und den Berechtigungen, die sie besitzen.
2. Ein kurzes Bedrohungsmodell schreiben. Fragen Sie für jedes Tool, was passiert, wenn das Modell es mit der schlimmsten plausiblen Eingabe aufruft.
3. Die Checkliste durchgehen und jede Lücke als Befund mit einem Schweregrad erfassen.
4. Prompt Injection testen. Platzieren Sie Anweisungen in Daten, die der Server zurückgibt, und bestätigen Sie, dass sie keine unbeabsichtigten Aktionen auslösen.
5. Berechtigungen testen mit zwei Nutzern, die unterschiedliche Daten sehen sollten.
6. Nach Priorität beheben, beginnend mit allem, was unautorisierte Schreibzugriffe oder Datenoffenlegung ermöglicht.
7. Bei jedem Release wiederholen, das ein Tool hinzufügt oder eine Beschreibung ändert.

Eingesetzte Tools

• MCP-SDKs für Python und TypeScript, mit strikten Eingabeschemas.
• Python mit FastAPI für Validierung, Auth-Middleware und Integrationsschichten.
• Ihr Identity Provider für OAuth und Rolleninformationen.
• Ein Secrets-Manager und Ihre bestehende Log- und Monitoring-Plattform.

Die MCP-Spezifikation und die Funktionen der Clients entwickeln sich weiter. Prüfen Sie die aktuelle Spezifikation und die Dokumentation des jeweiligen Anbieters, statt sich auf ältere Anleitungen zu verlassen.

Was Sie für den Start brauchen

• Zugriff auf Code, Konfiguration und Deployment-Einstellungen des Servers.
• Eine Liste der angebundenen Systeme und der Zugangsdaten, die jedes Tool verwendet.
• Jemanden, der erklären kann, wer den Server nutzt und wofür.
• Eine Staging-Umgebung für Injection- und Berechtigungstests.

Typischer Umfang und Zeitrahmen

Als Schätzung: Das Review eines kleinen Servers mit einer Handvoll Tools dauert oft eher Tage als Wochen. Ein neuer Read-only-Server, bei dem diese Kontrollen von Anfang an umgesetzt sind, dauert typischerweise ein bis drei Wochen, abhängig von den beteiligten Systemen.

Die häufigsten Befunde

Wenn wir bestehende Server prüfen, tauchen einige Probleme immer wieder auf.

• Ein gemeinsames Token für alle. Der Server funktioniert, aber jeder Nutzer hat im nachgelagerten System faktisch Admin-Rechte.
• Ein „Kann-alles“-Tool. Ein generisches API- oder SQL-Tool, das zum Testen gedacht war und nie entfernt wurde.
• Secrets am falschen Ort. Schlüssel in einer Konfigurationsdatei, die ins Repository eingecheckt wurde, oder in Logs ausgegeben.
• Keine Aufzeichnung von Aktionen. Niemand kann sagen, wer letzten Dienstag über den Assistenten einen Datensatz geändert hat.
• Ungeprüfte Server von Drittanbietern. Ein Community-Server, den ein Entwickler installiert hat und den jetzt das ganze Team nutzt.

Keines dieser Probleme erfordert eine Neuentwicklung. Jedes ist eine gezielte Korrektur, und eine frühe Behebung ist weit günstiger als die Reaktion auf einen Vorfall.

Risiken und wie wir damit umgehen

Das größte Risiko besteht darin, den MCP-Server als schnelles Skript statt als Produktionssoftware zu behandeln. Wir wenden dieselbe Disziplin an wie bei jeder API: Code-Review, Tests, gestaffelte Releases und Monitoring. Das zweite Risiko ist Freigabemüdigkeit, bei der Menschen auf „Freigeben“ klicken, ohne zu lesen. Halten Sie die Zahl schreibender Tools gering, die Vorschauen kurz und klar, und prüfen Sie die Freigabeprotokolle regelmäßig.

Wann Sie das nicht bauen sollten

Wenn der offizielle Connector eines Anbieters Ihren Bedarf deckt und sein Sicherheitsmodell Ihrer Prüfung standhält, nutzen Sie ihn. Wenn die Daten stark reguliert sind und Ihre Umgebung nicht verlassen dürfen, ziehen Sie zuerst ein privates Deployment in Betracht. Unser Leitfaden zu privatem RAG für regulierte Daten erklärt die Optionen. Und wenn sich nach dem Livegang niemand um den Server kümmert, verbinden Sie ihn nicht mit Systemen, in die er schreiben kann.

Zu konkreten Umsetzungen lesen Sie Ihr CRM per MCP mit Claude verbinden und ein MCP-Server für Datenbank-Analysen.

Wie UnlockLive Sie unterstützt

UnlockLive IT ist eine Softwareagentur mit Hauptsitz in Toronto und eigenem Entwicklungsteam. Wir bauen diese Integrationen für Unternehmen in den USA, Kanada, Großbritannien und Australien. Unser Service MCP-Server-Entwicklung umfasst Scoping, Bedrohungsmodell, Umsetzung, Deployment und laufende Wartung. Unser Cybersecurity-Team führt MCP-Sicherheitsreviews durch und liefert ein schriftliches Bedrohungsmodell mit priorisierten Korrekturen.

Wenn Sie eine zweite Meinung zu Umfang oder Risiken möchten, buchen Sie ein kostenloses 30-minütiges Gespräch. Bringen Sie ein oder zwei Fragen mit, die Ihr Team jede Woche stellt, und wir sagen Ihnen ehrlich, ob ein MCP-Server das richtige Werkzeug ist.