Uwe Grensing erklärt - Wann brauchen SAP-Anwender eine Blockchain?

2018-04-03

Blockchain ist eine Technologie, die das Potenzial hat, wirklich alles zu verändern - so sagt man. Aber ganz ehrlich: irgendwie tut man sich schwer damit. Welche Probleme kann man wirklich mit einer Blockchain lösen? Wann kann ich als Berater im SAP-Umfeld meinen Kunden sagen: "Diese Anforderung können Sie nur mit einer Blockchain umsetzen"?

Vielleicht besitzen Sie inzwischen ein paar Bitcoins. Oder Sie haben sie wieder verkauft. Virtuelle Währungen basieren auf Blockchains. Aber wie funktioniert das? Es könnte ja in der Unternehmens-IT Szenarien mit ähnlicher Problemstellung geben - und dann ist nur noch nie jemand auf die Idee gekommen dort eine Blockchain zu nutzen. Oder vielleicht ist es umgekehrt und die Unternehmens-IT hat Eigenschaften, die eine Blockchain komplett nutzlos machen? Es ist auf jeden Fall sinnvoll, die grundlegenden Techniken der Blockchain vor dem Hintergrund typischer SAP-Anwendungsszenarien zu erklären.

Der paranoide Wirtschaftsprüfer

Wirtschaftsprüfer wollen herausfinden, ob die in Ihrem SAP-System gespeicherten Daten der Finanzbuchhaltung vor Manipulationen geschützt sind. In der Regel wird da auf das interne Kontrollsystem und das Berechtigungskonzept verwiesen - aber ein technisches Verfahren, das auch bei bösartig kriminellen Angriffen hochkompetenter Experten die Sicherheit der Buchhaltung gewährleistet ohne sich auf sekundäre "organisatorische Maßnahmen" zu stützen - das wäre eine tolle Sache.

So ein Verfahren nennt sich "ewiges Logfile" und ist eine Grundlage der Blockchain-Technologie - und so weit ich weiß ist das in den SAP-Standardmodulen in dieser Form bislang nicht implementiert.

Was ist ein Hashwert und eine Hashfunktion?

Man benutzt eine Hashfunktion um auf mathematischem Weg beliebigen Daten eine Zahl zuzuordnen. Das Ziel ist dabei, solch eine Hashfunktion zu nutzen, bei der zwei unterschiedliche Datensätze praktisch nie die gleiche Zahl zugeordnet bekommen - sogenannte Kollisionen. Dazu müssen die berechneten Zahlen natürlich ausreichend groß sein. In der Praxis lagen diese am Anfang zwischen 1 und 2 hoch 128 (das sogenannte MD5-Verfahren, das aber inzwischen nicht mehr genutzt werden sollte), inzwischen sind jedoch Verfahren üblich, die bis zu 2 hoch 512 gehen (SHA-512, oder SHA-3-Verfahren). Das ist eine Zahl die größer ist als die Anzahl der Atome im Universum. Es versteht sich von selbst, dass es bei dieser Größenordnung ein Ding der Unmöglichkeit ist, aus einem Hashwert die ursprünglichen Daten zu rekonstruieren.

In SAP steht dem ABAP-Programmierer die Klasse CL_ABAP_MESSAGE_DIGEST zur Verfügung, mit der Hashwerte nach unterschiedlichen Hashfunktionen für beliebige Daten berechnet werden können.

Möchte man in SAP ECC mit einem ewigen Logfile sicherstellen, dass niemand die Finanzbuchhaltung manipuliert hat, muss man für jede Buchung aus den Inhalten der betroffenen Tabellen (z.B. BKPF, BSEG und FAGLFLEXA) den Hashwert berechnen. Jetzt kommt der spezielle Trick: man bezieht den Hashwert jeweils der Buchung davor in die Berechnung des neuen Hashwerts mit ein. Damit ergibt sich eine verbundene Kette von Buchungssätzen. Wird ein Satz manipuliert, reicht es nicht aus, einen Hashwert zu ändern, sondern auch alle nachfolgenden. Blockchain-Verfahren machen dies genau so, wobei allerdings nicht pro Datensatz ein Hashwert berechnet wird, sondern in aller Regel mehrere Datensätze in einem Block (deswegen: Blockchain) zusammengefasst werden.

