Zum Inhalt springen
>_<
AI EngineeringWiki

Security

Self-Hosted Sicherheit: Das 6-Layer Modell

Wenn du AI-Services selbst hostest, bist du für die Sicherheit verantwortlich. Kein Cloud-Anbieter fängt Fehler für dich ab. Hier sind die 6 Schichten, die deine Infrastruktur schützen.

Lesezeit: 15 minZuletzt aktualisiert: März 2026
📋 Auf einen Blick

Self-Hosting bedeutet volle Kontrolle — aber auch volle Verantwortung. Sicherheit ist kein einzelnes Feature sondern ein Schichtenmodell: 6 Layer von der physischen Infrastruktur bis zum Monitoring. Jede Schicht hält etwas anderes auf. Keine alleine reicht.

Die 6 Sicherheitsschichten

Jede Schicht adressiert eine andere Angriffsfläche. Wenn Layer 1 versagt, muss Layer 2 greifen. Das ist Defense in Depth.

6-Layer Security Modell

Sicherheit in Schichten: Jede Ebene schützt gegen andere Angriffsvektoren.

LayerSchützt gegenWerkzeuge
1. NetzwerkUnbefugter Zugriff von außenFirewall (UFW/iptables), VLAN, VPN
2. SSH & AuthentifizierungBrute Force, schwache PasswörterSSH Key-Only, fail2ban, 2FA
3. Host-BetriebssystemVeraltete Software, Kernel-ExploitsUnattended Upgrades, CIS Benchmark
4. Container & ServicesPrivilege Escalation, ungesicherte APIsRootless Container, Read-Only FS, Secrets
5. AnwendungPrompt Injection, Data LeakageInput Validation, Output Sanitizer, Rate Limits
6. Monitoring & ResponseUnbemerkte EinbrücheLoki, Grafana Alerts, Audit Logs

Layer 1: Netzwerk-Segmentierung

Dein lokaler AI-Stack sollte NICHT direkt aus dem Internet erreichbar sein. Die wichtigste Regel: Default Deny — alles ist gesperrt, du öffnest gezielt was nötig ist.

UFW Grundkonfiguration

# Alles sperren (Default Deny)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH erlauben (nur aus lokalem Netz)
sudo ufw allow from 10.40.10.0/24 to any port 22

# Reverse Proxy (HTTPS)
sudo ufw allow 443/tcp

# Firewall aktivieren
sudo ufw enable
sudo ufw status verbose
⚠️ Ports NICHT öffentlich freigeben

Services wie Ollama (11434), n8n (5678), Grafana (3000), PostgreSQL (5432) gehören NICHT ins Internet. Wenn du externen Zugriff brauchst: VPN oder Reverse Proxy mit Authentifizierung (z.B. Cloudflare Tunnel oder Traefik mit BasicAuth).

💡 VLAN für Isolation

Wenn dein Router VLANs unterstützt, trenne dein AI-Lab vom restlichen Netzwerk. AI-Server in VLAN 10, IoT in VLAN 20, reguläre Geräte in VLAN 1. So kann ein kompromittiertes IoT-Gerät nicht auf deine AI-Infrastruktur zugreifen.

Layer 2: SSH & Authentifizierung

SSH ist der Hauptzugang zu deinen Servern. Falsch konfiguriert ist es das größte Einfallstor.

SSH härten (/etc/ssh/sshd_config)

# Passwort-Login deaktivieren
PasswordAuthentication no

# Root-Login verbieten (oder nur mit Key)
PermitRootLogin prohibit-password

# Nur bestimmte User erlauben
AllowUsers joe admin

# Leerlauf-Timeout (5 Minuten)
ClientAliveInterval 300
ClientAliveCountMax 0

# Neustart: sudo systemctl restart sshd

fail2ban installieren

# Installation
sudo apt install fail2ban

# SSH Jail aktivieren
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# In jail.local:
# [sshd]
# enabled = true
# maxretry = 3
# bantime = 3600

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Status prüfen
sudo fail2ban-client status sshd
ℹ️ SSH Keys generieren

Wenn du noch keine SSH Keys hast: ssh-keygen -t ed25519 -C "dein@email.at". Den Public Key auf den Server kopieren: ssh-copy-id user@server. Danach Passwort-Login deaktivieren.

Layer 3 & 4: Host & Container absichern

Host-System

