Rollen und Rechte im Shop-Backend: Zugriffe begrenzen

In fast jedem gewachsenen Shop gibt es ein Konto, das alles darf. Angelegt wurde es vor Jahren, weil ein sauberer Rechteschnitt länger gedauert hätte als ein Haken bei der Administratorrolle, und seitdem hat es keiner mehr angefasst. Der Data Breach Investigations Report 2025 ordnet 60 % der ausgewerteten Sicherheitsverletzungen einer menschlichen Beteiligung zu (Verizon, DBIR 2025): Fehlbedienung, weitergegebene Zugangsdaten, missbrauchte Berechtigungen. Ein Rechtemodell verhindert solche Fehler nicht, aber es entscheidet darüber, wie weit einer davon reicht. Dieser Beitrag beschreibt den Rollenschnitt entlang der tatsächlichen Aufgaben, die Trennung von Preis-, Bestell- und Kundendatenrechten, die Protokollierung, das Vier-Augen-Prinzip bei Preisen und Rabatten sowie das Verfahren für den Tag, an dem ein Zugang ausscheidet.

Warum aus jedem Zugang mit der Zeit ein Vollzugang wird

Rechte wachsen in aller Regel nur in eine Richtung. Jemand übernimmt eine Vertretung, bekommt dafür ein zusätzliches Recht, gibt die Vertretung wieder ab – und das Recht bleibt stehen, weil das Entziehen keinen Auslöser hat. Nach zwei, drei Jahren tragen die meisten Konten die Summe aller Aufgaben, die ihre Inhaberinnen und Inhaber im Lauf der Zeit hatten. Die eingangs genannten 60 % sind auf einer Teilmenge von 10.798 ausgewerteten Datenverletzungen berechnet; automatisierte Fälle nimmt der Bericht von dieser Rechnung ausdrücklich aus (Verizon, DBIR 2025). Der Anteil beschreibt damit keinen Sonderfall, sondern das Bild des Erhebungszeitraums vom 1. November 2023 bis zum 31. Oktober 2024.

Im Shop-Backend fällt das lange nicht auf, weil der Alltag mit zu vielen Rechten reibungsloser läuft als mit zu wenigen. Sichtbar wird es erst, wenn eine Preisliste versehentlich überschrieben wird, ein Exportlauf Kundendaten aus einem Bereich mitnimmt, der ihn nichts angeht, oder ein Zugang, der längst hätte enden sollen, sich noch anmeldet. Die technische Absicherung des Shops – Aktualisierungen, Netztrennung, Verschlüsselung – ist an dieser Stelle bereits erledigt und hilft trotzdem nicht, weil der Zugriff von innen kommt und formal berechtigt ist. Welche Bausteine dabei ineinandergreifen, ordnet der Überblick zur IT-Sicherheit im E-Commerce ein.

Auch ist es möglich, dass Mitarbeitende, die in eine neue Abteilung versetzt wurden, ihre alten Berechtigungen behalten und dadurch mit der Zeit umfangreiche Gesamtberechtigungen ansammeln.

BSI, IT-Grundschutz-Kompendium, Baustein ORP.4, Abschnitt 2.1

Der zweite Weg ins Rechtechaos ist die Personalfluktuation ohne Gegenstück im Backend. Der Betrieb erfährt von einem Wechsel meist später als die Personalabteilung, unter Umständen gar nicht. Das BSI benennt auch diesen Fall im selben Abschnitt: Der IT-Betrieb erhalte möglicherweise keine Informationen über personelle Veränderungen, sodass Konten ausgeschiedener Mitarbeitender nicht gelöscht würden (BSI, ORP.4, Abschnitt 2.1). Für einen Shop heißt das konkret: Ein Konto mit Schreibrechten auf Preise und Bestellungen existiert weiter, wird aber von keiner Seite mehr beobachtet.

Der Rollenschnitt entlang der Aufgaben

