Datenschutzrechtliche Aspekte einer Jobsteuerung

[Manfred Mauermann]

Hallo zusammen,
mal ein völlig untechnischer Diskussionspunkt. Durch unseren geplanten Upgrade auf die 12.1 und einer damit verbundenen In-House Schulung bin ich dummerweise zwischen die hausinternen Bürokratiemühlsteine geraten und soll mich zu datenschutzrechtlichen Auswirkungen des Upgrades bzw. von UC4 insgesamt äußern.
Da wir ca. 90% unserer IT-Prozesse über UC4 steuern und in Form von File-Transfers sowieso alle Arten von Daten von A nach B bewegen (und auch Archivieren), fällt genau genommen eh alles darunter.

Durfte sich von euch auch schon jemand mit dem Thema beschäftigen und wie kann man damit, außer mit Fluchtgedanken, sinnvoll umgehen?

Beispiel einer Anmerkung:
Werden keinerlei Mitarbeiterdaten von Mitarbeitern des Unternehmens verarbeitet? Bitte trennen zwischen 1) mitarbeiterbezogene- und/oder mitarbeiterbeziehbare Daten von Mitarbeitern als Anwender/User des Systems und 2) sonstigen mitarbeiterbezogenen- und/oder mitarbeiterbeziehbaren Daten, die in den zugrundeliegenden Systemen liegen.

Ich will endlich wieder mal ein paar Workflows entwickeln! Kaum hat man eine Software 10 Jahre am laufen, erregt man Aufmerksamkeit. (-> Bitte kurzes Beispiel ergänzen, damit Funktionsweise einer Jobsteuerung auch dem Laien verständlich wird.)

Aber letztlich auch wieder irgendwie spannend......

Viele Grüße
Manfred

[Anon Anon]

Hallo Manfred,

Ah, ich sehe grad, wir arbeiten in der gleichen Branche :-)

Bei uns sind die jeweiligen Abteilungen für sowas verantwortlich und dürfen (müssen) das gemeinsam mit der hausinternen Security klären/machen/definieren.

lg Wolfgang

[Manfred Mauermann]

Hallo Wolfgang,

das mit den Abteilungen dachte ich bis vor kurzem auch noch, dass das bei uns ähnlich wäre. Wurde aber nun eines besseren belehrt. Was mir der Teamleiter vom Buchungssteam dazu berichtete, trug auch nicht wirklich zu meiner Entspannung bei, er hatte ein halbes Jahr "Spaß" mit den geforderten Auskünften. Ich lach mich ja kaputt, wenn der Upgrade dadurch verzögert wird....
Ich laß euch teilhaben  :)

lg Manfred

[Carsten Schmitz]

Hi Manfred.

Ja, das hat uns vor ein, zwei Jahren auch mal ereilt, und aktuell mit der neuen Datenschutzverordnung wieder. Du musst dazu wissen, wir (mein Kollege und ich) sind die Admins für den UC4 Server, aber UC4 wird von ca. 50 Leuten aus diversen Fachabteilungen nach absolut eigenem Gutdünken benutzt. Über diese Anwender haben wir auch keine oder nur marginale Weisungsbefugnis (jepp, das ist genauso schlecht, wie es sich anhört ;) )

Wir haben uns damals mit dem firmeneigenen Anwalt beraten und ich habe meinen Ansatz durchgedrückt, den er tatsächlich rechtlich abgesegnet hat. Der da lautet:

Unser Einsatz von UC4 ist der einer Middleware. Das heisst, ähnlich wie ein Sharepoint oder Wiki ist es uns als UC4-Server-Betreibern unmöglich, alle personenbezogenen Daten zu verantworten oder überhaupt zu kennen, die irgendwie durch z.B. JOBFs gehen. Daher liegt die Verwantortung für sämtliche personenbezogenen Daten in der Verantwortung derer, die diese Jobs im System verantworten. D.h. z.B. bei der SAP-Gruppe, die diese Daten eh in ihrem System (SAP) verantwortet und mit UC4 lediglich transportiert trägt die Verantwortung für diese pers.bez. Daten.

Im Server selbst sind somit lediglich die UC4 User-Accounts, die wir aber nicht als personenbezogenes Datum ansehen, und u.U. noch ein weiterer Stolperstein, nämlich personenbezogene Daten in Reports (wenn z.B. jemand eine Personalakte in einen Report dumpen würde, denn da steht ja alles drin was irgendwie and "stdout" ging). Und das stünde dann in der DB und wir wären dafür in der Verantwortung. Das umgehen wir, indem wir alle Bestandbenutzer retroaktiv, und alle Neubenutzer per Unterschrift zu einem Passus wie diesem verpflichtet haben: "Es ist untersagt, personenbezogene Daten jedweder Art in UC4 Reports zu verwenden."

Hth, Grüße,
Carsten

[Manfred Mauermann]

Hi Carsten,

herzlichen Dank für diesen perfekt ausformulierten Lösungsansatz, den ich mal so aufs Spielfeld bringen werde. Meine Gedanken gingen zuletzt auch in diese Richtung, das war aber tatsächlich nur recht grob.

Ich halte euch auf dem laufenden.

Viele Grüße
Manfred

[Manfred Mauermann]

Hallo zusammen,

im Moment habe ich tatsächlich Ruhe, hoffentlich verschreie ich das nun nicht

Der Vollständigkeit halber und für den Fall, dass es auch andere interessiert, hänge ich auch noch unsere leicht abgewandelte und auf unsere Situation angepasste Fassung hier mit an. Wir haben tatsächlich nicht so viele User, in erster Linie Entwickler, Betrieb und unseren Service-Provider, der in QSU und PROD unser verlängerter Arm ist. Wir haben lediglich in den Entwicklungsumgebungen Vollzugriff. Fachbereiche haben keinen Zugriff auf das System. Ausgewählte Application Manager dürfen gucken. Es läuft alles automatisiert ab, manuelle Jobstarts sind die Ausnahme und i.d.R. nur bei Entstörungen erforderlich.

