So härten Sie Ihre private Foto-Cloud für den produktiven Betrieb

Eine selbst gehostete Fotoverwaltung hat einen entscheidenden Vorteil:

Die eigenen Fotos und Videos bleiben unter der eigenen Kontrolle.

Gleichzeitig übernimmt man damit aber auch Aufgaben, die bei kommerziellen Cloud-Anbietern sonst im Hintergrund erledigt werden.

Dazu gehören:

• Verschlüsselung
• Zugriffssteuerung
• Updates
• Firewall-Regeln
• Backups
• Benutzerverwaltung
• Schutz vor Brute-Force-Angriffen
• Datenschutz
• Wiederherstellbarkeit

Gerade bei einer Anwendung wie Immich ist das besonders wichtig.

Fotos enthalten oft sehr persönliche Informationen:

• Gesichter
• Aufenthaltsorte
• Familienmitglieder
• Kinder
• Fahrzeuge
• Wohnumfeld
• GPS-Koordinaten
• Zeitpunkte
• Reisen
• Dokumente
• Screenshots

Eine kompromittierte Fotoplattform kann daher wesentlich sensibler sein als beispielsweise ein einfacher Webserver.

In diesem zwölften Teil unserer Immich-Serie beschäftigen wir uns deshalb damit, wie Immich sicher und datenschutzfreundlich betrieben werden kann.

Die wichtigste Grundregel: Immich nicht ungeschützt ins Internet stellen

Immich verwendet standardmäßig den Port:

2283

Ein häufiger Fehler besteht darin, diesen Port einfach per Router-Portweiterleitung direkt ins Internet zu veröffentlichen:

Internet
   │
   ▼
Router
   │
   ▼
Port 2283
   │
   ▼
Immich

Technisch kann das funktionieren.

Für einen produktiven Betrieb ist jedoch eine kontrollierte Architektur wesentlich sinnvoller.

Beispielsweise:

Internet
   │
   ▼
HTTPS
   │
   ▼
Reverse Proxy
   │
   ▼
Immich

Der Reverse Proxy übernimmt dabei die öffentlich erreichbare Verbindung und leitet die Anfrage intern an Immich weiter.

Immich unterstützt diesen Aufbau ausdrücklich und verlangt dabei unter anderem korrekt weitergereichte Host, X-Real-IP, X-Forwarded-Proto und X-Forwarded-For-Header. Außerdem muss der Proxy große Uploads und entsprechend lange Timeouts erlauben.

HTTPS ist Pflicht

Wer Immich außerhalb des eigenen lokalen Netzes verwendet, sollte ausschließlich:

https://

verwenden.

Ohne TLS-Verschlüsselung könnten unter Umständen:

• Zugangsdaten
• Session-Informationen
• Fotos
• Videos
• API-Kommunikation

unverschlüsselt über das Netzwerk übertragen werden.

Ein sinnvoller Aufbau lautet daher:

Smartphone
    │
    │ HTTPS
    ▼
Reverse Proxy
    │
    │ HTTP intern
    ▼
Immich

Die TLS-Terminierung kann beispielsweise durch:

• Nginx
• Apache
• Traefik
• Caddy
• Nginx Proxy Manager

erfolgen.

Für öffentlich erreichbare Instanzen eignet sich beispielsweise ein Zertifikat von Let's Encrypt. Die Immich-Dokumentation empfiehlt für öffentlichen Zugriff ebenfalls HTTPS über einen Reverse Proxy.

Eigene Subdomain verwenden

Immich sollte nicht unter einem Unterpfad wie:

example.de/immich

betrieben werden.

Die aktuelle Dokumentation weist darauf hin, dass Immich auf dem Root-Pfad einer Domain beziehungsweise Subdomain bereitgestellt werden muss.

Sinnvoll ist deshalb:

https://fotos.example.de

anstatt:

https://example.de/immich

Reverse Proxy richtig konfigurieren

