DSGVO-Anfragen automatisieren: Eine Go-Anwendung zur Verwaltung von Betroffenenrechten

DSGVO-Anfragen automatisieren: Compliance ohne Kopfzerbrechen mit Go

Seit dem Inkrafttreten der Datenschutz-Grundverordnung (DSGVO) haben Nutzer weitreichende Rechte bezüglich ihrer personenbezogenen Daten. Das Recht auf Auskunft (Artikel 15), Berichtigung (Artikel 16) und Löschung (Artikel 17, “Recht auf Vergessenwerden”) sind nur einige davon. Für Unternehmen bedeutet dies: Auf Anfrage müssen sie in der Lage sein, alle personenbezogenen Daten eines Nutzers über ihre gesamten Systeme hinweg zu finden, zusammenzustellen, zu korrigieren oder sicher zu löschen – und das innerhalb einer strengen Frist von einem Monat.

Die manuelle Bearbeitung dieser Anfragen ist zeitaufwändig, fehleranfällig und ab einer gewissen Unternehmensgröße schlicht nicht mehr machbar. Als Softwarearchitekt und Go-Entwickler setze ich auf Automatisierung, um diesen Prozess effizient, sicher und revisionssicher zu gestalten. In diesem Beitrag skizziere ich die Architektur einer Go-Anwendung, die ich entworfen habe, um die Verwaltung von Betroffenenrechten zu automatisieren und Compliance sicherzustellen.

Die Herausforderung: Verteilte Daten und manuelle Prozesse

Personenbezogene Daten liegen selten an einem einzigen Ort. Sie sind verteilt über:

• Produktionsdatenbanken (z.B. PostgreSQL)
• Caches (z.B. Redis)
• Log-Dateien
• CRM-Systeme von Drittanbietern
• Analyse-Tools
• Backups

Eine manuelle Suche in all diesen Systemen ist nicht nur langsam, sondern birgt auch das Risiko, Daten zu übersehen.

Meine Architektur: Ein zentraler “Privacy Hub” in Go

Ich entwerfe ein zentrales System, einen “Privacy Hub”, der als Orchestrator für alle DSGVO-Anfragen dient. Go ist hierfür die ideale Sprache, da es durch seine Nebenläufigkeit (Goroutinen) hervorragend geeignet ist, parallel Anfragen an verschiedene Systeme zu stellen und auf deren Antworten zu warten.

Komponenten des Privacy Hubs:

1. Frontend/API-Endpunkt:

   • Ein sicheres Web-Formular oder ein API-Endpunkt, über den Nutzer ihre Anfrage einreichen können.
   • Identitätsverifizierung: Dies ist ein kritischer Schritt. Wir müssen sicherstellen, dass die anfragende Person auch die ist, für die sie sich ausgibt. Dies kann durch einen Login, eine Zwei-Faktor-Authentifizierung oder einen E-Mail-Verifizierungsprozess erfolgen.

2. Request-Orchestrator (Go-Backend):

   • Das Herzstück der Anwendung. Wenn eine verifizierte Anfrage (z.B. “Auskunft für user@example.com”) eingeht, startet der Orchestrator eine Reihe von parallelen Aufgaben.
   • Jede Aufgabe ist für ein bestimmtes Datensilo (Datenbank, CRM etc.) zuständig.

3. Konnektoren (“Connectors”):

   • Für jedes System, das personenbezogene Daten enthält, schreibe ich einen spezifischen Konnektor. Ein Konnektor ist ein Go-Modul, das weiß, wie es mit dem jeweiligen System kommunizieren und die Daten für einen bestimmten Nutzer finden oder löschen kann.
   • PostgreSQL-Konnektor: Führt SELECT-Abfragen über mehrere Tabellen aus, um alle Daten zu einer User-ID zu finden. Für Löschungen führt er UPDATE- (Anonymisierung) oder DELETE-Befehle aus.
   • Redis-Konnektor: Sucht und löscht Schlüssel, die mit der User-ID in Verbindung stehen.
   • Third-Party-API-Konnektor: Ruft die API eines externen Dienstes (z.B. Salesforce, Zendesk) auf, um dort Daten abzufragen oder Löschanträge zu stellen.

Konzeptioneller Go-Code für den Orchestrator:

package main

import (
	"context"
	"fmt"
	"sync"
	"time"
)

