Wer wird die Wächter selbst bewachen?

Oder quis custodiet ipsos custodes wie die Römer sagen würden. Wenn Sie jemandem das Recht einräumen, Gewalt gegen Straftaten anzuwenden oder private Daten einzusehen, um Verbrechen aufzudecken, wie können Sie sicherstellen, dass er sein Schutzrecht zur Verbrechensbekämpfung nicht missbraucht? Sie beauftragen jemand anderen, sie zu überwachen. Aber wie stellt man sicher, dass diese Personen im erlaubten Rahmen bleiben? Eine Rekursion wird schnell zu einem Problem, und auf einer bestimmten Ebene muss man den Menschen vertrauen. Es gibt einfach nicht genug Wächter für uns alle.

Mit Gutgläubigkeit oder Vertrauen kommen wir hier nicht weiter. Wenn Sie Menschen Zugang zu einer der weltgrößten Datenbanken für vermeintlich private Daten und Nachrichten geben, werden einige von ihnen ihren Zugang missbrauchen, um zum Beispiel Ehepartner, Ex-Partner oder andere Liebesinteressen auszuspionieren. Dies geschah bei der US-Sicherheitsbehörde NSA oft genug, so dass man der Datenbank einen Codenamen gab: LOVEINT. Auch Kollegen, Verwandte und Prominente können Zielscheiben sein. Vergleichbare Missbräuche sind auch anderswo dokumentiert worden. Diejenigen, die mit der Beaufsichtigung von Menschen in solchen Berufen beschäftigt sind, müssen diesen traurigen Aspekt der menschlichen Natur zur Kenntnis nehmen und aktiv nach Verstößen und Möglichkeiten suchen, sie zu verhindern. Damit stellt sich natürlich in erster Linie die Frage nach der Ethik der Datenerhebung.

Vertrauen, aber auch überprüfen

Vertrauen Sie Ihren Mitarbeitern/Kollegen? Dies ist die falsche Frage. Die richtige Frage ist, wie sehr vertrauen Sie ihnen? Vertrauen Sie darauf, dass sie niemals Fehler machen? Unwahrscheinlich, denn errare humanum est. Ein Grund warum wir Haltegriffe und Sicherheitsgurte haben. Vertrauen Sie darauf, dass sie Ihre Kundendatenbank nicht an den Meistbietenden im Dark Web verkaufen? Hoffentlich, aber das bedeutet nicht, dass Sie nicht vorsichtig sein sollten, wem Sie welche Daten anvertrauen und wie Sie ihnen nachgehen. Доверя́й, но проверя́й oder Vertraue, aber überprüfe, wie das russische Sprichwort sagt.

Die Allgemeine Datenschutzverordnung der EU (DSGVO) beschreibt die Rolle des Datenschutzbeauftragten - jemand, der für den Datenschutz in einer Organisation verantwortlich ist. Wenn Sie mit oder in der EU/dem EWR zu tun haben, benötigen Sie wahrscheinlich einen solchen Beauftragten. In jedem Fall kann man eine Menge lernen, wenn man sich über die Datenschutzverordnung informiert: Es ist ratsam, die Datenerhebung zu minimieren, denn was nicht erhoben wird, kann nicht durchsickern. Ferner ist es sinnvoll, die Zahl der Personen, die Zugang zu den Daten haben, zu minimieren, denn das verringert die Wahrscheinlichkeit, dass einer von ihnen trotz guter Absichten einen verhängnisvollen Fehler begeht.

Wie können wir dies mit der eZ Platform erreichen?

Datenschutz in eZ Platform 

eZ Platform ist sofort einsatzfähig und bietet vier Benutzerrollen: Anonym (diejenigen, die sich nicht angemeldet haben), Mitglied (registrierte Benutzer), Redakteur und Administrator. Redakteure können Inhalte veröffentlichen, und Administratoren haben jegliche Zugriffsrechte. Sollten Sie feststellen, dass Ihre Redakteure nicht über die erforderlichen Berechtigungen verfügen, könnte man ihnen ebenfalls Administratorrechte erteilen. Aber mit dieser erweiterten Befugnis geht ebenfalls eine große Verantwortung einher. Daher ist es am besten, diese Berechtigung so wenigen Personen wie möglich zu gewähren. Sicherer ist es, die Rollen zu differenzieren.