Hier der gerechtfertigte Einwand: Was hindert einen Angreifer daran, nicht nur einen Datensatz zu manipulieren, sondern tatsächlich alle nachfolgenden Hashwerte auch neu zu berechnen?

Um diesen möglichen Angriff zu vereiteln, könnte man zu bestimmten Zeitpunkten den aktuellen Hashwert in einer Tageszeitung oder im Bundesanzeiger veröffentlichen. Damit ist eine nachträgliche Änderung sinnlos. Oder man nutzt einen kryptografischen Zeitstempel-Service. Dabei fügt ein unabhängiger vertrauensvoller Dienstleister - vergleichbar mit einem Notar - einem Hashwert ein Datum und eine Uhrzeit hinzu und unterschreibt diesen Datensatz mit seiner elektronischen Signatur. Versieht man die Buchungsdaten in regelmäßigen Abständen mit solch einen signierten Zeitstempel (z.B. stündlich oder täglich), erzielt man einen sehr engmaschigen Schutz.

Die virtuelle Währung Bitcoin geht hier einen anderen Weg: ein weiteres mit einzubeziehendes Datenfeld enthält einen Zähler - eine sogenannte "Nonce". Dieser Zähler muss so lange hochgezählt werden, bis ein weiterer Hashwert eine bestimmte festgelegte Anzahl Nullen enthält. Die Anzahl der Nullen wird so gewählt, dass es ungefähr 10 Minuten dauert, bis solch ein Wert errechnet wird. Will man also einen alten Wert manipulieren würde es für jeden nachfolgenden Wert 10 Minuten dauern, ihn zu korrigieren. Diese Performance-Einbuße wäre allerdings auch für die echten Daten relevant - deswegen müsste man auch hier mehrere Buchungen zu Blöcken zusammenfassen.

Mit diesem zusätzlichen Rechenschritt, dem sogenannten "Proof-of-Work" lösen Blockchain-Verfahren darüber hinaus ein weiteres Problem, das allerdings schwieriger zu verstehen ist: das der "verteilten Buchhaltung."

Die verteilte Verfügbarkeitsprüfung

Stellen Sie sich ein Unternehmen mit Niederlassungen in jeder Stadt Deutschlands vor. Jede der Niederlassungen hat ihr eigenes IT-System und eigene Lagerbestände, z.B. an Ersatzteilen. Um in ganz Deutschland immer lieferbereit zu sein, soll eine dezentrale Verfügbarkeitsprüfung implementiert werden, d.h. bei einer Kundenanfrage werden die Bestände in ganz Deutschland auf Verfügbarkeit geprüft, nicht nur die der Niederlassung, bei der die Anfrage eintrifft. Klarer Vorteil: Niedrigere Kosten, da nicht jede Niederlassung ständig alle Teile vor Ort am Lager halten muss. Wir SAP-Menschen würden das so umsetzen, dass das System der jeweiligen Niederlassung für ihren Lagerbestand verantwortlich ist wir würden dort die Verfügbarkeit prüfen und reservieren. Der Nachteil dieser Lösung ist, dass wir "blind" sind, wenn das System einer Niederlassung ausfällt und eine Niederlassung das System theoretisch "betrügen" kann: sie kann nämlich Bestände als nicht-verfügbar melden, wenn sie sie für sich behalten möchte.

