MCP Gateway Architektur: Komponenten und Vertrauensgrenzen

9 Minuten Lesezeit · MCP und Security Expert Review vor Veröffentlichung erforderlich

Ein MCP-Gateway ist ein erzwungener Vermittler zwischen MCP-Clients und einem oder mehreren MCP-Servern. Es zentralisiert Server-Erkennung, Authentifizierung, Token-Handling, Richtlinien, Tool-Filterung, Rate-Limits und Beweise. Es wird nicht zu einer Sicherheitsgrenze, nur weil der Datenverkehr es passieren kann. Direkte Routen, weitergeleitete Anmeldeinformationen und permissive Tool-Richtlinien können immer noch die beabsichtigte Kontrolle umgehen.

Die vollständige Kategoriedefinition ist in der MCP Gateway GuideDieser Artikel gibt Plattformteams eine Referenzbereitstellung und die Vertrauensfragen hinter jeder Komponente.

Referenzdatenfluss

[MCP client]
   | request + caller credential
   v
[edge authentication]
   | verified caller context
   v
[gateway router] <---- [approved server registry]
   |              <---- [policy bundle / grants]
   v
[tool schema validation + action authorization]
   | exact allowed request
   v
[credential broker] ---> [protected MCP server] ---> [domain API]
   |                            |
   +------ decision/event ------+
                 v
          [evidence pipeline]

Das Register gibt an, welche Server und Tools zugelassen sind. Es sollte nicht entscheiden, ob ein Principal einen bestimmten Toolaufruf ausführen darf. Der Credential Broker hält Upstream-Geheimnisse außerhalb des Modellkontexts und tauscht oder erhält einen eng begrenzten Credential für den vorgesehenen Server. Die Durchsetzungsstelle validiert die genauen Tool-Argumente vor der Ausführung.

Respektieren Sie die Protokollgrenze

Die aktuelle MCP-Berechtigungsspezifikation Definiert die Autorisierung für HTTP-Transporte. Geschützte Server veröffentlichen OAuth protected-resource Metadaten, Clients enthalten die beabsichtigten resource Die Autorisierung ist optional für MCP-Implementierungen, so dass ein Gateway Transport- und Authentifizierungsverhalten inventarisieren muss, anstatt einheitliche Unterstützung zu übernehmen.

{
  "resource": "https://mcp.example.com/finance",
  "authorization_servers": ["https://id.example.com"],
  "scopes_supported": ["invoices:read", "payments:submit"]
}

RFC 9728 definiert Metadaten zu geschützten Ressourcen. RFC 8707 Das Gateway sollte diese Semantik bewahren, wenn es mehreren Servern gegenübersteht; ein breites Gateway-Publikum darf nicht stillschweigend jedes Upstream-Token austauschbar machen.

Separate Gateway-Entscheidungen

Die Filterung von Werkzeuglisten verbessert die Benutzerfreundlichkeit und reduziert zufällige Anrufe. Sie darf die serverseitige Autorisierung nicht ersetzen, weil ein Client tools/call direkt.

Testen Sie den erzwungenen Weg

Führen Sie diese Akzeptanztests vor dem Rollout durch:

1. Senden Sie ein für Server A ausgegebenes Token an Server B. Sowohl Gateway als auch Server B lehnen es ab.
2. Addition x-user-id und x-tenant-id Das Gateway streift und regeneriert sie.
3. Rufen Sie ein blockiertes Tool auf, ohne zuerst Tools aufzulisten.
4. Ändern Sie ein genehmigtes Argument nach der Richtliniebewertung.
5. Erreichen Sie den MCP-Server über eine interne Adresse. Die Dienstidentität oder Netzwerkrichtlinie lehnt sie ab.
6. Das dokumentierte Risikoklassenverhalten tritt auf.

Die MCP-Sicherheitstestleitfaden böswillige Armaturen liefert. Registervergleich Trennt die Entdeckung von der Durchsetzung. Übersicht über die Plattform für anforderungsgebundene Autorisierungs- und Beweismuster.

OATI und die Gateway-Referenzpfade befinden sich in der Entwicklervorschau. Sie zeigen Schemata und Durchsetzungskonzepte, beanspruchen jedoch keine abgeschlossenen Kundenproduktionsvorgänge oder eine unabhängige Sicherheitsbewertung.

Architekturfragen zu lösen

