verschlüsselte Daten mit mehreren Personen teilen

[Klaus1]

Hallo,

ich habe folgendes Problem. Ein Abteilungsleiter soll vertrauliche Daten hochladen können. Dabei sollen alle Daten verschlüsselt werden (Die Daten selber, der Zeitpunkt des Hochladens und auch der Abteilungsleiter, der hochgeladen hat)

Diese Daten sollen aber nun von verschiedenen Stellen wieder entschlüsselt werden können:

• Der Abteilungsleiter selber nur seine eigenen Daten
• Der Vorgesetzte alle Daten, die von einem seiner Mitarbeiter hochgeladen wurden, für die er verantwortlich ist
• Der Chef generell von allen Personen

Weiteres Problem: Beim Wechsel einer Verantwortlichkeit (Vorgesetzte wechselt), müsste der neue auch auf die bisherigen Daten zugreifen können.

Ich kenne zwar eine einfache Verschlüsselung (Benutzer nutzt ein selbstgewähltes Passwort, bin dem die Daten ver-und entschlüsselt werden) und ich kenne Verschlüsselungen mit privatem und öffentlichen Schlüssel, bei dem die öffentlichen Schlüssel jeweils ausgetauscht werden müssen. Aber wie kann das mit mehr als zwei Personen funktionieren? Und auch noch wechselnde Personen?

Die Daten müssen in jedem Fall schon komplett unleserlich in der Datenbank gespeichert sein, damit auch Administratoren die daten nicht aus der Tabelle lesen können.

Wie könnte man so etwas umsetzen? Gibt es hierfür vielleicht Beispiele?

LG Klaus

[Felix Riesterer]

Lieber Klaus1,

Ein Abteilungsleiter soll vertrauliche Daten hochladen können. Dabei sollen alle Daten verschlüsselt werden (Die Daten selber, der Zeitpunkt des Hochladens und auch der Abteilungsleiter, der hochgeladen hat)

das klingt dermaßen verschwurbelt, dass die Idee aus dem Dunstkreis von Schule zu kommen scheint. Liege ich da richtig?

Diese Daten sollen aber nun von verschiedenen Stellen wieder entschlüsselt werden können:

Für mich klingt das danach, dass man da eine Webapplikation baut, die intern für sich einen Schlüssel verwaltet, der zum Ver- und Entschlüsseln der Daten benutzt wird. Außerdem verwaltet sie Benutzerkonten. Benutzer können Daten hochladen und wieder herunterladen. Die notwendige Verschlüsselung beim Speichern, sowie die Entschlüsselung beim Herunterladen (oder auch Anzeigen der Metainfos) übernimmt die Applikation.

Weiteres Problem: Beim Wechsel einer Verantwortlichkeit (Vorgesetzte wechselt), müsste der neue auch auf die bisherigen Daten zugreifen können.

Wenn die Verschlüsselungen nicht mit dem Benutzerpasswort, sondern mit einem in der Applikation hinterlegten Schlüssel erfolgen, ist das kein Problem.

Die Daten müssen in jedem Fall schon komplett unleserlich in der Datenbank gespeichert sein, damit auch Administratoren die daten nicht aus der Tabelle lesen können.

Das wird schwierig. Wenn es da Administratoren gibt, können die auf alles zugreifen. Wenn der gemeinsame Schlüssel für die Admins nicht erreichbar sein darf, dann darf er auch nicht auf dem Server gespeichert werden.

Warum dürfen die Admins die Daten nicht einsehen können?

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

Warum dürfen die Admins die Daten nicht einsehen können?

Weil ein Admin nicht die Person ist, der Du vertrauliche Daten anvertraust.

BOFH

Nein, wirklich. Viele Admin-Aufgaben werden heutzutage outgesourced. Irgendwohin. Gerne nach Spanien, Rumänien oder Indien.

Ein DMS für vertrauliche Daten sollte für den technischen Betreiber keinesfalls eine scheunentorgroße Hintertüre haben. Selbst ein Zertifikatspeicher, der nur mit der User-ID der DMS-Anwendung gelesen werden kann, ist nicht sicher. Soviel willst Du deinem Admin nicht bezahlen müssen, dass er unbestechlich ist.

Rolf

[Klaus1]

Hallo Felix,

das klingt dermaßen verschwurbelt, dass die Idee aus dem Dunstkreis von Schule zu kommen scheint. Liege ich da richtig?

Nein, einfach ein "ganz normales" Industrieunternehmen, nur eben mit Kollegen mit verrückten Ideen.

