DSGVO und IT-Systeme — Technische Vorbereitung auf die Verordnung

Am 25. Mai 2018 tritt die DSGVO — Datenschutz-Grundverordnung — in Kraft. Zwei Wochen vor der Frist fassen wir die konkreten technischen Maßnahmen zusammen, die IT-Systeme einhalten müssen. Keine Rechtstheorie, nur Code, Architektur und Werkzeuge.

Warum die DSGVO ein technisches Problem ist¶

Die DSGVO ist nicht nur Sache der Rechtsabteilung. Die Artikel 25 (Datenschutz durch Technikgestaltung) und 32 (Sicherheit der Verarbeitung) verlangen ausdrücklich technische Maßnahmen. Wenn Ihr System die personenbezogenen Daten eines bestimmten Nutzers nicht löschen kann, haben Sie ein Problem — unabhängig davon, wie viele Einwilligungsformulare Sie auf Ihrer Website haben.

Bußgelder von bis zu 20 Millionen EUR oder 4 % des weltweiten Umsatzes sind keine theoretische Bedrohung. Die irische und französische Datenschutzbehörde haben bereits angekündigt, aktiv zu kontrollieren. Die Tschechische Republik hat einen „sanften Start” angekündigt, aber das bedeutet nicht, dass Sie technische Anforderungen ignorieren können.

Kartierung personenbezogener Daten¶

Der erste Schritt ist ein Dateninventar — die Kartierung, wo sich personenbezogene Daten in Ihren Systemen befinden. Ein typisches Enterprise-System hat Daten verstreut über:

• Relationale Datenbanken — primärer Speicher, Tabellen für Kunden, Benutzer, Bestellungen
• Volltextindizes — Elasticsearch, Solr indizieren oft Namen, E-Mails, Adressen
• Cache-Schichten — Redis, Memcached können Session-Daten mit PII enthalten
• Logs — Anwendungslogs enthalten häufig IP-Adressen, User-Agent, manchmal auch Namen
• Backups — Datenbank-Dumps enthalten vollständige Kopien der Daten
• Message Queues — Kafka Topics, RabbitMQ Queues mit Business Events

Wir empfehlen die Erstellung eines Datenflussdiagramms, das den Weg personenbezogener Daten durch das gesamte System zeigt. Ohne dieses Diagramm können Sie das Recht auf Löschung nicht zuverlässig umsetzen.

Recht auf Löschung — Technische Umsetzung¶

Artikel 17 der DSGVO gibt Betroffenen das Recht auf Löschung ihrer personenbezogenen Daten. Technisch bedeutet das:

-- Soft Delete mit Anonymisierung
UPDATE customers SET
    first_name = 'DELETED',
    last_name = 'DELETED',
    email = CONCAT('deleted_', id, '@removed.local'),
    phone = NULL,
    address = NULL,
    deleted_at = NOW(),
    deletion_reason = 'GDPR_REQUEST'
WHERE id = :customer_id;

-- Kaskadierende Anonymisierung in verknüpften Tabellen
UPDATE orders SET
    shipping_name = 'DELETED',
    shipping_address = 'DELETED'
WHERE customer_id = :customer_id;

Warum kein Hard Delete? In vielen Systemen gibt es referenzielle Integritätsbedingungen, Buchhaltungseinträge und Audit Trails, die Sie nicht einfach löschen können. Anonymisierung ist eine DSGVO-konforme Alternative — die Daten hören auf, personenbezogen zu sein.

Vergessen Sie nicht die Löschungsweitergabe an alle Subsysteme: Elasticsearch Index, Redis Cache, Kafka Consumer Groups. Implementieren Sie ein asynchrones „Deletion Event”, das alle Systeme abonnieren.

Datenverschlüsselung — At Rest und In Transit¶

Die DSGVO erwähnt Verschlüsselung ausdrücklich als Beispiel für geeignete technische Maßnahmen (Artikel 32, Absatz 1a).

• In Transit — TLS 1.2+ für alle Kommunikation, einschließlich interner Services. Mutual TLS zwischen Microservices (siehe unseren Artikel über Istio).
• At Rest — Transparent Data Encryption (TDE) auf Datenbankebene. PostgreSQL unterstützt pgcrypto, MySQL hat InnoDB Tablespace Encryption.
• Application-Level Encryption — für besonders sensible Daten (Sozialversicherungsnummern, Gesundheitsdaten) verschlüsseln Sie auf Anwendungsebene mit einem dedizierten Key Management System (HashiCorp Vault, AWS KMS).

Pseudonymisierung¶

