Least Privilege bis in die Tiefe
Jede Route prüft vor der Ausführung eine deklarierte Berechtigung aus 32 Bereichen. Ein API-Schlüssel trägt nur eine Teilmenge davon und ein optionales Ablaufdatum — nie den Zugang zum gesamten Workspace.
32 Berechtigungsbereiche, API-Schlüssel mit eingeschränkter Teilmenge, ein verschlüsselter Secret-Tresor und selbst gesetzte Rate-Limits.
Was Sie bekommen
- Berechtigungsbeschränkte API-Schlüssel — Erstellen Sie einen Schlüssel, der einen Workflow auslösen, aber kein Secret lesen und niemanden einladen kann. Jeder Schlüssel trägt seine eigene explizite Berechtigungsliste und ein optionales Ablaufdatum — eine Drittanbieter-Integration bekommt nie mehr als das, wofür sie da ist.
- Rollenbasierter Teamzugriff — Laden Sie Teammitglieder mit einer Rolle in einen Workspace ein — jeder Endpunkt prüft vor der Ausführung die deklarierte Berechtigung. Deployen, ein Secret im Klartext ansehen, einen pausierten Lauf freigeben und Retries entsperren sind getrennte Rechte, die Sie unabhängig vergeben.
- Verschlüsselter Secret-Tresor — Speichern Sie Signatur-Secrets und Zugangsdaten pro Workspace und referenzieren Sie sie im Workflow über den Namen. Ein Secret aufzulisten und seinen Klartext anzuzeigen sind zwei verschiedene Berechtigungen — man kann prüfen, dass ein Zugangsdatum existiert, ohne es je lesen zu können.
- Rate-Limits, die Sie steuern — Legen Sie Durchsatzgrenzen pro Workspace und pro ausgehender Domain fest, damit eine laute Integration nicht die Kapazität aufbraucht, auf die Ihre Produktions-Workflows angewiesen sind, und eine fehlerhafte Partner-API nicht das ganze Konto mitreißt.
Plattform-Funktionen
- 32: Berechtigungsbereiche
- Standardmäßig verweigert: Verhalten einer Route ohne deklarierte Berechtigung
- 2: Getrennte Rechte zum Auflisten und zum Lesen eines Secrets
Kann ich einen API-Schlüssel erstellen, der nur eine Sache darf?
Ja. Ein Schlüssel wird mit einer expliziten Berechtigungsliste aus den 32 verfügbaren Bereichen erstellt, dazu ein optionales Ablaufdatum. Ein Schlüssel, der nur Ausführungen auslösen darf, kann keine Secrets lesen, keine Mitglieder ändern und nicht deployen.
Was passiert, wenn ein Endpunkt ohne deklarierte Berechtigung ausgeliefert wird?
Er verweigert jede eingeschränkte Identität. Zugriff entsteht durch Deklaration, nicht durch Ausschluss: Eine Route ohne deklarierte Berechtigung gewährt einem API-Schlüssel oder einer Rolle nichts — eine vergessene Annotation schlägt geschlossen fehl, statt den Endpunkt still freizugeben.
Kann jemand den Wert eines Secrets lesen, nur weil ein Workflow es benutzt?
Nein. Secrets aufzulisten und Klartext anzuzeigen sind getrennte Berechtigungen. Der Workflow löst das Secret zur Laufzeit auf, und ein Teammitglied kann bestätigen, dass es existiert und korrekt referenziert ist, ohne dass jemand das Recht hat, den Wert anzuzeigen.