Die Daten müssen in jedem Fall schon komplett unleserlich in der Datenbank gespeichert sein, damit auch Administratoren die daten nicht aus der Tabelle lesen können.

Das wird schwierig. Wenn es da Administratoren gibt, können die auf alles zugreifen. Wenn der gemeinsame Schlüssel für die Admins nicht erreichbar sein darf, dann darf er auch nicht auf dem Server gespeichert werden.

Für einen für jeden Benutzer individuellen Passwortresor habe ich es so gelöst, dass der Mitarbeiter ein Masterkennwort eingibt, das nicht gespeichert wird. Mit diesem verschlüsselt er seine eigentlichen Passwörter. Wenn er sein Masterpasswort vergisst, sind die Daten nicht mehr (in sinnvoller Zeit) zu retten. Aber der Admin kann auch nichts mehr sehen.

Bei zwei Leuten funktioniert es auch, wenn sie sich das Masterpasswort austauschen, aber mit mehreren Leuten und unterschiedlichen Berechtigungen klappt das nicht mehr.

Mit privatem Schlüssel und n öffentlichen Schlüsseln der jeweils Berechtigten ist es auch schwierig. Vorallem wenn einer wechselt.

Warum dürfen die Admins die Daten nicht einsehen können?

Im aktuellen Fall soll es bspw. um Gehälter gehen. Und die gehen auch den Admin nichts an.

LG Klaus

[JürgenB]

Hallo Klaus,

warum nimmst du kein NAS? Über die Nutzerrechte kannst du einstellen, wer welchen Share Beschreiben oder Lesen darf.

Gruß
Jürgen

[TS]

Hello Jürgen,

warum nimmst du kein NAS? Über die Nutzerrechte kannst du einstellen, wer welchen Share Beschreiben oder Lesen darf.

Es ist leicht verständlich, dass Klaus Bedarfe sich nicht mit einer ein- bis zweidimensolalen Rechtematrix erledigen lassen, sondern dass die außerdem

• Historienverwaltung
• Meldesysteme
• Workflowmanagement
• Groupware-Funktionalitäten
• ...

benötigen.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Klaus1,

Für einen für jeden Benutzer individuellen Passworttresor habe ich es so gelöst

Das Schlüsselmanagement ist immer ein Problem. Sobald sie wiederherstellbar sein sollen, sind sie angreifbar. Verwendest Du KeePass? Dort kannst Du die kdbx-Datei an ein Masterpasswort, eine Schlüsseldatei (die man z.B. auf mehrere USB Sticks legen kann) oder auch an die angemeldete Windows-User-ID binden (KeePassX für Linux kann die User-Bindung nicht).

Gefahr besteht bei Eigenbauten immer, wenn man selbst kein Sicherheitsexperte ist. Es gibt Standardsoftware für sowas, und in einem Unternehmen sollte das Geld dafür auch da sein. Ich habe eben mal nach "Dokumentenmanagementsystem vertraulich" gesucht, und auch Produkte gefunden. Die muss man dann evaluieren, und ggf. Experten suchen, die wirksame Medizin von Schlangenöl unterscheiden können. Man muss Anforderungen formulieren und dann auf dem Markt schauen, wer das erfüllt. Eventuell bindet man eine Unternehmensberatung ein. In einem Forum kann man natürlich fragen, aber eine verantwortungsvolle Entscheidung braucht mehr.

Rolf

[Rolf B]

Hallo Klaus1,

Beim Wechsel einer Verantwortlichkeit (Vorgesetzte wechselt), müsste der neue auch auf die bisherigen Daten zugreifen können.

Verschlüsselung für mehrere Personen bedeutet normalerweise, dass das Dokument mit einem symmetrischen Hauptschlüssel gesichert wird und dieser Hauptschlüssel dann einzeln mit den öffentlichen Schlüsseln der beabsichtigten Empfänger verschlüsselt wird. Bei 100 Empfängern habe ich dann also ein verschlüsseltes Dokument und 100 kleine Schlüsselpäckchen, die daran hängen. Der Hauptschlüssel ist pro Dokument einmalig, man bestimmt ihn mit einem kryptographisch sicheren Zufallszahlengenerator.

Wenn ein neuer Mitarbeiter Zugriff auf bestimmte Dokumente bekommen soll, muss jemand, der eins von diesen Päckchen öffnen kann, all diese Dokumente durchgehen und ein neues Schlüsselpäckchen für den neuen Mitarbeiter anhängen. Bei der Gelegenheit sollte er dann auch das Schlüsselpäckchen des alten Chefs eliminieren.

