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.
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.

Sicherheit in Schichten: Jede Ebene schützt gegen andere Angriffsvektoren.
| Layer | Schützt gegen | Werkzeuge |
|---|---|---|
| 1. Netzwerk | Unbefugter Zugriff von außen | Firewall (UFW/iptables), VLAN, VPN |
| 2. SSH & Authentifizierung | Brute Force, schwache Passwörter | SSH Key-Only, fail2ban, 2FA |
| 3. Host-Betriebssystem | Veraltete Software, Kernel-Exploits | Unattended Upgrades, CIS Benchmark |
| 4. Container & Services | Privilege Escalation, ungesicherte APIs | Rootless Container, Read-Only FS, Secrets |
| 5. Anwendung | Prompt Injection, Data Leakage | Input Validation, Output Sanitizer, Rate Limits |
| 6. Monitoring & Response | Unbemerkte Einbrüche | Loki, 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 verboseServices 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).
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 sshdfail2ban 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 sshdWenn 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ßnahme | Befehl / Konfiguration | Warum |
|---|---|---|
| Auto-Updates | sudo apt install unattended-upgrades | Sicherheits-Patches automatisch einspielen |
| Nicht-root User | sudo adduser deploy && sudo usermod -aG docker deploy | Minimale Rechte, kein permanenter root |
| Kernel-Updates | sudo apt upgrade linux-generic | Kernel-Exploits schließen |
| Unnötige Services | sudo systemctl disable bluetooth cups | Angriffsfläche reduzieren |
Container-Sicherheit
| Prinzip | Umsetzung | Beispiel |
|---|---|---|
| Read-Only Root | read_only: true in compose | Verhindert Dateisystem-Manipulation |
| Kein Root im Container | user: '1000:1000' in compose | Container läuft als normaler User |
| Secrets Management | Docker Secrets oder Vault | Keine Credentials in Umgebungsvariablen |
| Resource Limits | mem_limit: 4g, cpus: '2.0' | Container kann nicht den Host überlasten |
| Network Isolation | Eigene Docker-Netzwerke pro Stack | Services sehen nur was sie müssen |
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.
| Risiko | Beschreibung | Gegenmaßnahme |
|---|---|---|
| Prompt Injection | Nutzer manipuliert LLM-Anweisungen | System Prompt Isolation, Input Validation |
| Data Leakage | LLM gibt Environment Variables oder Secrets aus | Output Sanitizer (PFLICHT) |
| Token Theft | API Keys werden abgefangen | Vault, Token Rotation, Rate Limiting |
| Model Poisoning | Manipulierte Modelle von unsicheren Quellen | Nur offizielle Quellen (ollama.com, HuggingFace verified) |
| Resource Exhaustion | Überlange Prompts/Kontexte | Max Token Limits, Request Timeouts |
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 überwachen | Tool | Alert-Bedingung |
|---|---|---|
| SSH Login-Versuche | fail2ban + Grafana | Mehr als 5 fehlgeschlagene Logins/Stunde |
| Container Health | Docker Health Checks + Uptime Kuma | Container unhealthy oder gestoppt |
| Disk-Auslastung | Prometheus Node Exporter | Disk > 85% voll |
| API-Fehler | Loki Log Queries | HTTP 5xx Rate > 1% der Requests |
| Unerwartete Prozesse | Audit Logs (auditd) | Neuer Prozess von unbekanntem User |
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
- CIS Benchmarks — Industriestandard für Betriebssystem-Härtung
- Docker Security Documentation — Container-Sicherheit Best Practices
- OWASP Top 10 — Die häufigsten Sicherheitsrisiken in Webanwendungen
- fail2ban — Brute-Force-Schutz für SSH und andere Services
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.
- Lokal und self-hosted gedacht
- Dokumentiert und auditierbar
- Aus eigener Runtime entwickelt
- Made in Austria