Ein Reverse Proxy sollte mindestens:

HTTPS terminieren
korrekte Client-IP weiterreichen
große Uploads erlauben
ausreichende Timeouts besitzen

Bei großen Videos ist der letzte Punkt besonders wichtig.

Immich weist beispielsweise bei Traefik darauf hin, dass zu kurze Standard-Timeouts dazu führen können, dass große Video-Uploads abbrechen.

Ein Wert wie:

600 Sekunden

kann hier sinnvoll sein.

Trusted Proxies

Wenn Immich hinter einem Reverse Proxy betrieben wird, muss sichergestellt werden, dass Immich nur vertrauenswürdigen Proxy-Systemen vertraut.

Dafür steht unter anderem die Umgebungsvariable:

IMMICH_TRUSTED_PROXIES

zur Verfügung.

Damit lässt sich festlegen, welche Proxy-IP-Adressen als vertrauenswürdig behandelt werden.

Das ist wichtig, weil Header wie:

X-Forwarded-For

sonst manipuliert werden könnten.

Firewall einsetzen

Neben HTTPS sollte eine lokale Firewall eingesetzt werden.

Unter Debian eignet sich beispielsweise:

UFW

Eine einfache Strategie könnte lauten:

Port 22     SSH
Port 80     HTTP
Port 443    HTTPS

Andere Ports müssen nicht automatisch öffentlich erreichbar sein.

Der Immich-Port:

2283

sollte idealerweise nur intern erreichbar sein.

Beispielsweise:

Internet
   │
   ▼
443
   │
Reverse Proxy
   │
   ▼
2283 intern
   │
   ▼
Immich

Beispiel mit UFW

Eine mögliche Basiskonfiguration:

sudo ufw default deny incoming
sudo ufw default allow outgoing

SSH freigeben:

sudo ufw allow 22/tcp

HTTP und HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Firewall aktivieren:

sudo ufw enable

Status prüfen:

sudo ufw status verbose

Port 2283 muss dann nicht öffentlich geöffnet werden, sofern der Reverse Proxy lokal oder im gleichen internen Netzwerk erreichbar ist.

Docker und Firewall

Bei Docker ist eine Besonderheit zu beachten:

Docker verwaltet eigene iptables- beziehungsweise nftables-Regeln.

Deshalb sollte nicht automatisch davon ausgegangen werden, dass eine einfache UFW-Regel jeden veröffentlichten Docker-Port blockiert.

Ein Compose-Eintrag wie:

ports:
  - "2283:2283"

kann den Dienst unter Umständen auf allen Host-Interfaces veröffentlichen.

Sicherer kann eine Bindung ausschließlich an localhost sein:

ports:
  - "127.0.0.1:2283:2283"

wenn der Reverse Proxy auf demselben Server läuft.

Dann ist Immich selbst nicht direkt aus dem Netzwerk erreichbar.

Datenbank niemals öffentlich erreichbar machen

PostgreSQL sollte ausschließlich intern erreichbar sein.

Immich weist bei seiner Standardinstallation darauf hin, dass PostgreSQL nicht öffentlich exponiert wird.

Ein Port wie:

5432

sollte deshalb nicht einfach an das Internet weitergeleitet werden.

Dasselbe gilt grundsätzlich für interne Dienste wie Redis.

Fail2ban einsetzen

Ein öffentlich erreichbarer Login wird früher oder später automatisierte Zugriffsversuche sehen.

Fail2ban kann Logdateien überwachen und IP-Adressen temporär sperren, wenn wiederholt verdächtige Anmeldeversuche festgestellt werden.

Typischer Aufbau:

Angreifer
   │
   ▼
mehrere fehlerhafte Loginversuche
   │
   ▼
Reverse-Proxy-Log
   │
   ▼
Fail2ban
   │
   ▼
IP gesperrt

In der Praxis ist es häufig sinnvoller, Fail2ban auf den Logs des Reverse Proxys aufzubauen als direkt auf den Container-Logs.

Beispielsweise können Nginx- oder Apache-Logs ausgewertet werden.

Fail2ban ist keine vollständige Sicherheitslösung

Fail2ban bietet Schutz gegen einfache Brute-Force-Angriffe.

Es schützt aber nicht gegen:

• gestohlene Zugangsdaten
• Zero-Day-Schwachstellen
• fehlerhafte Proxy-Konfiguration
• bekannte Sicherheitslücken
• schwache Passwörter
• kompromittierte Geräte

Es ist deshalb nur eine zusätzliche Schutzschicht.

Defense in Depth

Eine sichere Immich-Installation sollte aus mehreren Ebenen bestehen:

Internet
   │
   ▼
Firewall
   │
   ▼
HTTPS
   │
   ▼
Reverse Proxy
   │
   ▼
Fail2ban
   │
   ▼
Authentifizierung
   │
   ▼
Immich
   │
   ▼
Docker Netzwerk
   │
   ▼
PostgreSQL

Fällt eine Schutzschicht aus, existieren weiterhin weitere Barrieren.

Zugang per VPN als Alternative

Nicht jede Immich-Installation muss öffentlich erreichbar sein.

Eine besonders restriktive Variante ist:

Internet
   │
   ▼
VPN
   │
   ▼
Heimnetz
   │
   ▼
Immich

Beispiele:

• WireGuard
• Tailscale
• andere VPN-Lösungen

Dann ist Immich selbst von außen nicht frei erreichbar.

Die offizielle Immich-Dokumentation nennt VPN- beziehungsweise Tailscale-basierte Varianten ebenfalls als mögliche Remote-Access-Strategien.

Benutzerverwaltung

Wie bereits in Teil 7 beschrieben, sollte jede Person einen eigenen Benutzeraccount erhalten.

Nicht empfehlenswert:

Familienaccount
Passwort für alle

Besser:

Benutzer Vater
Benutzer Mutter
Benutzer Kind

Dadurch können:

• Alben
• Freigaben
• Bibliotheken
• Sessions

sauber getrennt werden.

Administratorrechte begrenzen

Administratoren besitzen deutlich mehr Rechte als normale Benutzer.

Daher sollte gelten:

Administrator
=
nur tatsächliche Administratoren

Nicht jedes Familienmitglied benötigt administrative Rechte.

Je weniger privilegierte Accounts existieren, desto kleiner ist die Angriffsfläche.

Benutzerkonten deaktivieren

Nicht mehr benötigte Accounts sollten nicht unbegrenzt bestehen bleiben.

Beispiele:

• ehemaliger Mitarbeiter
• alter Testaccount
• nicht mehr verwendeter Familienaccount

Solche Benutzer sollten deaktiviert oder entfernt werden.

Regelmäßige Benutzerbereinigung gehört deshalb zu einem sicheren Betrieb.

Angemeldete Geräte kontrollieren

Benutzer können in Immich ihre Account-Einstellungen verwalten und unter anderem angemeldete Geräte beziehungsweise Sessions einsehen. Administratoren können Benutzerpasswörter zurücksetzen.

Das ist hilfreich, wenn beispielsweise:

Smartphone verloren

oder:

Laptop verkauft

wurde.

Alte Sessions sollten in solchen Situationen beendet werden.

Passwort-Richtlinien

Immich bietet derzeit nicht zwingend dieselbe komplexe Passwort-Policy-Steuerung wie ein klassisches Enterprise-Identity-System.

Deshalb sollte organisatorisch sichergestellt werden, dass Passwörter:

• lang
• einzigartig
• nicht wiederverwendet
• nicht leicht erratbar

sind.

Eine gute Praxis sind Passphrasen mit hoher Länge.

Beispielsweise:

mehrere zufällige Wörter
+
hohe Gesamtlänge

statt:

Sommer2026!

Passwortmanager verwenden

