Berechtigungen für API-Schlüssel entscheiden darüber, was ein offengelegter Schlüssel beschädigen kann. In einem Link-Tool ist die sichere Standardeinstellung ein Schlüssel, der an einen einzelnen Workspace gebunden, auf die niedrigste für die Aufgabe ausreichende Rolle begrenzt, als Pepper-Hash gespeichert, separat mit einem Limit versehen und mit einem Ablaufdatum ausgestattet ist. Ein Schlüssel, der nur Links erstellt, hat nichts an Webhooks, Mitgliedern oder Abrechnung zu suchen und darf niemals einen Admin-Endpunkt öffnen. Das ist das Prinzip der geringsten nötigen Rechte, und vieles davon hängt von Entscheidungen ab, die man in den dreißig Sekunden beim Erstellen des Schlüssels trifft.
Im vergangenen Jahr habe ich viele Automatisierungs-Setups gelesen, und das Muster wiederholt sich: Jemand fügt an einem Freitagnachmittag seinen allmächtigen Schlüssel in n8n ein, alles funktioniert, und niemand denkt wieder darüber nach, bis die Person das Unternehmen verlässt oder der Workflow-Export in einem gemeinsam genutzten Laufwerk landet. Der Rest dieses Beitrags erklärt, wie API-Schlüssel-Scopes und Rollen in einem Kurzlink-Produkt funktionieren, was die einzelnen Rollen tatsächlich tun können und wie man einen Schlüssel an ein Automatisierungstool übergibt, ohne den Workspace aus der Hand zu geben.
Der Beitrag ergänzt unsere umfassendere Sicherheits-Checkliste für URL-Shortener, die Scans, Webhook-Signaturen und Audit-Logs für die gesamte Plattform abdeckt. Hier geht es gezielt um den Schlüssel selbst.
Was Berechtigungen für API-Schlüssel in einem Link-Tool bedeuten
Die API eines Link-Tools greift auf mehr als Links zu. Dasselbe Token, das go.example.com/spring-sale erstellt, kann je nach seinen Berechtigungen Klickanalysen lesen, eine benutzerdefinierte Domain hinzufügen, ein Mitglied einladen oder einen Webhook registrieren, der jedes Ereignis an einen externen Server übermittelt. Das macht mir besonders Sorgen. Ein Webhook ist ein dauerhafter Datenstrom, den die erstellende Person auf einen beliebigen Server richten kann, ohne dass es in Ihrem Team zwangsläufig wochenlang jemand bemerkt.
Berechtigungen haben also drei Achsen. Wo funktioniert der Schlüssel, also in welchem Konto oder Workspace? Was darf er dort tun, also lesen, schreiben oder administrieren? Und wie lange sowie wie schnell? Die Definition des NIST für das Prinzip der geringsten nötigen Rechte läuft darauf hinaus, nur den für eine Aufgabe nötigen Zugriff zu gewähren, und alle drei Achsen gehören dazu. Ein Schlüssel mit Nur-Lese-Rechten, der nie abläuft und kein Limit hat, ist zeitlich trotzdem übermäßig privilegiert.
An den Workspace gebundene API-Schlüssel: ein Schlüssel, ein Workspace
Bei Elido wird jeder Schlüssel innerhalb eines Workspace erstellt und bleibt dort. Ruft man damit Endpunkte eines anderen Workspace auf, erhält man 404, dieselbe Antwort wie bei einem nicht existierenden Workspace. Ein Schlüssel kann dadurch nicht einmal bestätigen, dass andere Workspaces vorhanden sind.
Das ist wichtiger, als es zunächst klingt. Agenturen und größere Teams gehören oft fünf oder zehn Workspaces an. Wenn ein persönlicher Schlüssel alle Berechtigungen seiner erstellenden Person geerbt hätte, würde ein einziges offengelegtes Token aus einem Kundenprojekt alle Kunden öffnen. An einen Workspace gebundene API-Schlüssel begrenzen den möglichen Schaden auf einen Workspace.
Der Schlüssel ist außerdem auf die beim Erstellen gewählte Rolle begrenzt und überschreitet niemals die aktuelle Rolle seiner erstellenden Person. Der effektive Zugriff entspricht dem niedrigeren der beiden Werte. Wird der Admin, der einen Schlüssel erstellt hat, zum Editor herabgestuft, sinkt auch der Schlüssel mit. Benutzerdefinierte Berechtigungen dieser Person werden ebenfalls entfernt, sobald die Rolle des Schlüssels die niedrigere ist, denn diese Berechtigungen beschreiben die Person und nicht den Schlüssel.
Rollenbasierte API-Schlüssel: Was die einzelnen Rollen können
Elido-Schlüssel verwenden dieselben vier Rollen wie Personen: Viewer, Editor, Admin und Owner. Beim Erstellen des Schlüssels wird eine Rolle ausgewählt. Lässt man sie weg, erhält der Schlüssel standardmäßig die Editor-Rolle. Das deckt die übliche Automatisierungsaufgabe ab, Links zu erstellen und Analysen zu lesen, ohne Zugriff auf Admin-Funktionen.
In der Praxis sieht das für die Bereiche aus, mit denen Integrationen normalerweise arbeiten.
| Rolle | Links und Kampagnen | Analysen | Webhooks | Domains, Mitglieder, Schlüssel |
|---|---|---|---|---|
| viewer | Nur lesen | Lesen, CSV-Exporte ausführen | Endpunkte auflisten | Domains und Mitglieder ansehen |
| editor | Erstellen, bearbeiten, löschen, in großen Mengen erstellen | Lesen, CSV-Exporte ausführen | Endpunkte auflisten | Domains und Mitglieder ansehen |
| admin | Alles, was Editor kann | Zusätzlich Datenexporte, geplante Berichte | Erstellen, ändern, erneut senden | Domains, Mitglieder und Schlüssel verwalten |
| owner | Alles | Alles | Alles | Alles |
Ein Reporting-Dashboard, das Klickzahlen in ein BI-Tool übernimmt, braucht Viewer. Ein Google-Sheets-Job, der Kampagnenlinks erstellt, braucht Editor. Fast keine Automatisierung im Alltag benötigt Admin, und einen Owner-Schlüssel würde ich als Warnsignal betrachten: Owner ist für die Menschen gedacht, die den Workspace betreiben, und mir fällt keine Automatisierungsaufgabe ein, die ihn benötigt.
Zwei Einschränkungen sollte man kennen. Nur Admins und Owner können überhaupt Schlüssel erstellen, auflisten oder widerrufen. Ein Viewer- oder Editor-Schlüssel kann sich also keinen mächtigeren Schlüssel ausstellen. Außerdem erreicht kein Schlüssel irgendeiner Rolle die Admin-API der Plattform. Diese Oberfläche lehnt API-Key-Authentifizierung grundsätzlich mit 403 und der Meldung "admin access requires an interactive session" ab. Ein Schlüssel ist für eine Workspace-Integration gedacht, und genau das öffnet er.
Warum die Webhook-Verwaltung einen Admin-Schlüssel benötigt
Das überrascht viele. Das Lesen der Liste der Webhook-Endpunkte ist für jedes Mitglied erlaubt, auch für Viewer-Schlüssel. Einen Endpunkt zu erstellen, sein Ziel zu ändern oder eine Zustellung erneut zu senden erfordert jedoch die Berechtigung workspace.edit, die nur Admin und Owner besitzen.
Der Grund ist das zuvor beschriebene Problem des dauerhaften Datenstroms. Das Erstellen von tausend Links durch einen Editor würde auffallen. Ein Editor, der einen Catch-all-Webhook auf den eigenen Server richten könnte, würde dagegen ab diesem Zeitpunkt stillschweigend jedes Link-Ereignis empfangen. Deshalb bleibt die Änderung von Webhooks denselben Personen vorbehalten, die auch Workspace-Einstellungen ändern können.
Richten Sie Webhooks in der Praxis einmal manuell als Admin im Dashboard ein. Geben Sie der Automatisierung, die sie verarbeitet, danach einen Editor- oder Viewer-Schlüssel für ihre API-Aufrufe. Wenn Sie Webhooks für Link-Ereignisse in Slack oder ein CRM einbinden, braucht die empfangende Seite überhaupt keinen Elido-Schlüssel, sondern das Signaturgeheimnis zum Prüfen der Nutzdaten.
Sie möchten vor der Einrichtung einen Beleg? Erstellen Sie einen kostenlosen Workspace, stellen Sie einen Viewer- und einen Editor-Schlüssel aus und probieren Sie denselben Schreibaufruf mit beiden aus. Die 403-Antwort beim Viewer-Schlüssel sagt mehr aus als jede Tabelle.
Wie Schlüssel gespeichert werden: Pepper, Hash und Präfix
Ein Token sieht aus wie elido_, gefolgt von 52 Base32-Zeichen, erzeugt aus 32 zufälligen Bytes. Das vollständige Token wird genau einmal angezeigt, in der Antwort auf den Erstellungsaufruf. Danach ist es auf unserer Seite endgültig verschwunden.
Gespeichert wird ein HMAC-SHA256 des Tokens, der mit einem serverseitigen Pepper geschützt ist. Dieser liegt in der Konfiguration der Anwendung und nicht in der Datenbank. Bei jeder Anfrage wird das eingehende Bearer-Token, also das in RFC 6750 definierte Schema, auf dieselbe Weise gehasht und anhand des Hashes gesucht. Ein gestohlener Datenbank-Dump besteht aus Hashes, die ohne den Pepper nicht geprüft werden können, und der Produktionsdienst verweigert den Start, wenn kein Pepper gesetzt ist.
Für Ihre eigenen Unterlagen speichern wir die ersten acht Zeichen nach elido_ als Anzeigepräfix. Die API-Schlüsselseite zeigt dieses Präfix neben dem Namen, der Rolle, dem Erstellungsdatum, dem Ablauf, dem Zeitpunkt der letzten Nutzung und der IP-Adresse der letzten Nutzung sowie die Gesamtzahl der Anfragen und die Zahl der fehlgeschlagenen Anfragen. Taucht ein Schlüssel irgendwo in einem Log auf, zeigt das Präfix, um welchen Schlüssel es sich handelt, ohne dass jemand das vollständige Geheimnis sehen muss.
Limits, Ablauf und Rotation von API-Schlüsseln
Jeder Schlüssel erhält einen eigenen Token-Bucket, getrennt vom Limit pro Workspace. So kann ein außer Kontrolle geratener Workflow nicht das Budget für alle anderen aufbrauchen. Ein Admin kann das Limit eines einzelnen Schlüssels auf 1 bis 10.000 Anfragen pro Sekunde und seinen Burst auf 1 bis 20.000 überschreiben oder die Überschreibung löschen, um wieder den Standard zu verwenden. Bei Überschreitung erhält der Schlüssel eine 429-Antwort mit Retry-After: 1 und X-RateLimit-Scope: api_key, sodass die Wiederholungslogik zwischen einem Schlüssellimit und einem Workspace-Limit unterscheiden kann. Der Leitfaden zu Rate-Limits und Idempotenz erklärt den richtigen Umgang mit Backoff.
Der Ablauf ist optional und wird beim Erstellen als RFC-3339-Zeitstempel gesetzt. Sobald dieser Zeitpunkt überschritten ist, wird der Schlüssel einfach nicht mehr akzeptiert. Der Widerruf besteht aus einem DELETE. Auch dieser Vorgang ist idempotent.
Es gibt keinen einzelnen "Rotieren"-Button, und ich vermisse ihn nicht. Die Rotation erfolgt in drei Schritten:
- Erstellen Sie einen neuen Schlüssel mit derselben Rolle und einem neuen Ablaufdatum.
- Ersetzen Sie ihn im Zugangsdaten-Speicher des Tools und prüfen Sie, dass ein Aufruf erfolgreich ist.
- Widerrufen Sie den alten Schlüssel und prüfen Sie anschließend in der Liste, dass sich dessen Zeitpunkt der letzten Nutzung nicht mehr verändert.
Jeder Schritt landet im Workspace-Audit-Log: api_key.created mit Name und Rolle, api_key.revoked sowie api_key.rate_limit_set für Überschreibungen. Außerdem läuft alle fünf Minuten ein Hintergrundscan und markiert jeden Schlüssel mit mehr als 1.000 Anfragen, bei dem über 30 % fehlgeschlagen sind. Die Markierung erscheint im Audit-Log und am Schlüssel. Kein automatischer Widerruf. Einen Schlüssel zu deaktivieren ist eine menschliche Entscheidung, denn eine Serie von 404-Fehlern weist genauso oft auf einen defekten Workflow wie auf einen Angreifer hin.
API-Schlüssel mit den geringsten nötigen Rechten an n8n, Make und Zapier übergeben
Automatisierungsplattformen sind der Ort, an dem Schlüssel in Vergessenheit geraten. Sie liegen in einem Zugangsdaten-Speicher, werden in exportierte Workflow-JSON-Dateien kopiert und überdauern die Person, die sie eingerichtet hat. Zwei Gewohnheiten helfen:
- Ein Schlüssel pro Tool und Workflow-Familie, nach der jeweiligen Verwendung benannt ("n8n: Kampagnen-Tabellen"). Ein Widerruf legt dann genau eine Sache lahm, und das Audit-Log zeigt, welches Tool was getan hat.
- Editor für alles, was Links erstellt, Viewer für alles, was nur liest, und für beide ein Ablaufdatum.
Das ist die ganze Liste; der Rest ist eine Frage der Einschätzung. Das OWASP Cheat Sheet zur Geheimnisverwaltung ist eine gute Lektüre dazu, wie Tokens aus Logs und Exporten ferngehalten werden. Dort gelangen Automatisierungsschlüssel meistens nach außen.
Für die Einrichtung mit einem bestimmten Tool setzt der n8n-Leitfaden für URL-Shortener den Schlüssel in eine Header-Auth-Zugangsdatenkonfiguration. Der Vergleich von Make, IFTTT, n8n und Zapier erklärt, wo die einzelnen Plattformen ihn speichern. Zapier verbindet sich laut dem Zapier-Leitfaden zur Automatisierung mit demselben Token. Für CI oder alles, was den Weggang einer Person überdauern soll, ist ein Maschinenbenutzer besser geeignet: ein Dienstkonto mit eigener Rolle, getrennt vom Schlüssel jeder menschlichen Person.
Und genau diese Übergabe ist der Grund, warum ein Schlüssel niemals Admin-Endpunkte öffnen darf. Sobald ein Token in einem Drittanbieter-Tool liegt, kann es jeder mit Bearbeitungszugriff auf die Workflows dieses Tools verwenden. Sie vertrauen dann allen auf der anderen Seite, nicht nur den Menschen auf Ihrer Seite.
Tokens pro Scope sind geplant, aber noch nicht live
Rollen sind bewusst grob gehalten und manchmal zu grob. Ein Editor-Schlüssel, der ausschließlich Links erstellt, kann sie auch löschen, weil Löschen Teil der Editor-Rolle ist. Die Lösung sind Tokens pro Scope, etwa links:write oder analytics:read, die direkt an einen Schlüssel angehängt und zusätzlich zu den Rollen verwendet werden.
Das steht auf unserer Roadmap und ist noch nicht veröffentlicht. Heute bestehen die Berechtigungen eines Schlüssels aus seinem Workspace und seiner Rolle, und es gibt keine feinere Abstufung. Wenn Sie jetzt eine strengere Kontrolle benötigen, sind die beiden Stellschrauben eine niedrigere Rolle und ein kurzes Ablaufdatum sowie separate Schlüssel pro Aufgabe, damit der mögliche Schaden jedes einzelnen klein bleibt. Der API-Schnellstart und die API- und SDK-Referenz zeigen das aktuelle Schlüsselmodell anhand funktionierenden Codes. Teams, die zusätzlich Kontrolle auf Identitätsebene benötigen, können über SCIM und SSO für Marketing-Tools weiterlesen.
Lesen Sie den Grundlagenartikel: Die Sicherheits-Checkliste für URL-Shortener behandelt die Kontrollen rund um den Schlüssel, vom URL-Scan bis zu IP-Allowlisten.
Weitere Beiträge im Blog
Häufig gestellte Fragen
Was sind Berechtigungen für API-Schlüssel?
Sie sind die Menge an Aktionen, die ein Schlüssel gegenüber einer API ausführen darf: welche Ressourcen er lesen, welche er ändern kann und in welchem Konto. Bei Elido ergeben sich die Berechtigungen eines Schlüssels aus dem Workspace, in dem er ausgestellt wurde, und der beim Erstellen gewählten Rolle. Daher kann derselbe Schlüssel weder in einem anderen Workspace noch über dieser Rolle handeln.
Was bedeutet das Prinzip der geringsten nötigen Rechte für API-Schlüssel?
Jeder Schlüssel erhält genau die kleinste Menge an Berechtigungen, die seine Aufgabe benötigt, und nichts darüber hinaus. Ein Dashboard, das nur Klickzahlen liest, bekommt einen Viewer-Schlüssel, ein Workflow, der Links erstellt, einen Editor-Schlüssel, und Admin-Schlüssel bleiben der seltenen Aufgabe vorbehalten, Webhooks, Domains oder Mitglieder zu verwalten. Ein offengelegter Schlüssel kann dann nur das tun, was diese eine Aufgabe tut.
Was ist der Unterschied zwischen API-Schlüssel-Scopes und Rollen?
Ein Scope ist eine enge Berechtigung wie links:write, die direkt an ein Token angehängt wird, während eine Rolle ein benanntes Berechtigungspaket wie Editor ist. Rollen sind leichter zu überblicken, Scopes feiner abgestuft. Elido-Schlüssel verwenden derzeit Workspace-Rollen. Tokens pro Scope sind darauf aufbauend geplant, aber noch nicht live.
Wie oft sollten API-Schlüssel rotiert werden?
Eine gängige Empfehlung lautet alle 30 bis 90 Tage und sofort, wenn jemand, der den Schlüssel gesehen hat, das Unternehmen verlässt, der Schlüssel in einem Log auftaucht oder sein Datenverkehr verdächtig aussieht. Ein Ablaufdatum beim Erstellen macht aus diesem Zeitplan einen festen Stopp statt einer Kalendererinnerung, die leicht ignoriert wird.
Kann ein API-Schlüssel auf Admin-Endpunkte zugreifen?
Bei Elido nein. Die Admin-API der Plattform akzeptiert nur eine interaktive, angemeldete Sitzung und beantwortet einen API-Schlüssel unabhängig von der Rolle der erstellenden Person mit 403. Workspace-Einstellungen, die Admin-Rechte benötigen, bleiben erreichbar, aber nur über einen Schlüssel, der mit der Admin- oder Owner-Rolle erstellt wurde.
Wie sollten API-Schlüssel auf der Anbieterseite gespeichert werden?
Niemals im Klartext. Der Anbieter sollte einen schlüsselbasierten Hash des Tokens speichern und danach nur ein kurzes Präfix anzeigen, damit eine Kopie allein der Datenbank nicht für API-Aufrufe verwendet werden kann. Elido hasht jedes Token mit HMAC-SHA256 und einem serverseitigen Pepper und zeigt das vollständige Token genau einmal an.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag