Anonymisierung der Daten

Grundlagen

Bei der Anonymisierung unterscheiden sich prinzipiell zwei Anwendungsfälle:

Die Daten sollen an CURSOR oder einen Partner von CURSOR weiter gegeben werden, damit auf dieser Datenbasis Fehler reproduziert werden können
Die Daten sollen DSGVO-Konform in ein Entwicklungs- bzw. Abnahme-System eingespielt werden

Folgende Ziele sollen nun erreicht werden:

die Verlagerung des Tools auf den Server
die Verarbeitung der Daten als Massendaten-Updates sowie die Ausführung dieser Statements in einzelnen Transaktionen
die Konfiguration der Anonymisierung (Vorzugsweise über die Metadaten der Anwendung)
sicherstellen, dass die Anonymisierung auf einer Datenbank-Kopie erfolgt

Konfiguration der Einstellungen der Anonymisierung

Die Konfiguration ist von CURSOR vorbelegt.
- Es können nur Entitäten mit Bewegungsdaten anonymisiert werden.
- Daten, die als Customizing, Intern oder System gekennzeichnet sind, bleiben erhalten, da diese in beiden Szenarien benötigt werden.
- Schlüsselfelder und Primärschlüssel können nicht anonymisiert werden (Beispiel: ein Nachschlagefeld auf einen Geschäftspartner)
Die Konfiguration von Bewegungsdaten kann vom Kunden-Administrator verändert werden.
Insbesondere kann der Administrator
- Entitäten von der Anonymisierung ausschließen
- Felder von der Anonymisierung ausschließen
- Es existieren zwei PropertyMapper-Einträge
  einer um die maximale Textlänge der zu anonymisierenden Felder zu definieren
  einer um die ersten n Zeichen der Texte zu erhalten (performancekritisch)
Die redundanten Felder in basierender Person und Geschäftspartner werden gleich gezogen, wenn beide anonymisiert werden.

Start der Anonymisierung

Über den Windows-Client kann mit dem Aufruf in der CMD-Umgebung im bin-Verzeichnis des Windows-Clients
POWERSHELL
```
run anonymization
```
eine GUI geöffnet werden, die sich zunächst am produktiven System anmeldet, sowie die Datenbank-Verbindung zur zu anonymisierenden Datenbank herstellt.
Die Verbindung zur zu anonymisierenden Datenbank gilt als erfolgreich, wenn geprüft wurde, dass
- Die Datenbank nicht identisch zur angemeldeten Datenbank über die GUI ist
- Die Version, die in der Datenbank beinhaltet ist, vom gleichen Stand ist, wie die angemeldete Version
- Die Datenbank nicht als produktive Datenbank konfiguriert ist
Die Anonymisierung kann auch über eine Automation ohne GUI gestartet werden
POWERSHELL
```
run anonymization <db username> <db password> <db jdbc-url> <crm user> <crm password>
```
Die Verbindung zur zu anonymisierenden Datenbank gilt als erfolgreich, wenn geprüft wurde, dass
- Die Datenbank nicht identisch zur angemeldeten Datenbank über die GUI ist
- Die Version, die in der Datenbank beinhaltet ist, vom gleichen Stand ist, wie die angemeldete Version
- Die Datenbank nicht als produktive Datenbank konfiguriert ist
- Bei der jdbc-url ist zu beachten, dass dort ; durch {SEMICOLON} und = durch {EQUALS} ersetzt werden muss. An diesen beiden Zeichen werden in Batch-Dateien die Parameter auseinander geschnitten. Ohne diese Ersetzung ist ein Aufruf nicht möglich.
Eine Datenbank gilt als nicht produktive Datenbank, wenn im PropertyMapper-Eintrag mit der
id = '/de/cursor/jevi/server/system/SystemInfo$!!$Systemtype'
nicht der Wert 'production system' eingetragen ist.

Spezielle Logik für natürliche / juristische Personen

Wichtigste Unterschiede:

Auch bei den Mitarbeitern greift die Logik bzgl. natürlicher / juristischer Person.
Hintergrund der Umstellung: Die Verarbeitung der natürlichen Personen ist jetzt durchgängig für alle Rollen (GP, AP, Mitarb.) gleich. Eine Ausnahme für den Mitarbeiter halten wir nicht für den Standard sinnvoll. Zudem würde dies die Komplexität erhöhen und Laufzeit negativ beeinträchtigen.
Es wurden weitere Felder wie Kurzname, Anrede und Unterschrift berücksichtigt.

Einleitung:
Die Namen und Vornamen von natürlichen Personen müssen anonymisiert werden. Bei juristischen Personen ist dies nicht erforderlich und soll zur besseren Nachvollziehbarkeit nicht erfolgen (z.B. für Tests im Testsystem). Die Unterscheidung erfolgt über den Typ (Herr (H), Frau (F), Divers (D) oder Unternehmen (U)) auf den Entitäten Person, Geschäftspartner und Ansprechpartner. H, F, D sind natürliche Personen. U ist eine juristische Person. Das projektindividuelle Flag (C2IsPrivPerson.Customer) wird hierbei nicht beachtet.