Ein Passwortmanager ermöglicht für Immich beispielsweise ein komplett zufälliges Passwort mit hoher Länge.

Dadurch muss der Benutzer es sich nicht merken.

Das verhindert außerdem, dass dasselbe Passwort gleichzeitig für:

• E-Mail
• Social Media
• Immich
• Onlinebanking

verwendet wird.

OAuth und zentrale Anmeldung

Immich unterstützt OpenID Connect beziehungsweise OAuth2.

Damit kann beispielsweise ein externer Identity Provider verwendet werden.

Offiziell dokumentierte Beispiele sind unter anderem:

• Authentik
• Authelia
• Keycloak
• Okta
• Google

Das ist besonders interessant, wenn bereits eine zentrale Authentifizierungsplattform vorhanden ist.

Lokale Passwortanmeldung deaktivieren

Immich ermöglicht es, die klassische Anmeldung mit Benutzername und Passwort vollständig zu deaktivieren.

Dann kann beispielsweise ausschließlich OAuth verwendet werden.

Ein Aufbau könnte dann so aussehen:

Benutzer
   │
   ▼
Immich
   │
   ▼
OIDC
   │
   ▼
Authentik / Keycloak

Damit können Passwortrichtlinien und gegebenenfalls Mehrfaktor-Authentifizierung zentral im Identity Provider durchgesetzt werden.

API-Keys schützen

Immich-Benutzer können API-Schlüssel erzeugen.

Diese Schlüssel sollten wie Passwörter behandelt werden.

Ein API-Key darf niemals:

• öffentlich veröffentlicht
• in Screenshots gezeigt
• in Git-Repositories eingecheckt
• unverschlüsselt weitergegeben

werden.

Werden API-Schlüssel beispielsweise für CLI-Skripte verwendet, sollten die entsprechenden Konfigurationsdateien geschützt werden. Auch die Immich CLI weist darauf hin, dass gespeicherte Anmeldedaten sicher behandelt werden müssen.

Updates sind Sicherheitsmaßnahmen

Immich entwickelt sich sehr schnell.

Deshalb gehören regelmäßige Updates zur Sicherheitsstrategie.

Vor jedem Update sollten jedoch zunächst die Release Notes gelesen werden.

Immich empfiehlt genau dieses Vorgehen, insbesondere bei möglichen Breaking Changes.

Ein Standardupdate erfolgt anschließend beispielsweise mit:

docker compose pull
docker compose up -d

oder kombiniert:

docker compose pull && docker compose up -d

Nicht blind automatisch aktualisieren

Vollautomatische Updates klingen bequem.

Bei einer Anwendung mit Datenbankmigrationen ist jedoch Vorsicht sinnvoll.

Besser:

Release Notes lesen
      ↓
Backup prüfen
      ↓
Update durchführen
      ↓
Logs kontrollieren
      ↓
Funktion testen

Damit ist die Wahrscheinlichkeit geringer, dass eine inkompatible Änderung unbemerkt Probleme verursacht.

Betriebssystem ebenfalls aktualisieren

Nicht nur Immich benötigt Updates.

Auch folgende Komponenten müssen gepflegt werden:

Debian
Docker
Reverse Proxy
OpenSSL
Kernel
SSH
Fail2ban

Unter Debian:

sudo apt update
sudo apt upgrade

Ein ungepatchter Reverse Proxy kann genauso gefährlich sein wie eine ungepatchte Anwendung.

Backups gehören zur Sicherheit

Sicherheit bedeutet nicht nur:

Angreifer fernhalten

sondern auch:

Daten nach einem Fehler wiederherstellen können

Die DSGVO nennt für risikoadäquate technische und organisatorische Maßnahmen ausdrücklich auch die Fähigkeit, Verfügbarkeit und Zugang zu personenbezogenen Daten nach einem technischen oder physischen Zwischenfall wiederherzustellen.

Für Immich bedeutet das:

Fotos sichern
+
PostgreSQL sichern
+
Konfiguration sichern
+
Restore testen

Wie das funktioniert, haben wir ausführlich in Teil 10 behandelt.

3-2-1-Backup

Immich empfiehlt selbst die klassische:

3-2-1-Regel

also:

3 Kopien
2 unterschiedliche Medien
1 Kopie außerhalb des Standorts

Gesichert werden müssen sowohl Fotos und Videos als auch die Datenbank.

Backup verschlüsseln

Besonders Offsite-Backups sollten verschlüsselt sein.

Bei privaten Fotos ist das besonders wichtig.

Ein Backup bei einem externen Anbieter sollte nicht automatisch bedeuten, dass dieser:

sämtliche Fotos im Klartext

lesen kann.

Werkzeuge wie:

• Borg
• Restic
• Kopia

können verschlüsselte Backups erzeugen.

.env schützen

Die .env einer Immich-Installation enthält möglicherweise:

Datenbankpasswort
Pfade
Konfigurationsparameter

Sie sollte daher nicht:

chmod 777

erhalten oder öffentlich verfügbar sein.

Sinnvoll ist beispielsweise:

chmod 600 .env

wenn die lokale Betriebsumgebung dies zulässt.

Docker-Compose-Dateien ebenfalls schützen

Auch:

docker-compose.yml

kann Informationen über:

• Netzwerke
• Pfade
• Dienste
• Mounts

enthalten.

Diese Datei ist zwar normalerweise weniger sensibel als .env, gehört aber trotzdem zur Systemkonfiguration und sollte nicht unnötig veröffentlicht werden.

Setup-Endpunkte nach Einrichtung begrenzen

Immich stellt die Umgebungsvariable:

IMMICH_ALLOW_SETUP

bereit.

Wird sie auf:

false

gesetzt, werden bestimmte Setup- beziehungsweise Restore-Endpunkte deaktiviert, darunter der Admin-Sign-up-Endpunkt.

Für fertig eingerichtete produktive Systeme kann dies eine zusätzliche Härtungsmaßnahme sein.

Datenschutz bei Immich

Self Hosting bedeutet nicht automatisch:

DSGVO-konform

Es ist aber ein wichtiger Vorteil:

Die Daten müssen nicht zwangsläufig an einen externen Foto-Cloud-Anbieter übertragen werden.

Damit können beispielsweise:

• Drittstaatentransfers
• externe Auftragsverarbeiter
• externe Profilbildung

reduziert werden.

Ob und welche DSGVO-Pflichten bestehen, hängt jedoch davon ab, wer Immich betreibt und zu welchem Zweck.

Rein private Nutzung

Die DSGVO gilt grundsätzlich nicht für die Verarbeitung personenbezogener Daten durch natürliche Personen im Rahmen ausschließlich persönlicher oder familiärer Tätigkeiten.

Das ergibt sich aus Art. 2 Abs. 2 lit. c DSGVO beziehungsweise Erwägungsgrund 18.

Eine typische private Familieninstallation:

eigener Server
+
private Familienfotos
+
keine berufliche Nutzung

kann deshalb unter die sogenannte Haushaltsausnahme fallen.

Sobald Immich aber beruflich, geschäftlich, vereinsbezogen oder institutionell eingesetzt wird, sieht die Situation anders aus.

Fotos sind personenbezogene Daten

Fotos identifizierbarer Personen sind grundsätzlich personenbezogene Daten.

Dabei ist aber eine wichtige Differenzierung notwendig:

Nicht jedes Foto ist automatisch ein biometrisches Datum besonderer Kategorie.

Erwägungsgrund 51 der DSGVO stellt klar, dass Lichtbilder nur dann unter die biometrischen Daten fallen, wenn sie mit speziellen technischen Verfahren zur eindeutigen Identifizierung oder Authentifizierung verarbeitet werden.

Gesichtserkennung besonders betrachten

Immich kann Gesichter erkennen und Personen gruppieren.

