Governance einführen

Diese Anleitung führt Schritt für Schritt durch die Einführung von Genehmigungspflichten – einen Workflow nach dem anderen. Das System ist auf schrittweise Einführung ausgelegt: Deine Organisation startet schnell, wobei der Owner zunächst alles allein erledigen kann. Du verschärfst die Regeln für jeden Workflow, wenn du bereit bist – und landest am Ende, wenn du möchtest, bei einer Konfiguration, in der keine Einzelperson allein Einlagen bewegen oder Regeln ändern kann.

Informationen zur Funktionsweise von Richtlinien findest du unter Richtlinien, Genehmigungen und Governance. Zum Zugriffsmodell siehe Rollen, Profile und Berechtigungen.

Die Execute-Ebene und die Einstellung „Genehmigung immer erforderlich" ergeben zusammen zwei Konfigurationen:

  • Schneller Pfad für einige, Genehmigung für alle anderen. Sperre die Richtlinie mit deaktivierter Option „Genehmigung immer erforderlich". Mitglieder, deren Profil Execute enthält, schließen Anfragen sofort ab; alle anderen durchlaufen den Genehmigungsprozess. Die Sperre verhindert, dass jemand die Regeln allein lockern kann.
  • Genehmigung für alle. Sperre die Richtlinie mit aktivierter Option „Genehmigung immer erforderlich". Jede Anfrage – einschließlich der des Owners – durchläuft eine unabhängige Genehmigung. Keine Einzelperson kann einen geregelten Vorgang allein abschließen.

Verschiedene Workflows können unterschiedliche Konfigurationen haben. Eine typische Kombination: Genehmigung für alle bei Auszahlungsanfragen, schneller Pfad bei Überweisungsanfragen (Einlagen verbleiben innerhalb der Organisation) und Genehmigung bei „Richtlinien verwalten", um die Regeln selbst zu schützen.

Die ersten drei Schritte sind jederzeit umkehrbar. Das Sperren ist endgültig.

Schritt 1 – Bootstrap

Der Owner startet mit dem systemdefinierten Admin-Profil und der Rolle „Vollzugriff": Execute für jeden Workflow, jede Berechtigung auf jedem Konto. Die Richtlinie jedes Workflows startet offen. Als Organisation mit nur einem Benutzer arbeitest du genau wie bisher – keine Anfrage wartet auf Genehmigung, da es niemanden gibt, der genehmigen könnte.

Schritt 2 – Konfigurieren

Richte die Genehmigungskonfiguration für einen Workflow ein – in der Regel zuerst für Auszahlungsanfragen –, während „Genehmigung immer erforderlich" auf AUS bleibt:

  1. Lade Mitglieder ein und weise Workflow-Profile zu, die für den Ziel-Workflow die Berechtigung „Approve" enthalten. Das systemdefinierte Approver-Profil gewährt Genehmigungsrechte für jeden Workflow; Funds Manager deckt das Initiieren und Genehmigen von Überweisungen und Auszahlungen ab.
  2. Weise Kontorollen zu, damit Initiatoren die erforderlichen Berechtigungen für Geldbewegungen auf den richtigen Konten besitzen.
  3. Lege die erforderliche Anzahl von Genehmigungen für den Ziel-Workflow fest.
  4. Wenn du das Sperren planst (Schritt 4), erteile jetzt mindestens einem weiteren Mitglied die Berechtigung „Approve" für „Manage Policies" – das System verlangt einen unabhängigen Genehmiger, bevor es das Sperren erlaubt.

Noch ist nichts aktiv. Du behältst Execute und arbeitest normal weiter, während die Konfiguration schrittweise umgesetzt wird.

Schritt 3 – Validieren

