„Ups, habe ich gelöscht.“ – Sinn und Zweck eines Berechtigungskonzepts
Früher (als ich noch jung und voller Erwartungen war) durfte ich einen ähnlichen Satz einmal live erleben. Ich war Teil eines kleinen Teams, das mit einem speziellen dateibasierten Tool arbeitete. Die Dateien lagen auf einem für alle zugänglichen Laufwerk. Jeder konnte in dieser Umgebung auf alle Dateien und Verzeichnisse der Kollegen zugreifen; und diese natürlich auch löschen.
Erwischt! Jemand hat einfach etwas gelöscht, was er nicht löschen durfte.
In einem der größten Projekte, das sich über mehrere Monate hinzog und an dem alle in Teamarbeit beteiligt waren, ertönte eines Tages die Stimme meines Teamchefs ein wenig kleinlaut, ein bisschen verschmitzt:
“Äh, Marianne*, ich glaube, ich habe gerade deine ganzen Arbeitsverzeichnisse gelöscht.”
Stille. Wir schauten uns an.
Schließlich meinte die betroffene Kollegin etwas außer Atem: „Was?“
Um solche Schreckensmomente zu vermeiden, ist es sinnvoll, genau festzulegen, wer welche Dateien und Verzeichnisse öffnen darf, neue anlegen oder bearbeiten kann sowie – Sie ahnen es – wer welche löschen kann. Dafür eignet sich die Einrichtung eines Berechtigungskonzepts. Auch in objectiF RPM, unserer Application Lifecycle Management-Lösung, sowie im Requirements Engineering-Tool objectiF RM wird ab Version 4.3 bzw. 5.3 solch ein Berechtigungskonzept integriert sein. Ich möchte es Ihnen heute vorstellen.
*: Name wurde geändert.
Was ist ein Berechtigungskonzept?
In einem Berechtigungskonzept bzw. Rechtekonzept legen Sie Regeln für den Zugriff auf Dateien, Ordner oder Laufwerke in einem IT-System für einzelne Benutzer oder Gruppen fest. Zugriff umfasst u.a. das Lesen, Schreiben, Ausführen oder Löschen von Dateien. Wenn Sie z.B. Windows als Betriebssystem nutzen, dann haben Sie möglicherweise einen normalen Nutzer, über den Sie die alltägliche Arbeit erledigen. Außerdem gibt es einen administrativen Nutzer, der z.B. der Installation neuer Software explizit zustimmen muss. Oder für alle GNU/Linux-Fans unter uns: Sudo oder nicht sudo, das ist hier die Frage [1].
In Unternehmen werden Zugriffsrechte in der Regel nach Rollen, die die Mitarbeiter einnehmen, verteilt. Systemadministratoren haben so z.B. andere Rechte als Entwickler; und Entwickler können wiederum nicht alle Daten der Personalabteilung einsehen.
Warum sind Zugriffsrechte notwendig?
Sofern ein sicheres Backup-System eingerichtet ist, stellt sich ein Fall wie oben skizziert weniger problematisch dar. Daten können aber nicht nur durch ein unzureichendes Berechtigungskonzept gelöscht werden. Auch der Zugriff und die Ansicht auf spezielle Daten muss für alle Personen klar definiert sein, damit sie z.B. nicht einfach unbemerkt geheime Informationen einsehen oder weitergeben können. Das Stichwort der Insider-Bedrohung fällt immer häufiger; und diese besteht meistens nicht wegen Böswilligkeit der Mitarbeiter, sondern, so der Data Breach Investigation Report (DBIR) 2018 von Verizon, weil Menschen einfach Fehler machen: Es werden z.B. Dokumente oder E-Mails an die falschen Personen gesendet [2].
Rechtemanagement ist daher ein wesentlicher Bestandteil des Risikomanagements. Aber es bietet ebenfalls den bedeutenden Vorteil, die Arbeit von allen Beteiligten zu erleichtern. Denn zu viele Informationen, die man sehen oder bearbeiten kann, können auch überfordern – schließlich braucht man sie gar nicht für die eigene Funktion im Unternehmen oder auch im Projekt.
Überblick über das Rechtekonzept in objectiF RPM und objectiF RM
In objectiF RPM und RM können Sie zukünftig für Organisationen oder Projekte Zugriffsrechte vergeben sowie für einzelne Ordner, Sichten, Aktivitäten und Abfragen. Die Zugriffsrechte umfassen: anzeigen, lesen, schreiben, anlegen, löschen und den Zustand von Elementen ändern. Sie definieren Zugriffsrechte für einzelne Nutzer oder Nutzergruppen. Mitarbeiter, die Sie diesen Gruppen zuordnen, haben dann automatisch die der Gruppe zugewiesenen Rechte. Was genau das in der Praxis bedeutet, möchte in durch vier Beispiele näher erläutern. In diesen Beispielen arbeite ich außerdem mit der Themenleiste, die einen Schnellzugriff auf wichtige Funktionen gewährt und in Kombination mit den Zugriffsrechten die Arbeit aller Mitarbeiter erleichtert.
So richten Sie die Zugriffsrechte für das gesamte Projekt in objectiF RPM ein.
Beispiel 1: Das Projekt aus der Sicht eines Projektmanagers
In diesem Beispielprojekt ist Frieda Lautermann die Projektmanagerin. Zum Projekt gehören weiterhin ein Requirements Engineer, Stakeholder und zwei Entwicklungsteams (Team Berlin und Team Nürnberg). Frieda Lautermann muss zum einen das Projekt planen, den Mitarbeitereinsatz definieren, den Fortschritt kontrollieren und Vorgesetzten Bericht erstatten. Zum anderen stellt sie die Schnittstelle für alle Beteiligten dar. Kurzum: Sie trägt viel Verantwortung. Daher habe ich ihr alle Zugriffsrechte gewährt. Die Themenleiste bietet ihr u.a. Schnellzugriff auf Funktionen zur Planung des Mitarbeitereinsatzes oder zur Bearbeitung des Projektplans. Sie kann außerdem die gesamte Produktehierarchie (rechts) sehen und bearbeiten. Im Ordner “Dokumente” hat sie z.B. einen Unterordner “vertraulich” angelegt, den nur sie sehen kann.
Beispiel 2: Das Projekt aus der Sicht eines Requirements Engineers
In Frieda Lautermanns Team arbeitet der Requirements Engineer Herbert König. Er braucht insbesondere den Schnellzugriff auf Funktionen, mit denen er neue Anforderungen anlegen oder die bereits erstellten ansehen kann. Die Themenleiste hat sich damit deutlich reduziert. Ich habe ihm keine Zugriffsrechte auf die Projektplanung gewährt und ihm rechts in der Produktehierarchie den entsprechenden Ordner ganz ausgeblendet. Erkennbar ist außerdem, dass er keinen Zugriff auf die vertraulichen Dokumente hat.
Beispiel 3: Das Projekt aus der Sicht der Entwickler
Zum Entwicklerteam gehört Iris Winter. Sie arbeitet in ihrem Team agil und braucht u.a. Zugriff auf ihr User Story Board. Sie kann sich auch das Gantt-Diagramm anzeigen lassen, aber in erheblich reduzierter Form. Des Weiteren hat sie keinen Zugriff auf die gesamte Projektplanung, sondern nur auf die Release-Planung.
Beispiel 4: Das Projekt aus der Sicht eines neuen Mitarbeiters
Vielleicht ist Ihnen rechts in der Produktehierarchie der Ordner “_Spielwiese” aufgefallen. In diesem Ordner dürfen Mitarbeiter alles machen, sprich: Sie haben volle Zugriffsrechte und können z.B. Anforderungen anlegen, Ordner löschen oder Use Case-Diagramme erstellen. Der Anwendungsfall dahinter ist folgender:
Ich habe eine Projektgruppe “Einarbeitung” angelegt, die nur die Zugriffsrechte “Anzeigen” und “Lesen” auf das gesamte Projekt hat. In diese Gruppe möchte ich neue Mitarbeiter hinzufügen, die das Live-Projekt kennenlernen sollen, ohne die Möglichkeit zu haben, etwas “kaputt” zu machen. Damit sie sich selbst einarbeiten können, gibt es den Ordner “_Spielwiese”.
Dazu ein kurzes Video:
Fazit
Ganz klar: Mit einem Berechtigungskonzept im Tool sind Sie auf der sicheren Seite. Sie verhindern ungewollten Zugriff auf Dateien oder das Löschen wichtiger Arbeitsergebnisse. So lässt sich z.B. auch ganz einfach ein Ordner für vertrauliche Dokumente einrichten, auf den nur explizit definierte Gruppen oder Mitarbeiter Zugriff haben. Gleichzeitig entlasten Sie mit einem Berechtigungskonzept alle Projektbeteiligten, weil sie nur die für ihre Rolle relevanten Informationen sehen und bearbeiten können. Daher lohnt es sich, Zeit in die Erstellung eines Rechtekonzepts zu investieren und klar zu definieren, wer eigentlich was und wie in Projekten tun darf. Ist dieses dann im Tool hinterlegt, lässt sich effizienter und ohne Gefahr von Hiobsbotschaften arbeiten. Übrigens hatte sich mein Teamchef damals natürlich sofort um den Vorfall gekümmert und die IT angerufen. Ein Glück, dass es Backups gibt!
Eine kostenlose Testversion von objectiF RPM gibt es übrigens auch – noch ohne Berechtigungskonzept, dafür mit vielen anderen nützlichen Funktionen. Einen Überblick über die Funktionen finden Sie hier.
Hinweise:
[1]: sudo steht für “substitute user do” oder “super user do”. Mithilfe von sudo lassen sich Programme durch einen anderen, in der Regel administrativen Nutzer ausführen. Mehr dazu finden Sie hier: https://www.linux.com/learn/linux-101-introduction-sudo
[2]: Verizon (2018): Data Breach Investigations Report. Executive Summary. Aufrufbar über die URL: https://www.verizonenterprise.com/resources/reports/rp_DBIR_2018_Report_execsummary_en_xg.pdf
Diskutieren Sie mit.