Dieser Schritt braucht Zutun der IT: eine Adresse, ein Zertifikat und eine Freigabe nach außen. Ohne diese Vorarbeit kommt keine Verbindung zustande, und die Fehlermeldungen der Assistenten sind dabei wenig hilfreich.
Erforderlich sind: 1. Eine **Adresse**, etwa `mcp.kunde.de`, die auf Ihren Server zeigt. 2. Ein **Zertifikat** für diese Adresse. 3. Die Adresse muss aus dem Internet erreichbar sein, damit der Assistent sie erreicht. Für Punkt 2 und 3 gibt es zwei Wege: | Weg | Wann | Was zu tun ist | | --- | --- | --- | | **FINN.ghost verschlüsselt selbst** | in der Regel | Zertifikat in den Einstellungen von FINN.ghost beziehen (Let's Encrypt) und den Port des Zugangs nach außen freigeben. Die Adresse lautet dann `https://mcp.kunde.de:3000/mcp` — mit dem Port aus den Einstellungen. | | **Webserver davor** | wenn schon einer steht, oder eine Adresse ohne Port gewünscht ist | Der Webserver beendet die Verschlüsselung und leitet `/mcp` und `/download/` an den Port des Zugangs weiter. Die Adresse lautet dann `https://mcp.kunde.de/mcp`. |Der Zugang benutzt dasselbe Zertifikat wie die Oberfläche von FINN.ghost (data/ssl). Ein Zertifikat gilt für den Servernamen und nicht für einen einzelnen Port — es ist also nichts doppelt zu beschaffen und nichts doppelt zu erneuern. Nach außen gegeben wird trotzdem nur der Port des Zugangs, nicht der der Anwendung.
Liegt kein Zertifikat vor, spricht der Zugang unverschlüsseltes HTTP — und weist eine unverschlüsselte Verbindung nicht von sich aus ab. Dann läuft der Schlüssel im Klartext über die Leitung, und mit ihm die Mandantendaten. Die Einstellungsseite von FINN.MCP weist darauf hin, und im Protokoll steht beim Start eine Warnung.
Beim Weg über einen Webserver sollten nur /mcp und /download/ weitergeleitet werden, nicht die ganze Domain. Über /download/ laufen die Links auf Beleg-PDFs — fehlt die Weiterleitung, steht die Verbindung, aber jeder Download-Link führt ins Leere. Der Zugang beantwortet daneben ein /health für die Überwachung — und zwar ohne Schlüssel. Wer die ganze Domain durchleitet, verrät damit nach außen, dass hier ein KI-Zugang läuft. Wird die Überwachung von außen gebraucht, ist /health gezielt zusätzlich freizugeben.
Der Connector-Dialog in Claude hat ein Feld für eigene Kopfzeilen — deshalb genügt hier derselbe Schlüssel wie im eigenen Netz.
Wurde ein Connector früher über eine eigene Anmeldeseite eingerichtet, verbindet er sich nach einem Update nicht mehr. Er ist einmal neu einzurichten: dieselbe Adresse, den Schlüssel diesmal als Kopfzeile.
## Nur für den Proxy erreichbar machen Diese Möglichkeit gilt nur für den Weg über einen Webserver: Läuft er auf demselben Rechner wie FINN.ghost, muss der Port des Zugangs im Firmennetz gar nicht offen sein. Der Zugang lauscht standardmäßig auf allen Netzwerkschnittstellen; über die Einstellung `mcp.host` in der Konfiguration lässt sich das auf `127.0.0.1` begrenzen.Vorbelegt ist 0.0.0.0, also alle Schnittstellen. Die Änderung ist eine Sache für den Support oder die IT, kein Feld in der Oberfläche — und sie schließt den Zugang im eigenen Netz aus. Wer FINN.ghost selbst verschlüsseln lässt, darf sie nicht setzen: Dann kommt auch der Assistent aus dem Internet nicht mehr an.
Jede Anfrage des Assistenten steht für sich, eine Sitzung, die ablaufen oder verloren gehen könnte, gibt es nicht. Ein Neustart von FINN.ghost — etwa nach einem Update — trifft deshalb höchstens eine Anfrage, die genau in diesem Moment läuft.
## Schutz gegen Ausprobieren Vor dem Zugang steht ein einzelnes Geheimnis. Wird es falsch mitgesendet, antwortet der Zugang mit *nicht autorisiert* und schreibt eine Warnung samt Adresse des Aufrufers ins Protokoll.Diese Adresse stimmt nur, wenn die Anzahl der Proxy-Schritte richtig eingestellt ist. Vorbelegt ist ein Schritt (mcp.trustProxy) — also genau ein vorgeschalteter Webserver. Stehen mehrere hintereinander, etwa noch ein Lastverteiler, protokolliert der Zugang sonst dessen Adresse statt der des Aufrufers.
Gebremst werden Fehlversuche dabei nicht — das kann die Anwendung selbst nicht. Ist der Zugang öffentlich erreichbar und soll das Durchprobieren begrenzt werden, braucht es dafür einen vorgeschalteten Webserver.
Der Schlüssel selbst ist ein zufällig erzeugter Wert und nicht zu erraten. Gefährlich wird es erst, wenn er weitergegeben wurde. ## Nachvollziehbar, wer verbunden ist Am Zugang hängt der **Name des Programms**, das sich verbunden hat, etwa `claude-ai`. Er steht in jeder Protokollzeile des Aufrufs. In gemischtem Betrieb ist damit erkennbar, welche Verbindung eine Abfrage ausgelöst hat — nicht aber, welche Person. ## Zugang wieder entziehen Drei Möglichkeiten, je nach Anlass: | Anlass | Vorgehen | | ---------------------------------- | -------------------------------------- | | eine Verbindung soll enden | im Assistenten die Verbindung trennen | | **von außen** soll nichts mehr erreichbar sein | die Freigabe des Ports zurücknehmen, oder die Weiterleitung im Webserver abschalten | | der Schlüssel ist in falsche Hände geraten | Support ansprechen; ein neuer Schlüssel entwertet alle bestehenden Verbindungen |Ein neuer Schlüssel trifft alle Verbindungen, auch die im eigenen Netz. Danach ist er überall neu einzutragen.
Siehe [Sicherheit und Verantwortung](https://wiki.dako-it.com/books/finnai-mcp-fur-selectline/page/sicherheit-und-verantwortung). ## Weiter [Voraussetzungen für Copilot Studio](https://wiki.dako-it.com/books/finnai-mcp-fur-selectline/page/voraussetzungen-fur-copilot-studio)