">
Bei ersten produktiven dezentralen Anwendungen der Blockchain-Technologie ergeben sich spezielle Herausforderungen für die Nutzer-, Rollen- und Rechteverwaltung. Lösungen dafür sind aufwändig und komplex, aber durchaus möglich.
Herausforderungen beim Einsatz der Blockchain-Technologie.
Nachdem Firmen erste dezentrale Anwendungen als Distributed Ledger Expertise (DLT) oder Blockchain-Anwendungen produktiv gestellt haben und Erfahrungen mit diesem Anwendungstyp im produktiven Betrieb sammeln konnten, ergeben sich nun Probleme, für die es im Kontext zentraler Anwendungen längst etablierte Lösungen gibt, wie Beispiele zeigen.
Viele dieser Probleme sind hinlänglich bekannt, generische Lösungen sind im dezentralen Kontext allerdings komplex und technisch aufwändig zu realisieren, so dass fallbezogene Lösungen oder „Greatest Practices” sinnvolle Alternativen sein können.
Sicher und schnell und dezentral? Das Blockchain-Trilemma
Die Herausforderungen sind häufig inhärente Eigenschaften von dezentralen Anwendungen als neuem Anwendungstyp: so stehen beispielsweise Skalierbarkeit und Sicherheit immer konträr zueinander, d.h. jede Verbesserung der Skalierbarkeit resultiert in einer Verringerung der Sicherheit. Ein prominentes Beispiel ist der Kauf einer Ware mit einer dezentralen Kryptowährung. Die Kauftransaktion muss bei Nutzung der maximalen Sicherheit von allen Netzwerkknoten bestätigt werden („the entire world must know Bob simply purchased a beer”), damit der dezentrale Konsens in öffentlichen Blockchains funktioniert.
Natürlich wäre eine sichere und skalierbare Variante der Kauftransaktion möglich: wenn die Transaktion in einer zentral verwalteten Datenbank eingetragen würde. Offensichtlich wäre dies nur auf Kosten geringerer Dezentralisierung zu erreichen. Diese Gesetzmäßigkeit ist als Blockchain-Trilemma bekannt, in anderen Forschungsbereichen gibt es ähnliche Phänomene, das CAP-Theorem bei Datenbanken, das Trilemma des Wechselkursregimes in den Volkswirtschaften, usw.
Sicherheit, Dezentralität und Skalierbarkeit bilden das Blockchain-Trilemma.
Vielfältige Implementierungsoptionen im Blockchain-Bereich
Mittlerweile ist das Spektrum der Implementierungsoptionen im Blockchain-Bereich hinreichend groß. Zu Anfangszeiten der Blockchain-Implementierungen konnte eine Lösung auf Foundation der Bitcoin Blockchain, welche lange Zeit die einzig realitätserprobte Blockchain-Implementierung darstellte, nur maximal sicher, dafür aber sehr inperformant sein. Heute gibt es zahlreiche Abstufungen, so kann z.B. eine private-permissioned Blockchain in einem Betreiberkonsortium aus koopetitiven Unternehmen eine sehr hohe Sicherheit bei akzeptabler Efficiency und Dezentralisierung liefern.
Die verwendeten Technologien haben sich seit der Bitcoin Blockchain weiterentwickelt, so stehen bspw. mit Ethereum Turing-vollständige Implementierungen zur Verfügung oder mit Corda branchenspezifische Implementierungen, die für spezielle Anwendungsfälle optimiert sind. Generell gilt, dass die anwendungsspezifische Auswahl und die Anpassung von Blockchain- oder Distributed Ledger Technologie-Implementierungen der entscheidende Faktor für den Erfolg dezentraler Anwendungen ist.
Neben allgemeinen nicht-funktionalen Abwägungen wie Sicherheit vs. Performanz gibt es noch unternehmensspezifische Anforderungen, z.B. zu Nutzer-, Rollen- und Rechtemanagement und Authentizität der Nutzer, die bei Anwendungen berücksichtigt werden müssen.
Nutzer-, Rollen- und Rechtemanagement in der Blockchain
Ein sehr konkretes Drawback bei der Nutzung von dezentralen Technologien in einem Firmenkonsortium ist z.B. der Verlust eines Sicherheitstokens, z.B. eines privaten Schlüssels und die damit verbundene Frage, wie diesem in einem dezentralen Kontext begegnet werden kann. Wie können die Beteiligten einem einzelnen Teilnehmer des Konsortiums vertrauen, dass dieser nicht falsche Berechtigungen vergibt und wem genau vertrauen die Beteiligten hier?
Passwortverlust in zentralen Strukturen
Zunächst unser Beispielszenario in einem zentralisierten Kontext:
Anna hat ihr Passwort für das Intranet ihrer Firma versehentlich weitergegeben. Die Authentizität ihrer unternehmensspezifischen Handlungen ist somit gefährdet. Sie muss diesen Vorfall melden und einen Änderungsantrag stellen, dieser wird entsprechend der internen Sicherheitsrichtlinien und -prozesse protokolliert und ihre Identitäten und Berechtigungen im Id- und Entry-Managementsystem geprüft. Ein Administrator mit entsprechenden Berechtigungen (und Zuordnungen gemäß MA-Danger and so forth.) wird im 4-Augen-Prinzip über das Identitäts- und Accessmanagement-System ein neues Passwort vergeben und Anna muss sich bei Erstanmeldung ein eigenes, neues Passwort vergeben. Der sehr hohen Komplexität der korrekten Verwaltung der Identitäten und ihrer Eigenschaften, sowie der Rollen- und Rechtezuordnungen, wird additionally mit spezialisierten Werkzeugen und spezifizierten Prozessen begegnet.
Aufbau eines Identitäts-, Rollen und Rechtemanagements in Unternehmen.
Diese Prozesse unterscheiden sich typischerweise in Firmen nur marginal und die Aufsicht und Verantwortung über diese Prozesse liegen bei der jeweiligen Firma. Diese wiederum unterliegt ggf. externen Zwängen aufgrund von Prozess-Zertifizierungen, regulatorischen Anforderungen o.ä., ist aber prinzipiell für potenzielles Fehlverhalten und eingegangene Risiken eigenverantwortlich.
Im Unterschied zu dezentralen Anwendungen steht immer ein Mittelsmann zwischen dem einzelnen Nutzer und einer zentralen Logik. Der Mittelsmann, im Unternehmenskontext bspw. eine Abteilung mit Administratoren, kann immer die Rechte und Identitäten des einzelnen Nutzers vergeben, ändern oder zurückziehen.
Passwortverlust in dezentralen Strukturen
Im dezentralen Kontext wird das Vertrauen gänzlich auf den einzelnen Mitarbeiter übertragen, da konzeptionell kein Mittelsmann vorgesehen ist. Ethereum Good Contracts prüfen beispielsweise immer die Signatur des Senders, diese ergibt sich aus dem privaten Schlüssel des Firmenmitarbeiters. Ein Mittelsmann hätte entweder die komplette Kontrolle durch Besitz des privaten Schlüssels oder gar keine Kontrolle.
Dieses Drawback ist im Bereich von Crypto-Börsen bspw. als „Pockets/Key Custody” bekannt: wer übernimmt die Verwahrung der privaten Schlüssel und somit die komplette Kontrolle über die Signaturen?
Zahlreiche Börsen für dezentrale Kryptowährungen nutzen ein Custodial Pockets und haben damit die komplette Kontrolle über die Transaktionen ihrer Kunden – dies stellt einen eklatanten Widerspruch zu selbstverwalteten privaten Schlüsseln seitens des Endnutzers dar, welches das ursprünglich Ziel von Blockchains conflict. Die Nutzer einer dezentralen Anwendung sollten exklusive Kontrolle über ihre Property haben, ohne dritten Parteien, z.B. Banken, vertrauen zu müssen.
Authentizitätsprobleme im dezentralen Szenario
Die Übertragung dieses Authentizitätsproblems auf ein dezentrales Szenario ist somit weitaus komplizierter als in einer einzelnen Firma: Die Firmen A, B, C und D stehen z.B. koopetitiv zueinander, d.h. sie sind Konkurrenten, die aber für eine bestimmte Transaktionsart, für eine bestimmte Zeitspanne oder auch generell in einem gewissen Bereich everlasting zusammenarbeiten wollen. Die „Kooperative” A, B, C, D kann sich aber everlasting ändern, bspw. können E und F hinzukommen, während gleichzeitig A und B wegfallen. Entsprechend ändert sich auch das Vertrauen der Teilnehmer, so wird vermutlich zu Beginn die gemeinsame Lösung mit einem “vertrauten” Teilnehmerkreis beginnen, es können aber aufgrund der gegebenen Offenheit der Lösung auch neue Teilnehmer mitmachen oder bestehende Teilnehmer ausscheiden. Die technischen und organisatorischen Maßnahmen und Prozesse für einen reibungslosen Betrieb müssen dann fehlendes Vertrauen in diese neuen Teilnehmer ausgleichen.
Problematisch bei so einem Setup ist das unterschiedliche verteilte Vertrauen, welches identifiziert und bewertet werden muss. Im zweiten Teil des Beitrags werden entsprechende Lösungsansätze vorgestellt.