Aktiviere „Genehmigung immer erforderlich" für den Ziel-Workflow. Jede Anfrage – auch deine eigene – wird nun in die Warteschlange gestellt. Überprüfe anhand echter Anfragen:

  • Genehmiger sehen ausstehende Anfragen und können diese genehmigen oder ablehnen.
  • Die erforderliche Anzahl an Genehmigungen ist mit deinem aktuellen Team erreichbar.
  • Der vollständige Ablauf – von der Initiierung bis zum Abschluss – verhält sich wie erwartet. Prüfe, ob die zugehörigen Sicherheitsereignisse auf ihre jeweiligen Anfragen zurückverweisen.

Dies ist das sichere Zeitfenster: Die Governance ist aktiv, aber die Richtlinie ist noch nicht gesperrt – du kannst die Einstellung also jederzeit auf AUS setzen, Anpassungen vornehmen und den Vorgang beliebig oft wiederholen. Entscheide, ob „Genehmigung immer erforderlich" in der endgültigen Konfiguration EIN oder AUS bleiben soll, bevor du die Richtlinie sperrst.

Schritt 4 – Sperren

Richtlinie sperren. Das Sperren ist selbst eine Manage Policies-Anfrage: Wenn Manage Policies bereits eine Genehmigung erfordert, tritt die Sperre in Kraft, sobald ein anderes Mitglied sie genehmigt. Ab diesem Zeitpunkt gilt:

  • Alle Anfragen folgen den konfigurierten Genehmigungsregeln.
  • Jede Änderung an dieser Richtlinie – die Anzahl der erforderlichen Genehmigungen, die Einstellung „Genehmigung immer erforderlich" oder das Entsperren – erfordert die Zustimmung eines anderen Mitglieds mit der Berechtigung „Genehmigen" in Manage Policies. „Ausführen" in Manage Policies umgeht dies nicht: Die Sperre überschreibt die sofortige Ausführung für die gesperrte Richtlinie.
  • Änderungen des Owners durchlaufen dieselbe Prüfung wie die aller anderen.
Wichtig:

Schritt 5 – Wiederholen

Alle anderen Workflows behalten ihren aktuellen Status, bis du zu Schritt 2 zurückkehrst. Jede Kombination aus geregelten und ungeregelten Workflows ist ein gültiger stabiler Zustand – die beschriebene Abfolge ist eine Empfehlung, keine Pflicht.

Der letzte Schritt – Manage Policies selbst sperren

Manage Policies verfügt über eine eigene Richtlinie und eine eigene Sperre. Das Sperren ist der Abschluss des Rollouts: Von diesem Zeitpunkt an erfordert jede Regeländerung in der gesamten Organisation – Richtlinieneinstellungen, Sperren und Entsperren, für jeden Workflow – eine unabhängige Genehmigung, und niemand kann die Governance im Produkt allein abschwächen.

Führe diesen Schritt als letzten durch, nachdem alle Workflows, die du regeln möchtest, konfiguriert und gesperrt sind. Stelle zuvor sicher, dass mindestens zwei Mitglieder die Berechtigung „Genehmigen" in Manage Policies besitzen – gesperrte Richtlinien lassen sich nur ändern, solange unabhängige Genehmiger verfügbar sind. Wie sich diese Sperre verhält, erfährst du unter Richtlinien, Genehmigungen und Governance.

Ein CFO möchte Auszahlungen selbst sofort abschließen, während jede Auszahlung der Fondsmanager ihre Prüfung durchläuft.

Workflow-Profile:

Mitglied

Profil

Berechtigungsstufen für Auszahlungsanfragen

CFO

Benutzerdefiniert „CFO"

Anzeigen, Initiieren, Genehmigen, Ausführen

Fondsmanager A

Initiator (systemdefiniert)

Anzeigen, Initiieren

Fondsmanager B

Initiator (systemdefiniert)

Anzeigen, Initiieren

Alle drei verfügen über eine Kontorolle, die Auszahlen auf den Betriebskonten erlaubt. Die Berechtigungsstufen in diesem Beispiel beziehen sich ausschließlich auf Auszahlungsanfragen. Das systemdefinierte Initiator-Profil gewährt außerdem Initiieren in jedem anderen Workflow. Verwende ein benutzerdefiniertes Profil, wenn die Fondsmanager Auszahlungen initiieren, aber keine anderen geregelten Vorgänge durchführen sollen.

