Wissensdatenbank
Rollen & Berechtigungsstufen
Eine Rolle sagt, was jemand tun darf, eine Adressfreigabe sagt, womit.
Details
- Zwei Freigaben je Person, und beide müssen übereinstimmen, bevor etwas passiert. Die ROLLE, gesetzt unter Einstellungen → Mitglieder, sagt, was jemand im Workspace TUN darf: Mail lesen, senden, Vorlagen bearbeiten, eine Domain hinzufügen, einen API-Schlüssel prägen. Die Adress-FREIGABE, gesetzt über Teilen in der Adresszeile, sagt, mit welchen ADRESSEN er es tun darf, nur lesend oder lesend und sendend. Wer eine Rolle mit Senden darin und keine Adressen hat, kann von nichts senden; wer jede Adresse im Workspace unter einer nur lesenden Freigabe hält, kann ebenso wenig von einer von ihnen senden.
- Sechs Rollen existieren, ohne dass sie jemand anlegt, und jeder Workspace hat dieselben sechs, „Admin“ bedeutet hier also dasselbe wie in der Dokumentation und auf der API. Owner, Admin, Member und Viewer sind eine Leiter: Jede hält alles, was die nächste hält, jemanden herabzustufen verengt also, was er erreichen kann, statt es gegen einen anderen Ausschnitt zu tauschen. Developer und Billing sind keine Sprossen dieser Leiter. Developer baut Integrationen, hält API-Schlüssel, Webhooks, Vorlagen und das Senden und liest dabei keine Mail des Workspace, und Billing sieht den Tarif und die Rechnungen, kann den Tarif und die Zahlungsdaten darauf ändern und liest Postfacheinstellungen, ohne eine schreiben zu können. Ihre Berechtigungen sind bearbeitbar: Ein Workspace, in dem die Mitglieder lieber keine Vorlagen schreiben sollen, hakt das ab, und die Änderung greift bei der nächsten Anfrage von jemandem, der diese Rolle AUSDRÜCKLICH hält. Wessen Rolle noch aus einer Adressfreigabe von vor der Einführung der Rollen abgeleitet ist, behält die ausgelieferten Standards, bis sie ihm ausdrücklich zugewiesen wird. Ebenso ihre Namen: Ein Workspace, der mit Ops und On-call arbeitet, benennt sie um und beschreibt damit sich selbst, und genau darum geht es.
- Owner ist die Ausnahme in jeder Richtung: nicht bearbeitbar, nicht löschbar, nicht zuweisbar. Diese Rolle beschreibt das Konto, auf das der Workspace geschlüsselt ist, und hält jede Berechtigung, auch die in einem späteren Release hinzugefügten, weshalb ihre Liste berechnet statt gespeichert wird. Den Workspace an jemand anderen zu übergeben ist eine Übertragung und kein Rollenwechsel, und hier gibt es nichts, was eine ausführt.
- Darüber hinaus schreibt ein Workspace seine eigenen, bis zu 24 insgesamt, indem er Berechtigungen aus derselben gruppierten Matrix ankreuzt. Ankreuzen impliziert: „Vorlagen bearbeiten“ speichert „Vorlagen lesen“ daneben, denn eine Rolle, die eine Vorlage bearbeiten kann, die sie nicht öffnen kann, ist ein vergessenes Häkchen und keine gewollte Richtlinie. Das Löschen einer Rolle, die Menschen oder API-Schlüssel halten, fragt, wohin sie verschoben werden sollen, und verweigert, statt zu raten. Ein Schlüssel, dessen Rolle verschwände, fiele auf gar keine Obergrenze zurück, und das ist weiter als die Rolle, die gerade ging.
- Ein API-Schlüssel kann gegen eine Rolle ausgestellt werden, und die Rolle ist eine Obergrenze und keine zweite Freigabe: Was der Schlüssel darf, sind seine eigenen Scopes geschnitten mit den Berechtigungen der Rolle, aufgelöst bei jeder Anfrage. Ein Schlüssel, der mit Senden angelegt und durch Viewer gedeckelt wurde, kann nicht senden, und eine Rolle zu verengen entzieht es live, ohne dass der Schlüssel rotiert werden müsste. Der Assistent ist an dieselbe Liste gebunden, und der MCP-Server baut die Tools eines Clients aus den Berechtigungen des Aufrufers, der Client eines Viewers hat also überhaupt kein Tool zum Senden, und jedes abgesicherte Tool prüft beim Eintritt erneut, weil eine Sitzung nach dem Bau der Liste das Postfach wechseln kann.