Mit einem Blockchain-Verfahren kann die dezentrale Verfügbarkeitsprüfung anders umgesetzt werden: alle Niederlassungen kennen grundsätzlich alle (über die verketten Hashwerte als gültig befundenen) Transaktionen. Kommt eine neue Verfügbarkeitsanfrage, kann die Niederlassung die als erste den "Proof-of-Work" berechnet hat, den Bestand durch eine neue Buchung reservieren und es kann zu einem späteren Zeitpunkt durch eine neue Transaktion die Auslieferung veranlasst werden. Sollten zwei Niederlassungen zu unterschiedlichen Resultaten gelangen (weil beispielsweise Bestand in unterschiedlichen Niederlassungen verfügbar ist), sorgen komplexere Abstimmungsregeln zwischen den Systemen für ein eindeutiges Ergebnis. Versucht eine Niederlassung, Bestände zu verschleiern, geht das nicht, da alle Bestände überall parallel sichtbar sind, fällt ein System aus, übernehmen die anderen automatisch die Funktionalität während der Dauer des Ausfalls.

Der Nachteil dieses Verfahrens ist offensichtlich: durch den Zeitaufwand des "Proof-of-work" und den Abstimmungsmodalitäten geschieht solch eine Transaktion nicht online. Außerdem ist aus mathematischen Gründen (Stichwort: byzantinische Generäle-Problem) eine möglichst große Zahl an beteiligten Niederlassungen (i.d.R. mindestens 7) erforderlich, um das Verfahren betrugssicher zu machen. Der Vorteil ist auch klar: es handelt sich um eine wirklich fehlertolerante dezentrale Implementierung einer Verfügbarkeitsprüfung. (Anmerkung: es gibt neben dem "Proof-of-Work" weitere Verfahren für Blockchain-Algorithmen, die für bestimmte Anwendungsfälle genutzt werden können, wie beispielsweise "Proof-of-stake", doch darauf gehe ich hier heute nicht im Detail ein.)

Sind solche Verfahren in einer SAP-dominierten Unternehmens-IT praxisrelevant?

"Blockchain" ist nicht ein Verfahren - es ist eine Sammlung von Technologien, die unterschiedliche Probleme lösen können. Das Thema der verketten Hashwerte (ewiges Logfile) wird in nicht allzu ferner Zukunft bei Buchungen, bei denen es auf nachträgliche Fälschungssicherheit ankommt, sehr wahrscheinlich zum Standard vieler Systeme gehören. Das ist aber ein technisches Implementierungsdetail, dessen Potenzial, die Welt zu verändern doch eher begrenzt ist.

Anders sieht es mit den "verteilten Ledgern" aus. Aufgrund der mathematischen Grundlagen ihrer Funktionalität können solche Systeme nur mit einer großen Zahl von Beteiligten sinnvoll eingesetzt werden. Ist die Zahl der Beteiligten klein und das Misstrauen zwischen ihnen nur gering, da es sich z.B. um langfristige Geschäftsbeziehungen handelt, schrumpft der Vorteil einer verteilten Datenhaltung und zentralisierte, integrierte und gemeinsam genutzte Systeme können ihren klaren Nutzen ausspielen. Überall, wo dagegen eine große Zahl unbekannter Akteure sichere Transaktionen und den Zugriff auf gemeiname und begrenzte Ressourcen abwickeln wollen, ist das Potenzial von Blockchain-Anwendungen sicherlich in einem Ausmaß gegeben, wie es momentan noch nicht abzuschätzen ist.

Wenn Ihnen also demnächst vorgeschlagen wird, die Lieferdaten mit Ihrer Spedition, mit der Sie seit vielen Jahren vertrauensvoll zusammenarbeiten, per Blockchain auszutauschen, seien Sie skeptisch und bewundern Sie das phantasievolle Marketing von IT-Dienstleistern. Wenn es aber darum geht, beispielsweise Rohstoffkontrakte anstatt an Börsen per Blockchain abzuwickeln, seien Sie neugierig!

Anmerkung: Das Thema "Smart Contracts" habe ich in diesem Beitrag bewusst nicht angesprochen. Das ist Thema für einen separaten Artikel zu einem späteren Zeitpunkt.