DSGVO in SAP S/4HANA Projekten
S/4HANA

Serie: DSGVO in SAP S/4HANA Projekten

Teil 2: Datenschutz realisieren: Do – Check – Act!

Nachdem wir uns im ersten Blog „DSGVO in SAP-HANA Projekten“ mit den Voraussetzungen beschäftigt haben, geht es in diesem Teil um die Umsetzung (Do), die regelmäßige Kontrolle (Check) und darum, wie Sie die Erkenntnisse daraus in Maßnahmen umsetzen sollten (Act). Denn Datenschutz ist kein Projekt, sondern ein gelebter Prozess, der ständigen Änderungen unterlegen ist.

Die Umsetzung (Do)

Nach der Analyse geht es an die Umsetzung der Planung. Neben den üblichen Fachanforderungen sollten Sie ein paar Datenschutz-Anforderungen im Augen behalten, um nicht nachher im Tagesgeschäft Schwierigkeiten zu bekommen.

An erster Stelle steht dabei das Berechtigungskonzept in SAP. Da S/4HANA kein schlichtes Upgrade ist, sondern eine neue Technologie, scheinen Berechtigungen im ersten Blick gleich zu bleiben. Im zweiten Blick wird allerdings deutlich, dass sie technisch völlig anders aufgebaut sind. Ein gängiger Fehler ist es, die alten Rollen zu übernehmen und nur ein wenig anzupassen. Das führt dazu, dass die Berechtigungen im Projekt nicht ausreichend beachtet werden.

Da die Berechtigungen nicht mehr transaktional, sondern Serviceberechtigungen sind, kann man sie nicht mehr über die GUI-Oberfläche aufrufen, sondern ruft einen Frontend-Server auf. Der Frontend-Server hat die Verbindung zum Fiori Launchpad. Dieses nimmt die Anforderungen entgegen und stellt die Verbindung zum Backend her. Das Backend ist dann die eigentliche S/4HANA.

Ein häufiger Fehler ist, dass Unternehmen ihre alten Rollen in die S/4HANA zufügen und mit Sternchen versehen, damit alles läuft, anstatt neue Rollen hinzuzufügen. Ein weiterer Fallstrick besteht darin, dass höchstwahrscheinlich das „alte“ Berechtigungskonzept aus der Zeit vor der DSGVO existiert – ein weiterer Grund, unter Datenschutzgesichtspunkten das Berechtigungskonzept neu zu entwickeln und dessen Wirksamkeit zu überprüfen. Das neue Berechtigungskonzept ist ein wichtiger Baustein in der SAP-Sicherheit und darf nicht unterschätzt werden.

Sperren und Löschen im SAP

Die DSGVO schreibt vor, dass pbD* gelöscht werden müssen, wenn der Zweck der Erhebung entfallen ist. Es sei denn, die Daten unterliegen einer Aufbewahrungsfrist oder ein Löschen ist aus technischen Gründen nicht möglich. In diesen Fällen sind die Daten zu sperren.

Für das vorschriftsmäßige Sperren und Löschen der Daten werden im SAP-System die Archivierungs-Funktionen und das SAP ILM (Information Lifecycle Management) genutzt.

Dabei ist zu beachten, dass das

  • Sperren der Bewegungsdaten nur via Datenarchivierung möglich ist.
  • Sperren der Stammdaten über SAP-ILM-Reports nur bei abgeschlossenen Bewegungsdaten durchführbar ist.
  • Löschen archivierter Daten sowie nicht archivierte / gesperrte Stammdaten mittels SAP ILM löschbar sind.