Die DSGVO erwähnt Pseudonymisierung ausdrücklich als technische Maßnahme, die das Risiko für Betroffene reduziert. Pseudonymisierte Daten unterliegen weiterhin der DSGVO, aber das Risiko bei einem Datenleck ist deutlich geringer.

# DSGVO und IT-Systeme — Technische Vorbereitung auf die Verordnung
import hmac, hashlib

def pseudonymize(value, key):
    return hmac.new(
        key.encode(),
        value.encode(),
        hashlib.sha256
    ).hexdigest()[:16]

# Original: [email protected]
# Pseudonym: a3f8b2c1d4e5f6a7

Bewahren Sie den Schlüssel für das Reverse Mapping getrennt von den pseudonymisierten Daten auf — idealerweise in einem HSM oder Key Management System. Ohne den Schlüssel sind die Daten unwiderruflich anonym.

Audit-Logs und Verarbeitungsverzeichnis¶

Artikel 30 verlangt Verzeichnisse von Verarbeitungstätigkeiten. Implementieren Sie ein Audit-Log, das jeden Zugriff auf personenbezogene Daten aufzeichnet:

• Wer hat zugegriffen (Benutzer-ID, Rolle)
• Wann (Zeitstempel mit Zeitzone)
• Was (welche Daten, welcher Betroffener)
• Warum (Rechtsgrundlage — Einwilligung, Vertragserfüllung, berechtigtes Interesse)
• Was wurde getan (Lesen, Aktualisieren, Löschen, Exportieren)

Das Audit-Log muss unveränderlich sein — Append-Only-Speicher. Wir empfehlen einen dedizierten Log Store (Elasticsearch mit Write-Once-Indizes oder eine Blockchain-inspirierte Hash Chain).

Consent Management¶

Technisch benötigen Sie ein System, das:

• Granulare Einwilligungen speichert — getrennt für Marketing, Analytics, Weitergabe an Dritte
• Die Version der Bedingungen aufzeichnet, denen der Benutzer zugestimmt hat
• Den Widerruf der Einwilligung mit sofortiger Weitergabe an alle verarbeitenden Systeme ermöglicht
• Eine API zur Überprüfung der Einwilligungsgültigkeit vor jeder Verarbeitung bereitstellt

Datenportabilität — Export im maschinenlesbaren Format¶

Artikel 20 gibt Betroffenen das Recht auf Datenportabilität. Implementieren Sie einen Export-Endpoint:

GET /api/v1/users/{id}/data-export
Accept: application/json

Response:
{
  "personal_data": {
    "name": "Jan Novák",
    "email": "[email protected]",
    "created_at": "2017-03-15T10:00:00Z"
  },
  "orders": [...],
  "preferences": {...},
  "consent_history": [...]
}

JSON- oder CSV-Format ist ausreichend. Der Export muss innerhalb von 30 Tagen nach Anfrage verfügbar sein.

Datenaufbewahrung — Automatische Ablauffristen¶

Die DSGVO verlangt, dass personenbezogene Daten nicht länger als nötig aufbewahrt werden. Implementieren Sie Aufbewahrungsrichtlinien:

• TTL auf Datenbankeinträgen
• Automatischer Cronjob zum Löschen/Anonymisieren abgelaufener Daten
• Unterschiedliche Aufbewahrungsfristen für verschiedene Datentypen (Buchhaltungsunterlagen 10 Jahre, Marketing-Einwilligungen bis zum Widerruf)

Meldung von Datenschutzverletzungen — Erkennung und Berichterstattung¶

Artikel 33 verlangt die Meldung von Datenschutzverletzungen innerhalb von 72 Stunden. Das bedeutet, Sie benötigen:

• Erkennung — SIEM-System (ELK Stack, Splunk) mit Alarmen für anomale PII-Zugriffe
• Klassifizierung — automatische Feststellung, ob eine Verletzung personenbezogene Daten betrifft
• Incident Response Playbook — dokumentiertes Verfahren zur Benachrichtigung der Aufsichtsbehörde und der Betroffenen

Die DSGVO ist eine Chance, nicht nur eine Pflicht¶

Die technische Umsetzung der DSGVO zwingt Organisationen, endlich Probleme anzugehen, die sie seit Jahren aufschieben — Data Governance, Verschlüsselung, Audit Trail, saubere APIs. Systeme, die die DSGVO-Vorbereitung durchlaufen, werden robuster und sicherer sein. Und das ist ein Wert, der über Compliance hinausgeht.

Bei CORE SYSTEMS helfen wir Kunden bei der technischen Umsetzung der DSGVO — von der Datenkartierung über Anonymisierungspipelines bis hin zum Audit Logging. Kontaktieren Sie uns, wenn Sie vor dem 25. Mai Hilfe benötigen.