Rollen und Berechtigungen mit klaren Beispielen erklärt, damit Sie entscheiden können, was Inhaber, Manager, Mitarbeiter und Kunden sehen dürfen und Datenlecks verhindern.
Ein „Datenleck“ im Arbeitsalltag wirkt oft unspektakulär. Ein Support‑Agent öffnet ein Kundenprofil und sieht die komplette Zahlungshistorie. Ein Kunde meldet sich an und findet interne Notizen wie „20% Rabatt anbieten, wenn sie sich beschweren“ oder die tatsächlichen Kosten und Margen auf einer Rechnung. Es wurde kein Passwort gestohlen — die App hat einfach das Falsche angezeigt.
Die meisten Lecks passieren aus Versehen. Berechtigungen werden spät ergänzt, ein neuer Bildschirm wird schnell ausgeliefert oder jemand kopiert eine alte Rolle, die für Tests „gut genug“ war. Dann wird mit einer kleinen Änderung, etwa einem neuen Feld in einer Tabelle, stillschweigend etwas für alle sichtbar.
Deshalb sollten Rollen und Berechtigungen von Anfang an einen zentralen Platz in der App‑Planung haben, nicht nur eine Nachgedanke. Die meisten Kleinunternehmen landen bei den gleichen vier Rollentypen: Inhaber, Manager, Mitarbeiter und Kunde.
Das Ziel ist einfach: Jede Person soll nur das sehen, was sie für ihre Arbeit braucht — und nichts anderes. Das gilt für die Daten im Hintergrund, nicht nur für die erwarteten Bildschirme.
Wenn Sie schnell auf einer No‑Code‑Plattform wie AppMaster entwickeln, ist das noch wichtiger. Geschwindigkeit ist gut, erhöht aber das Risiko, private Notizen, Preisregeln oder fremde Kundendaten versehentlich offenzulegen, wenn Zugriff nicht von Anfang an mitgedacht wird.
Rollen und Berechtigungen sind die Regeln, die entscheiden, wer in einer App was darf.
Ein Zugriffslevel ist das praktische Ergebnis dieser Regeln. Zwei Personen können beide „Mitarbeiter“ sein, aber die eine hat ein höheres Zugriffslevel, weil sie Rückerstattungen genehmigen kann, die andere nicht.
Eine zuverlässige Vorgehensweise ist: Mit minimalem Zugriff starten und nur hinzufügen, was die Person wirklich für die tägliche Arbeit braucht. Wenn jemand nie Rechnungen bearbeitet, geben Sie ihm nicht „zur Sicherheit“ Bearbeitungsrechte. Es ist leichter, später Zugriff zu gewähren als ein Datenleck rückgängig zu machen.
Die meisten Berechtigungen lassen sich auf wenige Aktionen reduzieren: ansehen, erstellen, bearbeiten, löschen und einige risikoreichere Aktionen wie exportieren oder genehmigen.
Scope beantwortet eine andere Frage: „Auf welche Datensätze darf die Aktion angewendet werden?“ Jemand darf vielleicht Rechnungen ansehen, aber nur die eigenen, nicht alle.
Typische Scope‑Muster sind:
Ein Vertriebsmitarbeiter kann eigene Angebote erstellen und ansehen, aber nicht die komplette Kundendatenbank exportieren. Ein Vertriebsleiter kann die Angebote des gesamten Teams sehen und Rabatte genehmigen. Der Inhaber sieht alles und kann Berichte für die Buchhaltung exportieren.
Die meisten Apps haben am Ende dieselben vier Personengruppen. Die Details variieren, das Muster bleibt. Klare Rollen und Berechtigungen verhindern später viele unangenehme "Warum kann die das sehen?"‑Momente.
Inhaber benötigen in der Regel vollständige Sichtbarkeit über das Geschäft. Dazu gehören oft Abrechnung, Sicherheitseinstellungen (z. B. Passwortregeln und MFA) und ein Audit‑Verlauf, damit sie nachvollziehen können, wer wann was geändert hat.
Manager müssen ein Team führen, ohne komplette Administratorenrechte zu haben. Sie brauchen Übersichten (alles in ihrer Abteilung sehen), Genehmigungen (Rabatte, Rückerstattungen, Urlaubsanträge, Inhaltsänderungen) und Berichte. Eventuell benötigen sie eingeschränkte Admin‑Funktionen wie Mitarbeiter einladen oder ein Passwort zurücksetzen, aber keinen Zugang zu Abrechnung oder globalen Sicherheitseinstellungen.
Mitarbeiter sollen schnell ihre tägliche Arbeit erledigen können, mit möglichst geringem Risiko. Ein sicherer Standard ist „nur das, was mir zugewiesen ist.“ Ein Support‑Agent sieht nur seine Tickets, ein Disponent nur die Touren des Tages, ein Verkäufer nur seine Leads. Exporte und Bulk‑Downloads sollten standardmäßig aus sein und nur bei echtem Bedarf aktiviert werden.
Kunden sollten nur ihre eigenen Daten sehen, auch wenn mehrere Personen ein Konto teilen. Ermöglichen Sie begrenzte Aktionen (Anfragen erstellen, Rechnungen bezahlen, Profil aktualisieren), aber halten Sie interne Notizen, Mitarbeiterkommentare und interne Stati verborgen.
Eine Default‑Konfiguration, die in vielen Unternehmen funktioniert:
Viele Teams definieren Rollen nach Bildschirmen: „Mitarbeiter können die Bestellseite öffnen, Kunden nicht.“ Das hilft, übersieht aber das eigentliche Risiko. Dieselben Daten erscheinen in Suche, Kommentaren, Benachrichtigungen, Exporten und Anhängen.
Listen Sie Ihre Datenbereiche auf, nicht die Menüs. Hochrelevante Bereiche sind meist Kundenkontakte, Bestellungen und Lieferstatus, Rechnungen und Zahlungsstatus, Gehälter und HR‑Notizen sowie interne Notizen oder Analysen.
Bestimmen Sie dann, was jede Rolle mit jedem Datentyp darf: ansehen, erstellen, bearbeiten, löschen, genehmigen und teilen. Hier kommen feldbezogene Regeln ins Spiel. Dasselbe Objekt braucht oft eine öffentliche und eine interne Ansicht.
Beispiel: Eine Bestellung kann Kundenname, Lieferadresse, Preis, interne Marge und eine interne Notiz wie „Kunde reklamiert häufig, Rabatt anbieten“ enthalten. Ein Kunde sollte Adresse und Status sehen, aber niemals Marge oder interne Notiz. Ein Manager sieht alle Felder plus die Möglichkeit, Rabatte zu genehmigen. Mitarbeiter sehen nur die Felder, die sie zur Ausführung benötigen, aber keine Finanzdetails.
Dateien und Anhänge verdienen besondere Vorsicht. Verträge, Ausweise, Belege und Screenshots enthalten oft sensiblere Informationen als Formularfelder. Behandeln Sie sie als eigene Berechtigung: wer kann hochladen, wer herunterladen und wer kann Dateivorschauen sehen. Entscheiden Sie außerdem, ob Anhänge die Rechte des übergeordneten Datensatzes erben (z. B. eine Rechnung) oder eigene Regeln brauchen.
Behandeln Sie Exporte und Massenaktionen nicht als automatisch inklusive, nur weil jemand eine Liste sehen kann. Machen Sie sie explizit: Export nach CSV/PDF, Batch‑Download von Anhängen, Massenstatusänderungen (genehmigen, stornieren, erstatten), Massen‑Benachrichtigungen (E‑Mail/SMS/Telegram) und Admin‑Aktionen wie Umverteilung von Datensätzen.
Stellen Sie sich ein kleines Dienstleistungsunternehmen vor: Der Inhaber verkauft Projekte, Manager überwachen Jobs, Mitarbeiter führen die Arbeit aus und Kunden genehmigen Angebote und bezahlen Rechnungen. Der schnellste Weg, peinliche Fehler zu vermeiden, ist, Rollen und Berechtigungen zu vereinbaren, bevor sich jemand einloggt.
Beginnen Sie bei Gelddetails. Preise dürfen für mehr Personen sichtbar sein als die Marge. Eine übliche Regel: Mitarbeiter sehen, was berechnet werden muss, aber nicht, warum dieser Preis gewählt wurde. Ein Techniker braucht vielleicht Positionen zur Erklärung einer Rechnung, aber nicht die interne Marge, Lieferantenkosten oder einen speziellen Rabatt, den Sie zur Auftragsgewinnung gewährt haben.
Kundendaten sind ein weiterer Hotspot. Viele Teams möchten, dass mehrere Personen Kontaktdaten ansehen können (um die richtige Person anzurufen), aber nur wenige dürfen sie bearbeiten. Ansonsten kommt es zu versehentlichen Überschreibungen wie der Rechnungs‑E‑Mail, die durch eine private E‑Mail ersetzt wird, und Rechnungen erreichen die Buchhaltung nicht mehr.
Ein einfaches Setup, das für viele Teams gut funktioniert:
Sperren Sie risikoreiche Aktionen: Eine Rechnung als bezahlt markieren, eine Rückerstattung ausstellen oder eine Zahlungsmethode ändern sollte nur dem Inhaber (oder einer vertrauenswürdigen Finanzrolle) vorbehalten sein.
Ein Support‑Desk wirkt einfach: Kunden schicken Nachrichten, Ihr Team antwortet, Tickets werden geschlossen. Probleme entstehen, wenn dieselbe Ticketansicht für alle wiederverwendet wird. Eine falsche Einstellung und Kunden sehen interne Notizen, Tags oder sogar Mitarbeiterkennzahlen.
Stellen Sie sich ein kleines E‑Commerce‑Unternehmen mit einem gemeinsamen Support‑Postfach vor. Ein Ticket enthält die Kunden‑Nachricht, Bestelldetails, Versandstatus und interne Notizen wie „möglicher Betrug, Ausweis prüfen“ oder „VIP, priorisieren“. Diese interne Information hilft dem Team, darf aber niemals für den Kunden sichtbar sein.
Eine klare Trennung, die sensible Daten schützt:
PII von Kunden ist die nächste Falle. Support braucht oft Telefonnummer oder Adresse, aber nicht bei jedem Ticket. Eine gute Regel: Zeigen Sie sensible Felder nur, wenn der Workflow sie erfordert. Beispiel: Adresse nur nach Auswahl „Versandproblem“ anzeigen und wieder verbergen, wenn das Ticket geschlossen wird.
Halten Sie interne Kennzahlen getrennt von der Kundenerfahrung. Werte wie „Zeit bis erste Antwort“, „Agentenbewertung“ oder „an Rechtsabteilung eskaliert“ gehören nur in Mitarbeiter‑ und Manager‑Ansichten.
Stellen Sie sich ein Lager und ein Außenteam vor, die den ganzen Tag Lieferungen abwickeln. Eine Person plant Routen, eine andere kommissioniert, Fahrer erledigen Stopps. Wenn Ihre App falsche Details an die falschen Leute zeigt, ist das nicht nur peinlich — es kann Kundendaten, Preise oder interne Notizen offenlegen.
Beginnen Sie damit, für jede Gruppe klar zu trennen, was sie täglich braucht.
Mitarbeiter (Kommissionierer und Fahrer) brauchen meist eine enge, aufgabenfokussierte Ansicht. Ein Fahrer sollte beim Öffnen der App nur die ihm für den Tag zugewiesenen Jobs sehen, mit Stoppreihenfolge, Kontaktdaten für den Stopp und Lieferanweisungen. Er sollte nicht die komplette Kundenliste durchstöbern oder Jobs anderer Fahrer sehen. Wenn er eine Schicht abdeckt, kann ein Manager den Job umverteilen, statt weite Zugriffsrechte zu vergeben.
Manager brauchen das breitere Bild: Dienstpläne aller Teams, Lagerbestände und laufende Probleme (verspätete Lieferungen, fehlgeschlagene Zustellungen, beschädigte Artikel, fehlende Unterschriften). Sie brauchen Werkzeuge, um Ausnahmen zu lösen: Stopp neu zuweisen, Route splitten oder eine Inventuranpassung genehmigen.
Kunden brauchen die kleinste Ansicht: nur ihren Lieferstatus. Sie können ETA verfolgen, Liefernachweis sehen und Updates erhalten wie „out for delivery“ oder „verspätet“. Sie dürfen niemals andere Kunden, Tagesrouten oder interne Ausnahme‑Notizen sehen.
Eine einfache Durchsetzungsregel ist, Daten nach Zuweisung und Kundenkonto zu scopen. Ein Delivery‑Job kann lesbar sein nur für (1) das zugewiesene Teammitglied, (2) Manager und (3) den zum Auftrag gehörenden Kunden.
Benennen Sie Ihre Nutzergruppen in klarer Sprache. „Inhaber“, „Manager“, „Mitarbeiter“ und „Kunde“ sind ein guter Anfang, aber nur, wenn sie zur Arbeitsweise Ihres Unternehmens passen. Schreiben Sie für jede Gruppe in einem Satz, wie Erfolg aussieht, z. B. „Manager können Arbeit zuweisen und Teamleistung sehen, ohne Gehaltsdaten einzusehen.“
Als Nächstes ordnen Sie Aktionen den Datenbereichen zu. Denken Sie nicht zuerst in Bildschirmen, sondern in den vorhandenen Daten: Welche Daten gibt es und was dürfen Menschen damit tun. Ein einfaches Raster auf Papier reicht:
Testen Sie den Entwurf mit realen Aufgaben, nicht mit Vermutungen. Gehen Sie typische Abläufe durch wie „Bestellung erstellen“, „Ticket lösen“ oder „Bericht herunterladen“. Wenn eine Aufgabe Sie zwingt, zu breite Rechte zu vergeben, fehlt vermutlich eine feinere Berechtigung (z. B. „Summen anzeigen“ ohne „Export“).
Fügen Sie Genehmigungen ein, wo Geld oder sensible Änderungen betroffen sind. Mitarbeiter können eine Rechnung entwerfen, aber nur ein Manager darf sie genehmigen oder versenden. Mitarbeiter können Lieferadressen bearbeiten, aber Bankdaten dürfen nur der Inhaber ändern.
Die meisten Datenlecks in kleinen Teams sind keine Hacks. Sie passieren, wenn die App jemandem mehr Zugriff gibt, als der Job erfordert. Rollen und Berechtigungen versagen, wenn sie einmal gesetzt und nie wieder überprüft werden.
Ein verbreitetes Muster: Jemand erhält „Admin“ nur fürs Setup. Die Eile vergeht, die Rechte bleiben. Wochen später exportiert diese Person eine komplette Kundenliste „für einen Bericht“ und private Daten liegen in einer Tabelle.
Wiederkehrende Fehler:
Die Nebentüren sind am tückischsten. Sie sperren Mitarbeiter von einer Vertragsseite, schicken ihnen aber die PDF per E‑Mail. Oder die mobile Ansicht zeigt ausgeblendete Felder, die auf dem Desktop verborgen sind.
Eine praktische Lösung: Behandeln Sie Exporte und Downloads als eigene Berechtigungen, nicht als normalen „Anzeigen“-Recht. Wenn eine Rolle eine Liste braucht, geben Sie stattdessen eine gefilterte Ansicht statt eines kompletten Exports.
Bevor Sie echte Nutzer einladen, gehen Sie davon aus, dass jemand auf das falsche Feld klickt, den Bildschirm teilt oder eine Datei herunterlädt, die er nicht darf. Ein paar Checks jetzt ersparen später viel Arbeit.
Starten Sie mit sicheren Defaults. Ein neuer Nutzer landet automatisch in der niedrigsten Rolle, ohne Zugang zu Geld, Exporten oder Admin‑Einstellungen. Wenn jemand mehr braucht, machen Sie die Änderung bewusst.
Testen Sie die Kundenerfahrung wie ein Außenstehender. Kunden dürfen nur ihre eigenen Datensätze sehen, auch wenn sie URLs ändern, suchen oder filtern. Ein schneller Test: Melden Sie sich als Kunde A an und versuchen Sie, Kunde B per Name, Rechnungsnummer oder Ticket‑ID zu finden.
Fünf schnelle Checks, die die meisten Lecks entdecken:
Machen Sie einen „Unfall‑Test“. Bitten Sie eine Kollegin, eine echte Aufgabe mit einem Mitarbeiterkonto zu erledigen, und versuchen Sie dieselbe Aufgabe mit einem Kundenkonto. Wenn der Kunde interne Preise sehen, komplette Kundenlisten herunterladen oder eine Rückerstattung auslösen kann, sind Ihre Berechtigungen zu weit gefasst.
Eine häufige Anfrage beginnt so: Ein Kunde möchte ein Portal zum „Status prüfen“, aber Ihr Team nutzt dasselbe System zur Auftragsabwicklung. Ohne klare Rollen und Berechtigungen kann das Portal interne Notizen, Aufträge anderer Kunden oder mitarbeiterinterne Preise offenbaren.
Stellen Sie sich eine Druckerei vor: Ein Auftrag läuft von Angebot über Produktion bis Lieferung und Rechnung in einer App.
Das sollte jede Rolle in diesem Ablauf sehen:
Zwei Randfälle bringen das Modell oft durcheinander.
Erstens: Ein Manager übernimmt vorübergehend ein anderes Team. Schalten Sie ihn nicht auf Inhaber. Geben Sie stattdessen zeitlich begrenzten Zugriff, z. B. Zugriff auf Team B‑Aufträge für 7 Tage. Nach Ende der Vertretung läuft der Zugriff ab.
Zweitens: Ein VIP‑Kunde verlangt „mehr Einblick“. Geben Sie mehr Kontext, ohne mehr Daten freizugeben. Zeigen Sie eine erweiterte Zeitachse oder einen eigenen Nachrichtenverlauf, aber behalten Sie interne Notizen (z. B. „Kunde hat offene Zahlungen“ oder „Neudruck wegen unseres Fehlers“) für Mitarbeiter vor.
Verantwortlichkeiten ändern sich — betrachten Sie Zugriff als etwas, das geprüft werden muss, nicht als Einmalaufgabe. Wenn jemand die Rolle wechselt, nehmen Sie nicht einfach Rechte hinzu. Entfernen Sie, was nicht mehr nötig ist, und fügen Sie dann die kleinste notwendige Menge an Rechten für die neue Aufgabe hinzu.
Starten Sie klein. Wählen Sie einen Workflow, der am wichtigsten ist, z. B. „Rechnung erstellen und Zahlung entgegennehmen“ oder „Support‑Ticket erfassen und beantworten“. Definieren Sie Rollen und Berechtigungen für diesen einen Ablauf zuerst, dann erweitern Sie.
Halten Sie die Regeln in einer einfachen Tabelle: Rolle, was sie tun darf, was sie nicht darf, und eventuelle Grenzen (z. B. „nur eigene Datensätze“ oder „nur Standort X“). Wenn jemand fragt: „Sehen Mitarbeiter Kundentelefonnummern?“, sollte die Tabelle in Sekunden antworten.
Ein pragmatisches Vorgehen zur Einführung:
Wenn Sie auf AppMaster (appmaster.io) bauen, hilft es, Rollen gemeinsam mit Ihrem Datenmodell und der Geschäftslogik zu planen, damit dieselben Regeln konsistent in Web‑Apps, mobilen Apps und API‑Endpoints gelten.
Wenn Sie möchten: Erstellen Sie noch heute Ihre erste Rollentabelle und probieren Sie sie an einem Workflow aus. Dieser einzelne Schritt verhindert die meisten versehentlichen Datenlecks.
What’s the simplest way to start defining roles and permissions?Beginnen Sie damit, die Daten aufzulisten, die Sie speichern (Kunden, Bestellungen, Rechnungen, interne Notizen, Dateien), und entscheiden Sie dann, wer ansehen, erstellen, bearbeiten, löschen, genehmigen und exportieren darf. Starten Sie mit minimalen Rechten und fügen Sie nur das hinzu, was für die tägliche Arbeit nötig ist.
What’s the difference between permissions and scope?Berechtigungen legen fest, welche Aktionen jemand ausführen darf (z. B. anzeigen oder bearbeiten), während Scope bestimmt, auf welche Datensätze sich diese Aktionen beziehen. Ein Mitarbeiter darf etwa Rechnungen ansehen, aber nur die ihm zugewiesenen oder die seines Standorts.
Do I really need four roles (Owner, Manager, Staff, Client)?„Inhaber, Manager, Mitarbeiter, Kunde“ deckt die meisten kleinen Unternehmen ab, weil es Arbeit und Risiko sinnvoll trennt. Bei komplexeren Teams ergänzen Sie lieber wenige spezielle Rollen (z. B. Finanzen oder Auftragnehmer), statt alle zu Admins zu machen.
What should clients be able to see in a client portal?Als sichere Voreinstellung: Kunden sehen und bearbeiten nur ihre eigenen Datensätze; keine internen Notizen, internen Statusfelder, Margen oder mitarbeiterinterne Tags. Bei mehr Sichtbarkeit lieber mehr Statuskontext (z. B. Zeitachse) statt zusätzliche Rohdaten freizugeben.
How do I stop staff from seeing margin or sensitive pricing details?Trennen Sie was zu berechnen ist von warum der Preis so ist. Mitarbeiter brauchen oft Positionen und Status einer Rechnung, sollten aber nicht Margen, Lieferantenkosten, Rabatt‑Historie oder Zahlungssteuerungen wie „als bezahlt markieren“ sehen.
Why are exports and bulk downloads such a big permission risk?Behandeln Sie Exporte als hohes Risiko: Exportieren ist nicht automatisch in der Ansicht enthalten. Viele Lecks passieren, wenn jemand eine komplette Kundenliste oder Rechnungsdaten in eine Tabelle exportiert, ohne den Umfang zu verstehen.
Why isn’t “restrict the screen” enough to prevent data leaks?Weil Daten an vielen Stellen auftauchen: neben Bildschirmen auch in Suche, Benachrichtigungen, PDFs, mobilen Ansichten, Anhängen und API‑Antworten. Sichern Sie zuerst die Datenebene und die Feldsichtbarkeit, dann die Bildschirme darauf.
How should I handle permissions for files and attachments?Behandeln Sie Anhänge separat, da sie oft sensibler sind als Formularfelder. Legen Sie fest, wer Dateien hochladen, vorschauen und herunterladen darf, und entscheiden Sie, ob Datei‑Rechte automatisch vom übergeordneten Datensatz übernommen werden oder eigene Regeln brauchen.
How do I prevent customers from seeing internal notes in a support desk?Bauen Sie zwei Ticketansichten: eine klientensichere Ansicht ohne interne Notizen, Tags oder Mitarbeiterkennzahlen und eine interne Ansicht mit gesamtem Kontext. Zeigen Sie sensible Kundenfelder nur, wenn der Workflow sie erfordert (z. B. Adresse nur bei „Versandproblem“).
What are quick permission tests I should run before inviting real users?Erstellen Sie Demo‑Accounts für jede Rolle und führen Sie echte Tasks durch, inklusive Suchen, Filtern, Anhänge öffnen und Dokumente erzeugen. Testen Sie außerdem, ob „Kunde A“ wirklich nicht „Kunde B“ finden kann (Namen, IDs, URLs).
10. März 2026
7 Min
08. März 202610 Min
07. März 202611 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
