KI Server on Premise

Zielsetzung

Diese Architektur stellt eine auditfähige, segmentierte und Zero‑Trust‑konforme Plattform für KI‑gestützte Datenverarbeitung bereit. Sie ermöglicht sichere Benutzerinteraktion, kontrollierte Datenaufnahme und modellgestützte Analyse — unter vollständiger Einhaltung von Sicherheits- und Compliance‑Standards.

Architekturüberblick

Die Plattform besteht aus fünf logisch und technisch getrennten Sicherheitszonen:

Jede Zone ist durch harte Trust Boundaries voneinander getrennt. Kommunikation erfolgt ausschließlich über explizit definierte, protokollgebundene Schnittstellen.

---

Zone	Zweck	Hauptkomponenten
External Zone	Zugriff durch Endnutzer	Users / Clients
DMZ / Enforcement Point	Policy Enforcement, TLS‑Termination, AuthN/AuthZ	Reverse Proxy
AI Processing Zone	Verarbeitung von Benutzeranfragen, Modellinferenz	OpenWebUI, Ollama Engine, Model Storage
Ingestion Zone	Datenaufnahme aus Unternehmenssystemen	Ingestion Jobs (ETL/Batch)
Data Zone	Persistente Speicherung, analytische Datenhaltung	Data Lake / DB
Enterprise Systems	Externe Datenquellen	Jira, ERP

---

Zero‑Trust‑Prinzipien (konkret umgesetzt)

Explizite Authentifizierung & Autorisierung

• Alle externen Zugriffe erfolgen über den Reverse Proxy (Policy Enforcement Point).
• Der Reverse Proxy erzwingt:
  • TLS 1.2+
  • Identitätsprüfung (z. B. OIDC, SSO)
  • Rollenbasierte Autorisierung
  • Rate‑Limiting
  • Request‑Sanitization
  • Logging & Audit‑Trails

Least Privilege

• OpenWebUI erhält nur die minimalen Rechte, um Queries an Ollama und den Data Lake zu stellen.
• Ollama hat keinen direkten Zugriff auf externe Systeme.
• Ingestion Jobs haben keinen Rückkanal zur AI Processing Zone.
• Data Lake akzeptiert nur:
  • ETL‑Daten aus der Ingestion Zone
  • Query‑Requests aus OpenWebUI

Micro‑Segmentation

• Jede Zone ist ein eigenes Netzwerksegment.
• Firewall‑Regeln sind strikt unidirektional:
  • Users → Reverse Proxy
  • Reverse Proxy → OpenWebUI
  • OpenWebUI → Ollama
  • Ollama → Model Storage
  • Ingestion → Data Lake
  • OpenWebUI → Data Lake

No Implicit Trust

• Kein interner Traffic wird als „trusted“ behandelt.
• Jeder Request wird geprüft, geloggt und durch Policies validiert.

Observability & Auditability

• Reverse Proxy, OpenWebUI, Ollama und Ingestion Jobs erzeugen:
  • strukturierte Logs
  • korrelierbare Request‑IDs
  • Audit‑Events
• Data Lake speichert ETL‑Metadaten für Revisionszwecke.

---

Datenflüsse (auditrelevant)

Benutzeranfragen

1. User → HTTPS → Reverse Proxy
2. Reverse Proxy → Policy‑gefiltert → OpenWebUI
3. OpenWebUI → Authenticated API → Ollama
4. Ollama → Model Storage (Read‑Only)

Datenabfragen

• OpenWebUI → Least‑Privilege Queries → Data Lake

Datenaufnahme

1. Jira → Scoped REST → Ingestion
2. ERP → Scoped REST/DB → Ingestion
3. Ingestion → Controlled ETL → Data Lake

---

Sicherheitsmaßnahmen (prüfbar)

Netzwerk

• Segmentierung per VLAN / Docker Network
• Default‑Deny‑Policies
• Nur explizit erlaubte Ports/Protokolle

Identität & Zugriff

• Zentralisierte Authentifizierung
• Rollenbasierte Autorisierung
• Keine anonymen Zugriffe

Daten

• Verschlüsselung in Transit (TLS)
• Verschlüsselung at Rest (Data Lake, Model Storage)
• Versionierte ETL‑Pipelines

Monitoring

• Request‑Tracing
• Security‑Logs
• Alerting bei Policy‑Verstößen

---

Ergebnis: Audit‑Reife

Die Architektur erfüllt die Kernanforderungen von:

• Zero Trust Architecture (NIST SP 800‑207)
• Least Privilege Access
• Segmentation & Isolation
• Audit Logging & Traceability
• Secure Data Processing Pipelines

Damit ist diese Implementierung eines KI Servers auditfähig, revisionssicher und zukunftsfähig.