Schlüssel, Berechtigungen und Tenants

Zugang ist der Teil eines Integrationsprojekts, der in fünf Minuten entschieden wird und mit dem Sie fünf Jahre leben. Dieser Artikel sind die fünf Minuten, ordentlich gemacht.

Drei Arten von Identität — und sie sind nicht austauschbar

Die Plattform unterscheidet zwischen Menschen, Käufern und Maschinen. Sie zu verwechseln ist die Wurzel der meisten Zugangsprobleme in diesem Bereich.

Eine Maschine ist keine Person. Sie hat keinen Vorgesetzten, kein Austrittsdatum und keinen Passwort-Reset, und sie darf sich nicht die Zugangsdaten von jemandem leihen, der alle drei hat.

Der Credential-Vertrag

Jeder Aufruf an https://api.revenexx.com/v1 braucht zwei Dinge:

Senden Sie ein Credential, nie beide. Maschine-zu-Maschine-Integrationen — fast alles, worum es in diesem Bereich geht — verwenden den API-Schlüssel. Das Bearer-Token ist für eine Anwendung, die im Namen eines angemeldeten Benutzers handelt, und das ist Territorium des Developer Portals.

Ein Schlüssel je Integration, nie je Person

Diese Regel macht alles Weitere handhabbar.

Je Integration heißt: ein Schlüssel für die ERP-Bestellsynchronisation, ein anderer für den nächtlichen BI-Abzug, ein dritter für den Bestands-Push des Lagers. Jeder ist nach seiner Aufgabe benannt — erp-order-sync-prod, nicht key3 und nicht thomas.

Vier Dinge folgen daraus, und jedes ist ein vermiedener schlechter Tag:

Sie können eine Integration widerrufen, ohne die anderen zu stoppen. Der BI-Schlüssel taucht im Screenshot eines Support-Tickets auf; Sie widerrufen ihn und stellen ihn neu aus, und die Bestellungen fließen weiter. Mit einem geteilten Schlüssel stoppt der Widerruf alles auf einmal.

Die Logs sagen Ihnen, wer was getan hat. Ein unerwarteter Schreibzugriff lässt sich einem System zuordnen. Mit einem geteilten Schlüssel ist „etwas hat um 02:14 Uhr 4.000 Produkte geschrieben" der Anfang einer Untersuchung statt ihr Ende.

Scopes können eng geschnitten sein. Ein Schlüssel, der fünf Integrationen bedienen muss, braucht die Vereinigung von fünf Berechtigungsmengen — und das ist gar keine Einschränkung mehr.

Niemand nimmt ihn beim Gehen mit. Ein nach einer Person benannter Schlüssel verlässt mit ihr das Haus, und entweder funktioniert er weiter — ein Sicherheitsproblem — oder jemand löscht ihn, und eine Integration stirbt an einem Freitag.

Scopes: genau genug geben

Ein Scope ist eine Berechtigung, die der Schlüssel trägt. Der Schlüssel kann nur, was seine Scopes erlauben — ein Schlüssel kann stärker eingeschränkt sein als das Konto dahinter, nie weniger.

Beim Anlegen eines Schlüssels stehen zwei Arten zur Wahl.

Breite Plattform-Scopes, einer je Plattformbereich:

Capability-Scopes, enger geschnitten und das, was die meisten Integrationen tatsächlich bekommen sollten — als Freitext in der Form resource.action eingetragen: products.read, orders.update, orders.create, prices.write.

Ein durchgerechnetes Beispiel für einen typischen ERP-Konnektor:

Dieser Schlüssel kann kein Produkt veröffentlichen, keine E-Mail senden, keinen Kundendatensatz anfassen und nichts löschen. Wird er gestohlen, ist der Schaden durch diese Liste begrenzt. Trägt er *, ist der Schaden nur durch Ihre Vorstellungskraft begrenzt.

Tenant-Bindung

Ein Schlüssel gehört zu genau einem Tenant. Einen anderen erreicht er nicht, und wenn der Header X-Revenexx-Tenant der Bindung des Schlüssels widerspricht, wird der Aufruf abgelehnt statt stillschweigend umgedeutet.

Daraus folgt eine praktische Konsequenz, die Sie einplanen sollten: eine Sandbox braucht eigene Schlüssel. Sie können eine Sandbox-Integration nicht per Header-Änderung auf Produktion zeigen lassen — und genau das ist der Zweck. Siehe Die Sandbox.

Betreiben Sie mehr als einen Tenant — ein zweiter Markt, eine Tochter, eine eigene Marke —, hat jeder seine eigenen Schlüssel, seine eigenen Scopes und seinen eigenen Widerruf. Siehe Das Tenant-Modell.

Das Secret wird einmal angezeigt

Beim Anlegen eines Schlüssels wird das Secret einmal angezeigt und danach nie wieder. Es wird gehasht gespeichert; niemand — nicht Sie, nicht Ihr Integrator, nicht der revenexx-Support — kann es später abrufen. Geht es verloren, bleibt nur: widerrufen und neu ausstellen.

Das ist ein Feature, und es verändert Ihre Übergabe: Das Secret wandert direkt dorthin, wo der Integrator Secrets aufbewahrt — ein Secret-Manager, ein CI-Variablenspeicher, der Credential-Speicher des ERP — und nie in eine E-Mail, eine Chat-Nachricht oder ein Ticket.

Rotation und Widerruf

Rotation heißt: einen funktionierenden Schlüssel nach Plan ersetzen, bevor etwas schiefgegangen ist. Einmal im Jahr ist eine vernünftige Grundlinie, öfter für alles mit breiten Scopes. Die sichere Reihenfolge ist immer dieselbe:

1. Den neuen Schlüssel mit denselben Scopes anlegen, der Name trägt das Datum — erp-order-sync-prod-2027-03.
2. Ihn neben dem alten ausrollen. Beide sind aktiv.
3. Zusehen, wie der neue Schlüssel erfolgreich Aufrufe macht.
4. Den alten Schlüssel widerrufen.
5. Prüfen, dass nichts gebrochen ist, dann das alte Secret überall dort entfernen, wo es lag.

Widerruf wirkt sofort und ist unumkehrbar. Alles, was den Schlüssel noch verwendet, bekommt ab diesem Moment 401 Unauthorized. Widerrufen Sie ohne Zögern, wenn ein Schlüssel in einem Screenshot, einem Repository, einem Support-Ticket oder einer E-Mail auftaucht — und wenn der Vertrag eines Integrators endet.

Ein Zugangsreview, das zweimal im Jahr lohnt

Öffnen Sie Einstellungen › API-Schlüssel und stellen Sie zu jedem Schlüssel vier Fragen:

1. Wissen wir noch, wofür er ist? Ein Schlüssel, den niemand erklären kann, ist ein Schlüssel zum Widerrufen.
2. Passt sein Scope noch zu seiner Aufgabe? Scopes werden beim Troubleshooting geweitet und danach nie wieder verengt.
3. Wird er noch verwendet? Ein Schlüssel ohne jüngere Aktivität ist entweder tot oder kurz davor, jemanden zu überraschen.
4. Trägt irgendetwas *, das es nicht sollte?

Weiter

• Einen API-Schlüssel anlegen — die zehn Minuten, die daraus Praxis machen.
• Die Sandbox — wohin ein Integrator zeigen sollte, bevor es Produktion wird.