Vermutlich gibt es diverse Tools, die sowas auf Dateiebene lösen. Ich muss zugeben: das war bisher keine Aufgabe, die ich lösen musste, und ich bin darin nicht erfahren. Mir sagt gnuPG was, aber da ist ein Schwerpunkt auch das Web of Trust - ein Problem, dass man in einem Unternehmen nicht hat. Vielleicht habt ihr ja schon eine eigene PKI im Haus. Bei größeren Dokumentenmengen kann das Hantieren auf Dateiebene lästig werden, ich würde es dann mit einer Datenbank organisieren. Welche Tools Du konkret für AES und RSA nimmst, hängt dann von der Programmierumgebung ab, in der Du hantierst.

Tabelle 1: Dokument-ID, ein paar Metadaten und eine image-Column mit dem verschlüsselten Dokument. Zu den Metadaten sollte auch die Organisationsheit gehören, der dieses Dokument "gehört".

Tabelle 2: Dokument-ID, User-ID, Schlüsselpaket

Tabelle 3: User-ID, öffentlicher Schlüssel dieses Users

Wenn nun User U001 ein Dokument hochlädt, wird es mit einem Zufallskey symmetrisch verschlüsselt. Dieser Zufallskey wird mit den öffentlichen Schlüsseln (aus Tabelle 3) für jeden einzelnen, der Zugang haben soll, in ein Schlüsselpaket gelegt und in Tabelle 2 unter der User-ID des berechtigten Lesers gespeichert. Das kann zum Beispiel der User U005 sein, Chef von U001.

Herr U005 kann nun beim Abruf des Dokuments seinen privaten Schlüssel nutzen, damit den Zufallsschlüssel für das Dokument ermitteln und es so entschlüsseln. Diesen privaten Schlüssel hat er im Kopf, auf einem USB-Stick, auf einer Keycard oder sonst irgendwo, wo er sicher ist. Dieser Aspekt der ganzen Kette birgt die größten Gefahren, weil Schlendrian hier gang und gäbe ist, gerade bei höheren Dienstgraden, und Löcher ins System reißt.

Nun kommt der Tag X und Herr U005 wird durch Frau U006 ersetzt. Nun muss jemand, der ein Schlüsselpaket für die Dokumente von Herrn U005 hat (das kann jeder aus seiner Abteilung sein), die Schlüsselpakete dieser Dokumente öffnen, den Dokumentenschlüssel entnehmen und ein neuen Schlüsselpaket für Frau U006 schnüren. Das sollte vorzugsweise Herr U005 selbst sein, als letzte Amtshandlung, aber rein technisch kann das jeder tun, der auf alle Dokumente von Herrn U005 Zugriff hat. Nachdem nun Herr U005 nicht mehr Chef ist, kann man von den betreffenden Dokumenten sein Schlüsselpaket entfernen.

Kleiner Nachteil der Sache ist noch, dass ein so verpackter Schlüssel voraussetzt, dass die Schlüsselpaare der Anwender sich nicht ändern. Falls nun User U099 meint, sein Schlüssel wäre kompromittiert, dann muss er alle Schlüsselpakete, die ihm gehören, neu schnüren. Wenn das System 10000 Dokumente für ihn enthält, kann das eine Weile dauern.

Ob das sicher ist? Keine Ahnung. Aber wenn ich diesen Auftrag bekäme, wäre das mein Ansatz, mit dem ich zu unserer Security-Abteilung ginge und um Beurteilung bäte (bittete? bitten würde? Konjunktive sind was für Fortgeschrittene...).

Die Alternative ist, dass man seinen Admins vertraut (was man nie tun sollte) und den Dokumentenzugang über ein "vertrauenswürdiges System" regelt. Dokumente sind dann an Hand der Berechtigungen zugänglich, die ein angemeldeter User hat. In der DB können sie verschlüsselt sein, damit nicht jeder DB-Admin das Archiv plündern kann, aber das DBMS muss den Key haben. Wenn man das so macht, ist die Spielerei mit den Schlüsselpaketen nicht nötig, die Sicherheit wird über die Rolle der jeweiligen Person hergestellt. Aber es gibt dann die ständige Backdoor, dass ein Admin den Dokumentenschlüssel ausliest. Hinzu kommt, dass dieser Schlüssel übergreifend und nicht zufällig ist, d.h. wer ihn hat, kommt sofort an alle Dokumente.

Rolf

[TS]

Hello,

ich habe folgendes Problem.

Das haben Tausende Andere hochkarätige Denker auch schon :-O