MaßnahmeBefehl / KonfigurationWarum
Auto-Updatessudo apt install unattended-upgradesSicherheits-Patches automatisch einspielen
Nicht-root Usersudo adduser deploy && sudo usermod -aG docker deployMinimale Rechte, kein permanenter root
Kernel-Updatessudo apt upgrade linux-genericKernel-Exploits schließen
Unnötige Servicessudo systemctl disable bluetooth cupsAngriffsfläche reduzieren

Container-Sicherheit

PrinzipUmsetzungBeispiel
Read-Only Rootread_only: true in composeVerhindert Dateisystem-Manipulation
Kein Root im Containeruser: '1000:1000' in composeContainer läuft als normaler User
Secrets ManagementDocker Secrets oder VaultKeine Credentials in Umgebungsvariablen
Resource Limitsmem_limit: 4g, cpus: '2.0'Container kann nicht den Host überlasten
Network IsolationEigene Docker-Netzwerke pro StackServices sehen nur was sie müssen
⚠️ Swagger/Docs in Produktion

Viele Frameworks (FastAPI, Express) liefern automatisch API- Dokumentation unter /docs oder /swagger. In Produktion: deaktivieren mit docs_url=None. Angreifer nutzen diese Endpunkte um deine API-Struktur zu verstehen.

Layer 5: Anwendungssicherheit für AI

AI-Anwendungen haben eigene Sicherheitsrisiken. LLMs können manipuliert werden (Prompt Injection) und sensible Daten in ihren Antworten leaken.

RisikoBeschreibungGegenmaßnahme
Prompt InjectionNutzer manipuliert LLM-AnweisungenSystem Prompt Isolation, Input Validation
Data LeakageLLM gibt Environment Variables oder Secrets ausOutput Sanitizer (PFLICHT)
Token TheftAPI Keys werden abgefangenVault, Token Rotation, Rate Limiting
Model PoisoningManipulierte Modelle von unsicheren QuellenNur offizielle Quellen (ollama.com, HuggingFace verified)
Resource ExhaustionÜberlange Prompts/KontexteMax Token Limits, Request Timeouts
⚠️ Output Sanitizer ist Pflicht

LLMs können dazu gebracht werden, Umgebungsvariablen, API Keys oder System-Informationen auszugeben. JEDE Antwort muss durch einen Sanitizer laufen, der Patterns wie API Keys, IP-Adressen, und Dateipfade erkennt und entfernt. Das ist keine Nice-to-have-Funktion, sondern absolute Pflicht für Produktion.

Layer 6: Monitoring & Incident Response

Sicherheit ohne Monitoring ist blind. Du musst wissen was auf deinen Systemen passiert — in Echtzeit.

Was überwachenToolAlert-Bedingung
SSH Login-Versuchefail2ban + GrafanaMehr als 5 fehlgeschlagene Logins/Stunde
Container HealthDocker Health Checks + Uptime KumaContainer unhealthy oder gestoppt
Disk-AuslastungPrometheus Node ExporterDisk > 85% voll
API-FehlerLoki Log QueriesHTTP 5xx Rate > 1% der Requests
Unerwartete ProzesseAudit Logs (auditd)Neuer Prozess von unbekanntem User
💡 Security-Dashboard in Grafana

Erstelle ein dediziertes Security-Dashboard mit fail2ban-Bans, SSH-Logins, API-Fehlerraten und Disk-Nutzung auf einen Blick. So siehst du in 5 Sekunden ob etwas nicht stimmt. Im Grafana Monitoring Guide findest du Anleitungen fuer Security-Panels.

Das Wichtigste

  • Sicherheit ist ein Schichtenmodell. 6 Layer, jede hält etwas anderes auf. Keine alleine reicht.
  • Default Deny bei der Firewall. Nur öffnen was gebraucht wird. AI-Ports NICHT ins Internet.
  • SSH Key-Only + fail2ban. Kein Passwort-Login, automatische Sperre nach 3 Fehlversuchen.
  • Output Sanitizer ist Pflicht für AI-Anwendungen. LLMs leaken sonst Secrets und System-Infos.
  • Monitoring mit Alerting. Ohne Monitoring weisst du nicht, ob jemand schon drin ist.

Quellen

War dieser Artikel hilfreich?

Nächster Schritt: vom Wissen in die Umsetzung

Wenn du mehr willst als Theorie: Setups, Workflows und Vorlagen aus dem echten Betrieb für Teams, die lokale und dokumentierte AI-Systeme wollen.

Warum AI Engineering
  • Lokal und self-hosted gedacht
  • Dokumentiert und auditierbar
  • Aus eigener Runtime entwickelt
  • Made in Austria
Kein Ersatz für Rechtsberatung.