Lokale KI für Mitarbeitende und Standorte sicher erreichbar machen? WZ-IT verbindet den AI Cube über vorhandenes VPN, NetBird oder einen kontrollierten Gateway-Aufbau, ohne Modellserver und Administration direkt zu veröffentlichen. AI Cube und Vernetzung einordnen
Lokale KI soll im eigenen Netz rechnen, aber nicht nur am Schreibtisch neben dem Gerät nutzbar sein. Mitarbeitende im Homeoffice, weitere Standorte und mobile Administratoren benötigen einen kontrollierten Zugriff. Dafür muss nicht der Modellserver ins öffentliche Internet gestellt werden.
Dienste konsequent trennen
Eine lokale KI-Plattform besteht aus mehreren Endpunkten:
- Benutzeroberfläche wie Open WebUI;
- Modell-API oder Inferenzserver;
- Datenbank und Wissensspeicher;
- Administrationszugang;
- Monitoring, Backup und Updatewege.
Nur die Benutzeroberfläche oder eine bewusst freigegebene API gehört in den Nutzerpfad. Modellserver, Datenbank und Administration bleiben in getrennten Netzen oder Richtliniengruppen.
Welcher Zugriffsweg passt?
| Anforderung | Passender Ausgangspunkt |
|---|---|
| verwaltete Geräte sollen mehrere interne Dienste erreichen | vorhandenes Unternehmens-VPN mit begrenzten Netzregeln |
| Nutzer, Geräte und Standorte sollen identitätsbasiert bis auf Dienst und Port getrennt werden | NetBird mit Gruppen, Ressourcen und Policies |
| ein Webdienst soll ohne VPN-Client erreichbar sein | gehärteter Reverse Proxy mit SSO oder MFA |
| eine Anwendung soll automatisiert auf das Modell zugreifen | definierter API-Gateway-Pfad statt direkter Modellfreigabe |
Die Varianten können kombiniert werden. Nutzerzugriff, Administration und Integrationen sollten trotzdem getrennte Regeln und Endpunkte erhalten.
Variante 1: vorhandenes Unternehmens-VPN
Ein bestehendes VPN kann die Plattform in das interne Netz einbinden. Das ist sinnvoll, wenn Identitäten, Geräteverwaltung, MFA und Netzwerkregeln bereits sauber betrieben werden. Prüfen Sie, ob das VPN nur Netzreichweite oder auch anwendungsbezogene Regeln bietet. Ein breiter Zugriff auf das gesamte Subnetz ist für einen einzelnen KI-Dienst meist unnötig.
Variante 2: NetBird mit Identität und Policies
NetBird baut ein WireGuard-basiertes Overlay zwischen berechtigten Peers auf. Networks und Ressourcen erlauben, einen internen Dienst über Routing Peers erreichbar zu machen, ohne auf jedem Zielsystem einen Client zu installieren. Zugriffsregeln werden anhand von Gruppen, Quellen und Zielen gepflegt.
Für den AI Cube kann eine Policy beispielsweise nur der Gruppe „KI-Nutzer“ Zugriff auf die Weboberfläche geben, während „KI-Administratoren“ einen getrennten Managementpfad erhalten. Mitarbeitende erreichen damit den Dienst aus Homeoffice oder Außenstellen, ohne das gesamte Standortnetz freizugeben.
Variante 3: kontrollierter Reverse Proxy
Soll die Oberfläche ohne VPN-Client erreichbar sein, kann ein Reverse Proxy TLS, Hostnamen, Authentifizierung, Limits und Protokollierung übernehmen. Der Proxy ist die einzige öffentlich erreichbare Komponente und leitet nur zum vorgesehenen Dienst weiter. Datenbank, Modellport und SSH bleiben geschlossen.
Ein öffentlicher Zugang benötigt zusätzliche Schutzmaßnahmen: MFA oder SSO, Rate Limits, Session-Regeln, Patchprozess, Monitoring und einen Incident-Weg. Er ist keine rein technische Komfortoption.
Hybride Modellwahl bewusst behandeln
Open WebUI kann neben lokalen Modellen auch externe Anbieter anbinden. Das kann für freigegebene Aufgaben sinnvoll sein, verändert aber den Datenweg. Modellzugriff sollte nach Gruppe begrenzt und in der Oberfläche eindeutig benannt werden. Sensible Wissensbereiche dürfen nicht versehentlich an einen externen Endpunkt gesendet werden.
Einbindung des AI Cube
Der AI Cube wird im Kundennetz mit lokaler Oberfläche und Modell eingerichtet. Remote-Zugriff ist kein pauschaler offener Port. WZ-IT prüft Nutzer, Geräte, Standorte, Identitätsanbieter und vorhandene Netze und setzt danach VPN, NetBird oder Gateway als separaten Integrationsumfang um.
Für den laufenden Betrieb werden Update- und Supportzugänge ebenfalls getrennt geplant. Temporäre Freigaben, benannte Administratoren und nachvollziehbare Protokolle sind besser als ein dauerhaftes gemeinsames Wartungskonto.
Checkliste
- nur Oberfläche oder definierte API freigeben;
- Modellserver, Datenbank und SSH nicht öffentlich bereitstellen;
- SSO und MFA für externe Nutzer verwenden;
- Nutzer- und Administratorzugang trennen;
- Geräte- oder Peer-Vertrauen festlegen;
- Policies bis auf Dienst und Port begrenzen;
- externe Modelle sichtbar kennzeichnen und gruppenweise freigeben;
- Zugriffs-, Update- und Incident-Prozesse dokumentieren.