Ein Abteilungsleiter soll vertrauliche Daten hochladen können. Dabei sollen alle Daten verschlüsselt werden (Die Daten selber, der Zeitpunkt des Hochladens und auch der Abteilungsleiter, der hochgeladen hat)

Diese Daten sollen aber nun von verschiedenen Stellen wieder entschlüsselt werden können:

• Der Abteilungsleiter selber nur seine eigenen Daten
• Der Vorgesetzte alle Daten, die von einem seiner Mitarbeiter hochgeladen wurden, für die er verantwortlich ist
• Der Chef generell von allen Personen

Das eigentliche Thema lautet:

Zugriffsrechte und Verschlüsselungen, sowie Dokumentation in Groupware-Systemen unter Berücksichtigung von Cloud-Speichern.

Das Thema ist schon mindestens 35 Jahre alt (seit Novel Groupwise) und bisher gab es keine öffentliche Lösung dafür.

Wenn Du eine findest, und die nicht rechtzeitig weltweit patentieren lässt, entgehen Dir Millarden. Oder Du findest eine echte mathematisch basierte Lösung dafür und veröffentlichst die wahren Formeln, bevor die NSA oder andere Dienste Zwischenschritte (in die Algorithmen) einbauen lassen können (ähnlich Rubikon).

Generell suchst Du aber augenscheinlich nach einem ganzen System, und nicht nach einer einzelnen (Freeware-)Lösung.

Mein Rat:

Teile die Aufgabe in ihre Teilprobleme, bilde definierte Schnittstellen und lass uns dann nochmal von vorne beginnen ;-P

Glück Auf
Tom vom Berg

[Henry]

Hallo Klaus1,

es stellt sich ja noch die Frage, wie die Daten zu den Personen kommen und in welchem Format. Aber grundsätzlich würde ich bei sowas, sofern hier nicht pentagonmässige Ansprüche vorliegen, dafür ein CMS wie Wordpress nehmen. Das bringt von Haus aus schon einige Nutzereinordnungen/Berechtigungen mit und lässt sich noch stark erweitern.

Einige Links dazu:

https://www.akademie.de/de/wissen/benutzerverwaltung-autoren-wordpress

https://www.df.eu/blog/wordpress-rollen-benutzer-und-berechtigungen-was-sie-beachten-sollten/

Gruss
Henry

[Matthias Apsel]

Hallo Henry,

Klaus1' Anforderungen gehen weit über eine Nutzerverwaltung und eine Software wie Wordpress hinaus.

Bis demnächst
Matthias

[Henry]

Hallo Matthias,

Klaus1' Anforderungen gehen weit über eine Nutzerverwaltung und eine Software wie Wordpress hinaus.

na ja, ich kenne seine Zielvorstellung nicht, Felix vermutet schulisches Umfeld. Aber seine Anforderungen hören sich erst mal so an, als ob sie durchaus mit WP und/oder geeigneten Plugins zu realisieren sind.

Userverwaltung?
WP Basis, Done!

Erweiterte Userverwaltung?
WP + zb. Role Editor, Done!

Besserer Contenschutz?
WP Basis + ContentPasswort, done!

Noch gezielterer Contentschutz?
WP Basis + zb. Page Security & Membership, done!

Encrypted in DB?
WP Basis + zb. Gravitate Encryption, done!

Mit Kombinationen aus verschiedenen Plugins, oder noch besser Eigenentwicklung inspiriert aus den Plugins, lässt sich schon leicht was zusammenstellen.

Gruss
Henry

[Raketenzielsuchsystem]

Henry, da folgt wohl eine Enttäuschung:

Encrypted in DB?
WP Basis + zb. Gravitate Encryption, done!

Das „done“ hat hier wohl eine ganz besondere Bedeutung.

Übersetzte Nachricht des Autors des Plugins:

Sie haben insofern Recht, als das Plugin nicht mehr gepflegt wird. Es funktioniert immer noch, aber wir unterstützen das Hinzufügen oder Aktualisieren von Verschlüsselungsmethoden nicht.

Das war vor 3 Monaten.

[Henry]

Hallo Raketenzielsuchsystem,

Henry, da folgt wohl eine Enttäuschung:

nö.

Encrypted in DB?
WP Basis + zb. Gravitate Encryption, done!

Das „done“ hat hier wohl eine ganz besondere Bedeutung.

Erbsenzählerei?
WP Basis +zb. Gravitate Encryption, done!

Sie haben insofern Recht, als das Plugin nicht mehr gepflegt wird. Es funktioniert immer noch, aber wir unterstützen das Hinzufügen oder Aktualisieren von Verschlüsselungsmethoden nicht.

Das war vor 3 Monaten.

Na und?

