Das Design einer Berechtigungsmatrix hilft Ihnen, Rollen, Bereiche und Ausnahmen zu erfassen, bevor Sie Bildschirme und APIs bauen. So reduzieren Sie Nacharbeiten und spätere Zugriffsfehler.
Ein internes Tool ist die Software, die Ihr Team täglich nutzt, um das Geschäft zu betreiben. Denken Sie an Admin-Panels, Operations-Dashboards, Support-Konsolen, Finanzprüfingsseiten und kleine Apps, mit denen Mitarbeitende Arbeit genehmigen, Daten korrigieren oder auf Kundenanfragen reagieren.
Diese Tools berühren sensible Daten und bieten mächtige Aktionen. Ein Support-Mitarbeiter muss vielleicht ein Kundenprofil sehen, darf aber niemals vollständige Zahlungsdaten einsehen. Ein Finance-Nutzer kann Rechnungen exportieren, sollte aber keine Kontoeinstellungen ändern. Ein Ops-Leiter kann beides tun, aber nur für seine Region.
Berechtigungen werden schnell kompliziert, weil interne Tools oft in Schichten wachsen. Neue Rollen entstehen, alte Rollen werden aufgeteilt und Einzelausnahmen häufen sich: „Erlaube Maria Rückerstattungen“, „Sperre Auftragnehmer von Notizen aus“, „Teamleiter dürfen nur bis 500 $ genehmigen.“ Wenn die Regeln nur im Kopf der Leute (oder in verstreuten Tickets) existieren, driften UI und API auseinander und Sicherheitslücken entstehen.
Eine Berechtigungsmatrix schafft Abhilfe, indem sie eine gemeinsame Karte erstellt, wer was an welchen Daten und unter welchen Einschränkungen tun darf. Sie wird zur Quelle der Wahrheit – sowohl für UI-Entscheidungen (welche Bildschirme, Buttons und Felder angezeigt werden) als auch für Backend-Entscheidungen (was der Server tatsächlich erlaubt, selbst wenn jemand die UI umgeht).
Sie ist nicht nur für Entwickler gedacht. Eine gute Matrix ist ein Arbeitsdokument, dem Produkt, Operations und die umsetzenden Teams zustimmen können. Wenn Sie mit einer No-Code-Plattform wie AppMaster bauen, bleibt die Matrix wichtig: Sie zeigt, wie Sie Rollen anlegen, Ressourcen definieren und visuelle Bildschirme sowie generierte Endpunkte konsistent halten.
Eine einfache Matrix hilft Ihnen dabei:
Gutes Design einer Berechtigungsmatrix beginnt mit gemeinsamen Begriffen. Wenn Ihr Team diese Begriffe gleich verwendet, vermeiden Sie später unübersichtliche Regeln.
Eine Rolle ist eine aufgabenbasierte Gruppe von Personen, die üblicherweise denselben Zugriff benötigen. Denken Sie an Support, Finance, Ops oder Manager. Rollen sollten beschreiben, was jemand im Alltag macht, nicht dessen Seniorität. Eine Person kann mehrere Rollen haben, das sollte aber die Ausnahme bleiben.
Eine Ressource ist das, was Sie schützen. In internen Tools sind typische Ressourcen Kunden, Tickets, Rechnungen, Berichte, Integrationen und Einstellungen. Benennen Sie Ressourcen als Substantive. Das hilft später, wenn Sie Regeln in Bildschirme und API-Endpunkte übersetzen.
Eine Aktion beschreibt, was jemand mit einer Ressource tun kann. Verwenden Sie konsistente Verben, damit die Matrix lesbar bleibt. Typische Aktionen sind:
Ein Bereich beantwortet die Frage „welche Datensätze?“ ohne zusätzliche Rollen zu schaffen. Bereiche entscheiden oft über sicheren oder unsicheren Zugriff. Gängige Bereiche sind:
Eine Ausnahme ist eine Überschreibung, die die normalen Rollen- und Bereichsregeln durchbricht. Ausnahmen können zeitlich befristet sein (für eine Schicht), benutzerspezifisch (ein Spezialist braucht eine zusätzliche Aktion) oder datensatzspezifisch (ein VIP-Kunden-Datensatz ist gesperrt). Behandeln Sie Ausnahmen als kontrollierte technische Schulden: dokumentieren Sie, wer sie genehmigt hat, warum sie bestehen und wann sie auslaufen.
Beispiel: Ein Support-Mitarbeiter darf „Tickets ansehen“ mit Bereich „team“, bekommt aber eine kurzzeitige Ausnahme, um „Tickets zu exportieren“ für eine Vorfallanalyse. In einem mit AppMaster aufgebauten Tool ist so eine Regel einfacher zu pflegen, wenn Rollen, Ressourcen, Aktionen und Bereiche von Anfang an konsistent benannt werden.
Beginnen Sie damit, zu vereinbaren, was Sie tatsächlich schützen. Listen Sie die Bereiche des internen Tools als Ressourcen auf, nicht als Bildschirme. Ein Bildschirm kann gleichzeitig „Bestellungen“, „Rückerstattungen“ und „Kunden“ anzeigen, aber das sind unterschiedliche Ressourcen mit unterschiedlichen Risiken.
Standardisieren Sie vor dem Schreiben einer einzigen Berechtigung die Aktionsverben. Kleine Wortunterschiede erzeugen später doppelte Regeln (edit vs update, remove vs delete, view vs read). Wählen Sie eine kurze, gemeinsame Menge und halten Sie sich daran. Für die meisten internen Tools reicht eine einfache Menge wie ansehen, erstellen, bearbeiten, löschen, genehmigen, exportieren.
Bereiche sind die nächste Entscheidung und sollten zur Unternehmensstruktur passen. Zu viele Bereiche machen die Matrix unlesbar; zu wenige führen zu ständigen Ausnahmen. Ziel ist eine kleine Menge, die zur Organisation passt, z. B.:
Sie brauchen außerdem eine klare Regel für „kein Zugriff“. Entscheiden Sie, was ausdrücklich verboten ist gegenüber implizit verweigert. Implizite Verweigerung (alles, was nicht aufgeführt ist, ist verboten) ist sicherer und einfacher. Explizites Verbot ist nützlich, wenn Sie breiten Zugriff haben, aber eine bestimmte Aktion blockieren wollen, z. B. „Finance kann alle Rechnungen sehen, außer löschen.“
Markieren Sie abschließend früh Compliance-sensible Aktionen, bevor sie im Raster untergehen. Exporte, Löschungen, Auszahlungen, Rollenänderungen und Zugriff auf personenbezogene Daten verdienen besondere Aufmerksamkeit, Protokollierung und oft einen Genehmigungsschritt. Beispielsweise könnte ein Support-Lead ein Kundenprofil aktualisieren dürfen, aber für eine Auszahlung ist die Freigabe der Finance-Abteilung nötig.
Wenn Sie in AppMaster bauen, lassen sich diese Entscheidungen später sauber auf Backend-Endpunkte und Business-Process-Logik abbilden – aber die Matrix muss vorher klar sein.
Beginnen Sie mit der Arbeit, die Menschen erledigen, nicht mit den Bildschirmen, die Sie bauen wollen. Wenn Sie mit Bildschirmen starten, kopieren Sie die heutige UI und übersehen die echten Regeln (z. B. wer Rückerstattungen genehmigen kann oder wer einen Kunden-Datensatz nach Sperrung bearbeiten darf).
Eine einfache Methode ist, die Berechtigungsmatrix als Karte von Aufgaben zu Zugriffsrechten zu behandeln und diese später in Ihre App zu übertragen.
Listen Sie Geschäftstätigkeiten in einfacher Sprache auf. Beispiel: „Eine Rückerstattung durchführen“, „E-Mail eines Kunden ändern“, „Rechnungen des letzten Monats exportieren“. Kurz und realistisch bleiben.
Überführen Sie Aufgaben in Ressourcen und Aktionen. Ressourcen sind Substantive (Invoice, Ticket, Customer), Aktionen Verben (ansehen, erstellen, bearbeiten, genehmigen, exportieren). Bestimmen Sie für jede Ressource einen Verantwortlichen: eine Person, die Randfälle erklären kann und die sagt „ja, das stimmt so“.
Definieren Sie Rollen anhand stabiler Teams. Verwenden Sie Gruppen wie Support, Finance, Operations, Team Lead. Vermeiden Sie Titel, die sich häufig ändern (Senior, Junior), es sei denn, sie beeinflussen wirklich den Zugriff.
Füllen Sie die Matrix mit dem minimalen Zugriff, den jede Rolle braucht, um die Aufgaben zu erfüllen. Wenn Support nur Rechnungen ansehen muss, um Fragen zu beantworten, geben Sie nicht standardmäßig „exportieren“. Zugriff lässt sich später immer noch hinzufügen, aber Entzug bricht Gewohnheiten.
Fügen Sie Bereiche nur dort hinzu, wo sie relevant sind. Statt einer einzigen „bearbeiten“-Berechtigung notieren Sie Bereiche wie „bearbeiten own“, „bearbeiten assigned“ oder „bearbeiten all“. So bleiben Regeln klar, ohne 50 Rollen anzulegen.
Erfassen Sie Ausnahmen in einer separaten Tabelle, nicht als chaotische Notiz in der Matrix. Jede Ausnahme braucht ein klares Feld für den Grund (Compliance, Betrugsrisiko, Trennung von Zuständigkeiten) und einen einzelnen Genehmiger.
Sobald das steht, machen Tools wie AppMaster es einfacher, die Matrix in geschützte Endpunkte und Admin-Bildschirme zu übersetzen, ohne während der Umsetzung zu raten.
Eine Berechtigungsmatrix hilft nur, wenn Leute sie schnell lesen können. Wird sie zur riesigen Zellewand, hört das Team auf, sie zu nutzen, und Berechtigungen driften von der Absicht weg.
Teilen Sie die Matrix nach Domänen auf. Statt eines Blatts für alles, verwenden Sie ein Tab pro Geschäftsbereich wie Kunden, Abrechnung und Content. Die meisten Rollen berühren nur wenige Domänen; so bleiben Reviews schnell und versehentliche Änderungen seltener.
Nutzen Sie ein einheitliches Namensmuster über die Tabs hinweg. Ein Format wie Resource.Action.Scope macht sofort klar, was jede Berechtigung bedeutet und verhindert Duplikate, die verschieden aussehen, aber dasselbe tun. Zum Beispiel liest sich Invoice.Approve.Department genauso eindeutig wie Customer.Edit.Own.
Bei Randfällen widerstehen Sie der Versuchung, eine neue Rolle zu schaffen. Fügen Sie eine kurze Notiz neben die Zelle, die die Ausnahme und ihren Anwendungsfall beschreibt. Beispiel: Support darf Rechnungen sehen, aber erst nach Identitätsbestätigung des Kunden. Die Notiz kann auch auf den zusätzlichen UI-Schritt verweisen, ohne das Rollenmodell zu ändern.
Markieren Sie risikoreiche Berechtigungen, damit sie bei Reviews auffallen. Dazu gehören Aktionen wie Rückerstattungen, Genehmigungen, Exporte und Löschungen. Kennzeichnen Sie die Zellen und schreiben Sie, welche zusätzliche Prüfung nötig ist, z. B. Zwei-Personen-Genehmigung oder Manager-Bestätigung.
Um die Matrix langfristig wartbar zu halten, versionieren Sie sie wie ein echtes Artefakt:
Ist die Matrix stabil, ist es viel einfacher, Bildschirme und Endpunkte in AppMaster zu bauen, weil jeder Button und jede API-Aktion einer klaren Berechtigungskennung entspricht.
Eine Berechtigungsmatrix nützt nur, wenn sie in beiden Welten umgesetzt wird: API und UI. Behandeln Sie jede Ressource in der Matrix (z. B. Tickets, Rechnungen, Nutzer) als Endpunkt-Gruppe. Halten Sie die Aktionen an die Matrix-Verben angelehnt: ansehen, erstellen, bearbeiten, genehmigen, exportieren, löschen.
Auf der API-Seite setzen Sie Berechtigungen bei jeder Anfrage durch. UI-Prüfungen sind nützlich für die Bedienbarkeit, aber sie sind keine Sicherheit. Ein versteckter Button stoppt keinen direkten API-Aufruf.
Eine einfache Übersetzungsregel ist, Berechtigungsnamen konsistent zu wählen und sie dort zu prüfen, wo die Aktion ausgeführt wird:
Verwenden Sie dieselben Berechtigungsnamen, um UI-Gates zu steuern: Menüs, Seitenzugang, Buttons und sogar Felder. Ein Support-Mitarbeiter sieht vielleicht die Ticketliste und kann ein Ticket öffnen, aber das Feld „Rückerstattung“ ist nur lesbar, wenn er zusätzlich invoices:approve hat.
Achten Sie auf Listen- vs. Detailzugriff. Teams brauchen oft „sehen, dass etwas existiert“, ohne den Datensatz selbst zu öffnen. Das kann bedeuten, dass Listen mit begrenzten Spalten angezeigt werden, während die Detailansicht nur mit Detailberechtigung zugänglich ist (oder wenn ein Bereichscheck wie „mir zugewiesen“ besteht). Entscheiden Sie das früh, damit Sie keine Liste bauen, die sensible Daten leakt.
Ordnen Sie Audit-Logging Aktionen zu, die relevant sind. Exporte, Löschungen, Genehmigungen, Rollenänderungen und Datendownloads sollten Audit-Ereignisse erzeugen mit wer, was, wann und Ziel-Datensatz. Wenn Sie in AppMaster bauen, können Sie das in Endpoint-Logik und Business Process so abbilden, dass dieselbe Regel sowohl die Aktion als auch ihren Audit-Eintrag auslöst.
Der schnellste Weg, eine Berechtigungsmatrix zu zerstören, ist, die UI statt das Geschäft zu modellieren. Ein Bildschirm kann mehrere Dinge zeigen, und dasselbe Element kann auf verschiedenen Bildschirmen erscheinen. Wenn jedes UI als eigene Ressource modelliert wird, duplizieren Sie Regeln, übersehen Randfälle und streiten über Namensgebung statt über Zugriff.
Ein weiterer häufiger Fehler ist Rollenaufblähung. Teams fügen ständig Rollen hinzu (Support Level 1, Support Level 2, Support Manager usw.), obwohl ein kleineres Rollenset plus klare Bereiche ausreichend wäre. Bereiche wie „eigenes Team“, „zugewiesene Region“ oder „Konten, die Sie betreuen“ erklären Unterschiede oft besser als eine neue Rolle.
Typische Fehler in echten internen Tools:
Ausnahmen verdienen besondere Vorsicht. Sie sind nützlich für temporäre Situationen, müssen aber auslaufen oder überprüft werden. Wachsen Ausnahmen weiter, ist das ein Zeichen, dass Rollen oder Bereiche nicht sauber abgebildet sind.
Ein kurzes Beispiel: In einem Support- und Finance-Tool darf Support Kundenprofile ansehen und Tickets erstellen, Finance darf Rechnungen exportieren und Rückerstattungen durchführen. Wenn Sie nur die Seiten absichern, könnte ein Support-Mitarbeiter trotzdem den Export-Endpunkt direkt anrufen. Ob Sie mit Custom Code bauen oder mit einer Plattform wie AppMaster, die Regel muss serverseitig leben, nicht nur in der UI.
Eine Berechtigungsmatrix ist nur dann nützlich, wenn sie in klare, durchsetzbare Regeln übergeht. Bevor Sie den ersten Bildschirm oder Endpunkt erstellen, gehen Sie diese Checkliste durch. Sie hilft, „fast sicher“-Setups zu vermeiden, die beim nächsten Rollenwechsel brechen.
Beginnen Sie mit einer Default-Deny-Haltung: alles, was nicht explizit erlaubt ist, ist geblockt. Das ist die sicherste Basis und verhindert überraschenden Zugriff bei späteren Features.
Stellen Sie sicher, dass es eine einzige Quelle der Wahrheit für Berechtigungen gibt. Ob das ein Dokument, eine Tabelle in der Datenbank oder Ihre No-Code-Konfiguration ist – das Team muss wissen, wo die aktuellen Regeln stehen. Wenn die Tabelle etwas anderes sagt als die App, entstehen Bugs.
Kompakte Pre-Build-Checkliste für die Berechtigungsmatrix:
Machen Sie eine Plausibilitätsprüfung mit einer realistischen Situation: z. B. „Ein Support-Mitarbeiter kann eine Bestellung ansehen und eine Notiz für seine Region hinzufügen, darf aber Preise nicht ändern oder Rückerstattungen ausführen. Finance kann Rückerstattungen vornehmen, aber nur nach Manager-Genehmigung; jede Rückerstattung wird protokolliert.“ Wenn Sie das nicht in ein oder zwei Sätzen sagen können, sind Bereiche und Ausnahmen noch nicht klar.
Wenn Sie mit AppMaster arbeiten, behandeln Sie diese Punkte als Anforderungen für Bildschirme und Business-Logik, nicht nur für die UI. Buttons können Aktionen verbergen, aber nur Backend-Regeln erzwingen sie wirklich.
Stellen Sie sich ein mittelgroßes Unternehmen vor mit einem internen Tool, das Support und Finance nutzen. Dieselbe Datenbank enthält Customers, Tickets, Refunds, Payouts und ein kleines Settings-Panel (Templates, Integrationen). Ein einfacher Login-Check reicht hier nicht.
Startrollen, mit denen sie beginnen:
Eine praktische Berechtigungsmatrix beginnt damit, Aktionen pro Ressource aufzuschreiben und sie dann durch Bereiche einzuschränken.
Für Tickets dürfen Support Agents Tickets in ihrer zugewiesenen Queue ansehen und den Status aktualisieren. Sie können Notizen hinzufügen, aber nicht den Ticket-Besitzer ändern. Support Leads können alles, was ein Support Agent kann, plus Tickets innerhalb ihrer Region neu zuweisen.
Bei Rückerstattungen kann Finance Rückerstattungen erstellen und genehmigen, aber nur bis zu einem festgelegten Betrag. Support kann eine Rückerstattungsanfrage erstellen, darf sie aber nicht genehmigen. Rückerstattungsgenehmigung ist eine eigene Aktion und bleibt sichtbar in der Matrix, damit sie nicht versehentlich vergeben wird.
Für Payouts und Einstellungen bleibt das Tool strikt: Nur Finance kann Payouts sehen, nur Ops Admin kann Einstellungen ändern. Support sieht diese Bereiche gar nicht, was Versuchung reduziert und Fehler vermeidet.
Fügen Sie eine Ausnahme hinzu: Ein Support Lead deckt für zwei Wochen eine andere Region ab. Statt ihm pauschal die Ops-Admin-Rolle zu geben, trägt die Matrix eine temporäre Bereichserweiterung ein (Support Lead + Region B, läuft an einem bestimmten Datum aus). Diese einzelne Ausnahme ist sicherer, als Berechtigungen über Rollen zu duplizieren.
Wenn Sie das in AppMaster bauen, kann dieselbe Matrix steuern, welche Seiten in der UI erscheinen und was die API-Endpoints erlauben, sodass niemand per erratenem API-Aufruf Payouts oder Einstellungen erreicht.
Berechtigungen versagen meist auf kleine, langweilige Weise: Ein Screen versteckt einen Button nicht, ein Endpoint überspringt eine Prüfung, eine Bereichsregel greift zu weit. Eine gute Berechtigungsmatrix wird deutlich nützlicher, wenn Sie sie in wiederholbare Tests und eine einfache Wartungsroutine überführen.
Beginnen Sie mit einer kleinen Menge Testnutzer. Sie brauchen keine Dutzende Accounts. Erstellen Sie einen Nutzer pro Rolle plus einen „Rand“-Nutzer für jede typische Ausnahme (z. B. „Support mit Rückerstattungsfreigabe“). Halten Sie diese Accounts stabil, damit das Team sie Sprint für Sprint wiederverwenden kann.
Überführen Sie die Matrix in Testfälle. Für jede Regel schreiben Sie einen erlaubten Pfad und einen abgelehnten Pfad. Machen Sie den abgelehnten Pfad konkret (was soll passieren), damit er nicht ignoriert wird.
Testen Sie jede Regel doppelt: in der UI und in der API. Wenn die UI eine Aktion blockiert, die API sie aber erlaubt, kann jemand die UI umgehen. Wenn Sie mit AppMaster bauen, prüfen Sie, dass UI-Logik und Backend-Endpunkte dieselben Regeln durchsetzen.
Bereiche brauchen echte Testdaten. Erstellen Sie Testrecords mit unterschiedlicher Ownership, Team- und Region-Zuordnung. Verifizieren Sie, dass man nicht durch Erraten einer ID auf Datensätze außerhalb des eigenen Bereichs zugreifen kann.
Bestimmen Sie abschließend, was für sensible Aktionen geloggt werden soll (Rückerstattungen, Exporte, Rollenänderungen). Loggen Sie wer es getan hat, was sich geändert hat, wann und von wo. Prüfen Sie Logs regelmäßig und fügen Sie Alert-Regeln für seltene Aktionen hinzu, z. B. Berechtigungsänderungen oder Massenexporte.
Behandeln Sie die Berechtigungsmatrix als Bauplan, nicht als abgelegtes Dokument. Der schnellste Weg, Wert zu schaffen, ist, die Basics mit den Daten- und Prozess-Eigentümern abzustimmen.
Starten Sie mit einem kurzen Workshop (30 Minuten reichen) mit je einer Vertretung pro Rolle plus den Ressourcen-Eigentümern (Verantwortliche für Kunden, Rechnungen, Payouts, Tickets etc.). Gehen Sie Rollen, Ressourcen, Aktionen und Bereiche durch und notieren Sie Sonderfälle, die wie Ausnahmen wirken. Wenn eine Ausnahme häufig vorkommt, ist das wahrscheinlich ein fehlender Bereich.
Erstellen Sie dann eine v1-Matrix und prüfen Sie sie gezielt mit den Ressourcen-Eigentümern. Bleiben Sie praktisch: „Kann Support Rechnungen sehen?“ „Kann Finance Kundendaten bearbeiten?“ Wenn jemand zögert, halten Sie die Regel erstmal in einfacher Sprache fest. Formalisieren können Sie später.
Baue Sie danach eine Domäne Ende-zu-Ende, bevor Sie ausweiten. Wählen Sie einen dünnen Slice, der Daten, Logik und UI berührt (z. B. Ticketing oder Rechnungsfreigabe). Sie sollten beantworten können: Wer kann es sehen, wer kann es ändern und was passiert, wenn jemand es versucht.
Wenn Sie AppMaster verwenden, ordnen Sie die Matrix vor dem Generieren den Produktteilen zu:
Ein einfaches Beispiel: Bauen Sie einen „Rückerstattungsantrag“-Flow mit zwei Rollen (Support erstellt, Finance genehmigt). Wenn das sauber funktioniert, fügen Sie Randfälle hinzu wie „Support kann innerhalb von 30 Minuten stornieren.“
Probieren Sie ein kleines internes Tool in AppMaster, um Rollen und Abläufe frühzeitig zu validieren, und iterieren Sie dann basierend auf der Matrix. Ziel ist, Missverständnisse zu finden, bevor Sie 20 Bildschirme haben und eine Liste mit Berechtigungsfixes entsteht.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
