MCP-Sicherheit: sichere Konfiguration, Identität und Gateway-Autorisierung

Das Protokoll ist nicht der Kern des Problems; das Risiko entsteht durch die Verkabelung. MCP standardisiert, wie ein Agent Tools und Daten erreicht, und genau deshalb skalieren die Schwächen darum herum: weite Tokens, langlebige Schlüssel und Tools mit mehr Zugriff, als die Aufgabe braucht, werden plötzlich über eine einheitliche Schnittstelle erreichbar. Mit anderen Worten schafft MCP weniger neue Arten von Schwachstellen, als dass es bestehende Autorisierungs- und Identitätsfehler leicht überall zugleich begehbar macht. Das weist auch auf die Lösung. Sie machen MCP nicht sicher, indem Sie den Standard aufgeben — Sie machen es sicher mit disziplinierter Autorisierung: eingegrenzte, kurzlebige Credentials, eine Policy-Entscheidung vor sensiblen Aktionen sowie ein Eigentümer und Audit-Trail für jede Maschinenidentität. Behandeln Sie das Protokoll als Installation und stecken Sie die Sicherheitsarbeit in die Frage, wer was darüber tun darf.

Eine Non-Human Identity (NHI) ist die digitale Identität eines maschinellen Akteurs — eines Agenten, Dienstes oder Workloads — statt einer Person. Wo ein Mensch sich mit Benutzername und Passwort anmeldet, authentifiziert sich ein Agent mit einem API-Schlüssel, einem Token oder einem Zertifikat, und dieses Credential ist seine Identität auf Ihren Systemen. Das ist wichtig, weil die meiste Identitäts-Governance für Menschen gebaut wurde, rund um den Eintritt-Wechsel-Austritt-Lebenszyklus, und Agenten in keine dieser Phasen passen, obwohl sie Datenbanken lesen oder Mails senden können. NHIs als vollwertige Identitäten zu behandeln — jede mit benanntem Eigentümer, definiertem Geltungsbereich, Rotationsplan und Audit-Trail — ist der Kern der Zugriffskontrolle für Agenten. Organisationen, die das überspringen, enden mit tausenden Credentials, die niemandem gehören und die niemand sicher widerrufen kann, und genau das ist der Schadensradius, den ein Angreifer erbt.

Beginnen Sie mit einem Inventar, denn man kann keine Identitäten steuern, die man nie erfasst hat. Erfassen Sie jeden MCP-Server, jeden Agenten und die Credentials, die jedes davon hält, und markieren Sie dann die langlebigen, weit gefassten oder niemandem zugeordneten — das ist Ihr unmittelbares Risiko. Aus dieser Liste sind die ersten konkreten Schritte, die schlimmsten statischen Schlüssel zu beseitigen oder zu rotieren, jedes verbleibende Credential auf Least Privilege einzugrenzen und eine Laufzeit-Autorisierungsprüfung vor wirklich sensible Aktionen zu setzen. Diese Reihenfolge zählt: erst Entdeckung, weil die meisten Organisationen unterschätzen, wie viele Maschinenidentitäten sie bereits haben, dann Eindämmung, weil ein eingegrenztes Credential den Schaden jeder künftigen Kompromittierung begrenzt. Ein Inventar ist unglamourös, aber es ist die Kontrolle, die alle anderen erst möglich macht, und es fördert fast immer ein paar vergessene Schlüssel zutage, die vor Monaten hätten widerrufen werden müssen.

Ein langlebiger API-Schlüssel ist ein dauerhaftes, oft weit gefasstes Credential, das nicht von selbst abläuft, und für Agenten ist genau diese Kombination die häufigste Schwäche. Das Problem ist Dauer mal Reichweite: Der Schlüssel funktioniert unbefristet, sodass eine in einem Log, durch Prompt Injection oder über eine kompromittierte Abhängigkeit geleakte Kopie lange nach dem Vorfall gültig bleibt — und meist trägt er weit mehr Zugriff, als eine einzelne Aufgabe braucht. Weil derselbe Schlüssel oft über mehrere Tools geteilt wird, kompromittiert ein einziger Leak auf einen Schlag alles, was er berührt. Die Lösung ist, statische Schlüssel durch kurzlebige, automatisch rotierte Tokens zu ersetzen, die auf eine bestimmte Identität und Aktion eingegrenzt sind, sodass selbst ein gestohlenes Credential rasch abläuft und wenig erreicht. Ergänzen Sie das um Audit-Logging pro Identität, damit ein geleaktes Token nachverfolgt und widerrufen wird statt wochenlang still genutzt. Kurz und eng schlägt lang und weit jedes Mal.