Darüber hinaus schrieb ich auch noch: ...oder noch besser Eigenentwicklung inspiriert aus den Plugins...

Gruss
Henry

[Rolf B]

Hallo Henry,

oder noch besser Eigenentwicklung inspiriert aus den Plugins...

Wie ich schon schrieb: Bei Themen mit hohen Security-Anforderungen - Personal und Gehalt gehören dazu - sollte man sehr genau überlegen, ob man einen Eigenbau tatsächlich wagen möchte. Wenn erstmal der Gehaltszettel des Vorstands geleakt wurde, sollte man nicht sagen müssen: Oh, so konnte man das knacken?

Rolf

[Henry]

Hallo Rolf,

Wie ich schon schrieb: Bei Themen mit hohen Security-Anforderungen - Personal und Gehalt gehören dazu - sollte man sehr genau überlegen, ob man einen Eigenbau tatsächlich wagen möchte. Wenn erstmal der Gehaltszettel des Vorstands geleakt wurde, sollte man nicht sagen müssen: Oh, so konnte man das knacken?

da hast du natürlich recht, ist aber fallabhängig. Ein kleine Firma wird sich kaum die nötigen Experten leisten können/wollen und selbst dann wäre das Risiko ja niemals NULL.

Gruss
Henry

[Raketenzielsuchsystem]

Erbsenzählerei?

Nein. Auch keine Anpisserei. Ich wollte aus höchst positiv eigennützigen Gründen nur wissen, was genau und wie das Zeug das versprochene macht und wollte mir, um davon zu lernen, den Quelltext reinziehen. Hab es also in Google eingeworfen.

Naja. Dann kam gleich beim ersten Suchtreffer die obige offiziell, aussehende Nachricht - die jedenfalls für mich ganz klar ein Ausschlusskriterium wäre. Grund: Mit sowas macht man nichts Neues mehr.

[Henry]

Hallo Raketenzielsuchsystem,

Naja. Dann kam gleich beim ersten Suchtreffer die obige offiziell, aussehende Nachricht - die jedenfalls für mich ganz klar ein Ausschlusskriterium wäre.

Das ist ja völlig OK.

Grund: Mit sowas macht man nichts Neues mehr.

Das beträfe aber die Allgemeinheit und da sehe ich das anders. Viele, mich eingeschlossen, nutzen auch noch md5 obwohl nicht mehr absolut sicher, also nicht mehr aktuell. Na und, je nach Anwendung mir sicher genug.

Gruss
Henry

[Raketensprachausgabe]

Im Hinblick auf die zu gebende, inhaltlich richtige Antwort hätte mein Französisch einen wohl eher ungeläufigen Wortschatz.

Deshalb sage ich nichts dazu.

[Rolf B]

Hallo Henry,

Felix vermutet schulisches Umfeld.

Klaus hat "Industrie" nachgelegt.

WP klingt fast gut, aber einer fehlt:

• Kein Zugriff für neugierige Admins

Wir reden hier von einem HR System (Gehälter). Mitarbeiterdaten haben eine besondere Sensibilität. "Industrie" bedeutet ziemlich sicher auch Betriebsrat. Ohne Freigabe durch deren Technikausschuss kann man ein solches Projekt nicht einführen, und die werden, wenn sie was taugen, sehr genau auf solche Punkte schauen. Der Datenschutzbeauftragte des Unternehmens hat da auch mitzureden.

Klaus, wenn ihr keinen BR habt, wird es natürlich einfacher, aber als Mitarbeiter liegt es in deinem Eigeninteresse, auf diesen Punkt zu achten. Und einen DSB habt ihr garantiert, den schreiben DSGVO und BDSG vor. An diesen Stellen vorbei ein Dokumentenmanagementsystem für HR einzuführen wäre fahrlässig.

Rolf

[Klaus1]

Hallo,

wie zuvor kurz schon beschrieben, geht es innerhalb des eigenen Unternehmens um hochsensible Daten eines einzelnen Mitarbeiters, inklusive Workflow. Gedacht ist z.B. ein Antragsformular für Gehaltserhöhungen (damit ist nicht das persönliche Gespräch des Mitarbeiters mit dem Bereichsleiter gemeint, sondern der gesamte Genehmigungsprozess dahinter). Hier sollte klar sein, dass nur der Mitarbeiter selber seine Gehaltsforderung sehen sollte, plus dem Bereichsleiter (der die Anforderung erstellt) plus seinem Vorgesetzten (der genehmigen muss) plus dem Chef seines Vorgesetzten (der doch noch ablehnen kann). Und das sollte (und will) der Admin nicht sehen können.