Ist das Gateway der MCP-Host?

Nicht unbedingt. Der Host ist die Anwendung, die Clients, Berechtigungen und Benutzerinteraktion koordiniert. Ein Gateway kann zwischen Host-verwalteten Clients und Servern als gemeinsamer Durchsetzungspunkt angesiedelt sein. Diese Rollen müssen explizit sein, da der Host möglicherweise den Benutzerkontext enthält, während das Gateway über Unternehmensrichtlinien und vorgelagerte Anmeldeinformationen verfügt. Testen Sie, ob ein kompromittierter Host die Gateway-Richtlinie nicht umgehen kann, indem Sie eine direkte Serverroute öffnen.

Sollte das Gateway MCP-Sitzungen beenden?

Termination gibt dem Gateway-Protokoll Sichtbarkeit und Kontrolle über Toollisten, Anrufe und Fehler. Ein transparenter Proxy kann das Serververhalten bewahren, aber keine argumentbewusste Richtlinie durchsetzen, ohne Nachrichten zu analysieren. Wählen Sie bewusst Sitzungsbesitz, Abbruch, Wiederaufnahme und Rückdruck. Für Streaming-Transporte, Testtrennungen und Teilnachrichten, damit ein Wiederholungsversuch keinen abgeschlossenen Nebeneffekt wiederholt.

Wo sollten Werkzeugschemata validiert werden?

Validieren am Gateway und geschützten Server. Das Gateway verwendet sein genehmigtes Schema, um unerwünschte Anrufe vor der Nutzung von Anmeldeinformationen abzulehnen. Der Server validiert erneut, weil möglicherweise eine andere Routen- oder Versionsabweichung vorliegt. Vergleichen Sie Schemaverdauungen und Quarantänematerialdrift. Vertrauen Sie einem Modellclient nicht, dass er die Validierung durchgeführt hat, nur weil er Argumente aus der angekündigten Beschreibung generiert hat.

Wie sollten mehrere Autorisierungsserver gehandhabt werden?

Eine Mandanten- und Server-Vertrauensrichtlinie anwenden, anstatt einen beliebigen in Metadaten genannten Emittenten auszuwählen. Zugelassene Emittenten-Server-Beziehungen, Client-Registrierung, Scope-Mapping und Fehlerverhalten definieren. Cache-Entdeckung unter begrenzten Regeln und die verwendete Metadaten-Version beibehalten. Ein Server, der plötzlich einen anderen Emittenten bewirbt, sollte eine Überprüfung auslösen, keine automatische Vertrauenserweiterung.

Hat das Gateway eine eigene Geschäftspolitik?

Für eine Rückerstattung kann ein Domain-Policy-Service Bestellstatus- und Händlerlimits auflösen und dann eine anforderungsgebundene Entscheidung zurückgeben. Das Gateway vergleicht den Digest und die Verpflichtungen vor dem Versand. Diese Abteilung hält Routing und Anmeldeinformationen zentralisiert, während Lieferanten-, Zahlungs- oder Produktionsregeln rechenschaftspflichtigen Domain-Teams überlassen bleiben.

Was sollte Scale Testing beinhalten?

Messen Sie Autorisierungslatenz, Sitzungszahl, Nachrichtengröße, Streaming-Verhalten, Registrierungsaktualisierung, Richtlinienverteilung und Beweisrückdruck. Fügen Sie einen Ausbruch abgelehnter Anfragen und eine Verlangsamung des Replay-Stores hinzu, nicht nur erfolgreiche Lesevorgänge. Überprüfen Sie die Mandantenisolation unter Cachedruck und bestätigen Sie horizontale Replikate, die atomare Wiederholung und Idempotenz teilen, wenn die Aktion dies erfordert.

Dokumentieren Sie den Pfad für jeden Transport. HTTP-Server können den in der Spezifikation beschriebenen Autorisierungs- und Metadatenfluss verwenden. Ein lokaler STDIO-Server läuft innerhalb einer anderen Vertrauensgrenze und kann Anmeldeinformationen aus der Umgebung erhalten. Das Senden beider durch ein Diagramm ohne Nennung des Unterschieds verbirgt eine wichtige Kontrolllücke. Wenn das Enterprise-Gateway keinen lokalen Transport vermitteln kann, beschränken Sie, was dieser Prozess erreichen kann, und notieren Sie die Ausnahme im Serverinventar.