MCP-Portal: ein Endpunkt ist keine Sicherheitsgrenze

Ein verwaltetes Portal kann den Zugang von Clients zu genehmigten MCP-Servern vereinfachen. Allein dadurch ist jedoch weder jeder Upstream-Weg geschützt noch jede Anfrage geprüft oder jede Identitätsrichtlinie durchgesetzt.

Cloudflare meldete am 24. September 2026 die allgemeine Verfügbarkeit seiner MCP-Serverportale. Ein Portal bietet einen Endpunkt zu genehmigten Model Context Protocol-Servern. Cloudflare Access kann Aktivitäten zu Tools, Prompts und Ressourcen protokollieren. Der Release umfasst außerdem Optionen wie Gateway-Routing, Service-Token-Authentifizierung, Code-Mode-Richtlinien, Sitzungsverwaltung und Logpush. Die Ankündigung von Cloudflare beschreibt den Umfang.

Die Architekturfrage ist nicht nur, ob ein Portal existiert. Entscheidend ist, welche Anfragen darüber laufen, welche Identität beim Upstream verwendet wird und was außerhalb des Portals erreichbar bleibt.

Drei Kontrollebenen unterscheiden

• Portalzugriff: Wer sich am Portal anmelden und verbundene Server sehen darf.
• Autorisierung am Upstream: Ob der MCP-Server selbst die für eine Anfrage nötige Identität und Richtlinie erzwingt.
• Datenverkehr prüfen und protokollieren: Ob Anfragen durch Gateway laufen und welche Einträge exportiert oder gespeichert werden.

Diese Grenzen lassen sich gemeinsam konfigurieren, sind aber nicht austauschbar. Eine erfolgreiche Portal-Anmeldung beweist nicht, dass der Upstream eine direkte Verbindung ablehnt. Ein Access-Log ist nicht automatisch ein Gateway-HTTP-Log. Eine DLP-Richtlinie schützt nur Datenverkehr, der tatsächlich durch den eingerichteten Prüfpfad läuft.

Zuerst den direkten URL-Zugriff testen

Cloudflares Dokumentation stellt klar: Eine Access-Richtlinie kann einen MCP-Server im Portal verbergen, während Benutzer ihn weiterhin über seine direkte URL erreichen können. Soll Access auch die Anmeldung am Upstream erzwingen, weist Cloudflare Administratoren an, Access als OAuth-Anbieter des Servers einzurichten. Die Anleitung beschreibt diese Einschränkung.

Inventarisiere daher alle Upstream-Endpunkte und prüfe deren eigene Authentifizierung. Teste Portalweg und direkte Upstream-URL jeweils mit einer nicht privilegierten Identität. Ist der direkte Weg öffentlich oder zu breit zugänglich, schließen reine Portal-Sichtbarkeitsregeln diese Lücke nicht.

Identitäten vor dem Verbinden zuordnen

Kläre, ob Anfragen mit der Upstream-Identität jedes Benutzers oder mit einem Administratorkonto laufen sollen. Individuelle Autorisierung kann benutzerspezifische Rechte unterstützen, sofern Anbieter und Konfiguration es ermöglichen. Ein Service-Token ist anders: Laut Cloudflare verwenden solche Sitzungen für Upstream-Anfragen das Administratorkonto des Servers; benutzerbezogenes OAuth wird für diese Server nicht unterstützt.

Dadurch ändert sich das Audit- und Berechtigungsmodell. Nutzt der Upstream eine gemeinsame Admin-Identität, sieht er möglicherweise nicht, welcher Mensch eine Aktion ausgelöst hat. Halte Benutzeridentität, Dienstidentität, delegierte Rechte und Auditnachweise auseinander. Teile kein leistungsstarkes Administratorkonto nur, damit eine Verbindung funktioniert.

Grenzen der Richtlinien verstehen

Cloudflare dokumentiert, dass unabhängige MFA, Zweckbegründung und temporäre Authentifizierung bei Portal-autorisierter Nutzung von MCP-Servern nicht durchgesetzt werden. Andere Merkmale wie E-Mail, Gruppe, Land und Gerätestatus können weiterhin greifen. Wenn ein Upstream auf den ausgeschlossenen Kontrollen beruht, braucht es ein zusätzliches oder anderes Durchsetzungsdesign.