Mein derzeitiger Wissenstand: praktikabel und sicher geht es wohl nicht.

Aktuell habe ich über die Schwierigkeiten informiert und im Moment übersteigt der Aufwand wohl den Nutzen.

Somit ist das Thema erstmal (hoffentlich) vom Tisch.

Vielen Dank an die fleissigen Denker und Ideengeber. 👍

LG Klaus

[Rolf B]

Hallo Klaus1,

ihr habt ja einen ganz schönen Hierarchenbaum. D.h. ihr seit alles mögliche, aber nicht klein.

Dann habt ihr doch auch garantiert Tools im Haus für HR, DMS oder Prozesssteuerung. Bringen diese Tools nichts mit, worauf man aufsetzen kann? Vielleicht mal beim Hersteller anfragen?

Rolf

[Felix Riesterer]

Lieber Klaus1,

Gedacht ist z.B. ein Antragsformular für Gehaltserhöhungen (damit ist nicht das persönliche Gespräch des Mitarbeiters mit dem Bereichsleiter gemeint, sondern der gesamte Genehmigungsprozess dahinter). Hier sollte klar sein, dass nur der Mitarbeiter selber seine Gehaltsforderung sehen sollte, plus dem Bereichsleiter (der die Anforderung erstellt) plus seinem Vorgesetzten (der genehmigen muss) plus dem Chef seines Vorgesetzten (der doch noch ablehnen kann).

das klingt nach einem typischen Fall von "menschliche Probleme mit technischen Lösungen bewältigen" zu wollen. Menschliche Probleme benötigen menschliche Lösungen keine technischen. Der in diesem Thread diskutierte Ansatz ist in meinen Augen damit der falsche.

Liebe Grüße

Felix Riesterer

[Tabellenkalk]

Hallo,

das klingt nach einem typischen Fall von "menschliche Probleme mit technischen Lösungen bewältigen" zu wollen. Menschliche Probleme benötigen menschliche Lösungen keine technischen. Der in diesem Thread diskutierte Ansatz ist in meinen Augen damit der falsche.

Mit diesem Argument könntest du auch gleich den gesamten Datenschutz ad absurdum führen...

Gruß
Kalk

[Felix Riesterer]

Lieber Tabellenkalk,

Mit diesem Argument könntest du auch gleich den gesamten Datenschutz ad absurdum führen...

nein!

Liebe Grüße

Felix Riesterer

[Christian Kruse]

Hallo Felix,

das klingt nach einem typischen Fall von "menschliche Probleme mit technischen Lösungen bewältigen" zu wollen.

Nein, das denke ich nicht. Die Anforderung, dass nur ein bestimmter Personenkreis in der Lage ist, ein Datum zu betrachten und/oder zu ändern, ist eine ganz essentielle Anforderung, die sich in viel Software wiederfindet und sich oft nur in ihrem Sicherheitsbedürfnis unterscheidet.

Es gibt nicht umsonst Bestrebungen wie SELinux, Verschlüsselung u.ä., die auch dem Admin die Zugriffsmöglichkeiten auf mindestens Teile des Systems bzw der Daten entziehen.

Freundliche Grüße,
Christian Kruse

[Felix Riesterer]

Lieber Christian,

Die Anforderung, dass nur ein bestimmter Personenkreis in der Lage ist, ein Datum zu betrachten und/oder zu ändern, ist eine ganz essentielle Anforderung, die sich in viel Software wiederfindet und sich oft nur in ihrem Sicherheitsbedürfnis unterscheidet.

da will ich Dir auch nicht widersprechen. Ich bin mir auch sicher, dass die Buchhaltung einer Firma was die Lohnzahlungen angeht auch längst digital sein wird und dass es da eine wie auch immer geregelte Lösung gibt, wer da unter welchen Umständen an welche Daten gelangen kann.

Bestrebungen wie SELinux

Alles gut. Aber wenn ich eine Gehaltserhöhung will, dann muss ich mit meinem Chef von Angesicht zu Angesicht oder wenigstens von Ohr zu Ohr reden. Eine Mail, ein Brief oder eine Anforderung in irgend einer App ist dafür meines Erachtens ungeeignet. Schlimm fände ich es, wenn am Ende gar ein Algorithmus über solche Dinge entscheiden dürfte!

Liebe Grüße

Felix Riesterer

[Christian Kruse]

Hallo Felix,

