Nicht nur „Admin oder Nutzer“: Welche Handlung ist erlaubt?
Wenn ihr eine interne Anwendung entwickeln oder erweitern lasst, sollte vorab feststehen, wer eine Anfrage bearbeiten, eine Kalkulation ändern oder ein Angebot freigeben darf. Für Inhaber und Betriebsleitungen ist das eine Entscheidung über den Arbeitsablauf, nicht nur eine Einstellung am Ende des Projekts. Unser Vorschlag: Beschreibt Rechte anhand einer konkreten Aufgabe, der erlaubten Aktion und des betroffenen Datenbereichs. Der folgende Entscheidungsbogen hilft bei dieser Vorbereitung. Er ist kein vollständiges Sicherheitskonzept und kein Sicherheitsnachweis.
Ein erfolgreicher Login beantwortet noch keine Freigabefrage.
Microsoft unterscheidet zwischen der Prüfung einer Identität und der Entscheidung, welche Daten oder Funktionen diese Identität verwenden darf. Rollen können einzelne Berechtigungen bündeln; zusätzliche Bedingungen können nötig sein. Für euren Projektbrief heißt das beispielsweise: „Darf sich anmelden“ und „darf ein Angebot versenden“ sind getrennt zu klären. Dieser Beitrag behandelt solche Anwendungsrechte, nicht die Auswahl eines Anmeldedienstes.
Originalquelle: Microsoft zu Authentifizierung und Autorisierung
Sechs Felder machen aus einem Rollenwunsch eine prüfbare Regel.
Microsoft beschreibt anwendungsspezifische Rollen als Bündel benötigter Zugriffe, deren Bedeutung die Anwendung umsetzen muss. Diese Rollen sind nicht mit Azure- oder Entra-Administrationsrollen gleichzusetzen. Der folgende Bogen ist unser eigener Arbeitsvorschlag für ein Softwareprojekt, keine Microsoft-Vorlage und keine Produktempfehlung. Füllt für jede wichtige Aktion eine Zeile aus; ein einziges „darf bearbeiten“ ist dafür oft zu ungenau.
- Aufgabe: Welcher Vorgang oder welche Datengruppe ist gemeint? Zum Beispiel Anfragebearbeitung, nicht pauschal „Kundendaten“.
- Rolle: Welche betriebliche Aufgabe übernimmt der Personenkreis? Zum Beispiel Bearbeitung oder Freigabe, nicht nur ein aktueller Personenname.
- Aktion: Ansehen, anlegen, ändern, freigeben, exportieren und löschen getrennt entscheiden. Eine erlaubte Änderung bedeutet nicht automatisch eine erlaubte Freigabe.
- Datenbereich: Gilt die Regel für zugewiesene Vorgänge, ein Team, einen Standort oder einen ausdrücklich vereinbarten größeren Bereich?
- Bedingung: Welcher Bearbeitungsstand oder welche befristete Vertretung verändert die Entscheidung? Eine Ausnahme konkret beschreiben.
- Entscheidung und Pflege: Erlaubt, untersagt oder noch zu klären? Wer entscheidet, wer setzt es um und wer hält die Regel aktuell? Offene Punkte nicht als Freigabe behandeln.
Originalquelle: Microsoft zu Rollen innerhalb einer Anwendung
Fiktives Beispiel: Anfrage bearbeiten ist nicht Angebot freigeben.
Ein frei erfundener Dienstleistungsbetrieb plant einen Arbeitsbereich für Anfragen und Angebotsentwürfe. Die folgenden Regeln sind ein Diskussionsbeispiel, keine Beschreibung eines Kundenprojekts und keine allgemeine Vorgabe. Der Betrieb trennt die fachliche Bearbeitung, die Freigabe und die Verwaltung von Zugängen. Ob diese Trennung zum eigenen Team passt, muss die Betriebsleitung entscheiden.
- Bearbeitung: Zugewiesene Anfragen ansehen und einen Angebotsentwurf ändern. Die verbindliche Freigabe und ein Gesamtexport sind in diesem Beispiel nicht erlaubt.
- Freigabe: Entwürfe des zugeordneten Standorts prüfen und freigeben. Ein anderer Standort gehört nicht automatisch zu diesem Bereich.
- Zugangsverwaltung: Vereinbarte Rollen zuweisen oder entziehen. Daraus folgt hier keine fachliche Angebotsfreigabe. Welche Daten technische Supportrollen benötigen, wird gesondert geprüft.
- Vertretung: Eine ausdrücklich genehmigte Freigabeaufgabe für einen vereinbarten Bereich und Zeitraum übernehmen. Nach dem Ende der Vertretung muss der vereinbarte Zugriffsentzug geprüft werden.
Ausnahmen gehören in den Ablauf, nicht in ein späteres Bauchgefühl.
Für den fiktiven Betrieb bleiben trotz dieser Rollen Entscheidungen offen. Darf ein freigegebener Entwurf noch geändert werden? Wer übernimmt bei Abwesenheit? Braucht die Sachbearbeitung einen Export einzelner Vorgänge, aber keinen Gesamtexport? Solche Fragen sollten vor der Umsetzung beantwortet werden. Zusätzliche Bedingungen sind auch in Microsofts Grundlagen zur Autorisierung beschrieben. Welche technische Kombination aus Rollen und weiteren Regeln geeignet ist, entscheidet sich erst am konkreten System.
- Freigabestand: Im Beispiel führt eine nachträgliche Inhaltsänderung wieder zu einem prüfpflichtigen Entwurf. Das ist eine gewählte Betriebsregel, kein Automatismus jeder Software.
- Bereichswechsel: Wird ein Vorgang einem anderen Standort zugewiesen, muss geklärt sein, wer ihn danach bearbeiten darf.
- Ungeklärter Fall: Benennt eine zuständige Person und eine Entscheidung vor der Umsetzung. „Das machen wir später“ ist noch keine definierte Regel.
Zugänge brauchen auch einen Änderungs- und Entzugsweg.
OWASP empfiehlt aufgabenbezogene Rechte und spätere Überprüfungen. Klärt: Wer meldet, genehmigt und prüft Rollenwechsel? Vereinbart bei Vertretungen das Ende und technisch, wann ein Entzug in bestehenden Sitzungen und angebundenen Systemen wirksam sein muss. Eine sofortige Wirkung nicht ungeprüft voraussetzen.
Originalquelle: OWASP zu notwendigen Rechten und regelmäßiger Überprüfung
Die Abnahme braucht erlaubte und ausdrücklich untersagte Fälle.
OWASP empfiehlt Berechtigungsprüfungen bei jeder Anfrage, standardmäßige Verweigerung ohne Erlaubnis und Tests der Regeln. Ein ausgeblendeter Button genügt nicht: Entscheidend ist die vertrauenswürdige Serverseite. Prüft die folgenden fiktiven Fälle ausschließlich mit Testkonten und erfundenen Daten in einer vereinbarten Testumgebung. Sie ersetzen keine gesonderte Sicherheitsprüfung.
- Erlaubt: Die Bearbeitung kann ihren zugewiesenen Angebotsentwurf ändern.
- Untersagt: Dasselbe Konto kann den Entwurf nicht verbindlich freigeben oder einen Gesamtexport ausführen.
- Fremder Bereich: Die Freigaberolle für Standort A erhält nicht ungefragt Zugriff auf Standort B.
- Entzug: Die beendete Vertretung verliert den vereinbarten Zugriff innerhalb des festgelegten Zeitrahmens, auch bei bereits geöffnetem Zugang.
- Ungeklärt: Eine nicht zugewiesene Erlaubnis wird nicht als vorhandene Berechtigung behandelt.
Originalquelle: OWASP zu technischer Durchsetzung und Berechtigungstests
Belegter Bezug: ein geschützter Arbeitsbereich für Enke & Sohn.
Bei Enke & Sohn hat Klickunst einen Projekt-Konfigurator mit einem eigenen Verwaltungsbereich für Anfragen, Preise und Leistungen umgesetzt. Die öffentliche Referenz zeigt damit einen konkreten Einsatzbereich interner Software. Sie veröffentlicht jedoch weder vertrauliche Berechtigungsregeln noch die hier erfundenen Rollen. Unser Beispiel ist ausdrücklich kein Nachweis einer bestimmten Rollenverteilung bei Enke & Sohn und kein Versprechen messbarer Einsparungen. Für ein neues Projekt werden die Regeln mit dem jeweiligen Betrieb festgelegt.
Referenz: Konfigurator und Verwaltungsbereich für Enke & Sohn
Für den ersten Projektbrief reicht ein anonymisierter Kernfall.
Wenn unklar ist, wer etwas sehen, ändern oder freigeben soll, nehmt einen typischen Vorgang und füllt den Sechs-Felder-Bogen aus. Ergänzt einen erlaubten und einen untersagten Fall sowie die noch offene Entscheidung. So lässt sich gemeinsam prüfen, ob vorhandene Software eingestellt, gezielt ergänzt oder eine individuelle Anwendung entwickelt werden sollte. Für ein Erstgespräch reichen abstrakte Rollen und erfundene Beispieldaten. Bitte keine Zugangsdaten, echten Kundenvorgänge oder vertraulichen Mitarbeitendendaten ins Kontaktformular eintragen. Der Beitrag ist eine Planungshilfe, kein Audit oder Compliance-Nachweis.