Erfreulicherweise ist das Berechtigungssystem in eZ Platform sehr flexibel. Wir können so viele Rollen definieren, wie notwendig sind. Wir können Benutzern oder Benutzergruppen Rollen zuweisen, und wir können sie bedingt auf der Grundlage des jeweiligen Inhalts zuweisen. Wir können sogar Berechtigungen übertragen, indem wir vernetzte Benutzergruppen verwenden. Im Folgenden möchte ich ein datenschutzfreundliches Rollensetup skizzieren, das etwas differenzierter ist als die Standardeinstellung und auf dem Need-to-know-Prinzip sowie gängigen Anwendungsfällen basiert.

Ziele

1. Teilen Sie keine Passwörter, auch nicht die des ursprünglichen Administrator-Benutzers. Pflegen Sie separate, benannte Benutzerkonten. Ordnen Sie Benutzer in Gruppen ein, weisen Sie ihnen Rollen zu und gewähren Sie ihnen Zugriff. Auf diese Weise ist es einfach, den Zugriff zu überprüfen und zu widerrufen und Benutzeraktionen zu verfolgen.
2. Die Zahl der Administratoren sollte sehr gering sein und sorgfältig geprüft werden. Berücksichtigen Sie den Bus-Faktor, aber beachten Sie, dass bei Verlust des Administrator-Zugriffs dieser mit Hilfe von Skripten wie diesem wiederhergestellt werden kann.
3. Möglicherweise benötigen Entwickler während der anfänglichen Entwicklung mehr Zugriffsrechte als nach der Live-Schaltung. Stellen Sie sicher, dass Sie nicht benötigte Rechte ebenfalls widerrufen. Prüfen Sie auch, wer direkten Zugriff auf die Benutzeroberfläche und/oder die Datenbank hat, und widerrufen Sie diese Rechte, wenn immer dies möglich oder notwendig ist.
4. Fragen Sie nicht nach Daten, die Sie nicht benötigen. Was nicht gespeichert ist, kann nicht weitergegeben werden. Wenn Sie annehmen, dass Sie später vielleicht mehr Daten benötigen, fragen Sie erst dann danach, nicht bereits jetzt. Wenn Sie sie nicht mehr brauchen, löschen Sie sie. Informieren Sie den Benutzer darüber, was Sie speichern und warum.  
5. Geben Sie keinen Zugang zu externen Benutzerdaten an diejenigen, die diese nicht benötigen. Entwickler brauchen sie nicht, sie können Dummy-Benutzerkonten zum Testen verwenden. Redakteure brauchen diese sicherlich ebenfalls nicht. Der Datenschutzbeauftragte hingegen kann sie benötigen, ebenso wie der Support für Benutzer.
6. Bewahren Sie die Abgrenzung zwischen internen und externen Benutzern. Die Personalabteilung sollte für interne Benutzer verantwortlich sein, so wie der Datenschutzbeauftragte für externe Benutzer zuständig ist.

Im äußersten Fall sollten Sie den Verzicht auf Administratoren in Erwägung ziehen. Administratoren haben von vornherein Zugriff auf sämtliche Inhalte, einschließlich der Benutzerdaten. Dennoch ist es durchaus möglich, eine Webseite ohne solche vollwertigen Administratoren zu betreiben, wenn Sie für die erforderlichen Verwaltungsaufgaben Unteradministratorenrollen entwerfen. Bedenken Sie, dass der ursprüngliche Administrator-Benutzer vom System benötigt wird und nicht entfernt oder deaktiviert werden sollte. Allerdings könnten Sie ihm ein komplexes Passwort geben, das Sie im Firmen-Safe einschließen oder nirgends speichern (wenn Sie den Zugang wiederherstellen müssen, siehe Ziel 2).