Alles gut. Aber wenn ich eine Gehaltserhöhung will, dann muss ich mit meinem Chef von Angesicht zu Angesicht oder wenigstens von Ohr zu Ohr reden. Eine Mail, ein Brief oder eine Anforderung in irgend einer App ist dafür meines Erachtens ungeeignet. Schlimm fände ich es, wenn am Ende gar ein Algorithmus über solche Dinge entscheiden dürfte!

Ich zitiere nochmal Klaus1:

(damit ist nicht das persönliche Gespräch des Mitarbeiters mit dem Bereichsleiter gemeint, sondern der gesamte Genehmigungsprozess dahinter)

Der direkte Chef muss die verhandelte Gehaltserhöhung weiter reichen and FiBu, HR o.ä., da ist die Verhandlung und die Einwilligung schon lange gelaufen. HR wird die dann auch nicht mehr ablehnen weil sie das verhandeln wollen sondern weil formale Gründe dagegen sprechen und weil es für solche Abläufe immer ein Mehr-Augen-Prinzip gibt.

Das ist kein menschliches Problem, das ist einfach nur ein Absicherungsprozess.

Freundliche Grüße,
Christian Kruse

[Rolf B]

Hallo Felix,

für mich klingt das nach typischer Bürokratie in einem Unternehmen mit mindestens 4 Führungsebenen (genannt wurden Bereichsleiter, Chef, Chefchef, Chefchefchef). Mit so vielen Ebenen würde ich 10K Mitarbeiter oder mehr erwarten. Personalprozesse dieser Bürokratie sollen automatisiert werden. Ich benutze den Plural, weil Klaus ja "z.B. Gehaltsforderungen" schrieb. Dass man sowas nicht per E-Mail lösen möchte, ist nachvollziehbar. Dass man das - vor allem bei einer geographisch verteilten Organisation - nicht mit versiegelter Post tun möchte, auch.

Ein Unternehmen dieser Größe sollte sein Personalsystem aber bereits digitalisiert haben. Aber offenbar haben sie nicht SAP HR, weil es da nämlich sowas wie Employee Self Services gibt (ich bin kein SAPler, aber mein Arbeitgeber verwendet das). Zumindest im Bereich Mitarbeiterjahresgespräche gibt es darin auch eine Form der Prozesssteuerung.

Bevor man handgemachtes Schlangenöl anrührt, sollte man mit seinem SAP-Integrator (oder welches HR System man auch sonst verwendet) reden.

Rolf

[Christian Kruse]

Hallo Rolf,

Bevor man handgemachtes Schlangenöl anrührt, sollte man mit seinem SAP-Integrator (oder welches HR System man auch sonst verwendet) reden.

Bevor man Hände an SAP legt, sollte man die Firma lieber abwickeln…

Freundliche Grüße,
Christian Kruse

[Rolf B]

Hallo Christian,

grins - man muss schon wissen, dass man dabei den Teufel mit dem Beelzebub bekämpft. Und man kann viel falsch machen. Aber auch viel richtig, aus irgendeinem Grund wird in Walldorf ja immer noch Geld verdient, und bei den Integratoren (mein Brüderchen ist so einer) auch.

Rolf

[Felix Riesterer]

Lieber Rolf,

für mich klingt das nach typischer Bürokratie in einem Unternehmen mit mindestens 4 Führungsebenen (genannt wurden Bereichsleiter, Chef, Chefchef, Chefchefchef).

das hat sich mir auch so dargestellt.

Mit so vielen Ebenen würde ich 10K Mitarbeiter oder mehr erwarten.

Ja, die Größenordnung dürfte zutreffend sein.

Personalprozesse dieser Bürokratie sollen automatisiert werden.

Ist das wirklich der richtige Weg? Gerade hier habe ich das Bauchgefühl, dass Automation sich gegen den Menschen richtet.

Ich benutze den Plural, weil Klaus ja "z.B. Gehaltsforderungen" schrieb.

Genau so etwas muss doch zwangsläufig in einem Gespräch zwischen zwei Menschen münden. Wo soll da automatisiert werden? Soll der Mitarbeiter ein Formular ausfüllen und ein Algorithmus entscheidet dann, in welcher Höhe eine Gehaltserhöhung möglich ist?

Die Buchhaltung mit der Lohnauszahlung ist sicherlich schon längst digital. Was soll denn nun noch obendrauf?

Dass man sowas nicht per E-Mail lösen möchte, ist nachvollziehbar. Dass man das - vor allem bei einer geographisch verteilten Organisation - nicht mit versiegelter Post tun möchte, auch.

Wie schon geschrieben erwarte ich hier ein Gespräch zwischen zwei Menschen. Egal ob Telefon oder ViKo oder Präsenz. Ohne ein solches kann ich mir diesen Prozess für dieses Beispiel (Gehaltsforderung) nicht vernünftig vorstellen.