Ein tragfähiges Rechtemodell beginnt nicht bei den Personen, sondern bei den Aufgaben. Die Frage lautet nicht, was jemand können soll, sondern welche wiederkehrenden Tätigkeiten der Shop kennt und welche Datenbereiche jede davon berührt. In einem typischen Handelsbetrieb sind das fünf bis sieben Tätigkeitsbündel, die sich klar gegeneinander abgrenzen lassen. Erst danach werden Personen einer oder mehreren Rollen zugeordnet – und wer zwei Rollen braucht, bekommt zwei Rollen, keine dritte Sonderrolle mit der Summe aus beiden. Diese Reihenfolge ist der eigentliche Trick: Sie hält die Zahl der Rollen klein und macht jede einzelne beschreibbar.

Der Schnitt verläuft entlang von fünf Datenbereichen, die sich im Schadensfall unterschiedlich auswirken: Katalogdaten, Preise und Rabatte, Bestellungen, Kundendaten und die Benutzerverwaltung selbst. Ein falsch gepflegter Produkttext ist ärgerlich und in Minuten korrigiert. Ein falscher Preis läuft sofort in den Verkauf. Eine geänderte Bestellung berührt Buchhaltung und Versand. Ein Export von Kundendaten lässt sich nicht zurückholen. Eine geänderte Rolle wirkt auf alles Übrige. Genau in dieser Reihenfolge steigt die Anforderung an das Recht, das den Zugriff freigibt. Den Bereich Kundendaten kann ein Shop zusätzlich verkleinern, statt ihn nur abzusichern: Wo ein Merkmal im Bestellweg lediglich bestätigt und nicht gespeichert werden muss, entsteht der Datensatz gar nicht erst, um dessen Rechte es später geht – wie sich ein Alters- oder Adressnachweis auf diesem Weg führen lässt, beschreibt der Beitrag zu digitalen Identitätsnachweisen mit der EUDI-Wallet.

• Redaktion: Schreibrechte auf Texte, Kategorien und Medien, Leserecht auf Bestellungen zur Kontrolle des eigenen Ergebnisses, kein Zugriff auf Preise und Kundendaten. Wie sich der Medienbestand dabei ordnen lässt, ohne dass jede Rolle löschen darf, beschreibt der Beitrag zur Medienverwaltung für Produktbilder.
• Einkauf: Schreibrechte auf Stammdaten und Lieferantenzuordnung, Preisänderungen nur als Entwurf mit Freigabe durch eine zweite Person, Leserecht auf Bestellungen für die Bedarfsplanung.
• Kundendienst: Schreibrechte auf Bestellungen und Kundenkonten im laufenden Vorgang, Leserecht auf den Katalog, kein Zugriff auf Preislogik und Benutzerverwaltung.
• Buchhaltung: Leserechte auf Bestellungen, Zahlungen und Rechnungsdaten, Schreibrechte ausschließlich in den eigenen Belegprozessen, kein Zugriff auf Katalog und Benutzer.
• Administration: Benutzer, Rollen, Erweiterungen und Systemeinstellungen, dafür kein Schreibrecht auf Katalog, Preise und Bestellungen. Eine Administration, die nebenbei Preise pflegt, hebt jede Trennung wieder auf.
• Auswertung: Leserechte auf aggregierte Zahlen ohne personenbezogene Felder. Diese Rolle ist ein häufiger Grund, aus dem ein Vollzugang vergeben wird, und zugleich der am einfachsten zu ersetzende.

Der Rollenschnitt hat einen praktischen Nebeneffekt: Er macht wiederkehrende Vorgänge zurechenbar. Wenn die Bestandskorrektur nach der Inventur zum Jahreswechsel an eine Rolle gebunden ist, steht am Ende des Laufs fest, wer welche Menge angefasst hat – ohne dass jemand die Reihenfolge aus dem Gedächtnis rekonstruieren muss. Dasselbe gilt für jede Sammelaktion, die viele Datensätze auf einmal berührt: Sie ist entweder einer Rolle zugeordnet oder sie ist im Nachhinein nicht mehr erklärbar.

Preise, Rabatte und das Vier-Augen-Prinzip

