Automatisierte Anonymisierung von Daten der Einmalkunden

mrouissi commented

2025-06-17 15:52:35 +02:00

Owner

Es soll ein automatisierter Prozess entwickelt werden, der die personenbezogenen Daten von Einmalkunden sechs Monate nach dem Transaktionsdatum (riser_order.result_date) anonymisiert.

Das Skript betrifft spezifische Felder in den Tabellen riser_order und payment, ohne die Stammdaten von Portalkunden zu beeinflussen.

Gleichzeitig muss sichergestellt werden, dass die zugehörigen PDF-Dokumente für 10 Jahre sicher archiviert und auffindbar bleiben.

Es soll ein automatisierter Prozess entwickelt werden, der die personenbezogenen Daten von Einmalkunden sechs Monate nach dem Transaktionsdatum (`riser_order.result_date`) anonymisiert. Das Skript betrifft spezifische Felder in den Tabellen `riser_order` und `payment`, ohne die Stammdaten von Portalkunden zu beeinflussen. Gleichzeitig muss sichergestellt werden, dass die zugehörigen PDF-Dokumente für 10 Jahre sicher archiviert und auffindbar bleiben.

mrouissi self-assigned this

2025-06-17 15:52:48 +02:00

mrouissi added this to the Tasks Dashboard project

2025-06-17 15:52:52 +02:00

mrouissi added the

approved-project

label

2025-06-17 15:52:57 +02:00

mrouissi added reference develop-AG-2025/00216

2025-06-20 18:59:53 +02:00

mrouissi commented

2025-06-20 19:22:21 +02:00

Author

Owner

Die Entwicklung des Skripts ist abgeschlossen. Die folgenden Tests wurden erfolgreich auf der Testumgebung bnet005 durchgeführt, um die Funktionalität, Sicherheit und das Reporting des Skripts zu validieren.

1. Verifizierung der Geschäftslogik

Unterscheidung der Kundenarten bestätigt: Es wurde verifiziert, dass Transaktionen von Einmalkunden durch eine vorhandene inquiry_id eindeutig identifiziert werden, während Transaktionen von Portalkunden eine inquiry_id von NULL aufweisen.
Analyse der Customer Journey bestätigt: Es wurde bestätigt, dass die Customer Journey eines Benutzers als Einmalkunde beginnen und später, in die eines registrierten Portalkunden übergehen kann. Dies validiert den Ansatz des Skripts, die Anonymisierung auf der Ebene der einzelnen Transaktion (inquiry_id) durchzuführen, anstatt auf der Ebene des Kundenkontos.
Logik für Rabattaktionen bestätigt: Das potenzielle Risiko wurde untersucht, dass die Anonymisierung von E-Mail-Adressen die Rabattlogik für Viel-Anfrager beeinträchtigen könnte. Eine detaillierte technische Analyse der Customer Journey hat ergeben, dass die Rabattfunktion an das permanente Portalkonto (customer Tabelle) gebunden ist und nicht an eine simple Zählung von E-Mails in der inquiry-Tabelle. Da das Skript ausschließlich Einmalanfragen (inquiry_id IS NOT NULL) anonymisiert und niemals die customer-Stammdaten berührt, ist sichergestellt, dass die Geschäftsregel für Rabatte nicht beeinträchtigt wird.

2. Tests der Skriptfunktionalität und -sicherheit

Dry-Run-Modus: Der --dry-run Schalter wurde erfolgreich getestet. Das Skript hat alle Zieldatensätze korrekt identifiziert, ohne Änderungen an der Datenbank vorzunehmen.
Korrektheit der Live-Anonymisierung:
- Ein "Vorher-Nachher"-Vergleich von spezifischen Zieldatensätzen wurde durchgeführt.
- Es wurde bestätigt, dass nach einem Live-Lauf die personenbezogenen Daten in allen drei Ziel-Tabellen (riser_order, payment und inquiry) korrekt auf NULL gesetzt wurden.
Integrität der Portalkundendaten (Regressionstest):
- Datensätze in der payment-Tabelle mit inquiry_id IS NULL wurden vor und nach dem Live-Lauf abgefragt.
- Es wurde bestätigt, dass die Daten dieser Portalkunden zu 100% unberührt blieben, was eine zentrale Sicherheitsanforderung erfüllt.
Integrität der PDF-Archiv-Verknüpfung:
- Der hash eines anonymisierten inquiry-Datensatzes wurde erfolgreich ausgelesen.
- Mit diesem Hash wurde die zugehörige PDF-Datei auf dem Server gefunden. Dies bestätigt, dass die Verknüpfung zwischen Datenbank und Dateiarchiv intakt bleibt.
Transaktionssicherheit:
- Es wurde bestätigt, dass das Skript eine "Alles-oder-nichts"-Datenbanktransaktion verwendet.
- Im Fehlerfall wird die gesamte Transaktion per Rollback zurückgesetzt, sodass die Datenbank in einem konsistenten Zustand verbleibt.

