Einem Dienstleister Zugang zu Shopware geben: Admin-Benutzer, Rollen, Server, Entzug

Ein neuer Dienstleister soll am Shop arbeiten. Der schnellste Weg ist der schlechteste: die Zugangsdaten des eigenen Admin-Benutzers weitergeben. Danach weiß niemand mehr, wer was geändert hat, und beenden lässt sich der Zugang nur, indem man allen ein neues Passwort gibt.

Shopware bringt alles mit, um es besser zu machen. Wir haben dafür am 30.10.2026 das Datenmodell und die Konsolenbefehle in Shopware 6.6.10.6 und 6.7.2.2 nachgelesen und die wichtigsten Punkte am 11.11.2026 in 6.7.16.0 wiederholt. Beide Versionen verhalten sich in den hier beschriebenen Punkten gleich – mit einer Ausnahme beim Deaktivieren von Benutzern, die neuere 6.7-Versionen anders lösen (Abschnitt „Entzug“).

Ein Benutzer je Person

In der Administration legen Sie Benutzer unter Einstellungen → System → Benutzer & Rechte an. Jeder Benutzer hat Name, E-Mail-Adresse, Passwort und zwei Felder, die für Dienstleister wichtig sind:

Auf dem Server lässt sich ein Benutzer auch per Konsole anlegen:

bin/console user:create --firstName=Vorname --lastName=Nachname \
  --email=person@dienstleister.example vorname.nachname

Ohne --password erzeugt der Befehl ein zufälliges Passwort und gibt es aus. bin/console user:list zeigt alle vorhandenen Benutzer – ein guter erster Blick bei jeder Übernahme.

Ein eigener Benutzer je Person hat einen praktischen Nebeneffekt: Shopware speichert an Bestellungen und Kunden, welcher Benutzer sie angelegt oder zuletzt geändert hat. Mit geteilten Zugangsdaten steht dort immer derselbe Name.

Rollen statt Vollzugriff

Eine Rolle ist in Shopware eine Liste von Rechten der Form product:read oder order:update. In der Administration setzen Sie diese Rechte nicht einzeln, sondern je Bereich in vier Stufen: ansehen, bearbeiten, anlegen, löschen. Hinter „Produkte ansehen“ stehen in 6.7.2.2 mehr als vierzig Einzelrechte – von Herstellern über Preise bis zu SEO-Adressen –, dazu unter anderem die Leserechte für Medien und Erlebniswelten. Diese Zuordnung pflegt die Administration selbst.

Welche Stufe ein Dienstleister braucht, hängt vom Auftrag ab:

Schnittstellen über Integrationen

Ein ERP, ein Feed-Werkzeug oder ein Automatisierungsdienst sollte sich nie mit dem Benutzer eines Menschen anmelden. Dafür gibt es Integrationen unter Einstellungen → System → Integrationen, oder per Konsole mit bin/console integration:create.

Eine Integration hat im Datenmodell:

• einen eigenen Zugangsschlüssel und ein Geheimnis,
• wahlweise Vollzugriff (admin) oder eigene Rollen, genau wie ein Benutzer,
• das Feld last_usage_at – Shopware trägt dort ein, wann sich die Integration zuletzt einen Zugangs-Token geholt hat.

Das letzte Feld ist beim Aufräumen Gold wert. Eine Integration, die seit Monaten nicht benutzt wurde, gehört meist zu einem Werkzeug, das längst abgeschaltet ist. Wie sich die beiden APIs unterscheiden, beschreibt der Ratgeber Store API oder Admin API.

Zugang zum Server

Für Updates, Plugins und Fehlersuche braucht ein Dienstleister meist auch den Server: SSH oder SFTP, oft die Datenbank. Hier gilt dieselbe Regel wie im Admin: ein eigener Zugang je Person.

OpenSSH erlaubt, einen Schlüssel zusätzlich zu begrenzen, etwa auf bestimmte Absender-Adressen (from=) oder auf einen einzigen erzwungenen Befehl (command=). Für einen Menschen, der frei arbeiten soll, passt der erzwungene Befehl nicht. Für automatisierte Abläufe dagegen sehr gut.

Wir haben das im September 2026 für den Deploy-Schlüssel unserer eigenen Website umgesetzt: Ein erzwungener Befehl lässt nur das Übertragen in ein fest verdrahtetes Verzeichnis zu, dazu das Anlegen dieses Verzeichnisses und wenige feste Prüfaufrufe. Neun Negativproben mit einem eigens erzeugten Testschlüssel – Shell, Lesen fremder Dateien, Schreiben in ein Nachbarverzeichnis, Befehlsverkettung – wurden abgewiesen, ebenso drei Proben aus dem echten CI-Lauf. Die Grenze gehört dazu: Die Begrenzung gilt für diesen Schlüssel. Andere Schlüssel in derselben Datei bleiben, wie sie sind. Ein Server wird nicht sicherer, weil ein Zugang begrenzt ist.

Shopware-Konto und Lizenzen

Updates aus dem Store und Plugin-Lizenzen hängen am Shopware-Konto, nicht am Shop selbst. Auch dort gilt: Das Konto gehört Ihrem Unternehmen, der Dienstleister bekommt einen eigenen Zugang mit passenden Rechten. Lauten Lizenzen auf den Dienstleister, wird ein späterer Wechsel aufwendig. Prüfen Sie deshalb beim Start, auf wen die Lizenzen laufen. Wie eine Übertragung abläuft, beschreibt der Ratgeber Shopware-Plugin-Lizenzen beim Dienstleisterwechsel.

Entzug am Projektende

Der letzte Schritt ist der, der nach Projektende leicht liegen bleibt. Dabei gibt es eine Falle, die von der Shopware-Version abhängt: das Feld „aktiv“ eines Benutzers.

Wir haben das am 30.10.2026 in Wegwerf-Installationen nachgestellt: Benutzer anlegen, auf inaktiv setzen, mit Passwort anmelden. In 6.6.10.6 und 6.7.2.2 gab Shopware ein gültiges Zugangs-Token aus, und die Admin-API antwortete damit normal. Am 11.11.2026 haben wir den Test in 6.6.10.6 und 6.7.16.0 wiederholt: 6.6.10.6 verhielt sich wie zuvor, 6.7.16.0 lehnte die Anmeldung ab und nahm auch das vorher ausgestellte Token nicht mehr an.

Behoben hat Shopware das in Version 6.7.13.0. Seitdem prüft der Kern das Feld bei der Anmeldung, lehnt Tokens inaktiver Benutzer ab und widerruft beim Deaktivieren deren Refresh-Tokens. Laut der Beschreibung der Änderung zeigte die Administration den Zustand vorher auch nicht durchgängig an.

Bei einem Wechsel des Dienstleisters ist diese Liste auch der Ausgangspunkt für den neuen. Wenn Sie dabei Unterstützung möchten – von der Bestandsaufnahme der Zugänge bis zur laufenden Betreuung –, finden Sie den Rahmen unter Shopware Support.

Ein Zugang je Person, so wenig Rechte wie möglich, ein Enddatum von Anfang an. Und beim Entzug löschen und die Anmeldung prüfen – in vielen Shopware-Versionen hält „inaktiv“ niemanden auf.