Preisrechte sind der Bereich mit der kürzesten Strecke zwischen Fehler und Umsatzwirkung. Ein Rabatt, der statt auf eine Kategorie auf das gesamte Sortiment gelegt wird, wirkt in dem Moment, in dem er gespeichert ist, und wird oft erst in der Tagesauswertung sichtbar. Deshalb gehört dieser Bereich als einziger Teil des Modells nicht auf ein einzelnes Recht, sondern auf ein Verfahren: Eine Person legt die Änderung an, eine zweite gibt sie frei. Das BSI führt diese Aufteilung für administrative Tätigkeiten als exemplarischen Vorschlag für einen erhöhten Schutzbedarf; ob sie im eigenen Shop angemessen ist, ergibt eine Risikobetrachtung.

Administrative Tätigkeiten SOLLTEN nur durch zwei Personen durchgeführt werden können.

BSI, IT-Grundschutz-Kompendium, Baustein ORP.4, Abschnitt 3.3 Anforderungen bei erhöhtem Schutzbedarf, Anforderung ORP.4.A24 (H)

Im Shop-Backend lässt sich das auf zwei Wegen abbilden. Der eine trennt Entwurf und Veröffentlichung: Preisänderungen entstehen in einer geplanten Aktion mit Startzeitpunkt, die Freigabe ist ein eigenes Recht und liegt bei einer anderen Rolle. Der andere Weg trennt Umfang von Höhe: Wer den Rabattbetrag setzen darf, bestimmt nicht zugleich, auf welche Artikelmenge er wirkt. Beide Varianten kosten einen zusätzlichen Arbeitsschritt und verhindern erfahrungsgemäß genau die Fehler, die sonst erst der Umsatz meldet. Wie stark ein einzelner Parameter im Verkauf durchschlägt, zeigt sich auch bei den Versandkostenmodellen, deren Schwellen an denselben Stellen gepflegt werden.

Protokollierung: wer hat wann was geändert

Ein Rechtemodell ohne Protokoll ist eine Behauptung. Erst die Aufzeichnung macht aus der Rollenzuordnung eine überprüfbare Aussage, und erst sie erlaubt es, nach einem Vorfall zwischen Fehlbedienung, Missverständnis und Missbrauch zu unterscheiden. Der Aufwand dafür ist gering, weil die meisten Backends die Daten bereits erzeugen; was in der Regel fehlt, ist die Auswertung und eine Ablage, die das Protokoll vor den Personen schützt, deren Handeln es aufzeichnet.

Wichtig ist die Trennung zweier Ebenen. Anwendungsprotokolle halten fachliche Änderungen fest – welcher Preis, welche Bestellung, welches Kundenkonto. Zugriffsprotokolle des Servers halten fest, von wo und wann eine Sitzung kam. Beide sind für sich unvollständig und ergeben erst zusammen ein Bild, etwa wenn eine Preisänderung außerhalb der Arbeitszeit aus einem unbekannten Netz stammt. Wie sich Serverprotokolle systematisch auswerten lassen, ohne in Rohdaten zu versinken, zeigt die Logfile-Analyse – das Vorgehen ist dasselbe, nur die Fragestellung eine andere.

• Wer: die Kennung, nicht die Rolle. Rollen ändern sich, die Zuordnung zum Zeitpunkt der Änderung muss erhalten bleiben.
• Wann: Zeitstempel mit Zeitzone. Ein Protokoll in Ortszeit ohne Angabe der Zone ist bei der Umstellung auf Winterzeit für eine Stunde mehrdeutig.
• Was: der Feldname und der Wert davor. Ein Eintrag, der nur den neuen Wert festhält, beantwortet die wichtigste Frage nicht.
• Woher: Adresse und Sitzungskennung. Damit lässt sich eine Reihe zusammengehöriger Änderungen als ein Vorgang lesen statt als fünfzig Einzelfälle.
• Wie lange: eine festgelegte Aufbewahrungsdauer mit anschließender Löschung, abgestimmt mit den Aufbewahrungspflichten der Buchhaltung.

Protokolle gehören nicht auf dasselbe Konto wie die Anwendung, die sie erzeugt. Wer Schreibrechte im Shop hat, sollte das Protokoll lesen, aber nicht ändern können; die Ablage liegt sinnvollerweise außerhalb der Anwendung, etwa in der Betriebsumgebung mit eigener Rechtevergabe. Für die laufende Auswertung reicht ein wöchentlicher Blick auf drei Listen: neu angelegte Konten, geänderte Rollen, ausgeführte Exportläufe. Alles Weitere ist Anlassarbeit.

