Kurzanleitungen

Die wichtigsten technischen Grundlagen zur Vermeidung unnötiger IP-Speicherung – kompakt zusammengefasst.

1. Apache HTTP Server

Variante A: Access-Log nicht schreiben

Wenn für die Website kein Access-Log benötigt wird, ist der Verzicht die datensparsamste Lösung. In einer selbst verwalteten VirtualHost-Konfiguration kann beispielsweise kein CustomLog eingerichtet bzw. die vorhandene Protokollierung deaktiviert werden. Bei Hosting-Oberflächen muss die Einstellung des Providers verwendet werden.

Nicht ideal: CustomLog /dev/null combined verhindert zwar die dauerhafte Datei, Apache erzeugt aber weiterhin den vollständigen Logeintrag. Besser ist eine Konfiguration, die den betreffenden Access-Log gar nicht erst benötigt.

Variante B: weiter loggen, aber ohne Besucher-IP

Apache bestimmt den Inhalt eines Access-Logs über LogFormat. Die Clientadresse wird typischerweise über %h bzw. %a aufgenommen. Wer Statuscodes, Pfade und übertragene Bytes zur Fehleranalyse behalten möchte, kann ein eigenes Format ohne Clientadresse verwenden:

LogFormat "%t "%r" %>s %b" wsn_noip
CustomLog /var/log/apache2/example-access.log wsn_noip

Auch Referrer und User-Agent sollten nur aufgenommen werden, wenn sie wirklich benötigt werden. Zusammen mit Zeitstempel und seltenen URLs können auch solche Daten zur Wiedererkennung beitragen.

Error-Log beachten

Ein deaktiviertes oder IP-freies Access-Log reicht nicht. Anwendungen, Module und bestimmte Fehlersituationen können Adressen oder Request-Daten in Error-Logs schreiben. Deshalb Error-Logs separat kontrollieren und einige reale Fehlerfälle testen.

2. nginx

Variante A: Access-Log vollständig abschalten

server {
    server_name example.de;
    access_log off;
}

nginx unterstützt access_log off direkt.

Variante B: Log ohne IP-Adresse

Wer ein technisches Log behalten möchte, definiert ein Format ohne $remote_addr und ohne weitergereichte IP-Header:

log_format wsn_noip '$time_local "$request" $status $body_bytes_sent';
access_log /var/log/nginx/example-access.log wsn_noip;

Nicht zusätzlich $http_x_forwarded_for, $http_cf_connecting_ip oder ähnliche Header aufnehmen.

3. Caddy

Caddy schreibt HTTP-Access-Logs nur, wenn Request-Logging konfiguriert wurde. Werden Logs benötigt, unterstützt Caddy Filter und IP-Maskierung. Bei konfigurierten Trusted Proxies müssen sowohl remote_ip als auch client_ip berücksichtigt werden:

example.de {
    log {
        format filter {
            request>remote_ip ip_mask 16 32
            request>client_ip ip_mask 16 32
            request>headers>Cookie delete
        }
    }
}

Für „Wir speichern nicht!“ ist vollständiger Verzicht auf eine gespeicherte Besucheradresse vorzuziehen. Maskierung ist eine Alternative, wenn ein technisches Log benötigt wird; die gewählte Maskierung muss ausreichend stark sein.

4. Traefik

Traefik-Access-Logs lassen sich feldweise reduzieren. Besonders ClientAddr und ClientHost enthalten die Clientadresse. Header und Query-Parameter können ebenfalls sensible Daten enthalten.

accessLog:
  format: json
  fields:
    defaultMode: keep
    names:
      ClientAddr: drop
      ClientHost: drop
      ClientPort: drop
    headers:
      defaultMode: drop
    queryParameters:
      defaultMode: drop

Wer keine Access-Logs benötigt, sollte sie gar nicht aktivieren.

5. Reverse Proxy / CDN

Ein vorgeschalteter Proxy sieht die Besucher-IP technisch zunächst selbst. Entscheidend für den eigenen Origin ist, ob die ursprüngliche Besucher-IP anschließend weitergereicht und dort gespeichert wird.

Cloudflare

Im Cloudflare-Dashboard die Domain öffnen und Regeln → Einstellungen → Verwaltete Transformationen → HTTP-Anforderungsheader aufrufen. Dort „Besucher-IP-Header entfernen“ aktivieren.

Cloudflare verarbeitet die IP weiterhin am Proxy, entfernt dabei aber die Besucher-IP-Header vor der Weiterleitung an den Origin. Anschließend prüfen, dass Webserver und Anwendung nicht aus anderen Forwarded-Headern wieder eine Besucheradresse übernehmen.

Für die Prüfung entspricht das „Proxy verarbeitet Besucher-IP, übermittelt sie aber nicht an den Origin“.

Eigener Reverse Proxy

Bei nginx, HAProxy, Traefik oder einem anderen selbst betriebenen Proxy müssen zwei Ebenen geprüft werden: Logging am Proxy selbst und an den Origin übermittelte Header. Es bringt nichts, den Origin IP-frei zu konfigurieren, wenn der vorgeschaltete Proxy weiterhin vollständige Clientadressen dauerhaft protokolliert.

6. PHP und eigene Anwendungen

Auch ein IP-freier Webserver kann durch die Anwendung wieder personenbezogene Logs erzeugen. Typische Quellen sind:

