Immer mehr Unternehmen betreiben Sprachmodelle nicht mehr nur über die Schnittstelle eines Anbieters, sondern auf eigener Hardware. Die Gründe sind nachvollziehbar: Daten sollen im Haus bleiben, Kosten sollen planbar sein, manche Aufgaben laufen mit einem kleineren, lokal betriebenen Modell schlicht gut genug. Also wird ein Server mit Grafikkarten angeschafft oder gemietet, ein Modell installiert, eine Schnittstelle für die internen Anwendungen eingerichtet.
Damit man weiß, ob die teure Hardware ausgelastet ist, kommt fast immer ein Monitoring dazu. Kleine Exporter-Dienste lesen Auslastung, Speicher, Temperatur und Stromverbrauch der Grafikkarten aus und stellen die Werte über einen HTTP-Endpunkt bereit, damit ein zentrales System sie abholen kann. Das ist sinnvoll und in wenigen Minuten erledigt. Genau darin liegt das Problem: Was in wenigen Minuten eingerichtet ist, wird selten danach noch einmal angesehen.
Warum ein harmloser Messwert nicht harmlos ist
Auf den ersten Blick wirken solche Endpunkte unbedenklich. Sie liefern Zahlen, keine Kundendaten. Wer sie öffentlich erreichbar lässt, verrät aber mehr, als man denkt:
- Was Sie betreiben. Die Messwerte nennen Kartentyp, Anzahl der Karten und oft auch Hostnamen. Daraus lässt sich ablesen, welche Infrastruktur ein Unternehmen hat und wofür es sie vermutlich nutzt.
- Wann Sie arbeiten. Auslastungskurven zeigen, wann Modelle laufen, wann Trainings stattfinden und wann das System ruht.
- Welche Software läuft. Exporter melden häufig ihre eigene Version und die der Treiber. Für jemanden, der nach bekannten Schwachstellen sucht, ist das eine nützliche Liste.
- Wo weitere Dienste liegen. Ein offener Monitoring-Port ist selten allein. Wo er erreichbar ist, sind es oft auch die Schnittstelle des Modells, eine Verwaltungsoberfläche oder ein Notebook-Server.
Hinzu kommt, dass auch reine Lese-Endpunkte angreifbar sein können. Ein Dienst, der auf jede Anfrage aufwendig Messwerte sammelt, lässt sich mit vielen Anfragen belasten. Und Software für das Monitoring hat gelegentlich selbst Fehler, die über das reine Auslesen hinausgehen. Ein Endpunkt, der nicht öffentlich erreichbar ist, muss vor solchen Fehlern nicht geschützt werden.
Wie diese Endpunkte im Netz landen
Kaum jemand stellt ein Monitoring absichtlich ins offene Internet. Meist ist es eine Kette kleiner Entscheidungen:
- Der Exporter hört standardmäßig auf allen Netzwerkschnittstellen, nicht nur auf der internen.
- Der Server wurde bei einem Cloud- oder GPU-Anbieter gemietet und hat eine öffentliche Adresse.
- Die Firewall-Regel wurde beim Einrichten weit gefasst, damit „erst einmal alles funktioniert“.
- Das Projekt war als Versuch gedacht und ist ohne Übergabe in den Betrieb gerutscht.
Keiner dieser Schritte ist für sich genommen ungewöhnlich. Zusammen ergeben sie einen Dienst, den jeder abfragen kann. Wir kennen dieses Muster aus unserem Research Lab: Wer das öffentliche Web in großem Umfang liest, findet dort nicht nur offen liegende Zugangsdaten in Webseiten, sondern auch Dienste, die nie für die Öffentlichkeit gedacht waren. Der Grund ist fast nie Nachlässigkeit einer einzelnen Person, sondern ein fehlender Schritt zwischen Versuch und Betrieb.
Ein Beispiel
Ein mittelständisches Industrieunternehmen möchte interne Dokumente mit einem Sprachmodell durchsuchbar machen, ohne sie an einen externen Anbieter zu geben. Ein kleines Team mietet dafür einen GPU-Server, installiert ein offenes Modell und eine Suchanwendung. Für den Überblick über die Kosten richtet ein Entwickler ein Monitoring ein: einen Exporter auf dem Server und ein Dashboard auf seinem Rechner, das die Werte über die öffentliche Adresse des Servers abholt.
Der Versuch überzeugt, das Projekt wird verlängert. Monate später fragt die IT-Abteilung, welche Systeme von außen erreichbar sind. Ein einfacher Abgleich der offenen Ports zeigt neben der erwarteten, per Anmeldung geschützten Suchanwendung zwei weitere Dienste: den Exporter und die Schnittstelle des Modells selbst, beide ohne Anmeldung. Über die Schnittstelle hätte jeder das Modell auf Kosten des Unternehmens nutzen können. Wer die Antworten genau ansah, hätte unter Umständen auch Rückschlüsse auf interne Dokumente ziehen können.
Die Behebung dauert einen Nachmittag: Beide Dienste hören nur noch auf der internen Schnittstelle, der Zugriff des Dashboards läuft über eine verschlüsselte Verbindung ins interne Netz, die Firewall erlaubt von außen nur noch die Suchanwendung. Aufwendiger ist die Frage danach: Wurde die offene Schnittstelle genutzt, und von wem? Dafür braucht es Protokolle, und die waren für diese beiden Dienste nicht eingerichtet.
Was Sie prüfen sollten
Die gute Nachricht: Die nötigen Prüfungen sind einfach und brauchen keine Spezialwerkzeuge.
| Frage | Wie Sie es prüfen | Was das Ziel ist |
|---|---|---|
| Welche Ports sind von außen offen? | Scan der eigenen öffentlichen Adressen von einem externen Netz aus | Nur Dienste, die bewusst öffentlich sein sollen |
| Worauf hört jeder Dienst? | Konfiguration der Exporter, Modellserver und Notebooks | Interne Adresse oder localhost statt aller Schnittstellen |
| Wer darf zugreifen? | Firewall- und Sicherheitsgruppen beim Hoster | Zugriff nur aus bekannten Netzen oder über VPN |
| Ist eine Anmeldung nötig? | Testweise Abfrage ohne Zugangsdaten | Keine Antwort ohne Authentifizierung |
| Wird protokolliert? | Zugriffslogs der Dienste und des Reverse Proxy | Nachvollziehbar, wer wann was abgefragt hat |
Wichtig ist, den Scan tatsächlich von außen durchzuführen. Wer aus dem eigenen Netz prüft, sieht Dienste als erreichbar, die es nur intern sind, und übersieht manchmal Regeln, die nur für externe Anfragen gelten. Ebenso wichtig: Die Prüfung gehört nicht nur an den Anfang eines Projekts, sondern in einen festen Rhythmus. Neue Versuche entstehen laufend, und jeder davon kann einen weiteren offenen Port mitbringen.
Versuche dürfen schnell sein, der Betrieb nicht
Wir arbeiten selbst AI-first und halten es für richtig, dass Teams Modelle ausprobieren, ohne dafür monatelange Freigaben abzuwarten. Wie das ohne Schattenbetrieb gelingt, beschreibt der Beitrag Fachabteilung baut mit KI. Der entscheidende Punkt ist der Übergang: Sobald ein Versuch mit echten Daten arbeitet oder länger als ein paar Wochen läuft, braucht er eine kurze Abnahme. Dazu gehören eine Liste der laufenden Dienste, ihre Erreichbarkeit, eine verantwortliche Person und ein Datum, an dem das System entweder in den regulären Betrieb übergeht oder abgeschaltet wird.
Diese Abnahme muss kein schweres Verfahren sein. Eine Seite mit fünf Fragen reicht oft. Sie verhindert, dass aus einem Experiment unbemerkt Infrastruktur wird, für die sich niemand zuständig fühlt. Wie wir Unternehmen bei solchen Fragen begleiten, vom ersten Versuch bis zum geordneten Betrieb, beschreibt unsere Seite zur KI-Beratung.
Und falls jemand von außen auf einen offenen Dienst bei Ihnen hinweist: Nehmen Sie die Meldung ernst. Wie ein brauchbarer Ablauf dafür aussieht, steht im Beitrag Gemeldete Sicherheitslücke.
Fazit
Eigene KI-Server sind für viele Unternehmen eine vernünftige Entscheidung. Sie bringen aber Infrastruktur ins Haus, die früher beim Anbieter lag, und mit ihr die Pflicht, sie sauber abzuschotten. Monitoring-Endpunkte und Modellschnittstellen gehören nicht ins offene Internet, auch wenn sie nur Messwerte liefern. Ein Scan von außen, eine bewusste Bindung an interne Adressen, eine eng gefasste Firewall und eine kurze Abnahme beim Übergang vom Versuch in den Betrieb reichen in den meisten Fällen aus. Der Aufwand dafür ist gering, verglichen mit der Frage, wer die offene Schnittstelle in den letzten Monaten genutzt hat.