Cyberbedrohungen
Mit Containern gesicherte MCP-Infrastruktur, Teil 2
Über verifizierte MCP-Server lassen sich Angriffe auf die KI-Lieferkette über MCP-Server-Repositorys verhindern. Auch lässt sich KI-Sicherheit über die Einführung des Prinzips der Mindestprivilegien und über die Containerisierung verbessern.
Save to Folio
Das Model Context Protocol (MCP) ist ein Open-Source-Standard, der es KI-Anwendungen ermöglicht, mit Systemen wie Datenbanken, APIs und Diensten unter Verwendung natürlicher Sprache zu interagieren, wodurch die Erstellung komplexer Workflows auf Basis von LLMs vereinfacht und skalierbarer wird. Das Protokoll bietet zwar viele Vorteile für Unternehmen, erweitert aber auch bei der Implementierung die Angriffsfläche und erfordert daher zusätzliche Sicherheitsmaßnahmen, so etwa die Containerisierung von MCP-Servern.
Seit der Einführung von MCP im Oktober 2024 ist die Anzahl der öffentlichen MCP-Server-Repositorys auf über 22.000 gestiegen. Mittlerweile wurde die Entwicklung bestimmter MCP-Server bereits wieder aufgegeben. Diese werden dann zu ruhenden, ungenutzten Ressourcen.
Wir haben über 22.000 MCP-Server-Code-Repositorys analysiert, die über öffentliche MCP-Marktplätze verfügbar sind. Diese Marktplätze bieten MCP-Server-Listen mit Funktionsbeschreibungen, Tool-Verfügbarkeit, Bereitstellungseinstellungen und, was am wichtigsten ist, Links zum Quellcode-Repository des Entwicklers. In 746 Fällen existiert das Code-Repository nicht mehr oder ist privat.
Dies schafft eine gefährliche Situation, da diese verlassenen Einträge von jedem wiederbelebt werden können, der es schafft, denselben Repository-Namen zu kontrollieren, insbesondere wenn der ursprüngliche Betreuer nicht mehr aktiv ist.
Sobald ein GitHub-Benutzername freigegeben ist, kann er von jedem anderen registriert werden. Das heißt, ein Angreifer könnte den Benutzernamen übernehmen, das Repository neu erstellen und eine bösartige Version des MCP-Servers unter derselben bekannten Adresse veröffentlichen. Ein Nutzer, der dies in einem MCP-Marktplatz sieht, keine Ahnung, dass es nicht mehr das ursprüngliche sichere Projekt ist, und könnte es klonen. Dies ist ein Szenario für einen Supply-Chain-Angriff im Zeitalter der KI, das durch das Vertrauen der Marktplätze ermöglicht wird.
Ein verifiziertes MCP-Server-Container-Image hilft, dieses Risiko zu mindern. Ein vom Anbieter signiertes Container-Image gewährleistet die Authentizität des Codes und verringert die Wahrscheinlichkeit, dass eine manipulierte oder veraltete Version ausgeführt wird.
Der Betrieb des MCP-Servers in einem Container sorgt zusätzlich für eine Isolationsschicht, die die Auswirkungen einer Kompromittierung des Servers begrenzt. Diese Kombination aus Image-Verifizierung und Container-Isolation hilft, sowohl die Vertrauens- als auch die Wartungsprobleme zu lösen, die mit einem so schnell wachsenden Ökosystem einhergehen.
Es sollte jedoch gesagt werden, dass ein verifiziertes Container-Image zwar das Risiko der Verwendung inoffizieller, anfälliger oder bösartiger Images mindert, aber keine Supply-Chain-Angriffe auf den Anbieter oder die Container-Registrierung selbst verhindert und somit allein keine vollständige Sicherheit garantieren kann.
Implementierung des Prinzips der geringsten Privilegien mit Containerisierung
Im Falle der MCP-Sicherheit ist die Anwendung des Prinzips der geringsten Privilegien der beste Ansatz: Es ist einfach, messbar und kann mit einer Checkliste nachgewiesen werden. Die Begrenzung der effektiven Funktionen und Berechtigungen des Servers ist der realistischste Weg, um Risiken zu minimieren: Sie kann getestet, durchgesetzt und überprüft werden.
Im Folgenden finden Sie einige Best Practices für MCP-Server, die in Containern ausgeführt werden:
- Identität und Tokens
- Weisen Sie jedem MCP-Server ein eigenes Dienstkonto und eine eigene Client-Identität zu. Verwenden Sie Tokens nicht für mehrere Server oder Tools.
- Nutzen Sie kurzlebige Anmeldeinformationen (OIDC/STS). Legen Sie den TTL-Wert auf Minuten statt auf Tage fest.
- Beschränken Sie Tokens auf die genauen APIs und Aktionen, und vermeiden Sie Platzhalter.
- Binden Sie Tokens nach Möglichkeit an Zielgruppe und Herkunft. Deaktivieren Sie die Aktualisierung, sofern nicht erforderlich.
- Prozess- und Container-Laufzeit
- Führen Sie den Prozess als Nicht-Root aus, fügen Sie „No-New-Privileges” hinzu, entfernen Sie alle Funktionen und fügen Sie dann nur das hinzu, was wirklich erforderlich ist (oftmals nichts).
- Verwenden Sie ein schreibgeschütztes Root-Dateisystem, mounten Sie bei Bedarf ein kleines beschreibbares tmpfs.
- Aktivieren Sie das Standardprofil von seccomp und ein AppArmor/SELinux-Profil.
- Vermeiden Sie eine Shell im Image; keine Bash, keine Paketmanager im Produktions-Image.
- Dateisystem und Mounts
- Mounten Sie nur das Verzeichnis, das der Server benötigt, wenn möglich schreibgeschützt.
- Hängen Sie niemals den Docker-Socket, den SSH-Agenten, Cloud-CLI-Profile oder Ihr Home-Verzeichnis ein.
- Netzwerkausgang
- Verweigern Sie standardmäßig alle Ausgänge. Lassen Sie nur die wenigen Endpunkte zu, die der Server erreichen muss (z. B. einen bestimmten API-Hostnamen).
- Binden Sie sich an 127.0.0.1, wenn Sie HTTP/SSE verwenden müssen; bevorzugen Sie stdio, um Listening-Sockets zu vermeiden.
- Werkzeugoberfläche
- Deaktivieren Sie riskante Tools standardmäßig (Dateisystemschreiben, Shell, Cloud-Verwaltung). Aktivieren Sie sie von Fall zu Fall.
- Fügen Sie für Befehle, Pfade und Zielressourcen Zulassungslisten anstelle von Sperrlisten hinzu.
- Geheimnisverwaltung
- Bevorzugen Sie das On-Demand-Abrufen geheimer Daten aus einem Tresor gegenüber der Festcodierung von Anmeldedaten.
Stellen Sie sicher, dass der MCP-Servercontainer nur kurzzeitig besteht und sein Zugriffstoken auf eine einzige API beschränkt ist. Der Container sollte keine beschreibbaren Mounts, keine Shell und keine zusätzlichen Linux-Funktionen haben, und die Netzwerkzugänglichkeit sollte auf ein Minimum beschränkt sein. Wenn dieser Server ausgenutzt wird, bleiben die Auswirkungen gering und sind leichter zu erkennen, was in der Praxis dem Prinzip der geringsten Privilegien entspricht.
Eine weitere wichtige Sicherheitsmaßnahme, die bei containerisierten MCP-Bereitstellungen oft übersehen wird, ist die Ausführung des Prozesses als Nicht-Root-Benutzer innerhalb des Containers. Container bieten Isolation, aber wenn der Containerprozess als Root ausgeführt wird und ein Angreifer aus der Anwendung in den Container entkommt, erbt er Root-Rechte, was die Auswirkungen verstärkt.
Insgesamt enthielten 5414 der 22000 von uns analysierten MCP-bezogenen GitHub-Repositorys eine Dockerfile, was auf eine Unterstützung der Containerisierung hindeutet. Alarmierend ist, dass nur 1.276 davon explizit einen Benutzer mit Mindestprivilegien konfiguriert hatten, während 96 die Root-Nutzung verstärkten. Die übrige Mehrheit vertraute dem Standardbenutzer aus dem Basis-Image, der in der Regel Root ist.
Diese Daten verdeutlichen eine erhebliche Lücke in den Standard-Sicherheitspraktiken. Container bieten zwar eine wertvolle zusätzliche Sicherheitsebene, doch wenn die Berechtigungen innerhalb der Container nicht eingeschränkt werden, wird das gesamte Modell untergraben, sodass MCP-Server Angriffen zur Erhöhung der Privilegien ausgesetzt sind.
Mit anderen Worten: Die bereitgestellten MCP-Container sind nicht unbedingt sicher und müssen möglicherweise individuell bewertet und angepasst werden. Entscheidet sich ein Unternehmen dafür, MCPs durch Containerisierung zu stärken, sollten Sicherheitstools und -richtlinien implementiert werden, um den Schutz der Container-Infrastruktur, der Software-Lieferkette, der Laufzeitumgebung und der dazwischen laufenden Prozesse zu gewährleisten.
Trend Vision One™ Container Security bietet umfassenden Containerschutz, indem die Lösung die Containersicherheit durch fortschrittliche Image Scans, richtlinienbasierte Zugriffskontrolle sowie Schutz, Erkennung und Reaktion während der Laufzeit vereinfacht.