Was BSI-Grundschutz und NIS2 verlangen

Das Rechtemodell ist keine freie Kür. Der Baustein ORP.4 des IT-Grundschutz-Kompendiums beschreibt Identitäts- und Berechtigungsmanagement in nummerierten Anforderungen, von denen mehrere unmittelbar auf ein Shop-Backend passen. Für Unternehmen, die unter die NIS2-Richtlinie fallen, kommt eine gesetzliche Ebene dazu; welche Betriebe betroffen sind und woran sich das festmachen lässt, ordnet der Beitrag zur NIS2-Richtlinie für Online-Händler ein.

Die NIS2-Richtlinie geht den Weg von der anderen Seite: Sie schreibt keine einzelnen Rechte vor, sondern verlangt in Artikel 21 Absatz 2 einen Mindestbestand an Risikomanagementmaßnahmen, den die Mitgliedstaaten den betroffenen Einrichtungen auferlegen. Zugriffskontrolle steht dort in Buchstabe i als eigener Punkt neben Personalsicherheit und Anlagenverwaltung, Mehr-Faktor-Authentifizierung folgt in Buchstabe j (Richtlinie EU 2022/2555, Artikel 21 Absatz 2).

Die in Absatz 1 genannten Maßnahmen müssen auf einem gefahrenübergreifenden Ansatz beruhen, der darauf abzielt, die Netz- und Informationssysteme und die physische Umwelt dieser Systeme vor Sicherheitsvorfällen zu schützen, und zumindest Folgendes umfassen: [...] Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen

Richtlinie (EU) 2022/2555 (NIS2), Artikel 21 Absatz 2 Buchstabe i

Wer nicht unter NIS2 fällt, hat damit trotzdem eine brauchbare Gliederung in der Hand, weil sie die Zugriffskontrolle in einen Zusammenhang mit Personal und Anlagen stellt und nicht als reine Technikfrage behandelt. Diese Blickrichtung führt in der Praxis zu einem Betriebsmodell, das jeden Zugriff prüft, statt ihn aus der Lage im Netz abzuleiten – der Ansatz, den der Beitrag zu Zero Trust für Online-Shops beschreibt.

Zugänge, die von außen kommen

Agenturen, Aushilfen, Steuerbüro, Warenwirtschaft, Marktplatzanbindung: Viele Backends tragen mehr fremde Zugänge als eigene. Sie entstehen unter Zeitdruck, oft während einer Umstellung, und werden anschließend selten geprüft, weil sie funktionieren. Für sie gelten dieselben drei Regeln wie für interne Konten – Bedarf, Zurechenbarkeit, Befristung -, nur dass die Befristung hier von Anfang an gesetzt gehört, weil der Anlass des Zugangs ein Ende hat.

• Eigene Kennung je Person, auch bei Dienstleistern. Ein Agenturzugang, den vier Personen benutzen, ist ein Sammelkonto mit einem anderen Etikett.
• Befristung im System, nicht im Kalender. Ein Ablaufdatum am Konto entzieht das Recht auch dann, wenn der Termin im Projektbetrieb untergeht.
• Schnittstellen mit eigenem Recht. Ein Warenwirtschaftsabgleich braucht Schreibrechte auf Bestände und Bestellstatus, aber keinen Zugang zur Benutzerverwaltung und keinen zum Katalogtext.
• Testsysteme ohne echte Daten. Ein externer Zugang zum Testsystem ist unkritisch, solange dort keine Kundendaten liegen; wie sich das herstellen lässt, beschreibt der Beitrag zum Shopware-Staging ohne echte Kundendaten.
• Zweiter Faktor für weitreichende Rechte. Das BSI empfiehlt, Benutzendenkennungen mit weitreichenden Berechtigungen mit einer Mehr-Faktor-Authentisierung zu schützen (BSI, ORP.4.A10); passwortlose Verfahren nehmen dabei den Aufwand aus dem Alltag, wie der Beitrag zu Passkeys zeigt.