// Connector ist ein Interface, das jeder Datenquellen-Konnektor implementieren muss.
type Connector interface {
	FetchData(ctx context.Context, userID string) (string, error)
	DeleteData(ctx context.Context, userID string) error
}

// simulateFetch simuliert das Abrufen von Daten aus einem System.
func simulateFetch(systemName string, userID string) (string, error) {
	time.Sleep(1 * time.Second) // Simuliert Netzwerk-Latenz
	return fmt.Sprintf("Daten für %s aus %s", userID, systemName), nil
}

// OrchestrateAuskunft führt eine Auskunftsanfrage parallel aus.
func OrchestrateAuskunft(userID string) {
	connectors := []string{"PostgreSQL", "Redis", "CRM"}
	var wg sync.WaitGroup
	results := make(chan string, len(connectors))

	fmt.Println("Starte Auskunftsanfrage für", userID)

	for _, connectorName := range connectors {
		wg.Add(1)
		go func(name string) {
			defer wg.Done()
			data, err := simulateFetch(name, userID)
			if err != nil {
				// Fehlerbehandlung
				return
			}
			results <- data
		}(connectorName)
	}

	wg.Wait()
	close(results)

	fmt.Println("\nZusammengefasster Bericht:")
	for result := range results {
		fmt.Println("-", result)
	}
}

func main() {
	OrchestrateAuskunft("user-12345")
}

4. Audit-Log:

   • Jeder einzelne Schritt des Prozesses wird in einem unveränderlichen Audit-Log (z.B. in einer separaten PostgreSQL-Tabelle oder einem spezialisierten Log-System) protokolliert.
   • Was wird geloggt?
     • Eingang der Anfrage (wer, was, wann)
     • Ergebnis der Identitätsverifizierung
     • Welche Konnektoren wurden ausgeführt?
     • Erfolgs- oder Fehlermeldungen von jedem Konnektor
     • Zeitpunkt des Abschlusses und der Benachrichtigung des Nutzers
   • Dieses Log ist entscheidend, um gegenüber den Aufsichtsbehörden die Einhaltung der Prozesse nachweisen zu können.

5. Report-Generator:

   • Für Auskunftsanfragen sammelt der Orchestrator die Ergebnisse aller Konnektoren und ein Report-Generator erstellt einen maschinenlesbaren, strukturierten Bericht (z.B. JSON), der dem Nutzer sicher zur Verfügung gestellt wird.

Der Löschprozess: Anonymisierung vs. Hard Delete

Beim “Recht auf Vergessenwerden” gibt es oft eine Abwägung:

• Hard Delete: Die Datensätze werden physisch aus der Datenbank entfernt. Dies ist der sauberste Ansatz, kann aber zu Problemen mit referenzieller Integrität führen.
• Anonymisierung/Pseudonymisierung: Personenbezogene Daten (Name, E-Mail) werden durch zufällige oder generische Werte ersetzt (z.B. “Gelöschter Nutzer”). Die restlichen, nicht-personenbezogenen Daten (z.B. ein verfasster Kommentar) können erhalten bleiben. Dies ist oft der pragmatischere Weg.

Ich implementiere den Lösch-Konnektor so, dass er je nach Anforderung und gesetzlichen Aufbewahrungspflichten (z.B. für Rechnungen) die richtige Strategie wählt.

Fazit: Compliance als Engineering-Herausforderung

Die Einhaltung der DSGVO ist nicht nur eine rechtliche, sondern auch eine technische Herausforderung. Ein manueller Ansatz zur Bearbeitung von Betroffenenrechten ist nicht skalierbar und riskant. Durch den Bau eines zentralen, in Go geschriebenen Automatisierungstools verwandeln wir eine gefürchtete manuelle Aufgabe in einen effizienten, nachvollziehbaren und sicheren Prozess. Wir stellen nicht nur die Einhaltung der gesetzlichen Fristen sicher, sondern schaffen auch das Vertrauen bei unseren Nutzern, dass wir ihre Rechte ernst nehmen und ihre Daten professionell verwalten.

Kämpfen Sie mit der manuellen und zeitaufwändigen Bearbeitung von DSGVO-Anfragen? Ich helfe Ihnen bei der Konzeption und Entwicklung einer maßgeschneiderten Automatisierungslösung. Lassen Sie uns gemeinsam einen robusten und revisionssicheren Prozess aufbauen, der Ihre Compliance sicherstellt und Ihr Team entlastet. Kontaktieren Sie mich für eine Analyse Ihrer Datenschutz-Prozesse.