Ein internes Verwaltungswerkzeug entsteht in den meisten Produkten ungeplant: Zuerst ein Skript, dann eine geschützte Seite, dann ein gewachsenes Sammelsurium mit weitreichenden Rechten. Es ist damit oft der am schlechtesten gesicherte Teil eines Produkts — und derjenige mit dem grössten Zugriff.
Warum es das schwächste Glied ist
Das Verwaltungswerkzeug greift auf Daten aller Kunden zu und umgeht damit typischerweise die Mandantentrennung, die überall sonst gilt. Es wird intern genutzt, also ohne die Sorgfalt, die für Kundenschnittstellen aufgewendet wird. Und es wächst um Funktionen, die jemand gerade braucht.
Ein Angreifer, der Zugang zu einem Verwaltungskonto erlangt, hat nicht Zugriff auf einen Kunden, sondern auf alle. Der Aufwand für Absicherung sollte sich daran orientieren, nicht an der Zahl der internen Nutzenden.
Die Kernfunktionen
In der Praxis braucht ein Verwaltungswerkzeug vier Dinge. Erstens eine Suche über Konten und Nutzende, denn der häufigste Anlass ist eine Supportanfrage zu einem konkreten Fall.
Zweitens die Möglichkeit, den Zustand eines Kontos zu sehen, wie er tatsächlich ist — Abonnement, Nutzungsgrenzen, aktive Merkmale, letzte Ereignisse. Ohne diese Ansicht besteht Support aus Vermutungen.
Drittens die Möglichkeit, gezielt einzugreifen: ein Merkmal freischalten, eine Grenze anheben, einen Abrechnungszustand korrigieren. Diese Eingriffe sind es, die eine saubere Protokollierung erfordern.
Viertens die Sicht auf die Abläufe, die im Hintergrund laufen — fehlgeschlagene Nachrichten, hängende Aufgaben, abgelehnte Zahlungen.
Stellvertretender Zugriff: nützlich und heikel
Die Möglichkeit, ein Produkt aus der Sicht einer Kundin zu sehen, ist im Support ausserordentlich wertvoll. Sie ist zugleich ein Zugriff auf personenbezogene Daten und braucht deshalb Regeln.
Drei Anforderungen sind unverzichtbar. Erstens muss jeder solche Zugriff protokolliert werden, mit handelnder Person, betroffenem Konto, Zeitpunkt und Anlass. Zweitens sollte die Sitzung erkennbar sein, damit niemand versehentlich im Namen einer Kundin handelt. Drittens sollte sie zeitlich begrenzt sein und schreibende Zugriffe entweder ausschliessen oder gesondert kennzeichnen.
Datenschutzrechtlich ist dieser Zugriff eine Verarbeitung, die im Verzeichnis auftauchen und in der Datenschutzerklärung abgebildet sein sollte. Kunden aus regulierten Bereichen fragen im Beschaffungsprozess ausdrücklich danach.
Protokollierung ist der eigentliche Zweck
Ein Protokoll interner Eingriffe ist kein Nebenprodukt, sondern der Grund, warum ein strukturiertes Werkzeug besser ist als ein Skript. Es beantwortet die Frage, wer wann was geändert hat — und diese Frage kommt zuverlässig.
Wichtig ist, dass das Protokoll nachträglich nicht veränderbar ist und dass es auch lesende Zugriffe erfasst, wenn es um personenbezogene Daten geht. Ein Protokoll, das nur Schreibvorgänge kennt, beantwortet die Datenschutzfrage nicht.
Merkmalsschalter gehören hierher
Die Möglichkeit, Funktionen je Konto ein- oder auszuschalten, ist im Verwaltungswerkzeug gut aufgehoben: Sie erlaubt Erprobungen mit einzelnen Kunden, gestaffelte Einführungen und ein schnelles Abschalten, wenn etwas nicht funktioniert.
Die Disziplin, die dazugehört, ist das Aufräumen. Ein Schalter, der seit einem Jahr überall auf demselben Wert steht, ist keine Flexibilität mehr, sondern eine Verzweigung im Code, die niemand mehr versteht.
Zugang absichern
Das Verwaltungswerkzeug gehört nicht unter dieselbe Anmeldung wie das Produkt. Mindestens erforderlich sind eine getrennte Berechtigungsprüfung, Mehrfaktor-Authentifizierung und, wo möglich, eine Einschränkung des Zugangs auf bekannte Netzwerke.
Die interne Berechtigung sollte zudem gestuft sein. Nicht jede Person im Support braucht die Möglichkeit, Abrechnungszustände zu ändern oder Konten zu löschen — und je weniger Konten die weitreichenden Rechte haben, desto kleiner ist die Angriffsfläche.

