Für die Nutzer-, Rollen- und Rechteverwaltung bei der produktiven Nutzung von Smart Contracts gilt es, das Trilemma der dezentralen Blockchain-Technologie bestmöglich zu lösen. Dazu gibt es unterschiedliche Möglichkeiten, insbesondere für den „off-chain“ Bereich.
Herausforderungen beim Einsatz der Blockchain-Technologie.
Partner des Bank Blogs
Im ersten Teil des Beitrags wurde das grundsätzliche Problem dezentral verwalteter Blockchain-Umsetzungen analysiert. Demnach gilt es, eine Abwägung zwischen den inhärente Eigenschaften von dezentralen Anwendungen vorzunehmen. Beispielsweise stehen Skalierbarkeit und Sicherheit immer konträr zueinander, d.h. jede Verbesserung der Skalierbarkeit resultiert in einer Verringerung der Sicherheit.
Im heutigen zweiten Teil geht es um Lösungsansätze dieses Problems. Es gibt unterschiedliche Lösungsvarianten, deren Anwendbarkeit sich aus dem Unternehmenskontext ergibt: wie groß ist das Unternehmen, in welchem Bereich ist es tätig, wie stark ist es reguliert oder unterliegt es externen Vorgaben?
Sicherheit, Dezentralität und Skalierbarkeit bilden das Blockchain-Trilemma.
Im Folgenden sind einige Optionen angegeben, wobei die offensichtliche Implementierung eines Nutzer-, Rollen- und Rechtekonzeptes „on-chain”, also im Smart Contract, nicht betrachtet wurde, da diese Lösung aus unterschiedlichen Gründen problematisch ist:
- Die Logik in Smart Contracts kann nicht einfach angepasst werden und Rollen-/Rechtekonzepte sind komplex zu implementieren
- Firmeninterne Prozesse zur Nutzer-, Rollen- und Rechteverwaltung werden redundant neu implementiert und müssen parallel gepflegt werden
- Die Lösung ist nicht DLT-agnostisch, d.h. für jede DLT oder Blockchain-Implementierung muss eine eigene, potentiell fehleranfällige und wartungsintensive, Lösung implementiert werden
Ist trotz dieser Tradeoffs die „on-chain” Variante die bestmögliche, gibt es sehr gute Hilfestellungen für die Implementierung unter Ethereum.
Drei „off-chain” Lösungsvarianten
Mögliche „off-chain” Lösungsvarianten sind:
- Non-Custodial Wallet, proprietäre Eigenimplementierungen der Schlüsselverwaltung
- Multi-Signature Wallets (MultiSig) oder proprietäre Lösungen zur Schlüsselverwaltung wie EthSigner (mit Implementierungen für Azure Vault oder HashiCorp Vault)
- OAuth2/OIDC basierende Autorisierung im Smart Contract mit automatischem Schlüsselaustausch
Varianten der Zugriffskontrolle und Authentizitätsprüfung bei dezentralen Anwendungen.
Variante 1: Private Key Non-Custodial Wallets und proprietäre Eigenentwicklungen
Eine Eigenentwicklung, die auf einer sicheren Verwahrung des unverschlüsselten privaten Schlüssels beruht, ist sicherlich nur bei nicht regulierten Firmen wie FinTechs ohne besondere Lizenz möglich, wobei auch hier die konkrete Anwendung geprüft werden muss. Grundidee ist die Nutzung einer Wallet, z.B. bei Ethereum des Browser-Plugins MetaMask, welches die Credentials speichert. Der private Schlüssel muss, da er die einzige Zugriffsmöglichkeit für den Smart Contract darstellt, dann noch in einer externen Peripherie gespeichert werden.
Der Prozess der Verwaltung dieses Schlüssels wird hier nicht betrachtet. Hierbei ergeben sich mannigfaltige Probleme und Fragestellungen, die nicht abschließend und ausreichend geklärt werden können. Grundsätzlich ist diese Variante gleichzusetzen mit dem Speichern des Passworts eines Nutzers im Klartext in einer speziellen Verwaltungsdatenbank.
Diese Variante ist nur im Prototypenstadium sinnvoll und scheidet schon aus, wenn sichergestellt werden muss, dass ein Nutzer eine Aktion tatsächlich selbst erwirkt hat und der private Schlüssel nicht unbefugt verwendet wurde.
Variante 2: Multi-Signature Wallets (MultiSig), sehr effektiv, aber auch „Blockchain-zentrisch”
Die Multi-Signature-Variante kommt aus der dezentralen Peer-To-Peer-Blockchain-Nutzung für Transaktionen, welche Aktionen bzw. Bestätigungen mehrerer Akteure verlangen. Eine Analogie aus dem zentralisierten Finanzbereich ist ein „Und-Konto”, welches für eine bestimmte Transaktion eine 4-Augen-Pflicht vorschreibt. Bei MultiSig-Wallets wird nicht nur eine, sondern M von N Signaturen geprüft, welche mit den jeweiligen privaten Schlüsseln erfolgten. Nur wenn M vorgeschriebene Signaturen vorhanden sind, wird die Transaktion durchgeführt.
Eine solche Variante ist “Blockchain-nativ”, aber wird von bestehenden Unternehmensprozessen nicht hinreichend abgebildet. So ist nicht klar, was passiert, wenn einzelne Teilnehmer aus dem Unternehmen ausscheiden oder neue hinzukommen. Bei vollständiger Ausgestaltung der Fälle ist die Gefahr eines Nachbaus von komplexen, teuren und fehleranfälligen Rollen- und Rechteverwaltungen groß.
Variante 3: Nutzung von etablierten IdAM Anwendungen und Prozessen
Auf einer Skala von „praktischem Nutzen” zu „vollständiger Dezentralisierung” ist diese Variante dem praktischen Nutzen, vor allem im Unternehmenskontext, deutlich näher als die anderen Varianten. Die Sollbruchstelle der Dezentralisierung ist das Vertrauen in die bestehenden IdAM-Werkzeuge und Prozesse der einzelnen Teilnehmerfirmen, nicht aber in einzelne Mitarbeiter dieser Firmen.
In unserem Beispiel kann ein Schlüsseltausch für Anna erfolgen, dazu muss aber ein firmeninterner Prozess erfolgreich durchlaufen werden. Als Nachweis des erfolgreichen Durchlaufs des Prozesses wird im Smart Contract einer Signatur des IdAM-Systems vertraut, nicht einem einzelnen Schlüssel eines Firmenmitarbeiters. Dieser Trade-off erlaubt es nun, zu Lasten des Vertrauens, Firmen den Betrieb der dezentralen Anwendung trotz typischer Situationen wie Schlüsselverlust, Mitarbeiterdeaktivierung usw. zu nutzen.
Für unseren speziellen Fall geht also das notwendige Vertrauen in Anna in ein Vertrauen der Konsortienteilnehmer in die bestehenden Prozesse des jeweiligen Teilnehmerunternehmens, also Annas Arbeitgeber, über.
Übersicht eines Schlüsselaustauschs im dezentralen Kontext.
Bleibt man beim typischen Anwendungsfall „Wer hat wann was getan?” von Blockchain-Anwendungen, so wird im Smart Contract fest eingebaut, dass dieser einer Signatur der jeweiligen IdAM-Systeme der einzelnen Firmen vertraut. Diese Überprüfung ist „trust-less”, die Logik der Signaturprüfung und des anschließenden Schlüsselaustausches kann also nicht geändert und auch von jedem Teilnehmer geprüft werden. Statt eines einzelnen Mitarbeiters wird in diesem Fall aber einem Firmenprozess vertraut.
Trade-off zu echter Dezentralisierung
Dieser Trade-off zu echter Dezentralisierung muss im Einzelfall bewertet werden, geht man aber von allgemeinem Geschäftsgebaren aus, wird unternehmensinternen Prozessen allgemein stark vertraut. Bei dieser Implementierungsoption kann eine Zuwiderhandlung des abgestimmten, übergreifenden Prozesses unwiderruflich bewiesen und sanktioniert werden.
Aus der Risikosicht betrachtet birgt diese Variante die geringsten Risiken, da einzelne Mitarbeiter keinen Angriffsvektor haben. Hierbei setzt man voraus, dass die Firma diese Risiken schon intern minimiert hat, in dem sie z.B. die IdAM Prozesse entsprechend sicher aufgesetzt hat und kontinuierlich auditiert.
Neue Lösungen für dezentrale Anwendungen
Altbekannte Probleme wie die Authentizität eines Akteurs in einem koopetitiven Konsortium erfordern im dezentralen Umfeld neue Lösungen. Diese sind nicht technischer Natur, sondern bedeuten konzeptionelle Herausforderungen und werden durch viele Faktoren und Stakeholder beeinflusst, da es keinen zentralen Verantwortlichen geben kann.
Generell können Probleme im dezentralen Umfeld nicht mehr „hands-on” von einzelnen Teilnehmern angegangen werden, sondern erfordern Absprachen und Koordination der Teilnehmer. Die Gesamtheit dieses neuen Forschungsfeldes wird unter dem Begriff „dezentrale Steuerung” (decentralized Governance) zusammengefasst und steht noch ganz am Anfang.
Technisch sind Unternehmensgrenzen nun durchlässig geworden, administrativ, operativ und politisch ergeben sich aber neue Fragestellungen. Das Angehen dieser Probleme ist die eigentliche Herausforderung bei der Dezentralisierung von Anwendungen und Prozessen.