Der häufigste Einwand gegen befristete Zugänge lautet, dass die Verlängerung Arbeit macht. Sie macht weniger Arbeit als eine Bestandsaufnahme nach drei Jahren, in der zwanzig fremde Konten auf ihre Berechtigung geprüft werden müssen, ohne dass noch jemand den ursprünglichen Anlass kennt. Wer den Shop von einer Shopware-Agentur betreuen lässt, kann die Befristung gleich in den Betriebsablauf legen: Ein Zugang, der nach dem Ende eines Auftrags abläuft, muss aktiv verlängert werden – und genau diese Verlängerung ist die Prüfung, die sonst keinen Termin hätte.

Umsetzung im Backend: die Stellen, an denen es bricht

Shopware bringt in der Community Edition ein Rollensystem mit, das für den beschriebenen Schnitt fein genug ist: Rechte werden je Bereich in Lesen, Schreiben, Anlegen und Löschen unterschieden, Rollen lassen sich frei zusammensetzen und einem Benutzer mehrfach zuordnen. Was fehlt, ist die Verzahnung mit dem eigenen Verfahren – etwa eine Freigabe, die zwei verschiedene Konten verlangt. Solche Ergänzungen entstehen als eigene Erweiterung im Rahmen der Shop-Programmierung und bleiben damit aktualisierungsfest, statt als Handeingriff in den Kern zu wandern.

<?php
// Rechteprofile als Datensatz, nicht als Sammlung von Haken im Backend.
// Eine Rolle beschreibt eine Aufgabe und ist in einem Satz erklärbar.

const PROFILE = [
    'redaktion' => [
        'katalog'      => 'schreiben',
        'preise'       => 'kein_zugriff',
        'bestellungen' => 'lesen',
        'kundendaten'  => 'kein_zugriff',
        'benutzer'     => 'kein_zugriff',
    ],
    'einkauf' => [
        'katalog'      => 'schreiben',
        'preise'       => 'entwurf',        // Freigabe liegt bei einer anderen Rolle
        'bestellungen' => 'lesen',
        'kundendaten'  => 'kein_zugriff',
        'benutzer'     => 'kein_zugriff',
    ],
    'preisfreigabe' => [
        'preise'       => 'freigeben',      // darf selbst keinen Entwurf anlegen
    ],
];

function darf(array $rollen, string $bereich, string $stufe): bool
{
    foreach ($rollen as $rolle) {
        if ((PROFILE[$rolle][$bereich] ?? 'kein_zugriff') === $stufe) {
            return true;
        }
    }
    return false;
}

// Vier-Augen-Prinzip: Entwurf und Freigabe dürfen nicht aus einer Hand kommen.
function freigabe_zulaessig(string $entwurfKonto, string $freigabeKonto): bool
{
    return $entwurfKonto !== $freigabeKonto;
}

Zwei Stellen brechen in der Praxis regelmäßig. Die erste ist die Erweiterung: Ein zugekauftes oder selbst gebautes Modul bringt eigene Rechte mit, die in keiner Rolle auftauchen und deshalb im Zweifel bei der Administration landen. Die zweite ist die Datenbank: Wer direkten Zugriff auf sie hat, umgeht das Rollensystem, weil die Rechte in der Anwendung liegen und nicht in den Tabellen. Beide Stellen gehören in dieselbe Übersicht wie die Backend-Rollen. Drei Abfragen zeigen den Ist-Stand in wenigen Minuten.

Die dritte Abfrage ist die aufschlussreichste, weil sie den Wildwuchs sichtbar macht: Eine Rolle, deren Rechtezahl deutlich über den anderen liegt, ist in der Regel keine Rolle mehr, sondern eine Sammelstelle. Der zweite Blick gilt den Konten mit gesetztem Administratorkennzeichen, denn dieses Kennzeichen hebt jede Rollenzuordnung auf und taucht in keiner Rollenübersicht auf. Beide Werte gehören in die regelmäßige Shopware-Wartung, zusammen mit der Frage, welche Rolle seit dem letzten Durchlauf gewachsen ist und aus welchem Anlass.

Wenn ein Zugang ausscheidet

Der Austritt ist der Punkt, an dem sich zeigt, ob das Modell trägt. Das BSI formuliert die Anforderung knapp: Bei personellen Veränderungen müssen die nicht mehr benötigten Benutzendenkennungen und Berechtigungen entfernt werden (BSI, ORP.4.A2). In der Praxis scheitert das seltener am Willen als an der Reihenfolge – der Zugang wird gesperrt, bevor jemand weiß, welche laufenden Vorgänge daran hängen, oder er bleibt offen, weil noch ein Export aussteht. Ein festes Verfahren löst beides, weil es die Reihenfolge vorgibt.