Der Einsatz von UC4 ist der einer Middleware. Das heißt, ähnlich wie ein SharePoint oder Wiki ist es dem UC4-Team/Betreiber unmöglich, alle personenbezogenen Daten zu verantworten oder überhaupt zu kennen, die irgendwie durch die Verarbeitungsprozesse gehen. Daher kann die Verantwortung für sämtliche personenbezogenen Daten nur in den dafür relevanten Systemen (eCA, SAP, KYC, Ratenkauf, etc.), liegen. D.h., wenn z.B. personenbezogene Daten von der eCA per DAP (Datenaustauschplattform) übertragen werden, trägt die eCA-Gruppe die Verantwortung für diese personenbezogenen Daten.

Im Server selbst sind somit lediglich die UC4 User-Accounts, die aber nicht als personenbezogenes Datum anzusehen sind.

Ein weiterer Punkt sind personenbezogene Daten in Job-Reports (wenn z.B. Personendaten über stdout in einen Report ausgegeben werden), dann wird das in der Datenbank gespeichert. Dem wird vorgebeugt, indem alle Entwickler angehalten sind, dass keinerlei sensible Daten im Job-Report erscheinen dürfen. Dies wird im Test sorgfältig geprüft und im laufenden Betrieb permanent überwacht.

lg, Manfred

[Tim Quakulinsky]

Hallo zusammen,

 

auch die Benutzer-Accounts im Automic-System können, abgesehen von Name und E-Mailadresse, personenbezogene Daten beinhalten: Wenn nicht explizit deaktiviert, werden alle Benutzer-Sessions aufgezeichnet (siehe UC_STATISTIC_OPTIONS). Diese Daten könnten also ausgewertet werden, um zu ermitteln wie "aktiv" ein User war bzw. von wann bis wann er gearbeitet hat. Zumindest unser Betriebsrat hat sich dafür interessiert aber letzten Endes auch abgesegnet, da der Zugriff auf diese Daten nur durch uns Automic-Administratoren erfolgen kann (also eine stark eingeschränkte Gruppe).

 

In der Version 12.1 sehe erachte ich zusätzlich das Widget "Benutzer-Aktivitäten" im AWI als kritisch, da hier jeder sehen kann wann welcher Benutzer was mit dem System gemacht hat, z.B. Objekte angelegt, geändert, gelöscht oder Kommentare einer Ausführung hinzugefügt. Die Darstellung dieser Daten für alle Automic-Benutzer ist eventuell aber nur begrenzt mit dem deutschen Bundesdatenschutzgesetz in Einklang zu bringen. Allerdings ist auch der praktische Nutzen je nach Nutzung des Automic-Systems fragwürdig, da auch automatisierte Änderungen durch Scriptsprachmittel angezeigt werden. Dies kann sicherlich als „Ausrede“ für z.B. den Betriebsrat genutzt werden.

Viele Grüße aus dem Münsterland

Tim

[Manfred Mauermann]

Hallo Tim,

 

Danke für die gute Ergänzung, ich hatte gestern wieder div. Abstimmungen zu dem Thema, dabei ging es tatsächlich rein um mitarbeiterbezogene bzw. mitarbeiterbeziehbare Daten und einer möglichen Leistungskontrolle, was durch unseren Betriebsrat bewertet werden soll.

Letztlich haben wir die grundsätzliche Möglichkeit einer techn. Auswertung bejaht, denke mal, hier muss man bei jedem System mit Benutzeraccounts das Kind beim Namen nennen, aber auch die Absicht verneint, das zu tun. Begründung war zum einen der Aufwand und die Sinnhaftigkeit des Ergebnisses. Klar, das ist alles Auslegungssache. Aber ich brauche ja auch im Fehlerfall eine nachvollziehbare Änderungshistorie für eine vernünftige Analyse. Selbst in unserem Wiki haben wir eine Änderungsübersicht, wer was wann und warum getan hat.

Hatte dabei auch angemerkt, dass ich aus unserem Intranet deutlich mehr Mitarbeiter-Daten beziehen kann, als aus unserem System.

Werde mir aber zu dem Thema sicher demnächst das Benutzer-Widget ansehen, bei uns wird gerade die 12.1-Testdatenbank wiederhergestellt, die hatte ich wohl durch das Einspielen eines 11.2-er TKs zerschossen.

 

Viele Grüße aus der Erstliga-Stadt Nürnberg

Manfred

[Carsten Schmitz]

Hallo Tim,

 

welches Widget meinst Du bitte genau? Ist das Widget Teil einer "Vanilla" Installation, meinst Du das unter "Process Automation" -> Aktivitäten im Widget-Dialog?

 

Ich kann damit zumindest bei mir nichts sehen, was nicht auch per Statistiken sichtbar wäre. Eventuell müsste man da tatsächlich die Frage aufwerfen, ob auch Statistiken DSGVO-kritisch sind (dann müsste man wohl in logischer Konsequenz die User auf allgemein anerkanntem Band-Aid-Niveau anonymisieren ... good bye Schmitz/UC4, Hallo V&sR)bv76!k/UC4 ...

 

Vg

[Tim Quakulinsky]

Hinweis: Automic hat das Benutzer-Widget inzwischen geändert, sodass nur mehr die Aktivitäten des eingeloggten Benutzers sichtbar sind und nicht alle Aktivitäten (siehe Kommentar von Robert Thullner vom 18.02.2019).