Richtlinie für Auszahlungsanfragen: erforderliche Genehmigungen 1, „Genehmigung immer erforderlich" AUS, Richtlinie gesperrt.

Das Ergebnis: Die Auszahlungen der CFO werden über Execute sofort ausgeführt. Die Auszahlung jedes Fondsmanagers wartet auf eine Genehmigung – in der Praxis die der CFO, da sie die einzige Genehmigerin ist. Niemand kann diese Regeln allein ändern, da die Richtlinie gesperrt ist.

Vor dem Sperren muss ein weiteres Mitglied ebenfalls über Genehmigen in „Richtlinien verwalten" verfügen. Dieses Mitglied genehmigt künftige Richtlinienänderungen und Entsperranfragen eigenständig.

Spätere Verschärfung. Wenn das Unternehmen entscheidet, dass alle Auszahlungen – einschließlich der der CFO – geprüft werden müssen, wird die Änderung über eine Richtlinienanfrage abgewickelt (unabhängige Genehmigung erforderlich, da die Richtlinie gesperrt ist):

  1. Weise die Fondsmanager einem Profil mit Genehmigen zu, damit sie sich gegenseitig und die CFO prüfen können.
  2. Erhöhe die erforderlichen Genehmigungen auf 2.
  3. Aktiviere „Genehmigung immer erforderlich".

Execute bleibt im Profil der CFO erhalten, ist jedoch inaktiv. Wenn das Unternehmen die Richtlinie später wieder lockert, steht ihr direkter Pfad wieder zur Verfügung – ohne dass Zugriffsberechtigungen neu vergeben werden müssen.

Ein vierköpfiges Team im Workflow für Auszahlungsanfragen – so wird die Genehmigungsberechtigung je Anfrage ermittelt:

Mitglied

Anzeigen

Einleiten

Genehmigen

Ausführen

Eigentümer

Ja

Ja

Ja

Ja

Alice

Ja

Ja

Ja

-

Bob

Ja

-

Ja

-

Charlie

Ja

Ja

-

-

Richtlinie: 2 erforderliche Genehmigungen, „Genehmigung immer erforderlich" AN (Execute des Inhabers ist dadurch inaktiv).

Szenario

Wer muss genehmigen

Grund

Owner initiiert

Alice und Bob

Der Owner ist von der Genehmigung eigener Anfragen ausgeschlossen; Alice und Bob sind die einzigen weiteren Genehmigenden, daher sind beide erforderlich.

Alice initiiert

Owner und Bob

Alice ist ausgeschlossen; die verbleibenden Genehmigenden sind der Owner und Bob.

Charlie initiiert

Beliebige 2 von Owner, Alice, Bob

Charlie hat kein Approve; alle drei Genehmigenden können seine Anfragen genehmigen.

Bob initiiert

-

Bob hat kein Initiate; er kann keine Auszahlungsanfragen erstellen. Er ist reiner Genehmiger – eine Rolle, die viele Teams bewusst so vergeben.

  • Withdrawal Request konfiguriert, validiert und gesperrt
  • Ausrichtung für Transfer Request festgelegt (direkte Ausführung oder vollständige Genehmigungspflicht) und gesperrt
  • Genehmigungsanforderungen für Manage Addresses eingerichtet; die Whitelist schützt jede Auszahlung
  • Richtlinien für Manage Team & Access und Manage API Keys eingerichtet; Zugriffsänderungen und neue Anmeldedaten sollten regelmäßig geprüft werden
  • Manage Policies unter Governance; als abschließender Schritt die eigene Richtlinie gesperrt, damit die Regeln selbst geschützt sind
  • Mindestens zwei Mitglieder verfügen über Approve für Manage Policies, damit gesperrte Richtlinien änderbar bleiben
  • Eine regelmäßige Zugriffsüberprüfung anhand der Sicherheitsereignisse eingeplant

Brauchst du Hilfe?