Person:

Die Feldeigenschaft „Datenanonymisierung“ wird für die Felder Name1-3 und MatchCode in der Person aktiviert. Diese Felder werden in die Geschäftspartner-, Ansprechpartner- und Mitarbeiterrollen delegiert. Bedeutet die Werte stehen physikalisch nur in der Person und nicht in den Rollen. Werden diese in der Person anonymisiert, sind diese automatisch in der Rolle ebenfalls anonymisiert.
Bei natürlicher Person (Typ: H, F, D): Nachname, Vorname, Zusatz, Kurzname wird anonymisiert.
Bei juristischer Person (Typ U): Firma, Zusatz1, Zusatz2, Kurzname wird NICHT anonymisiert.

Geschäftspartner:

Die Feldeigenschaft „Datenanonymisierung“ wird für die Felder Name1-3 (Nachname/Firma, Vorname/Zusatz1, Zusatz/Zusatz2) und MatchCode (Kurzname) im Customer aktiviert. Dies sind nicht die delegierten Felder aus der Person, sondern zusätzliche Felder im GP parallel zu den delegierten Feldern aus der Person.
Für diese Felder, würden die Werte aus der basierenden Person übernommen werden.

Ansprechpartner:

Im AP sind die Felder Nachname/Firma, Vorname/Zusatz1, Zusatz/Zusatz2 und Kurzname ausschließlich aus der Person delegiert. Wird also die basierende Person anonymisiert, sind die Felder im AP automatisch mit anonymisiert.
Im AP gibt es zusätzlich die Felder Anrede (Salutation.ContactPerson) und Briefanrede (LetterSalutation.ContactPerson). Diese würden ebenfalls in Abhängigkeit zum Typ bei natürlichen Personen anonymisiert werden und bei juristischen Person nicht.

Mitarbeiter:

Im Mitarbeiter sind die Felder Name, Vorname und Kurzname ausschließlich aus der Person delegiert. Wird also die basierende Person anonymisiert, sind die Felder im AP automatisch mit anonymisiert.
Das Kürzel (Login) würde nicht anonymisiert werden. Damit könnte der Mitarbeiter noch identifiziert werden.
Im Mitarbeiter selber gibt es zusätzlich die Felder Anrede (Salutation.Employee) und Briefanrede (LetterSalutation.Employee) und Unterschrift (Signature.Employee) in denen die Namen enthalten sind.
Bei diesen Feldern sehen wir nicht die Notwendigkeit diese bei juristischen Personen nicht zu anonymisieren, da es in der Regel keine Mitarbeiter vom Typ U (juristisch) gibt. Falls gewünscht ist dies natürlich möglich. In diesem Fall bitten wir um einen entsprechenden Hinweis.
Werden diese Felder im Mitarbeiter nicht zum Anonymisieren gekennzeichnet, kann man hier ebenfalls wie beim Kürzel sehen, wer es ist.

Allgemein für die Entitäten Person, Geschäftspartner und Ansprechpartner:
Alle anderen Felder auf den oben genannten Entitäten werden unabhängig vom Natürlicher- oder Juristischer-Person anonymisiert wenn die Feldeigenschaft „Datenanonymisierung“ entsprechend gesetzt ist. Die Logik ist an das Feld JurisitcPerson.PersonType gebunden.

Die Funktionalität kann mit dem PropertyMapper-Eintrag aktiviert werden. Eine weitere Voraussetzung ist, dass die Felder überhaupt anonymisiert werden sollen (dies ist die Standard-Einstellung dieser Felder).

Oracle

SQL

INSERT into PropertyMapper (Pk, id, property, propertyType, principal, Active, CreateUser, UpdateUser, CustLayer, CreateDate, UpdateDate, propertyValue) 
VALUES ('AnonymizationHandler$!!$keepJuristicPersons', '/de/cursor/jevi/server/admin/anonymization/AnonymizationHandler$!!$keepJuristicPersonNames', '', 'SYSTEM', '', 1, 'TECH_USER', 'TECH_USER', 'CN', sysdate, sysdate, 'true') ;

MS-SQL

SQL

INSERT into PropertyMapper (Pk, id, property, propertyType, principal, Active, CreateUser, UpdateUser, CustLayer, CreateDate, UpdateDate, propertyValue) 
VALUES ('AnonymizationHandler$!!$keepJuristicPersons', '/de/cursor/jevi/server/admin/anonymization/AnonymizationHandler$!!$keepJuristicPersonNames', '', 'SYSTEM', '', 1, 'TECH_USER', 'TECH_USER', 'CN', getdate(), getdate(), 'true') ;