Zu Projektbeginn scheint es zwei Rollen zu geben: „Admin“ und „Nutzer“. Ein halbes Jahr später kommen Manager, Buchhalter, externe Partner und Kunden mit Zugriff auf eigene Daten hinzu – und Berechtigungen werden Fall für Fall im Code verdrahtet. So entstehen Sicherheitslücken und Fehler. Das Zugriffsmodell sollte vorab entworfen werden; das gehört zu den Grundaufgaben der Webanwendungsentwicklung.
Kurz gesagt: Trennen Sie zwei Achsen – auf welche Daten ein Nutzer zugreift (Mandant, Organisation, Projekt) und welche Aktionen er ausführen darf (Rolle und Rechte). Prüfen Sie Rechte serverseitig bei jeder Anfrage und protokollieren Sie wichtige Aktionen.
Mandantenfähigkeit: Wem gehören die Daten?
Nutzen verschiedene Unternehmen das Produkt, müssen die Daten jedes einzelnen isoliert sein. Die wichtigsten Ansätze:
| Ansatz | Funktionsweise | Wann passend |
|---|---|---|
| Gemeinsame Datenbank mit Mandanten-ID | Jeder Datensatz trägt die Organisations-ID | Die meisten SaaS, schneller Start |
| Schema pro Mandant | Eigener Tabellensatz je Kunde | Höhere Isolationsanforderungen |
| Datenbank pro Mandant | Vollständige Isolation | Große Kunden, regulatorische Vorgaben |
Berechtigungsmodelle
- RBAC (rollenbasiert): Rollen mit Rechtesätzen – Inhaber, Admin, Manager, Betrachter. Einfach und klar.
- Ressourcenrechte: Ansehen, Anlegen, Bearbeiten, Löschen je Bereich – flexibler, ideal für CRM und Backoffice.
- Attributbasierte Regeln (ABAC): Zugriff hängt von Eigenschaften ab – „Manager sieht nur eigene Deals“. Mächtig, aber aufwendiger in der Pflege.
Was von Anfang an eingebaut werden sollte
- Eine Organisations-ID in jeder Geschäftstabelle.
- Serverseitige Rechteprüfung, nicht nur ausgeblendete Buttons.
- Nutzereinladungen mit Rolle und ablaufendem Link.
- Ein Audit-Log: wer hat was wann geändert.
- Eigene Rechte für Datenexport und Löschen.
Typische Fehler
- Rechte nur im Frontend geprüft – die API steht jedem angemeldeten Nutzer offen.
- Fortlaufende Datensatz-IDs ohne Prüfung der Organisationszugehörigkeit.
- Fest verdrahtete Rollen ohne Konfigurationsmöglichkeit.
- Kein Aktionsprotokoll – Vorfälle lassen sich nicht aufklären.
Häufige Fragen
Lässt sich Mandantenfähigkeit später ergänzen?
Ja, aber teuer: Datenmigration und umgeschriebene Abfragen. Wird das Produkt mehrere Unternehmen bedienen, bauen Sie sie von Anfang an ein.
Brauche ich Single Sign-on (SSO)?
Für Unternehmenskunden oft ja, im MVP kann es warten. Siehe unseren Beitrag zu SaaS-MVP-Prioritäten.
Was hat das mit CRM zu tun?
Ressourcenrechte sind das Rückgrat jedes CRM: Manager sehen ihre Deals, Leiter die Abteilung. Dasselbe Modell nutzen wir in CRM/ERP-Systemen und binden Daten anderer Dienste per API an.
Sie entwerfen ein Produkt mit Rollen und Kundenportalen? Senden Sie eine Anfrage auf der Seite Webanwendungen – wir entwerfen Daten-, Zugriffs- und Audit-Modell vor dem Entwicklungsstart.