Licensed to be used in conjunction with basebox, only.
// integration
VPN / Netzwerk
Gilt für
Produkt: Cloud · Server · Zielgruppe: IT / Netzwerk · Platform Operator · Sicherheitsprüfer
Netzwerkpfade zwischen Nutzern, basebox und angebundenen Systemen – inklusive Fernwartungszugang, wenn basebox mit dem Betrieb eines Servers beauftragt ist. Diese Seite ist die Vorlage für Ihre Firewall-Regeln: Sie listet jeden Pfad, seine Richtung und seinen Port.
Die Pfade im Überblick
flowchart LR
U["Nutzer / Browser"] -->|"HTTPS 443"| BB["basebox-Plattform<br/>Frontend · AISRV · Keycloak"]
API["API-Clients"] -->|"HTTPS 443"| BB
BB -->|"OpenAI-kompatible API<br/>intern oder TLS"| INF["Inferenz-Endpunkt"]
BB -->|"443 / systemspezifisch"| SYS["Fachsysteme<br/>Wiki · Tickets · IMAP"]
BB -->|"HTTPS 443, nur Anbieter-Hosts"| WEB["Websuche-Anbieter"]
BB -->|"389 / 636"| LDAP["LDAP / AD"]
BB -->|"443"| IDP["OIDC-Anbieter"]
BB -->|"587 / 465"| MAIL["Mailserver"]
BB -.->|"443, Installation & Updates"| REG["Image-Registry<br/>gitea.basebox.health"]
OPS["basebox-Betrieb"] -.->|"PAM / VPN, nur bei Beauftragung"| BB
style BB fill:#f4f2ee,stroke:#524e47,color:#1d1e1c
style INF fill:#dbeafe,stroke:#1e40af,color:#1d1e1c| Pfad | Richtung | Protokoll / Port | Pflicht? |
|---|---|---|---|
| Nutzer → basebox | eingehend zu basebox | HTTPS 443 | Ja |
| API-Clients → basebox | eingehend zu basebox | HTTPS 443 | Wenn API genutzt |
| AISRV → Inferenz | intern oder zu separatem GPU-Host | OpenAI-kompatible API; TLS, wenn Hosts überschritten werden | Ja |
| basebox → Fachsysteme (Konnektoren) | ausgehend | systemspezifisch, meist HTTPS 443; IMAP 993 | Je Konnektor |
| basebox → Websuche-Anbieter | ausgehend | HTTPS 443 zu api.staan.ai (Standard) bzw. duckduckgo.com, html.duckduckgo.com, lite.duckduckgo.com |
Nur mit Websuche |
| Keycloak → LDAP/AD | ausgehend | TCP 389 / LDAPS 636 | Nur mit LDAP |
| Keycloak → OIDC-Anbieter; Browser → Anbieter | ausgehend / öffentlich | HTTPS 443 | Nur mit SSO |
| AISRV → Mailserver | ausgehend | TCP 587 (STARTTLS) / 465 (TLS) | Für Einladungen |
| Cluster → Registry und Paketquellen | ausgehend | HTTPS 443 | Installation und Updates; Alternative: Offline-Transfer |
| basebox-Betrieb → Server | eingehend, kontrolliert | PAM / VPN, wie vereinbart | Nur bei Betriebsbeauftragung |
Die Liste der Domains für die Installation (Ubuntu, Docker, Kubernetes, NVIDIA, Helm, Registries) steht im Server Preparation Guide.
Grundsätze
- Nutzer sprechen nie direkt mit der Inferenz. Nur AISRV erreicht den Inferenz-Endpunkt; dieser verlangt eine API-Zugangsberechtigung und ist nicht für Endnutzer freigegeben.
- Konnektoren erreichen nur ihr Zielsystem. Das MCP-Gateway erzwingt eine Egress-Allowlist je Konnektor. Ihre Firewall sollte das spiegeln: eine Regel je Konnektor, ein Ziel.
- Websuche-Anfragen verlassen die Umgebung – ohne Nutzeridentität und Nutzer-IP, über die Verbindung von basebox. Alles andere bleibt innerhalb der freigegebenen Datenverarbeitungsgrenze.
- Prompts, abgerufener Kontext und Dokumentinhalte wandern vom Anwendungsserver zum Inferenzserver. Liegen beide auf getrennten Hosts, gehören beide in dieselbe Datenverarbeitungsgrenze und der Pfad ist TLS-geschützt.
basebox Server
Im Kunden-Rechenzentrum: Sie kontrollieren alle Pfade. Nutzer greifen aus dem Firmennetz oder per VPN zu. Ausgehende Pfade beschränken Sie auf das, was die Installation nutzt; im vollständig abgeschotteten Betrieb entfallen Websuche und Online-Modelldownloads – siehe Air-Gapped-Umgebungen.
Gehostet bei basebox: Netzanbindung und physischer Zugang liegen bei basebox; Ihre Nutzer erreichen den Server per HTTPS oder VPN. Der Server bleibt dediziert – siehe Hosting bei basebox.
Getrennte Anwendungs- und Inferenzserver: Der Anwendungsserver kann rein CPU-basiert sein; nur AISRV darf den GPU-Host erreichen, mit TLS und API-Schlüssel. Anleitung und Prüfschritte: Deployment-Topologien.
TLS ohne Internet: Let's Encrypt ist nicht nötig. global.tls.mode=existing-secret mit einem Zertifikat Ihrer internen CA oder local für Evaluierung – siehe Netzwerk (Bare Metal).
Fernwartung durch basebox
Wo basebox mit Installation oder Betrieb beauftragt ist, erfolgt der Zugang über einen kontrollierten, vereinbarten Weg – typischerweise Privileged Access Management (PAM) und/oder VPN, zeitlich begrenzt und vom Kunden freigegeben. Der Wartungszugang wird ausschließlich für Supportzwecke freigegeben und danach deaktiviert. Was protokolliert wird, wer freigibt und wie der Zugang entzogen wird: Fernwartung.
Ohne Betriebsbeauftragung gibt es keinen Zugang von basebox auf Ihren Server.
basebox Cloud
Nutzer erreichen Ihre Umgebung über das Internet per HTTPS. Für Konnektoren und Mail muss die Cloud Ihre Systeme aus dem Noris-Rechenzentrum erreichen – also eingehend in Ihr Netz. Optionen dafür und die IP-/Egress-Aspekte stehen unter Netzanbindung (Cloud). Für Identität ist OIDC meist einfacher als LDAP, weil kein eingehender Pfad in Ihr Verzeichnis nötig ist.
Checkliste
- Eingehend 443 zu basebox für Nutzer (und API-Clients) geöffnet
- AISRV → Inferenz erlaubt, alles andere zum Inferenz-Host blockiert
- Je aktiviertem Konnektor genau eine ausgehende Regel zum Zielsystem
- Websuche: nur die Hosts des gewählten Anbieters, oder gar nicht
- LDAP 636 bzw. OIDC 443, je nach Identitätsmodell
- SMTP 587/465 zum Mailserver
- Registry-Zugang für Updates oder ein Offline-Transferverfahren
- Fernwartungsweg vertraglich und technisch festgelegt – oder ausdrücklich keiner
Weiter: Enterprise-Integration · Datenflüsse