3. Tests des Reportings und der Benachrichtigungen

Konsolenausgabe: Die finale Skriptversion zeigt wie gewünscht einen sauberen Fortschrittsbalken an und gibt am Ende nur eine einzige Statuszeile aus. Fehler werden während der Ausführung dezent gemeldet.
Log-Datei-Erstellung: Es wurde verifiziert, dass das Skript eine detaillierte, täglich erweiterte Log-Datei im korrekten Format und am spezifizierten Ort (/var/log/...) anlegt.
E-Mail-Benachrichtigungen:
- Die Funktionalität des mail-Befehls auf dem Server wurde bestätigt.
- Es wurde verifiziert, dass E-Mail-Alerts nur bei Warnungen oder Fehlern versendet werden.
- Es wurde bestätigt, dass Betreffzeile und E-Mail-Inhalt dem gewünschten Format entsprechen (nur eine Zusammenfassung, keine Detaillisten).

Die Entwicklung des [Skripts](https://git.b-net.cloud/Clients/neveling/src/branch/develop-AG-2025/00216/scripts/anonymize/adressermittlung-anonymize-data.py) ist abgeschlossen. Die folgenden Tests wurden erfolgreich auf der Testumgebung `bnet005` durchgeführt, um die Funktionalität, Sicherheit und das Reporting des Skripts zu validieren. **1. Verifizierung der Geschäftslogik** - [x] **Unterscheidung der Kundenarten bestätigt:** Es wurde verifiziert, dass Transaktionen von Einmalkunden durch eine vorhandene `inquiry_id` eindeutig identifiziert werden, während Transaktionen von Portalkunden eine `inquiry_id` von `NULL` aufweisen. - [x] **Analyse der Customer Journey bestätigt:** Es wurde bestätigt, dass die Customer Journey eines Benutzers als Einmalkunde beginnen und später, in die eines registrierten Portalkunden übergehen kann. Dies validiert den Ansatz des Skripts, die Anonymisierung auf der Ebene der einzelnen Transaktion (`inquiry_id`) durchzuführen, anstatt auf der Ebene des Kundenkontos. - [x] **Logik für Rabattaktionen bestätigt:** Das potenzielle Risiko wurde untersucht, dass die Anonymisierung von E-Mail-Adressen die Rabattlogik für Viel-Anfrager beeinträchtigen könnte. Eine detaillierte technische Analyse der Customer Journey hat ergeben, dass die Rabattfunktion an das permanente Portalkonto (`customer` Tabelle) gebunden ist und nicht an eine simple Zählung von E-Mails in der `inquiry`-Tabelle. Da das Skript ausschließlich Einmalanfragen (`inquiry_id IS NOT NULL`) anonymisiert und niemals die `customer`-Stammdaten berührt, ist sichergestellt, dass die Geschäftsregel für Rabatte nicht beeinträchtigt wird. **2. Tests der Skriptfunktionalität und -sicherheit** - [x] **Dry-Run-Modus:** Der `--dry-run` Schalter wurde erfolgreich getestet. Das Skript hat alle Zieldatensätze korrekt identifiziert, ohne Änderungen an der Datenbank vorzunehmen. - [x] **Korrektheit der Live-Anonymisierung:** - Ein "Vorher-Nachher"-Vergleich von spezifischen Zieldatensätzen wurde durchgeführt. - Es wurde bestätigt, dass nach einem Live-Lauf die personenbezogenen Daten in allen drei Ziel-Tabellen (`riser_order`, `payment` und `inquiry`) korrekt auf `NULL` gesetzt wurden. - [x] **Integrität der Portalkundendaten (Regressionstest):** - Datensätze in der `payment`-Tabelle mit `inquiry_id IS NULL` wurden vor und nach dem Live-Lauf abgefragt. - Es wurde bestätigt, dass die Daten dieser Portalkunden zu 100% unberührt blieben, was eine zentrale Sicherheitsanforderung erfüllt. - [x] **Integrität der PDF-Archiv-Verknüpfung:** - Der `hash` eines anonymisierten `inquiry`-Datensatzes wurde erfolgreich ausgelesen. - Mit diesem Hash wurde die zugehörige PDF-Datei auf dem Server gefunden. Dies bestätigt, dass die Verknüpfung zwischen Datenbank und Dateiarchiv intakt bleibt. - [x] **Transaktionssicherheit:** - Es wurde bestätigt, dass das Skript eine "Alles-oder-nichts"-Datenbanktransaktion verwendet. - Im Fehlerfall wird die gesamte Transaktion per Rollback zurückgesetzt, sodass die Datenbank in einem konsistenten Zustand verbleibt. **3. Tests des Reportings und der Benachrichtigungen** - [x] **Konsolenausgabe:** Die finale Skriptversion zeigt wie gewünscht einen sauberen Fortschrittsbalken an und gibt am Ende nur eine einzige Statuszeile aus. Fehler werden während der Ausführung dezent gemeldet. - [x] **Log-Datei-Erstellung:** Es wurde verifiziert, dass das Skript eine detaillierte, täglich erweiterte Log-Datei im korrekten Format und am spezifizierten Ort (`/var/log/...`) anlegt. - [x] **E-Mail-Benachrichtigungen:** - Die Funktionalität des `mail`-Befehls auf dem Server wurde bestätigt. - Es wurde verifiziert, dass E-Mail-Alerts _nur_ bei Warnungen oder Fehlern versendet werden. - Es wurde bestätigt, dass Betreffzeile und E-Mail-Inhalt dem gewünschten Format entsprechen (nur eine Zusammenfassung, keine Detaillisten).

mrouissi commented

2025-06-20 19:28:21 +02:00

Author

Owner

Skript-Abhängigkeiten

Die folgenden Pakete sind auf dem Server (bnet005 und wfweb012) erforderlich, damit das Anonymisierungsskript korrekt funktioniert.

1. Python-Pakete
Diese sollten mittels pip innerhalb der aktivierten virtuellen Umgebung (venv) des Skripts installiert werden.

mariadb: Für die Verbindung zur MariaDB-Datenbank.
tqdm: Zur Anzeige des sauberen, visuellen Fortschrittsbalkens.

Installationsbefehl:

pip install mariadb tqdm

2. System-Pakete

Diese werden vom Betriebssystem (Debian) benötigt und sollten via apt installiert werden. Sie stellen die notwendigen Werkzeuge zur Erstellung der Umgebung, zum Kompilieren der Python-Pakete und zum Versenden von E-Mail-Benachrichtigungen bereit.

• python3-venv: Ermöglicht die Erstellung von virtuellen Python-Umgebungen.
• build-essential: Stellt essenzielle Compiler und Werkzeuge (wie gcc) bereit, die zum Kompilieren von Software benötigt werden.
• libmariadb-dev: Die C-Connector-Entwicklungsdateien für MariaDB, die zum Kompilieren des mariadb Python-Pakets erforderlich sind.
• python3-dev: Die Python-3-Entwicklungsdateien (Python.h), die ebenfalls zum Kompilieren des mariadb-Pakets benötigt werden.
• mailutils: Stellt das mail-Kommandozeilenprogramm zur Verfügung, das für den Versand von E-Mail-Alerts verwendet wird.

Installationsbefehl:

sudo apt update && sudo apt install python3-venv build-essential libmariadb-dev python3-dev mailutils

#### Skript-Abhängigkeiten Die folgenden Pakete sind auf dem Server (`bnet005` und `wfweb012`) erforderlich, damit das Anonymisierungsskript korrekt funktioniert. **1. Python-Pakete** Diese sollten mittels `pip` innerhalb der aktivierten virtuellen Umgebung (`venv`) des Skripts installiert werden. * `mariadb`: Für die Verbindung zur MariaDB-Datenbank. * `tqdm`: Zur Anzeige des sauberen, visuellen Fortschrittsbalkens. **Installationsbefehl:** ```bash pip install mariadb tqdm ``` **2. System-Pakete** Diese werden vom Betriebssystem (Debian) benötigt und sollten via `apt` installiert werden. Sie stellen die notwendigen Werkzeuge zur Erstellung der Umgebung, zum Kompilieren der Python-Pakete und zum Versenden von E-Mail-Benachrichtigungen bereit. • `python3-venv`: Ermöglicht die Erstellung von virtuellen Python-Umgebungen. • `build-essential`: Stellt essenzielle Compiler und Werkzeuge (wie `gcc`) bereit, die zum Kompilieren von Software benötigt werden. • `libmariadb-dev`: Die C-Connector-Entwicklungsdateien für MariaDB, die zum Kompilieren des `mariadb` Python-Pakets erforderlich sind. • `python3-dev`: Die Python-3-Entwicklungsdateien (`Python.h`), die ebenfalls zum Kompilieren des `mariadb`-Pakets benötigt werden. • `mailutils`: Stellt das `mail`-Kommandozeilenprogramm zur Verfügung, das für den Versand von E-Mail-Alerts verwendet wird. **Installationsbefehl:** ```bash sudo apt update && sudo apt install python3-venv build-essential libmariadb-dev python3-dev mailutils ```

mrouissi commented

2025-06-20 19:58:15 +02:00

Author

Owner

Produktions-Deployment-Plan für `wfweb012`

Beschreibung der Vorgehensweise zur sicheren Inbetriebnahme des Anonymisierungsskripts in der Produktionsumgebung.

Phase 1: Vorbereitung der Produktionsumgebung

1. Datenbank-Backup

Erstellen eines vollständigen Backups der Produktionsdatenbank wf10501_live. Dies ist die wichtigste Sicherheitsmaßnahme für den Fall eines unerwarteten Problems.

mariadb-dump  wf10501_live > /root/bkp/wf10501_live_backup_$(date +%F).sql

2. Skript und Umgebung übertragen

Installation aller System- und Python-Abhängigkeiten, wie im Dokument Skript-Abhängigkeiten beschrieben.

System-Pakete:

sudo apt update && sudo apt install python3-venv build-essential libmariadb-dev python3-dev mailutils

Python-Pakete:

# Zuerst die virtuelle Umgebung erstellen und aktivieren
cd /usr/local/src/anonymizer
python3 -m venv venv
source venv/bin/activate

# Dann die Pakete installieren
pip install mariadb tqdm

3. Datenbankbenutzer und Berechtigungen einrichten

Erstellen des dedizierten Datenbankbenutzers auf der Produktionsdatenbank.
Vergeben der korrekten Berechtigungen für alle drei Tabellen in der wf10501_live Datenbank.

-- In MariaDB als root-Benutzer ausführen
CREATE USER 'anonymizer'@'localhost' IDENTIFIED BY 'xxx';

GRANT SELECT, UPDATE ON wf10501_live.riser_order TO 'anonymizer'@'localhost';
GRANT SELECT, UPDATE ON wf10501_live.payment TO 'anonymizer'@'localhost';
GRANT SELECT, UPDATE ON wf10501_live.inquiry TO 'anonymizer'@'localhost';

FLUSH PRIVILEGES;
EXIT;

Phase 2: Sicherer Test und erste Live-Ausführung

1. Finaler Sicherheitscheck: Dry Run in der Produktion

Aktivieren der virtuellen Umgebung: source /usr/local/src/anonymizer/venv/bin/activate
Ausführen des Skripts mit dem --dry-run Schalter. Dies ist der letzte Sicherheitscheck, um zu sehen, welche Datensätze betroffen wären, ohne reale Änderungen vorzunehmen.

python anonymize_data.py --dry-run

Überprüfung der Konsolenausgabe. Es sollte ein Fortschrittsbalken und ein finaler Bericht mit der Anzahl der gefundenen Datensätze angezeigt werden.

2. Erste Live-Ausführung

Bei erfolgreichem Dry Run: Ausführung des Skripts zum ersten Mal im Live-Modus.

python anonymize_data.py

Überprüfung der Konsolenausgabe und der neu erstellten Log-Datei in /var/log/adressermittlung_anonymization/, um den erfolgreichen Abschluss zu bestätigen. Der Status sollte "COMPLETED SUCCESSFULLY" sein.

Phase 3: Automatisierung (Cronjob)

1. Cronjob einrichten

Öffnen der Crontab zur Bearbeitung: crontab -e
Hinzufügen der folgenden Zeile, um das Skript wöchentlich ( am Samstag - nach dem klassischem Update, um 01:05 Uhr nachts) automatisch auszuführen.

5 1 * * 6 /usr/local/src/anonymizer/venv/bin/python /usr/local/src/anonymizer/anonymize_data.py

### Produktions-Deployment-Plan für `wfweb012` Beschreibung der Vorgehensweise zur sicheren Inbetriebnahme des Anonymisierungsskripts in der Produktionsumgebung. #### Phase 1: Vorbereitung der Produktionsumgebung ##### 1. Datenbank-Backup - [x] Erstellen eines vollständigen Backups der Produktionsdatenbank `wf10501_live`. Dies ist die wichtigste Sicherheitsmaßnahme für den Fall eines unerwarteten Problems. ```bash mariadb-dump wf10501_live > /root/bkp/wf10501_live_backup_$(date +%F).sql ``` ##### 2. Skript und Umgebung übertragen - [x] Installation aller System- und Python-Abhängigkeiten, wie im Dokument `Skript-Abhängigkeiten` beschrieben. **System-Pakete:** ```bash sudo apt update && sudo apt install python3-venv build-essential libmariadb-dev python3-dev mailutils ``` **Python-Pakete:** ```bash # Zuerst die virtuelle Umgebung erstellen und aktivieren cd /usr/local/src/anonymizer python3 -m venv venv source venv/bin/activate # Dann die Pakete installieren pip install mariadb tqdm ``` ##### 3. Datenbankbenutzer und Berechtigungen einrichten - [x] Erstellen des dedizierten Datenbankbenutzers auf der Produktionsdatenbank. - [x] Vergeben der korrekten Berechtigungen für alle drei Tabellen in der `wf10501_live` Datenbank. ```sql -- In MariaDB als root-Benutzer ausführen CREATE USER 'anonymizer'@'localhost' IDENTIFIED BY 'xxx'; GRANT SELECT, UPDATE ON wf10501_live.riser_order TO 'anonymizer'@'localhost'; GRANT SELECT, UPDATE ON wf10501_live.payment TO 'anonymizer'@'localhost'; GRANT SELECT, UPDATE ON wf10501_live.inquiry TO 'anonymizer'@'localhost'; FLUSH PRIVILEGES; EXIT; ``` #### Phase 2: Sicherer Test und erste Live-Ausführung ##### 1. Finaler Sicherheitscheck: Dry Run in der Produktion - [x] Aktivieren der virtuellen Umgebung: `source /usr/local/src/anonymizer/venv/bin/activate` - [x] Ausführen des Skripts mit dem `--dry-run` Schalter. Dies ist der letzte Sicherheitscheck, um zu sehen, welche Datensätze betroffen wären, ohne reale Änderungen vorzunehmen. ```bash python anonymize_data.py --dry-run ``` - [x] Überprüfung der Konsolenausgabe. Es sollte ein Fortschrittsbalken und ein finaler Bericht mit der Anzahl der gefundenen Datensätze angezeigt werden. ##### 2. Erste Live-Ausführung - [x] Bei erfolgreichem Dry Run: Ausführung des Skripts zum ersten Mal im Live-Modus. ```bash python anonymize_data.py ``` - [ ] Überprüfung der Konsolenausgabe und der neu erstellten Log-Datei in `/var/log/adressermittlung_anonymization/`, um den erfolgreichen Abschluss zu bestätigen. Der Status sollte "COMPLETED SUCCESSFULLY" sein. #### Phase 3: Automatisierung (Cronjob) ##### 1. Cronjob einrichten - [x] Öffnen der Crontab zur Bearbeitung: `crontab -e` - [x] Hinzufügen der folgenden Zeile, um das Skript wöchentlich ( am Samstag - nach dem klassischem Update, um 01:05 Uhr nachts) automatisch auszuführen. ```bash 5 1 * * 6 /usr/local/src/anonymizer/venv/bin/python /usr/local/src/anonymizer/anonymize_data.py ```

mrouissi commented

2025-06-20 20:56:42 +02:00

Author

Owner

966bbf8d8c

- 966bbf8d8c78126a660bb243fc4f297868b1f65b

mrouissi commented

2025-06-20 21:09:12 +02:00

Author

Owner

Das Skript muss auch in der Lage sein, die Daten von Leads zu anonymisieren, deren payment-Status canceled ist.

Das Skript muss auch in der Lage sein, die Daten von Leads zu anonymisieren, deren `payment`-Status `canceled` ist.

Rows
Columns

Automatisierte Anonymisierung von Daten der Einmalkunden #18

Skript-Abhängigkeiten

Produktions-Deployment-Plan für wfweb012

Phase 1: Vorbereitung der Produktionsumgebung

1. Datenbank-Backup

2. Skript und Umgebung übertragen

3. Datenbankbenutzer und Berechtigungen einrichten

Phase 2: Sicherer Test und erste Live-Ausführung

1. Finaler Sicherheitscheck: Dry Run in der Produktion

2. Erste Live-Ausführung

Phase 3: Automatisierung (Cronjob)

1. Cronjob einrichten

Produktions-Deployment-Plan für `wfweb012`