Technisch werden dabei Gesichtsinformationen analysiert und Embeddings erzeugt.

Bei einer professionellen oder institutionellen Nutzung sollte deshalb besonders sorgfältig geprüft werden:

• welcher Zweck verfolgt wird,
• welche Rechtsgrundlage besteht,
• ob biometrische Verarbeitung vorliegt,
• ob diese Verarbeitung erforderlich ist,
• welche Risiken entstehen.

Bei Unsicherheit sollte dies datenschutzrechtlich bewertet werden.

Datenminimierung

Art. 5 DSGVO verlangt unter anderem Datenminimierung: Es sollen nur personenbezogene Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind.

Für eine Immich-Installation kann das beispielsweise bedeuten:

nicht jedes Smartphone-Verzeichnis sichern

sondern gezielt:

Camera

statt automatisch:

Camera
Screenshots
Downloads
Messenger
Dokumente

Das reduziert sowohl Speicherbedarf als auch unnötige personenbezogene Daten.

Datenschutz durch Technikgestaltung

Art. 25 DSGVO fordert Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen.

Auf Immich übertragen können dazu gehören:

private Bibliotheken als Standard
restriktive Freigaben
minimale Benutzerrechte
HTTPS
begrenzte Freigabelinks
keine unnötig öffentlichen Alben

Das Prinzip lautet:

Nicht erst nach einem Problem schützen, sondern Schutz von Anfang an einbauen.

Sicherheit der Verarbeitung

Art. 32 DSGVO nennt unter anderem:

• Verschlüsselung
• Vertraulichkeit
• Integrität
• Verfügbarkeit
• Belastbarkeit
• Wiederherstellbarkeit
• regelmäßige Überprüfung von Sicherheitsmaßnahmen

als mögliche Bestandteile eines risikoadäquaten Schutzniveaus.

Für Immich passen dazu sehr konkret:

HTTPS
Firewall
Backups
Restore-Tests
Updates
Benutzerrechte
Monitoring

Standortdaten nicht vergessen

Fotos können GPS-Koordinaten enthalten.

Immich kann diese Informationen beispielsweise für Karten- und Ortsfunktionen verwenden.

Damit verraten Fotos möglicherweise:

Wohnort
Arbeitsplatz
Schule
Urlaubsort
Bewegungsmuster

Diese Informationen sollten deshalb genauso geschützt werden wie die Bilder selbst.

EXIF-Daten beachten

Fotodateien können neben GPS-Daten weitere Metadaten enthalten:

Kameramodell
Datum
Uhrzeit
Objektiv
Aufnahmeort

Wer Bilder öffentlich teilt, sollte deshalb überlegen, welche Metadaten tatsächlich weitergegeben werden sollen.

Freigabelinks

Freigabelinks sind komfortabel, erhöhen aber die Angriffsfläche.

Ein Link kann:

• weitergeleitet
• falsch adressiert
• kopiert
• langfristig gespeichert

werden.

Deshalb gilt:

nur notwendige Inhalte teilen
+
Passwort verwenden
+
Ablaufdatum setzen
+
alte Links löschen

Öffentliche Freigabe ist eine Datenschutzentscheidung

Bei Familienbildern sollte besonders sorgfältig entschieden werden, ob eine Freigabe wirklich notwendig ist.

Ein öffentlich erreichbarer Link bedeutet zwar nicht automatisch, dass das Album von Suchmaschinen gefunden wird.

Aber:

Wer den Link besitzt,
kann zugreifen.

Das sollte bei sensiblen Fotos immer berücksichtigt werden.

Logging und Datenschutz

Logs sind wichtig für Sicherheit.

Sie können allerdings selbst personenbezogene Daten enthalten.

Beispiele:

IP-Adressen
Benutzernamen
Zeitstempel
Zugriffswege

Bei institutioneller Nutzung sollten daher:

• Aufbewahrungsdauer
• Zugriff auf Logs
• Zweck
• Löschfristen

