Berechtigungen als Systemgrenze: warum die Rechtefrage über den Projekterfolg entscheidet
Es gibt einen Punkt, an dem Wissensprojekte im Mittelstand regelmäßig sterben, und er kommt später als gedacht: in der Sicherheitsprüfung. Dann stellt jemand die Frage, ob der Werkstudent über das neue System die Gehaltsliste findet, und wenn die Antwort nicht in einem Satz überzeugt, ist das Projekt vorbei.
Wissensprojekte scheitern häufig erst in der Sicherheitsprüfung. Ein eigenes Rechtekonzept im neuen System ist der falsche Weg: Es veraltet sofort und ist nicht prüfbar. Richtig ist die Abfrage im Namen des Nutzers über delegierte Zugriffe wie OAuth2 — wer ein Dokument heute nicht öffnen darf, sieht es auch in der Antwort nicht. Aufgedeckte Rechteprobleme bestehen vorher schon.
Der Fehler: ein zweites Rechtekonzept
Die naheliegende Lösung ist, im neuen System eigene Rollen und Rechte zu definieren. Sie ist falsch, und zwar aus zwei Gründen. Erstens ist sie sofort veraltet: Jede Änderung in den Quellsystemen muss nachgepflegt werden, und das passiert nach dem dritten Monat nicht mehr. Zweitens ist sie nicht prüfbar, weil niemand beide Konzepte gegeneinander abgleichen kann.
Die richtige Lösung: im Namen des Nutzers
Das System fragt die Quellsysteme mit den Rechten der Person ab, die die Frage stellt — technisch über delegierte Zugriffe, etwa per OAuth2. Wer ein Dokument in SharePoint heute nicht öffnen darf, bekommt seinen Inhalt auch über die Antwort nicht zu sehen, weil das System es für diese Person gar nicht erst lesen kann.
Der Vorteil ist struktureller Natur: Es gibt nichts nachzupflegen. Ändert die IT eine Berechtigung im Quellsystem, gilt sie ab der nächsten Frage. Und die Antwort in der Sicherheitsprüfung passt in einen Satz.
Die Stellen, an denen es trotzdem klemmt
- Historisch gewachsene Ablagen, in denen faktisch alle alles dürfen. Das System deckt das auf, verursacht es aber nicht.
- Technische Sammelkonten, mit denen frühere Integrationen alles lesen. Sie sind der eigentliche Befund.
- Postfächer, deren Freigaben niemand mehr überblickt.
- Papier und Netzlaufwerke ohne Rechtestruktur.
In allen Fällen gilt: Das Projekt macht ein bestehendes Problem sichtbar. Das ist unangenehm und im Ergebnis wertvoll, weil die Alternative ist, es weiter nicht zu wissen.
Häufige Fragen
Wie funktioniert Zugriff im Namen des Nutzers?
Das System nutzt eine delegierte Berechtigung, meist über OAuth2, und liest die Quellsysteme mit den Rechten der fragenden Person. Es gibt kein technisches Sammelkonto, das alles sehen darf. Dadurch entstehen Antworten immer nur aus dem Material, das die Person ohnehin öffnen dürfte.
Was passiert, wenn wir Berechtigungen ändern?
Die Änderung gilt ab der nächsten Anfrage, weil es keine zweite Rechteverwaltung gibt, die nachgezogen werden müsste. Genau das ist der strukturelle Vorteil gegenüber einem eigenen Rollenkonzept, das erfahrungsgemäß nach wenigen Monaten nicht mehr gepflegt wird.
Was, wenn unsere Ablagen historisch offen sind?
Dann macht das Projekt ein bestehendes Problem sichtbar, ohne es verursacht zu haben. Der pragmatische Weg ist, für den Piloten klar abgegrenzte Bereiche zu wählen und die offenen Ablagen parallel zu bereinigen. Wichtig ist die richtige Zuordnung in der Kommunikation, sonst wird das Projekt für einen Altbestand verantwortlich gemacht.
Wie erklären wir das dem Betriebsrat?
Mit demselben Satz wie der IT: Niemand sieht durch das System etwas, das er vorher nicht sehen durfte. Ergänzen Sie das Aktivitätsprotokoll und die Zusage, dass keine Leistungs- oder Verhaltenskontrolle stattfindet. Frühe Einbindung ist hier deutlich günstiger als eine nachträgliche Klärung.
Hält Ihr Rechtekonzept der Prüfung stand?
Sicherheits-Dossier und AVV für Ihre IT, vor dem ersten Dokument.
Unterlagen anfordern →
