Rollen und Berechtigungen in SSP Enterprise
Die Frage, die darüber entscheidet, ob geteilte Verwahrung wirklich funktioniert, lautet nicht „wer hat das Sagen?“. Sie lautet „wer kann das Geld bewegen?“ — und in einem gut gebauten System sind das zwei verschiedene Fragen mit verschiedenen Antworten.
SSP Enterprise beantwortet sie an zwei getrennten Orten. Administrative Autorität liegt in den Datensätzen der Organisation, wo sie wie jede andere Berechtigung gewährt und entzogen werden kann. Ausgabeautorität liegt in der Vault-Adresse, wo sie das nicht kann. Dieser Artikel ist die vollständige Karte beider — samt der Fälle, in denen Menschen am häufigsten überrascht werden.
Wenn du den Überblick darüber, wie Organisationen und Vaults zusammenpassen, noch nicht gelesen hast: SSP Enterprise: Multisig-Vaults für Teams ist das Stück davor.
Zwei Systeme, mit Absicht
Eine Organisationsrolle regelt den Arbeitsbereich: Menschen einladen, Vaults anlegen, Einstellungen ändern, den Prüfpfad lesen. Sie ist ein Datenbankeintrag. Ändere ihn, und die Änderung greift sofort.
Eine Vault-Rolle regelt einen bestimmten Vault, und einer ihrer drei Werte — Signierender — bedeutet, dass dein öffentlicher Schlüssel Teil davon ist, wie die Adresse dieses Vaults abgeleitet wurde. Das lässt sich nicht durch Bearbeiten von irgendetwas ändern. Es lässt sich nur ändern, indem ein anderer Vault an einer anderen Adresse angelegt und die Mittel bewegt werden.
Die praktische Folge, und der wichtigste Satz dieses Artikels: ein Organisations-Owner, der auf einem Vault kein Signierender ist, kann aus diesem Vault nicht ausgeben. Nicht mit Dashboard-Zugang, nicht mit Datenbankzugang, nicht mit SSPs Mitwirkung. Die Adresse weiß nicht, was ein Owner ist.
Organisationsrollen, präzise
Vier Rollen, streng gestuft.
| Fähigkeit | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| Vaults, Aktivität, Prüfpfad lesen | Ja | Ja | Ja | Ja |
| Neue Personen einladen | Ja | Ja | Nur wenn die Org es erlaubt | Nein |
| Rolle eines Members oder Viewers ändern | Ja | Ja | Nein | Nein |
| Rolle eines anderen Admins ändern | Ja | Nein | Nein | Nein |
| Organisationseinstellungen ändern | Ja | Ja | Nein | Nein |
| Eigentum übertragen, Organisation löschen | Ja | Nein | Nein | Nein |
| Die Organisation verlassen | Nein — erst übertragen | Ja | Ja | Ja |
Drei Details dieser Tabelle lohnen es, herausgezogen zu werden.
Admins können andere Admins nicht anfassen. Ein Admin kann Members und Viewer befördern, herabsetzen und entfernen, aber sobald das Ziel ein anderer Admin ist, wird der Vorgang abgelehnt. Das ist Absicht: Ein einzelnes kompromittiertes Admin-Konto kann die übrige administrative Schicht nicht leise abbauen.
Einladungen durch Members sind ein Schalter auf Organisationsebene. Standardmäßig ist Einladen eine Admin-Fähigkeit. Eine Organisation kann sich entscheiden, es auch Members zu erlauben — nützlich für größere Teams, in denen das Onboarding nicht hinter zwei Personen anstehen sollte, und besser aus, wenn du einen engen Perimeter willst.
Der Owner kann nicht gehen. Es gibt genau einen Owner, und der Ausgang besteht darin, das Eigentum zuerst an jemand anderen zu übertragen. Das verhindert den Fehlerfall, in dem eine Organisation ohne jemanden endet, der Owner-exklusive Vorgänge ausführen kann.
Vault-Rollen, präzise
Drei Rollen, und ihr Geltungsbereich ist ein einzelner Vault, nicht die Organisation.
Ein Vault-Admin verwaltet den Vault: seine Richtlinien, seine Benachrichtigungseinstellungen, seine Viewer. Ein Vault-Admin ist nicht notwendigerweise ein Signierender, und ein Vault-Admin ohne Signaturrolle kann keinen Vorschlag freigeben.
Ein Signierender hält einen der Schlüssel im M-von-N des Vaults. Signierende entwerfen Vorschläge und geben sie frei. Ihr öffentlicher Schlüssel steckt in der Adresse.
Ein Vault-Viewer sieht Guthaben, Vorschläge und Verlauf, ohne etwas entwerfen oder freigeben zu können. Nützlich für Prüfer, Buchhaltung und alle, die Einblick ohne Befugnis brauchen.
Weil Vault-Rollen pro Vault gelten, kann dieselbe Person auf dem Operations-Vault Signierender und auf dem Treasury-Vault nur Viewer sein. Das ist eine normale und gesunde Aufstellung: Sie gibt Alltags-Ausgabebefugnis den Leuten, die sie brauchen, und hält die Reserve hinter einem anderen, kleineren Gremium.
Einladungen gehen an Identitäten, nicht an Postfächer
Eine Einladung in SSP Enterprise ist an eine WK-Identität adressiert — die 2-von-2-Multisig-Identität, die aus SSP Wallet und SSP Key einer Person abgeleitet wird — und nicht an eine E-Mail-Adresse.
Das ist eine Sicherheitseigenschaft, keine Unbequemlichkeit. Eine E-Mail-Adresse kann kompromittiert, weitergeleitet oder vertippt in fremde Hände geraten. Eine WK-Identität kann nur von jemandem vorgelegt werden, der beide Geräte dieser Person hat — eine Einladung kann also nicht von dem angenommen werden, der zufällig die Nachricht liest.
Zwei Folgen ergeben sich. Erstens braucht die eingeladene Person ein eingerichtetes SSP, bevor sie beitreten kann; einen „Registrieren über die Einladungs-E-Mail“-Pfad gibt es bewusst nicht. Zweitens sind Einladungen prüfbar, wie E-Mail-Einladungen es nicht sind, weil die Annahme ein signierter Akt ist.
Abgelaufene Einladungen werden nicht gelöscht. Sie werden unbegrenzt aufbewahrt, denn „wer wurde eingeladen und trat nie bei“ ist genau die Art Frage, die eine Prüfung Monate später stellt. Nichts im Prüfpfad hat eine Lebensdauer.
Was ein erneutes Signieren verlangt
Manche Vorgänge sind zu folgenreich, um sie mit einem Session-Cookie zu autorisieren. Dreizehn davon verlangen, dass du im Moment der Handlung mit beiden Geräten erneut signierst, darunter:
- Eigentum an einer Organisation übertragen
- Eine Organisation löschen
- Ein Mitglied entfernen
- Die Unternehmens-E-Mail eines Kontos ändern
Die Mechanik zählt hier. Der Server erzeugt die zu signierende Challenge — nie der Client — und die Challenge ist an die konkrete Aktion, das konkrete Ziel und einen Zeitstempel gebunden. Eine bei einem Vorgang abgefangene Signatur lässt sich nicht in einen anderen einspielen.
Jeder Versuch wird dauerhaft protokolliert, auch die gescheiterten. Ein Muster gescheiterter kritischer Aktionen ist selbst ein Signal, das man festgehalten haben will.
Wo Rollenänderungen festgehalten werden
Jede Berechtigungsänderung wird in den Prüfpfad der Organisation geschrieben: Rollen gewährt und entzogen, Einladungen ausgestellt, angenommen, abgelehnt und zurückgezogen, Beitritte und Abgänge, Entfernungen und Eigentumsübertragungen. Änderungen auf Vault-Ebene erhalten eigene Ereignisse — Signierende und Viewer hinzugefügt oder entfernt, Richtlinien bearbeitet, Vault-Status geändert.
Prüfeinträge sind dauerhaft. Es gibt kein Ablaufdatum und keinen Aufräumjob, denn der Wert eines Prüfpfads liegt vollständig in den Teilen, deren Bedarf niemand vorhergesehen hat. Eine Organisation, die im November ein Problem entdeckt, will den Eintrag aus dem März.
Deinen Rollenaufbau entwerfen
Ein paar Muster, die sich in der Praxis halten.
Trenne den Administrator von den Signierenden. Lass eine Operations-Leitung Organisations-Admin sein, damit sie Menschen und Vault-Einstellungen verwalten kann, ohne ihren Schlüssel in die Treasury-Adresse zu legen. Administrative Bequemlichkeit trägt dann kein Verwahrungsrisiko.
Vergib Viewer-Rollen an die Finanzfunktion großzügig. Lesezugriff ist billig und macht Abstimmung möglich, ohne den Kreis derer zu erweitern, die ausgeben können. Es gibt keinen Grund, warum eine Buchhalterin Signierende sein müsste.
Halte das Treasury-Gremium kleiner als das Operations-Gremium. Eine 3-von-5-Reserve und ein 2-von-3-Betriebs-Vault ist eine verbreitete und sinnvolle Aufteilung: Das Geld, das du täglich anfasst, hat eine niedrigere Freigabehürde als das, was du jährlich anfasst. 2-von-2 vs. 2-von-3 vs. m-von-n behandelt, wie man über die Zahlen nachdenkt.
Entscheide das Austrittsverfahren, bevor jemand austritt. Jemanden aus der Organisation zu entfernen ist eine Rollenänderung; ihn als Signierenden zu entfernen ist ein neuer Vault und eine Mittelmigration. Schreib auf, was du tun wirst, und bestätige, dass der verbleibende Kreis die Schwelle noch erreicht. Was passiert, wenn einer deiner Schlüssel kompromittiert ist geht das benachbarte Szenario durch.
Behandle Richtlinien nicht als Berechtigungen. Whitelists, Zeitsperren und Freigaberegeln formen, was vorgeschlagen wird, aber die Schwelle ist das Einzige, was die Chain durchsetzt. Entwirf deine Rollen so, als gäbe es die Richtlinien-Engine nicht, und füge Richtlinien dann als Prozessverbesserungen obendrauf.
Die Rollenhierarchie ist leicht richtig zu treffen, wenn du eine Frage vorn im Kopf behältst: Welche dieser Änderungen brauchen eine neue Adresse, und welche sind bloß Datensätze? Alles in der Organisationsschicht ist ein Datensatz. Nur der Signierendenkreis ist eine Adresse.