Bevor man handgemachtes Schlangenöl anrührt, sollte man mit seinem SAP-Integrator (oder welches HR System man auch sonst verwendet) reden.

Der war gut. grins

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

Soll der Mitarbeiter ein Formular ausfüllen und ein Algorithmus entscheidet dann, in welcher Höhe eine Gehaltserhöhung möglich ist?

Christian hat darauf ja auch schon geantwortet

Der direkte Chef muss die verhandelte Gehaltserhöhung weiter reichen and FiBu, HR o.ä., da ist die Verhandlung und die Einwilligung schon lange gelaufen.

Ich würde das so ergänzen: das technische System dokumentiert die persönlichen Verhandlungen, Schritt für Schritt. Mitarbeiter und direkter Vorgesetzter handeln was aus und halten das in einem Dokument fest. Vermutlich ist das ein Formular, das unterschrieben werden muss. Ein rein digitales System könnte ein elektronisches Formular verwenden und auf Unterschriften verzichten, aber ein Blechbieger oder Maschinenschrauber von altem Schrot und Korn braucht Zeit, um das zu lernen. Darum sind solche Prozesse häufig noch - zumindest auf unterster Ebene - von Papier begleitet. Und auf höherer Ebene muss man damit rechnen, dass der Direktor Dr. Klöbner sich diese Formulare von seiner Sekretärin ausdrucken lässt, seinen Teil einträgt, abzeichnet und seiner Sekretärin zur technischen Bearbeitung zurückgibt. Die muss das einscannen und an den Vorgang anhängen. Eine rein digitale Bearbeitung scheitert an den Einsprüchen Dr. Klöbners, der Revisionssicherheit und mehr faselt und letztlich nur verhindern will, selbst an den Bildschirm zu müssen, während der Prozessrealisierer Klaus Müller-Lüdenscheid sich an den Kopf fasst.

Rolf

[Raketenwilli]

Hm. So wie ich das lese kann ich mir eigentlich nur zwei Wege vorstellen:

1.)

Ein Server, ein Admin: Die „Datei“ wird für jeden Berechtigtenkreis (Indivuduen, Gruppen) mit dessem öffentlichen Schlüssel (und dem privaten des Erstellers) verschlüsselt und also mehrfach abgelegt. Beim Abholen bekommt jeder Empfänger(kreis) die für ihn verschlüsselte Kopie und kann diese mit seinem (gruppen-) privatem und dem öffentlichen Schlüssel des Erstellers entschlüsseln.

Nachteil: Viel Speicherplatz wird benötigt. Neuverschlüsselung bei Rechtwechseln.

Ich habe hier einen Überblick (FAQ) zu PKI gefunden - das wäre in einer Windows-Domain wohl das Mittel der Wahl.

2.)

Zwei Server, zwei, sich „spinnefeinde“ Admins:

A) Jede „Datei“ wird mit einem individuellen shared key verschlüsselt auf einem Server („Fileserver“) abgelegt.

B) Der Key auf einem zweitem Server („Keyserver“) mit einem anderen Admin. Hierbei (oder später) wird fest gelegt, wer was darf.

C) Beim Zugriff authentifiziert sich der Benutzer gegenüber dem Fileserver. Der Fileserver authentifiziert sich gegenber dem Keyserver, übermittelt den Benutzer, bekommt dann den Key (oder nicht ...) - und entschlüsselt die Datei (vergisst den Key) , gibt sie in eine Pipe, verschlüsselt diese für den Transport und liefert sie aus.

Brennpunkte bei Variante 2 wäre neben der Zusammenarbeit der Admins (Einer hat die Schlüssel, der andere das verschlüsselte Zeug) wohl die Pipe (da ist ein Datenstrom mit Klartext im Arbeitsspeicher) und der geholte Key (der muss auch im Arbeitsspeicher sein, den der Fileserver-Admin überwachen könnte). Außerdem könnte der FilserverAdmin auch in die Programme eingreifen.

In jedem Fall findet sich der Klartext als Datei oder im Arbeitsspeicher auf den Client-Rechnern (oder, wenn die Homeverzeichnisse auf einem Filseserver liegen, dort). Klar kann man das auch verschlüsseln - aber in der Konsequenz ist der Admin des Clients halt der Admin… und der könnte das für die Betrachtung benötigte Programm, sogar den Webbrowser gegen eine von ihm benötigte Version austauschen.

In jedem Fall wird es bei genügend bösem Wille einen potentiellen Bypass geben.