Zu beachten ist außerdem, dass die Rolle des Redakteurs standardmäßig keinen Zugriff auf Benutzerdaten gewährt, obwohl er Zugriff auf das Backend und eine Content/* Richtlinie hat. Dies liegt an der Einschränkung in der Baumstruktur und der Media Root innerhalb eZ Platform - nicht der User Root, was vorteilhaft ist und so belassen werden sollte.

Beispiel Benutzergruppe/Rollenstruktur

Die Benutzergruppen sind kursiv, die Rollen fett hervorgehoben.

• Administratoren/ Administrator - Voller Zugang. Könnte bis auf den ursprünglichen Administrator-Benutzer leer sein, siehe oben. Wenn Sie ihn jedoch verwenden, verwenden Sie separate Konten pro Administrator.
• Sub-Administratoren / Sub-Administrator - Haben Zugriff auf bestimmte administrative Funktionen, aber nicht auf andere Benutzer. 
• Human Resources/ Human Resources - Haben Zugang zu allen Benutzergruppen außer Administratoren und externen Benutzern. Können beispielsweise neuen Mitarbeitern Zugang gewähren und Ex-Mitarbeitern den Zugang entziehen. (Dies könnte stattdessen in die Rolle des Sub-Administrators integriert werden, um die Gruppenkomplexität zu minimieren).
• Editors/ Editor - Kann zum Beispiel Inhalte erstellen, aber nicht veröffentlichen.
  • Chief Editors/ Chief Editor - Übertragen Sie die Bearbeiterrolle. So können z.B. Inhalte genehmigt und veröffentlicht werden.
• Developers/ Developer - Zugriff auf Dummy-Benutzer, aber nicht auf externe Benutzer.  Rolle des Redakteurs und Chefredakteurs sind möglich, sowie administrative Rechte nach Bedarf. Widerrufen Sie nicht benötigte Berechtigungen/Zuweisungen, bevor Sie live gehen. (Könnte stattdessen in die Rolle des Sub-Administrators integriert werden, um die Komplexität der Gruppe zu minimieren).
• Data Protection Officer/ Data Protection Officer - Voller Zugang zu externen Benutzern.
• External users/ External user - Für niemanden außer dem Datenschutzbeauftragten einsehbar.
  • Premium users/ Premium user - Zusätzliche Privilegien, z.B. zahlende Abonnenten. Übertragung der externen Benutzerrolle.
• Dummy users/ External user - Dieselben Berechtigungen wie externe Benutzer.
  • Premium users/ Premium user - Gleiche Berechtigungen wie externe Premium-Benutzer. 
• Anonymous users/ Anonymous - Enthält nur den anonymen Benutzer, welcher verwendet wird, wenn man nicht angemeldet ist.

In der Dokumentation zu Rollen und Richtlinien erfahren Sie, wie Sie das von Ihnen benötigte Setup entwerfen können. Haben Sie Fragen oder Feedback? Bitte teilen Sie mir dies im Abschnitt "Kommentare" mit - vielen Dank.

Weitere Datenschutz-Methoden

Die DSGVO schlägt diverse Methoden zur Gewährleistung des Datenschutzes vor, schreibt aber keine von ihnen ausdrücklich vor. Eine Möglichkeit ist die Pseudonymisierung: wenn persönlich identifizierbare Informationen durch gefälschte Daten ersetzt werden, z.B. wenn ein Name durch John Doe ersetzt wird, aber so, dass die Originalinformationen von denjenigen, die den richtigen Legitimationsschlüssel besitzen, wiederhergestellt werden können. Eine andere Möglichkeit ist die Verschlüsselung, über die ich bereits kurz geschrieben habe. Diese Themen möchte ich in zukünftigen Blogbeiträgen im Zusammenhang mit eZ Platform und der DSGVO betrachten.

Vergessen Sie in der Zwischenzeit bitte nicht unsere Richtlinien für das sichere Melden von Sicherheitsproblemen in Produkten und gehen Sie dem auch bei anderen Anbietern nach.