festgelegt werden.

Reverse-Proxy-Logs regelmäßig rotieren

Nginx- oder Apache-Logs sollten nicht unbegrenzt wachsen.

Unter Linux kann dafür beispielsweise:

logrotate

eingesetzt werden.

Eine sinnvolle Retention hängt vom Betriebszweck ab.

Sicherheitsanalyse benötigt Logs – unbegrenzte Speicherung dagegen ist meist unnötig.

Verschlüsselung auf Datenträgerebene

HTTPS schützt Daten:

während der Übertragung

Nicht automatisch geschützt sind dagegen:

ausgebaute Festplatten
gestohlene Server
Backup-Datenträger

Deshalb kann zusätzliche Verschlüsselung sinnvoll sein.

Beispiele:

LUKS
verschlüsseltes ZFS
verschlüsseltes Backup

Server physisch absichern

Bei Self Hosting wird physische Sicherheit häufig vergessen.

Ein Server:

frei zugänglich im Wohnzimmer

ist anders zu bewerten als ein:

verschlossener Technikraum

Besonders bei Organisationen sollte auch physischer Zugriff Bestandteil des Sicherheitskonzepts sein.

SSH absichern

Wer Immich auf einem Linux-Server betreibt, sollte auch SSH härten.

Sinnvolle Maßnahmen sind:

SSH Keys
Root Login deaktivieren
Passwortlogin einschränken
Fail2ban
Firewall

Ein kompromittierter SSH-Zugang bedeutet schließlich häufig vollständigen Zugriff auf:

• Docker
• PostgreSQL
• Fotos
• Backups

Updates vor Zugriff aus dem Internet priorisieren

Eine öffentlich erreichbare Immich-Instanz sollte zeitnah aktualisiert werden.

Die Immich-Dokumentation weist selbst darauf hin, dass bei öffentlich erreichbaren Instanzen aufgrund der aktiven Entwicklung schwere Sicherheitslücken prinzipiell nicht ausgeschlossen werden können.

Wer Updates selten durchführen möchte, sollte deshalb ernsthaft überlegen, ob:

VPN

statt:

öffentlicher Zugriff

die bessere Lösung ist.

Monitoring

Neben Logs sollte der Serverzustand überwacht werden.

Interessant sind:

freier Speicherplatz
Containerstatus
Backupstatus
Zertifikatslaufzeit
CPU
RAM
PostgreSQL
Festplattenzustand

Ein voller Datenträger kann genauso gefährlich werden wie eine Sicherheitslücke.

Zertifikate überwachen

Let's-Encrypt-Zertifikate werden normalerweise automatisch erneuert.

Trotzdem sollte kontrolliert werden, dass dies tatsächlich funktioniert.

Ein abgelaufenes Zertifikat kann dazu führen, dass:

Mobile App
Browser
API

die Verbindung verweigern.

Eine sichere Referenzarchitektur

Eine private produktive Installation könnte so aufgebaut sein:

                    Internet
                        │
                        ▼
                   Firewall
                        │
                        ▼
                     HTTPS
                        │
                        ▼
                Reverse Proxy
                        │
                   Fail2ban
                        │
                        ▼
               internes Netzwerk
                        │
                        ▼
                   Immich
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
      PostgreSQL                 Media Storage
       NVMe SSD                     NAS/HDD
          │                           │
          └───────────┬───────────────┘
                      ▼
                    Backup
                      │
                      ▼
                  Offsite

Sicherheitscheckliste

Vor einem produktiven Einsatz sollte mindestens geprüft werden:

HTTPS aktiv
Reverse Proxy korrekt
Port 2283 nicht unnötig öffentlich
PostgreSQL nicht öffentlich
Firewall aktiv
Fail2ban eingerichtet
starke Passwörter
Administratorrechte begrenzt
OAuth optional eingerichtet
alte Sessions entfernt
Immich aktuell
Debian aktuell
Docker aktuell
Backups vorhanden
Restore getestet
Offsite-Backup vorhanden
.env geschützt
Logs kontrolliert