Auch der Betrieb zählt: Laut Dokumentation können OAuth-Tokens eines Upstream-Administrators unbemerkt ablaufen. Der Server bleibt dann in einem Fehler- oder Synchronisierungszustand, bis die Authentifizierung erneuert wird. Ergänze Zustandskontrolle und Token-Erneuerung im Supportablauf.

Verstehen, was Gateway sieht

Bei aktiviertem Gateway-Routing können Echtzeit-Toolaufrufe von Benutzern in Gateway-HTTP-Logs erscheinen und von passenden DLP-Richtlinien geprüft werden. Cloudflare sagt, dass Hintergrundsynchronisierung von Tools und Prompts nicht über Gateway geleitet wird. Beschreibe Gateway-Routing daher nicht als Prüfung jeder Portalaktivität.

Laut Dokumentation ist Logpush-Export für MCP-Portal-Logs nur in Enterprise-Tarifen verfügbar. Prüfe Tarif und Aufbewahrungsbedarf. Lege getrennt fest, was Access protokolliert, was Gateway erfasst, wo jeder Datensatz gespeichert wird und wer ihn prüfen darf.

Checkliste vor dem Rollout

Dokumentiere und teste vor dem Verbinden eines MCP-Clients mit einem Produktionsportal:

1. Alle Portal- und Upstream-URLs einschließlich direkter Wege am Portal vorbei.
2. Authentifizierungsanbieter, Benutzer- oder Dienstidentität, Credential-Verantwortliche und Umfang je Upstream.
3. Ob direkter Zugriff gesperrt oder unabhängig authentifiziert wird.
4. Welche Access-Funktionen erforderlich sind und ob sie für Portal-Server gelten.
5. Ob Gateway aktiv ist, welchen Live-Verkehr es prüft und welche DLP-Regel den Upstream erfasst.
6. Welche Aktivitäten in Access- und Gateway-Logs erscheinen, wie lange sie gespeichert und ob sie exportiert werden.
7. Wie abgelaufene Zugangsdaten, Synchronisierungsfehler, verweigerte Tool-Aufrufe und Richtlinienänderungen erkannt und behoben werden.
8. Erlaubte und verweigerte Identitäten auf Portal- und Direktwegen mit minimalen Berechtigungen.

Halte für jeden Weg Soll- und Ist-Ergebnis fest. Dies ist eine Architekturprüfliste, kein Bericht über eine Cloudflare-Konfiguration oder einen Sicherheitstest für diesen Artikel.

Häufige Fehler

• Annehmen, dass Portal-Sichtbarkeit eine direkte URL sperrt. Upstream unabhängig testen und schützen.
• Access- und Gateway-Logs als einen Datensatz behandeln. Dokumentiere, was jedes Produkt für welche Wege protokolliert.
• Von allen Access-Funktionen ausgehen. Prüfe dokumentierte Ausschlüsse für Portal-Server.
• Das Diagramm als Testergebnis bezeichnen. Es beschreibt dokumentierte Abläufe; für diesen Artikel wurde kein Konto konfiguriert.

Portal als nützliche Schicht, nicht als Sicherheitsurteil

Ein MCP-Portal kann einen klareren Einstieg und bessere Übersicht über Remote-Server bieten. Der Nutzen hängt von Upstream-Kontrollen und Betriebsabläufen ab. Schütze Ursprungsendpunkte, wähle ein explizites Identitätsmodell, kenne nicht unterstützte Kontrollen und verifiziere, welcher Verkehr tatsächlich geprüft oder protokolliert wird.

Weiterführende Artikel

• Eine lokale KI-Coding-Sandbox braucht klare Sitzungsgrenzen behandelt eine getrennte, sitzungsbezogene Zugriffskontrolle.
• Cloudflare-Dokumentation zu MCP-Portalen und Ankündigung der allgemeinen Verfügbarkeit.
• Bildnachweis: Originales Request-Flow-SVG von Cloudflare, unverändert unter CC BY-SA 4.0 gemäß Cloudflare Docs.

Redaktioneller Hinweis: Dieser Artikel basiert auf öffentlichen Cloudflare-Releases und Konfigurationsdokumenten. Für diesen Artikel wurde kein Cloudflare-Konto eingerichtet oder getestet. Das Titelbild ist die offizielle Ablaufgrafik aus Cloudflare Docs, ohne Beschnitt oder Überlagerung in PNG konvertiert und unter CC BY-SA 4.0 wiederverwendet.