# GDPR Compliance: Linux-Systeme rechtssicher härten

TL;DR / Management Summary Die DSGVO (Datenschutz-Grundverordnung) fordert “Sicherheit durch Technikgestaltung und datenschutzfreundliche Voreinstellungen”. Für einen Linux-Admin bedeutet das: Personenbezogene Daten müssen geschützt (Verschlüsselung), Zugriffe kontrolliert (Least Privilege) und Änderungen protokolliert (Auditing) werden. In diesem Modul lernen wir, wie wir die rechtlichen Anforderungen in konkrete Linux-Konfigurationen (LUKS, SSSD, Auditd) übersetzen, um Bußgelder und Datenlecks zu vermeiden.

# 1. Einführung & Architektur

Die vier Säulen der Compliance.

1. Vertraulichkeit: Daten dürfen nur von berechtigten Personen gelesen werden.
2. Integrität: Daten dürfen nicht unbemerkt verändert werden.
3. Verfügbarkeit: Systeme müssen zuverlässig laufen.
4. Transparenz: Wir müssen wissen (und beweisen), wer was wann getan hat.

# Das Compliance-Framework (Mermaid)

graph TD
    A[GDPR Requirement] --> B[Technical Control]
    B --> C[Encryption at Rest: LUKS]
    B --> D[Access Control: Sudo / AD]
    B --> E[Audit Trail: Auditd / Syslog]
    B --> F[Data Minimization: Logrotate]
    subgraph "Proof of Compliance"
        G[OpenSCAP Reports]
        H[Centralized Logs]
    end
    E --> H
    B --> G

# 2. Säule 1: Verschlüsselung (Data at Rest)

Schutz vor Diebstahl.

Alle Datenträger, die personenbezogene Daten enthalten (z.B. User-Datenbanken, Backups), müssen verschlüsselt sein.

• Host-Ebene: Nutzen Sie LUKS (Artikel 320).
• Virtualisierung: Nutzen Sie Disk-Encryption auf Hypervisor-Ebene (Proxmox/ZFS) oder innerhalb des Gastes.

# 3. Säule 2: Strenge Zugriffskontrolle

Weg von shared Accounts.

Jeder Zugriff muss einer natürlichen Person zugeordnet werden können.

• Verbot: Nutzen Sie niemals den root Account für tägliche Arbeit.
• Identität: Binden Sie Linux an das Firmen-AD via SSSD (Artikel 136).
• Sudo: Nutzen Sie granulare Sudoers-Regeln statt ALL=(ALL) ALL (Artikel 288).

# 4. Säule 3: Revisionssicheres Logging

Die Nachweispflicht.

Im Falle eines Datenlecks müssen Sie innerhalb von 72 Stunden den Vorfall melden. Ohne Logs ist das unmöglich.

• Auditd: Protokollieren Sie jeden Zugriff auf sensible Dateien (z.B. /var/lib/mysql).
• Persistence: Senden Sie Logs sofort an einen externen, unveränderbaren Log-Server (Artikel 339).

# 5. Day-2 Operations: Datenlöschung und Log-Privacy

Recht auf Vergessenwerden.

# Log-Anonymisierung

IP-Adressen in Web-Logs gelten als personenbezogene Daten.

• Konfiguration: Konfigurieren Sie Nginx/Apache so, dass das letzte Oktett der IP-Adresse maskiert wird (192.168.1.0 statt .50).

# Aufbewahrungsfristen (Logrotate)

Löschen Sie Logs konsequent nach Ablauf der gesetzlichen oder betrieblichen Fristen (z.B. 180 Tage).

# In /etc/logrotate.conf
rotate 26
weekly

# 6. Troubleshooting & “War Stories”

Wenn die Compliance die Fehlersuche erschwert.

# Story 1: “Das anonymisierte Log-Rätsel”

Symptom: Ein Angreifer flutet den Webserver mit Anfragen. Das Log zeigt tausende Zeilen, aber die IP ist durch Anonymisierung unbrauchbar für eine Firewall-Sperre. Ursache: Zu frühe Anonymisierung direkt auf dem Host. Lösung: Loggen Sie die volle IP auf dem Server (Rechte 600), aber anonymisieren Sie die Daten erst beim Import in den zentralen (öffentlicheren) ELK-Stack. So behalten Sie die Abwehrfähigkeit lokal bei.

# Story 2: “Die vergessenen Backups”

Symptom: Bei einem Audit stellt sich heraus, dass alte Server-Backups unverschlüsselt auf einem NAS liegen. Ursache: Fokus lag nur auf den Live-Servern. Lösung: Backup-Ziele müssen zwingend die gleichen Sicherheitsstandards erfüllen wie die Quellsysteme. Nutzen Sie verschlüsselte Repositories (z.B. Restic, Artikel 057).

# 7. Fazit & Empfehlung

• Automation: Nutzen Sie OpenSCAP (Artikel 179), um automatisch Berichte für den Datenschutzbeauftragten zu generieren.
• Wartung: Überprüfen Sie jährlich, ob die gespeicherten Daten noch dem Verwendungszweck entsprechen (Datenminimierung).
• Wahl: Setzen Sie auf Distributionen mit langer Support-Laufzeit (SLES/RHEL), um Compliance durch stetige Sicherheits-Updates zu garantieren.

# Anhang: Die GDPR-Checkliste für Admins