Pseudonymisierung und Verschlüsselung

Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und des Risikos für die betroffenen Personen und dessen Eintrittswahrscheinlichkeit sind nach Art. 32 DSGVO geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Einen Vorschlag zur Erreichung eines angemessenen Schutzniveaus hat die Verordnung aber auch zu bieten: die Pseudonymisierung. Artikel 25 der EU-DSGVO beschreibt, dass die Pseudonymisierung vor allem hilft, den Datenschutzgrundsatz “Datenminimierung” wirksam umzusetzen und somit die Rechte der betroffenen Personen zu schützen. Die gute Nachricht: Pseudonymisierung eignet sich hervorragend, um Risiken wie Insider-Bedrohungen oder die Auswirkungen von Datenabflüssen sowie unerlaubten Zugriffen und Einsichtnahmen zu reduzieren – egal ob es sich um personenbezogene oder andere sensible Unternehmensdaten handelt. Hier sollte man frühzeitig im Planungs- und Entwicklungsprozess prüfen, an welchen Stellen eine Pseudonymisierung möglich ist.

Bei der Verschlüsselung sind im Projekt die unterschiedlichen Verschlüsselungsebenen und -möglichkeiten zu untersuchen. Von der Verschlüsselung auf Betriebssystem-Ebene, über die Verschlüsselung der Datenbank-Inhalte bis hin zu einer Verschlüsselung auf Applikationsebene oder einer benutzer- / rollenabhängigen Verschlüsselung.

Verfügbarkeit und Belastbarkeit

Dies betont die DSGVO ausdrücklich. Belastbarkeit (Resilienz) bedeutet in diesem Zusammenhang die Widerstandsfähigkeit der IT-Systeme im Fehlerfall, bei Störungen, bei hoher Beanspruchung.

Mangelnde Belastbarkeit der IT-Systeme wirkt sich indirekt auch auf die Verfügbarkeit der Daten aus.

Der Check (Prüfung)

Beim Check der IT-Security sind die umgesetzten Regeln, die vergebenen Berechtigungen und neuen DSGVO Prozesse regelmäßig zu prüfen und idealerweise in einem Datenschutzbericht zum Nachweis des Datenschutzmanagements zu dokumentieren.

Weitere Bereiche, die aus Datenschutzsicht einer regelmäßigen Prüfung und Awareness unterliegen sollten, sind:

  • SAP-System Konfiguration
  • Schnittstellensicherheit
  • Patchmanagement
  • Logging
  • Faktor Mensch

Gerade letzterer Punkt sollte mit regelmäßigen Datenschutz- und Security-Schulungen unterstützt werden.

Aus Datenschutzsicht sind ebenfalls die Prozesse für Auskunfts-, Widerspruchs- und Korrekturrechte der Betroffenen frühzeitig zu prüfen. Denn hier gibt es für die Betroffenenrechte Zeit- und Formvorschriften in der DSGVO, wonach vollständig und richtig beantwortet werden muss. Ansonsten drohen Bußgelder bis 20. Mio. € oder 4 % des Jahres-Weltumsatzes der Unternehmensgruppe wegen Missachtung der Rechte der betroffenen Person.

Ein Augenmerk sollte auf das Auskunftsrecht gelegt werden, insbesondere wenn die betroffene Person eine elektronische Kopie ihrer Daten wünscht. Hier muss unterschieden werden, was muss und was kann beauskunftet werden und was unterliegt dem Geschäftsgeheimnis.

Act (Erkenntnisse in Verbesserungen umsetzen)

Erkannte Schwachstellen oder neue Anforderungen sind im ACT-Zyklus mit konkreten Maßnahmen zu hinterlegen. Danach wird mit diesen Erkenntnissen der Zyklus mit der Planung neu gestartet und anschließend im DO-Zyklus im System umgesetzt.

Fazit

Nicht nur wegen drohender hoher, abschreckender Sanktionen, sondern auch wegen möglicher Reputationsschäden, sollten Unternehmen frühzeitig die Anforderungen des Datenschutzes im HANA-Projekt berücksichtigen. Denn… „Vor-Sicht ist günstiger als Nach-Sicht“.

Anmerkung:

  • *pbD = personenbezogene Daten

Fragen, Feedback und Kommentare zu diesem Beitrag senden Sie bitte an r.vgehlen@acent.de

Roland von Gehlen | 05.08.2020

Ähnliche Beiträge

Mehr laden
Mehr laden
Weniger anzeigen