$_SERVER['REMOTE_ADDR'],
X-Forwarded-For, Forwarded, CF-Connecting-IP und True-Client-IP,
Login-, Registrierungs- und Passwort-Reset-Protokolle,
Kontaktformular- und Kommentar-Spamschutz,
Rate-Limits auf Basis dauerhaft gespeicherter IP-Adressen,
Exception-/Debug-Logger, die den gesamten Request-Kontext mitschreiben,
Session-, Geräte- oder Fingerprint-Kennungen.

Für einfache Missbrauchsabwehr sind je nach Anwendung beispielsweise Honeypots, zeitliche Plausibilitätsprüfungen, Same-Origin-Prüfungen und kurzlebige signierte Formulartokens möglich, ohne eine dauerhafte Besucher-IP-Datenbank aufzubauen.

7. Matomo und andere Statistiksysteme

Am datensparsamsten ist es, kein besucherbezogenes Analysesystem einzusetzen. Wird Matomo benötigt, kann die IP vor der Speicherung maskiert bzw. vollständig auf 0.0.0.0 anonymisiert werden. Wichtig: Matomo weist selbst darauf hin, dass dies nichts nützt, wenn parallel im Webserver weiterhin die vollständige IP gespeichert wird.

Zusätzlich sollten User-IDs, detaillierte Referrer, Besucherprofile und andere zur Wiedererkennung geeignete Funktionen geprüft bzw. deaktiviert werden.

8. Shared Hosting

Bei Shared Hosting kann der Kunde Apache/nginx häufig nicht selbst konfigurieren. Dann zuerst im Kundenmenü nach Einstellungen wie Logfiles, Besucherstatistik, IP-Anonymisierung, WebAnalytics oder Access Logs suchen. Manche Anbieter anonymisieren automatisch, andere bieten eine Option an, wieder andere lassen die Protokollierung nicht vollständig abschalten.

Ist eine providerseitige Speicherung technisch nicht durch den Kunden beeinflussbar, sollte sie bei der Einreichung genau so angegeben werden. Sie wird getrennt von einer selbst veranlassten Speicherung bewertet.

9. CMS und Plugins prüfen

Bei WordPress, Joomla, TYPO3 und anderen CMS reicht die Webserver-Konfiguration allein nicht. Erweiterungen können eigene Datenbanken und Logdateien führen. Besonders prüfen sollte man Security-, Firewall-, Login-, Statistik-, Formular-, Kommentar-, Antispam-, Newsletter- und Backup-Plugins.

WordPress

WordPress behandelt IP-Adressen ausdrücklich als personenbezogene Daten und besitzt Werkzeuge zum Exportieren und Löschen personenbezogener Daten. Diese Werkzeuge erfassen jedoch nur WordPress selbst und Plugins, die sich daran beteiligen. Deshalb jedes aktive Plugin separat prüfen.

Kommentare und Kommentar-Metadaten prüfen.
Security-/Firewall-Plugins auf IP-Logging, Blocklisten und Login-Protokolle prüfen.
Statistik-Plugins und externe Analytics möglichst deaktivieren oder datensparsam konfigurieren.
Formular- und Antispam-Plugins darauf prüfen, ob sie IP, User-Agent oder Fingerprints speichern.
Nach einer Änderung alte Plugin-Logs und Datenbanktabellen nicht vergessen.

Joomla

Bei Joomla insbesondere Erweiterungen prüfen. Die Joomla-Datenschutzempfehlungen für Extensions nennen Datensparsamkeit und „Privacy by Default“ ausdrücklich als Ziel; zusätzliche Erfassung wie IP-Collection sollte nur erfolgen, wenn sie tatsächlich benötigt wird. Für „Wir speichern nicht!“ daher jede aktive Erweiterung auf eigene Protokollierung untersuchen.

TYPO3

TYPO3 besitzt ein eigenes Logging-Framework; Logs können auch personenbezogene Daten wie IP-Adressen enthalten. Zusätzlich gibt es eine ipAnonymization-Konfiguration. Wichtig: Die TYPO3-Dokumentation weist darauf hin, dass diese Einstellung für Anonymisierungsaufgaben gilt und nicht automatisch verhindert, dass neue Logeinträge zunächst eine Adresse enthalten. Deshalb tatsächliche Logwriter, Systemlogs und Extensions kontrollieren.

Allgemeine Plugin-Regel

Ein Plugin ist nicht allein deshalb für „Wir speichern nicht!“ geeignet, weil es „DSGVO“, „Privacy“ oder „anonymisiert“ in der Beschreibung nennt. Entscheidend ist der tatsächlich gespeicherte Datensatz. Nach der Konfiguration einen Test auslösen und anschließend Datenbank, Plugin-Log und Serverlog kontrollieren.

10. Nach der Änderung prüfen

Website einige Male von einem externen Anschluss aufrufen.
Access- und Error-Logs kontrollieren.
Reverse-Proxy-/CDN-Logs separat kontrollieren.
Anwendungs-, Login-, Formular- und Sicherheitslogs durchsuchen.
Nach REMOTE_ADDR und typischen Forwarded-IP-Headern in der Anwendungskonfiguration suchen.
Prüfen, ob alte Logdateien mit vollständigen IP-Adressen noch vorhanden sind und ob sie weiterhin benötigt werden.

Grundregel: Nicht nur das sichtbare Access-Log prüfen. Die gesamte Kette vom vorgeschalteten Proxy über den Webserver bis zur Anwendung entscheidet darüber, was am Ende tatsächlich gespeichert wird.