1. Übergabe vor der Sperrung. Offene Vorgänge, geplante Aktionen und vorbereitete Preisänderungen auf eine übernehmende Rolle umschreiben, bevor der Zugang endet. Danach ist die Zuordnung schwerer zu rekonstruieren.
2. Persönliches Konto deaktivieren, nicht löschen. Ein deaktiviertes Konto behält die Verknüpfung zu vergangenen Änderungen im Protokoll. Ein gelöschtes Konto lässt an dieser Stelle eine Lücke, die sich später nicht schließen lässt.
3. Technische Zugänge trennen. Zugangsschlüssel für Schnittstellen, die auf die Person ausgestellt waren, austauschen und auf ein benanntes Dienstkonto umstellen.
4. Gemeinsame Geheimnisse wechseln. Zugangsdaten, die die Person kannte und die nicht personengebunden sind, erneuern – beginnend bei den Zugängen mit Schreibrechten auf Preise, Bestellungen und Kundendaten.
5. Rechte am Ende zählen. Nach dem Austritt eine kurze Gegenprobe: Existiert die Kennung noch, taucht sie in einer Rolle auf, meldet sich noch eine Sitzung mit ihr an? Das Ergebnis gehört mit Datum zur Personalakte des Vorgangs.

Prüfliste für das Rechteinventar

Ein Rechteinventar ist kein Projekt, sondern ein wiederkehrender Termin. Zweimal im Jahr genügt in den meisten Handelsbetrieben; bei starker Fluktuation oder häufig wechselnden Dienstleistern lohnt der Quartalsrhythmus. Der Durchlauf dauert erfahrungsgemäß zwei bis drei Stunden, wenn die Abfragen aus dem vorigen Abschnitt vorbereitet sind, und lässt sich als Teil eines Shop-Checks mit den übrigen Betriebsfragen zusammenlegen.

• Alle Backend-Konten auflisten und jedem eine benannte Person zuordnen; Konten ohne Zuordnung deaktivieren.
• Administratorkennzeichen zählen und je Konto begründen; jede Begründung, die eine Fachaufgabe nennt, verweist auf eine fehlende Rolle.
• Rollen nach Rechtezahl sortieren und die größte Rolle gegen ihre Aufgabenbeschreibung prüfen.
• Preis- und Rabattrechte gegen das Freigabeverfahren prüfen: Kann eine einzelne Person anlegen und freigeben?
• Externe Zugänge mit Auftrag, Ansprechpartner und Ablaufdatum gegenprüfen; Zugänge ohne Ablaufdatum befristen.
• Exportrechte auf Kundendaten einzeln bestätigen und den Umfang je Recht auf die benötigten Felder begrenzen.
• Ergebnis mit Datum ablegen und beim nächsten Durchlauf gegen den vorigen Stand halten, statt neu zu beginnen.

Wo der Aufwand wirklich liegt

Der technische Teil eines Rollenmodells ist an einem Nachmittag erledigt: Rollen anlegen, Rechte zuordnen, Benutzer umhängen. Der Aufwand liegt davor und danach. Davor in der Frage, welche Aufgaben der Betrieb tatsächlich kennt – eine Frage, die selten jemand aus dem Stand beantworten kann, weil Zuständigkeiten mündlich gewachsen sind und in keiner Datei stehen. Danach in der Disziplin, jede neue Anforderung auf eine bestehende Rolle abzubilden, statt eine Ausnahme zu vergeben; jede Ausnahme ist der erste Schritt zurück in den Zustand, den das Modell beenden sollte. Erfahrungsgemäß trägt ein Schnitt etwa zwei Jahre, bevor er eine Überarbeitung braucht – so lange dauert es, bis genügend neue Aufgaben entstanden sind, um die Grenzen zu verschieben. Wer diesen Rhythmus einplant, führt keine Aufräumaktion durch, sondern eine Fortschreibung, und die kostet einen Bruchteil.