Datenschutzcheckliste

Bei nicht rein privater Nutzung sollte zusätzlich geprüft werden:

Zweck der Verarbeitung
Rechtsgrundlage
Datenminimierung
Zugriffsrechte
Löschkonzept
Aufbewahrungszeiten
Backup-Retention
Logging
Freigaben
Gesichtserkennung
GPS-Daten
Betroffenenrechte
technische und organisatorische Maßnahmen

Je nach Nutzung können weitere Anforderungen hinzukommen.

Self Hosting verbessert Kontrolle – nicht automatisch Sicherheit

Ein eigener Server hat einen großen Vorteil:

Datenhoheit

Die Bilder müssen nicht automatisch auf Infrastruktur fremder Anbieter übertragen werden.

Aber:

Self Hosting
≠
automatisch sicher

Eine ungepatchte, direkt ins Internet veröffentlichte Installation mit schwachen Passwörtern kann schlechter geschützt sein als ein professioneller Cloud-Dienst.

Self Hosting funktioniert deshalb nur dann gut, wenn technische Verantwortung ernst genommen wird.

Die wichtigsten Maßnahmen nach Priorität

Wenn eine bestehende Immich-Installation schnell abgesichert werden soll, würde ich in dieser Reihenfolge vorgehen:

1. Backup erstellen

2. Immich aktualisieren

3. Betriebssystem aktualisieren

4. HTTPS einrichten

5. Reverse Proxy verwenden

6. unnötige Ports schließen

7. Firewall aktivieren

8. starke Benutzerpasswörter setzen

9. Administratorrechte reduzieren

10. Fail2ban ergänzen

11. Offsite-Backup einrichten

12. Logs und Updates regelmäßig kontrollieren

Damit werden bereits viele der größten Risiken reduziert.

Immich kann sehr gut als private und kontrollierbare Foto-Cloud eingesetzt werden.

Der sichere Betrieb erfordert allerdings mehr als nur:

docker compose up -d

Wer den Server produktiv und möglicherweise aus dem Internet erreichbar betreibt, sollte mindestens HTTPS, Reverse Proxy, Firewall, regelmäßige Updates und eine belastbare Backup-Strategie einsetzen.

Der direkte Immich-Port muss nicht öffentlich erreichbar sein. PostgreSQL und andere interne Dienste sollten vollständig vom Internet abgeschirmt bleiben.

Zusätzliche Schutzschichten wie Fail2ban, OAuth beziehungsweise ein zentraler Identity Provider und restriktive Benutzerrechte erhöhen die Sicherheit weiter.

Auch Datenschutz sollte von Anfang an berücksichtigt werden. Fotos können personenbezogene Daten, GPS-Koordinaten und weitere sensible Informationen enthalten. Gesichtserkennung kann zusätzlich besondere rechtliche Fragen aufwerfen.

Bei rein persönlicher und familiärer Nutzung kann die Haushaltsausnahme der DSGVO greifen. Für Unternehmen, Vereine, Behörden oder andere institutionelle Anwendungen gelten dagegen deutlich weitergehende Anforderungen.

Technisch lässt sich die grundlegende Strategie auf einen einfachen Satz reduzieren:

Nur das veröffentlichen, was wirklich erreichbar sein muss – alles andere bleibt geschützt im internen Netz.

Kombiniert mit regelmäßigen Updates, getesteten Backups und einer konsequenten Benutzerverwaltung wird aus einer experimentellen Self-Hosting-Installation eine belastbare private Foto-Plattform.

Im nächsten Teil unserer Serie beschäftigen wir uns mit Immich in der Praxis. Wir betrachten typische Einsatzszenarien für Familien, Fotografen, NAS-Nutzer und große private Fotoarchive und entwickeln daraus sinnvolle Beispielarchitekturen.