Lizenzverwaltung mit Prüfspur
Schlüssel sperren, entsperren, Gerätebindung zurücksetzen, Laufzeit verlängern. Jede dieser Aktionen greift in etwas ein, für das jemand bezahlt hat — und gehört deshalb protokolliert.
947 Wörter · 5 Min. Lesezeit
- lizenzen
- architektur
- sicherheit
Das Lizenzsystem von 2023 hatte die Grundlagen: Schlüsselformat, Hashes statt Klartext, weiche Gerätebindung. Was fehlte, war alles, was mit Verwaltung zu tun hat — und das ist bei Lizenzen mehr Arbeit als die Prüfung selbst.
Die Aktionen und was sie bedeuten
| Aktion | Wirkung |
|---|---|
| sperren | Schlüssel gilt sofort nicht mehr, bleibt aber bestehen |
| entsperren | Rücknahme |
| Gerätebindung zurücksetzen | Zähler der Installationen auf null |
| Laufzeit verlängern | Ablaufdatum verschieben |
| Antrag genehmigen / ablehnen | Aus einem Antrag wird ein Schlüssel — oder nicht |
Jede dieser Aktionen greift in etwas ein, wofür jemand bezahlt hat. Bei jeder muss man später beantworten können, wer sie wann warum ausgelöst hat.
Die Prüfspur
CREATE TABLE lizenz_pruefspur (
id INTEGER PRIMARY KEY,
zeitpunkt DATETIME NOT NULL,
akteur VARCHAR(40) NOT NULL,
aktion VARCHAR(40) NOT NULL,
schluessel_id INTEGER NULL,
vorher TEXT NULL,
nachher TEXT NULL,
bemerkung TEXT NULL
);Zwei Entscheidungen darin sind wichtig.
Vorher und nachher, nicht nur die Aktion. „Status geändert" hilft nicht. „Status von aktiv auf gesperrt" beantwortet die Frage, ohne dass man rekonstruieren muss.
Die Spur ist nur anhängend. Es gibt keine Möglichkeit, Einträge zu ändern oder zu löschen — auch nicht für mich. Eine Prüfspur, an der man arbeiten kann, ist keine.
Zustände statt Schalter
Der Teil, an dem ich am längsten gesessen habe, war nicht die Prüfspur, sondern die Frage, welche Zustände ein Schlüssel überhaupt haben kann.
Meine erste Fassung hatte ein Feld aktiv mit ja oder nein. Das reicht für ungefähr drei Wochen. Danach stellt sich heraus, dass „nicht aktiv" mindestens vier verschiedene Dinge bedeuten kann:
- abgelaufen — die Laufzeit ist vorbei, der Kunde könnte verlängern
- gesperrt — von mir ausgesetzt, meistens wegen einer offenen Zahlung
- widerrufen — endgültig, etwa nach einer Rückbuchung
- noch nicht ausgegeben — erzeugt, aber niemandem zugeordnet
Diese vier Fälle unterscheiden sich in dem, was der Kunde sieht, in dem, was er tun kann, und darin, ob eine Rückkehr möglich ist. Sie in einem Wahrheitswert zusammenzufassen bedeutet, dass die Information verloren geht — und dass der Support raten muss.
Damit kam auch die Frage nach erlaubten Übergängen. Von gesperrt zurück nach aktiv: ja. Von widerrufen zurück: nein, nur über einen neuen Schlüssel. Diese Regeln stehen an einer Stelle und nicht in der Oberfläche verteilt:
const ERLAUBT = {
ausgegeben: ["aktiv", "widerrufen"],
aktiv: ["gesperrt", "abgelaufen", "widerrufen"],
gesperrt: ["aktiv", "widerrufen"],
abgelaufen: ["aktiv", "widerrufen"],
widerrufen: [],
};Ein Übergang, der nicht in dieser Tabelle steht, wird abgelehnt — mit einer Meldung, die sagt, was stattdessen möglich wäre. Das hat mir später mehrfach Fehlbedienungen erspart, und es macht die Prüfspur lesbar: Jede Zeile enthält einen Übergang, den es tatsächlich gibt.
Was ich beim Bau der Verwaltung noch gelernt habe
Anträge sind ein eigener Zustand. Ein Antrag ist kein Schlüssel. Er hat einen Antragsteller, einen Zeitpunkt, eine Begründung und einen Bearbeiter — und aus ihm entsteht bei Genehmigung ein Schlüssel. Wer beides vermischt, kann später nicht beantworten, warum jemand einen Schlüssel hat.
Kommentare an Schlüsseln sind Gold wert. Ein Freitextfeld, in das man schreibt, warum gesperrt wurde. In einem halben Jahr weiß man es sonst nicht mehr.
Bündelaktionen brauchen ein Protokoll pro Vorgang. Zwanzig Schlüssel auf einmal zu verlängern ist eine Aktion für den Bediener und zwanzig Einträge in der Prüfspur. Sonst fehlt genau die Zeile, die man sucht.
Was eine Prüfspur im Alltag wert ist
Ich habe die Prüfspur gebaut, weil es sich richtig anfühlte. Benutzt habe ich sie anders, als ich dachte.
Nicht bei Streitfällen — davon gab es kaum welche.
Sondern bei eigenen Fehlern. „Warum ist dieser Schlüssel gesperrt?" — Antwort in fünf Sekunden statt Rekonstruktion aus dem Gedächtnis. Und einmal die unangenehme Erkenntnis, dass ich selbst es war, bei einer Massenaktion, die mehr erfasst hatte als beabsichtigt.
Und beim Nachvollziehen von Abläufen. Wie lange dauert es zwischen Antrag und Genehmigung? Wie oft wird eine Gerätebindung zurückgesetzt? Beides waren Fragen, die ich vorher nicht beantworten konnte.
Der zweite Punkt ist der, den ich am wenigsten erwartet hatte: Eine Prüfspur schützt vor allem gegen die eigenen Irrtümer. Ohne sie hätte ich einen selbst verursachten Fehler für ein Systemproblem gehalten und an der falschen Stelle gesucht.
Die Massenaktion, die ich seitdem anders baue
Aus genau diesem Vorfall ist eine Regel geworden.
Jede Aktion, die mehr als einen Datensatz betrifft, zeigt vorher an, was sie tun wird — mit Anzahl und einer Stichprobe der betroffenen Einträge.
Sie schreibt einen Eintrag pro Datensatz, nicht einen für den ganzen Vorgang.
Sie ist rückgängig zu machen oder wenigstens nachvollziehbar genug, um von Hand korrigiert zu werden.
Der erste Punkt hätte meinen Fehler verhindert. Ich hätte gesehen, dass die Auswahl vierzehn Schlüssel umfasst statt der drei, die ich meinte — und der Grund war ein Filter, der anders wirkte, als ich angenommen hatte.
Bestätigungen mit Zahl sind lästig und die einzige Bremse, die bei Massenaktionen zuverlässig greift.
Was in eine Prüfspur nicht gehört
Genauso wichtig wie der Inhalt ist, was nicht hineingehört — sonst wird aus einem Werkzeug eine Datensammlung.
Keine vollständigen Schlüssel. Ein Ausschnitt zur Wiedererkennung reicht.
Keine personenbezogenen Details über den Zweck hinaus. Wer, was, wann — nicht mehr.
Keine Inhalte aus Anfragen. Der Rumpf einer Anfrage kann alles Mögliche enthalten.
Keine internen Fehlerdetails. Wenn eine Aktion scheitert, gehört das Ergebnis in die Spur, nicht der Verlaufsstapel.
Dazu eine Frist. Eine Prüfspur, die für immer wächst, ist irgendwann eine Sammlung, die man erklären muss. Bei mir bleiben Einträge zwei Jahre — lang genug für jede Frage, die tatsächlich gestellt wird, und kurz genug, dass die Tabelle handhabbar bleibt.
Was das mit Vertrauen zu tun hat
Ein Lizenzsystem ist eine Machtposition. Ich kann jemandem den Zugang zu etwas nehmen, das er gekauft hat — versehentlich, durch einen Fehler oder weil ich mich vertue.
Die Prüfspur ist deshalb nicht nur ein Werkzeug für die Fehlersuche. Sie ist die Möglichkeit, im Streitfall belegen zu können, was tatsächlich passiert ist. Das schützt beide Seiten, und zwar die schwächere mehr als mich.