Blockchain krempelt das Records Management um

26. Mai 2017 10:25 Uhr  |  Dr. Ulrich Kampffmeyer  |  Permalink


Bisher dachte man beim Begriff Blockchain immer an digitale Währungen, neue Geschäftsmodelle für Banken und Versicherungen. Aber Blockchain verändert auch andere traditionelle Anwendungsfelder – so zum Beispiel das Records Management.

Die „Blockkette“ ist ein Verfahren, in dem kontinuierlich gemachte Einträge durch kryptografische Enkodierung der verketteter Einträge die Verfälschbarkeit ausschließen. In der Regel benutzt man eine Datenbank, deren Sicherung gegen Manipulation (Integrität, Authentizität) durch Speicherung des Hashwertes des vorangehenden Datensatzes im jeweils nachfolgenden durch kryptographische Verkettung gesichert ist. Ähnliche Prinzipien kennen wir bereits aus kaufmännischen Systemen, wo eine Buchung nicht einfach gelöscht werden kann. Hier muss im Journal ein neuer Eintrag gemacht, der alte als ungültig gekennzeichnet und vom neuen Datensatz referenziert werden.

Daher ist der Schritt in die gleichermaßen abzusichernde revisionssichere Archivierung naheliegend. Records Management und revisionssichere Archivierung betreffen auch vorrangig kaufmännische, handels- und steuerrechtliche Vorgaben, wo es um Verfälschungssicherheit und Nachweisfähigkeit geht.

Was man jedoch bedenken muss ist, es geht hier um eine spezielle Lösung für die Datenbank, also bei einer traditionellen Referenz-Datenbank-Architektur eines revisionssicheren Archives um die Metadaten und Verwaltungsdaten. Die Objekte (Belege, Dokumente etc.) werden ja in einem separaten Speicher referenziert. Dieser ist aber nicht durch Blockchain abgesichert. Lediglich wenn man die Dokumente auch direkt als BLObs Binary Large Objects in der Datenbank mitspeichern würde, ergäbe sich das gleiche Schutzprinzip. Das würde aber die Nutzung durch die großen Datenmengen entscheidend verlangsamen. Allerdings ist für die revisionssichere Archivierung dieser Schritt eigentlich nicht notwendig, weil die Informationsobjekte im WORM-Verfahren unveränderbar gespeichert werden und zu dem die Daten der Informationsobjekte wie Hash, Größe, Datum, Titel etc. ebenfalls in Eingangs-Protokollen verzeichnet wird, die ihrerseits auch revisionssicher archiviert werden. natürlich kann man aber auch bei den Audit-Trails das Blockchain-Prinzip zur Absicherung einsetzen. Der Einsatz von Blockchain wäre aber genaugenommen nur auf die Index- und Verwaltungsdatenbank zu beschränken und macht dort auch Sinn. Über die Indexdatenbank wird das Wiederfinden und der Zugriff auf die sicher archivierten Objekte umgesetzt. Veränderungen hier würden zwar nicht zu Veränderungen bei den revisionssicher archivierten Objekten führen, aber man würde durch Manipulation gegebenenfalls andere oder keine Dokumente finden. Durch Blockchain lässt sich also die Verwaltung der archivierten Objekte zusätzlich absichern. Aber man muss auch noch andere Records-Management-Prinzipien in Betracht ziehen – das Löschen von Informationen. Hier wird bisher unterschieden zwischen „logischem Löschen“ des Eintrags, der auf das separat gespeicherte Dokument verweist, und das „physische Löschen“, bei dem sowohl der Eintrag in der Indexdatenbank als auch das gespeicherte Objekt gelöscht werden. Dies funktioniert so mit Blockchain nicht.

Der Ansatz Blockchain für Records Management zu nutzen und generell Records Management zu automatisieren kommt wie vieles aus den USA. Dort geht es im Records Management vorrangig um die Verwaltung von Daten mit Datenbanken. Der zu nutzende Speicher, also z.B. ein sicheres WORM-Verfahren, ist eine nachgeordnete „Baustelle“. Bei reinen Records-Management-Anwendungen wird sich ebenso wie bei Fibu-, ERP-, Bank- und anderen Anwendungen der Blockchain-Ansatz sinnvoll einsetzen lassen. Für Konzepte wie die revisionssichere Archivierung wird aber eine generelle Frage zu lösen sein: welche Zukunft hat die Referenz-Datenbank-Architektur? Werden hier BLOb-Datenbanken, Hadoop-Speicher, Cloud-Architekturen und andere Entwicklungen das traditionelle, liebgewonnene Konzept grundsätzlich in Frage stellen? Immerhin beschäftigen sich auch professionelle Archivdienstleistungsanbieter wie Iron Mountain damit und nicht nur Berater und Analysten wie Alan Pelz-Sharpe (Deep Analysis) und Steve Weissman (Holly Group). In den USA ist das Thema brandheiß.

Ach ja, ähnliche Ideen für einen anderen Anwendungszweck hatten wir in Deutschland schon mit den Verfahren zum Nachsignieren der Zertifikate von elektronischen Signaturen mittels Hash-Bäumen. Und das könnte auch jemanden auf die Idee bringen, man lässt das Ganze mit Signaturen und Nachsignieren und macht hier einfach auch auf Blockchain.

Ulrich Kampffmeyer

Dr. Ulrich Kampffmeyer

Curriculum auf Wikipedia https://de.wikipedia.org/wiki/Ulrich_Kampffmeyer

27 Kommentare zu “Blockchain krempelt das Records Management um

  • Blockchain Hype aus technologischer Sicht nicht nachvollziehbar
    1. Juni 2017 um 16:35
    Permalink

    Die Blockchain soll ja nun mal wieder alles revloutionieren, auch „Information Governance“ oder „Records Management“.
    Als ITler denke ich da eher an „The Hype is a Cycle“ [http://geek-and-poke.com/geekandpoke/2016/12/12/hype-cycle]
    ich kann diese Euphorie inhaltlich leider nicht nachvollziehen, ganz im Gegenteil.

    Im Ernst: Wenn man die Grundlagen der Blockchain-Technologie betrachtet, wie sie aus der Originalquelle [https://bitcoin.org/bitcoin.pdf] hervorgehen (deren Lektüre bei diesem Thema zu empfehlen ist), dann kann ich nur sehr wenig Potenzial für diese Technologie rund um „Information Governance“ oder „Records Management“ erkennen.

    Das revolutionäre an Blockchain ist zunächst die Vermeidung einer zentralen Instanz. Bei der wichtigsten Anwendung von Blockchain – Bitcoin – werden Finanztransaktionen ohne eine zentrale Bank abgewickelt. Die Blockchain ist ein „Distributed Ledger“, der zudem noch vollständig öffentlich ist. Dies ist die zweite wichtige Eigenschaft. Da dies natürlich ein Problem ist, sind sie z.B. bei Bitcoin komplett anonym (die Blockchain verwendet Signaturen; die verwendeten Zertifikate sind dann wieder anonymisiert, eigentlich ein schlechter Scherz).

    Um ohne zentrale Instanz Transaktionen sicher abzuwickeln, bedarf ist zudem einer Lösung des Double-Spending Problems. Die Validierung der Transaktion erfolgt durch ein sog. „Proof-Of-Work“. Die Beteiligten Knoten des Blockchain-Netzes „kämpfen“ darum, als erste einen Block zu validieren (wodurch im Übrigen die neuen Bitcoins geschürft werden). Da dies sehr aufwendig ist, werden immer viele Transaktionen in einem Block zusammengefasst. Schließlich ist die Chain eine Chain, eine sequentielle Kette. Skalierung erreicht man damit nicht. Die Validierung einer Transaktion ist also langsam und die Technologie by-design nicht skalierungsfähig. Und etwas aus der Kette löschen bricht die Kette auch, wie im Artikel schon erwähnt wurde.

    Zusammengefasst: Wir haben es also mit einer nicht-skalierbaren, langsamen, oft Einzelobjektebene nicht-transaktionalen Technologie zu tun deren Daten entweder komplett öffentlich sind (Datenschutz? Unternehmensgeheimnisse?) oder daher ggf. noch komplett anonym sind. Und damit möchte man nun „Information Governance“ oder „Records Management“ abbilden?

    Wie geht Nachvollziehbarkeit bei Anonymität?
    Wie geht Datenschutz bei öffentlichen Daten? Und ohne Löschmöglichkeit?
    Wann bekommt man die Bestätigung, dass ein Dokument erfolgreich archiviert wurde?

    Und vor allem: wo ist hier überhaupt der UseCase, auf eine zentrale Instanz verzichten zu müssen? Es ist ja nicht so, dass man seine aufbewahrungspflichtigen Dokumente heutzutage zu einem zentralen ArchivCenter bringen muss. Vielmehr steht doch jedes Unternehmen für sich in der Pflicht, die Dokumente selbst aufzubewahren. Es gibt hier weder den Bedarf, eine zentrale Instanz aus der Transaktionskette zu entfernen noch den Bedarf, ein „Distributed Ledger “ nutzen zu wollen (abgesehen davon, dass man es in diesem Kontext wohl auch nicht so einfach darf). Der Austausch aufbewahrungspflichtiger Dokumente läuft heute und seit je her immer schon zwischen zwei Parteien und jeder bewahrt seine Dokumente auf. Die Echtheit kann man mit digitalen Signaturen schon ewig absichern, wenn denn überhaupt gewünscht.

    Stopp, halt. Eine zentrale Instanz gibt es noch. Den Staat. U.a. als zentrale Stelle von Geburts- und Heiratsurkunden usw. Super, diese zentrale Instanz könnten wir natürlich ausbooten. Heiraten ohne Staat, das wird ein Erfolgsmodell…

    Lassen wir das brandheiße Thema mal in Ruhe abkühlen.

    Entspannte Grüße,
    Gregor Joeris

    Antwort
  • Blockchain funktioniert nicht für Records Management
    11. Juni 2017 um 10:47
    Permalink

    Nur ein paar klärende Argumente zur Erläuterung meines Ursprungsbeitrages und um Gregor Joeris‘ Kritik aufzugreifen:

    Die Grundkonzepte der Blockchain funktionieren nicht für Records Management:

    • verteilt und öffentlich
      passen nicht in eher zentrale Inhouse-IT-Konzepte
    • sequentielle Absicherung
      wird bei größeren Datenmengen ineffektiv und langsam
    • Anonymität der Einträge
      widerspricht Verantwortlichkeit, Nachvollziehbarkeit und Prüfbarkeit
    • keine Möglichkeit zum Löschen
      widerspricht dem Grundprinzip des Records Management in Bezug auf die Entsorgung veralteter, ungültiger und falscher Information

    Besonders das Thema Datenschutz, DSGVo, wird noch einige Hürden für die Blockchain aufbauen. Und von der Stromrechnung einmal ganz zu schweigen … 

    Antwort
  • Trends im Records Management
    29. Juli 2017 um 9:15
    Permalink

    Zwei Trends verändern aktuell das Records Management: Blockchain und Automatisierung.

    Während Unternehmen wie Deep Analysis (Alan Pelze-Sharp), Holly Group (Steve Weissman), Inacta (Jens Beba), Iron Mountain und zahlreiche andere den Einsatz von Blockchain beim Records Management promoten, sieht SER Solutions (Gregor Joeris) dies in seinem Beitrag in unserem Blog kritisch. Auch wir bei PROJECT CONSULT reagieren eher zurückhaltend auf dieses Einsatzfeld von Blockchain. 

    Den Trend der Automatisierung im Records Management beflügelt Künstliche Intelligenz (KI). Bereits im Sommer 2014 hatten wir Anwendungsfelder der Automatisierung im Records Management beschrieben (Records Management und Automation) und das Thema in einem virtuellen Roundtable der Competence-Site zur Diskussion gestellt (Automatisierung als Zukunft des Records Management?). In unserem Artikel findet sich bereits damals eine lange Liste von Funktionen, die automatisiert werden.

    Records Management & Automatisierung (2014): Anwendungsbereiche

    Durch die rasch voranschreitenden Entwicklungen bei Bigdata Analytics und Artificial Intelligence (AI) hat sich der Trend nun beschleunigt. Gerade beim Aufbau von Ordnungssystematiken, bei der Erfassung von neuen Records (Records Declaration), bei intelligenter Vererbung von Ordnungskritierien und anderen Metadaten. und beim Erschließen der Inhalte sind Fortschritte zu verzeichnen. Besonders der aufwändige und fehlerträchtige Flaschenhals der manuellen Erfassung von Records und ihrer Metadaten kann überwunden werden. In verschiedenen Vorträgen, zuletzt im Juni 2017, und Artikeln sind wir auf die möglichen Einsatzfelder von KI Künstlicher Intelligenz im Information Management eingegangen.

    Folie 89 - Keynote "ECM - und was kommt danach?" Lobonet http://bit.ly/lobonet_DrUKff    

    Die Automatisierung im Records Management schreitet schneller voran und ist wichtiger als der rein technologische Ansatz von Blockchain. Künstliche Intelligenz, Analyse-Verfahren und Automatisierung entlasten direkt den Endanwender. Sie unterstützen nicht nur herkömmliche Verfahren und Ansätze des Records Management sondern bringen neue Funktionalität und Nutzungsmodelle in die angestaubte Branche, die sich auf die Verwaltung von klassischen Dokumenten mittels ihrer Metadaten konzentrierte. Voluminöse Konzepte der Vergangenheit, die besonders das Records Management in der öffentlichen Verwaltung und regulierten Branchen betreffen, werden obsolet. Bereiten wir uns auf eine Revolution der Schriftgutverwaltung vor! Auch die systematische Behinderung von effizienten Methoden zur Verwaltung, Erschließung und Nutzung elektronischer Records im Public Sector wird zu einem Ende kommen.

    Antwort
    • Skepsis ist angebracht
      21. Januar 2019 um 18:59
      Permalink

      So wie man Blockchain im ECM Umfeld kritisch betrachten sollte, sehe ich das auch bezüglich KI.
      KI-Funktionalität wird noch stärker als heute im Dokumenteingang und Klassifizierung die Aufgabe der Massenbelegverarbeitung übernehmen und mit zunehmender Leistungsfähigkeit in weitere und komplexere Szenarien vordringen, z. B. Vertragsmanagement u. ä und in den heute noch manuellen Aufgaben mindestens qualifizierte Vorarbeit leisten.
      Wenn man die Arbeitskräfte-Entwicklung sich anschaut ein nahezu notwendiger Schritt.
      Ich denke KI wird ähnlich ECM in früheren Jahren überschätzt und z. T. überzeichnet – schließlich kann man an einem Hype gut verdienen und die Karten der Anbieter können ggf. neu gemischt werden.

      Deswegen Augen auf wenn jemand vorschwärmt – er könnte dafür entsprechendes Eigeninteresse haben, ebenso wie derjenige der neue Themen in Bausch und Bogen ablehnt.

      Antwort
  • Blockchain & Records Management ?
    26. August 2017 um 14:39
    Permalink

    Während bei uns im Blog Joeris von SER wie auch wir (siehe oben) den Einsatz von Blockchain-Technologien für Records Management eher „zurückhaltend“ sehen, ist Beba von inacta durchweg positiv eingestimmt, was den Einsatz von Blockchain im Informationmanagement angeht. In unserem Jubiläums-Newsletter-Kompendium (http://bit.ly/PCJub25NL) hat er den Beitrag „Anwendungsmöglichkeiten von Blockchain-Technologie im Information Management“ veröffentlicht: http://bit.ly/PCjub25Beba . Die kritischen Stimmen weisen auf Anforderungen der GDPR/DS-GVO und Architektur-Probleme hin, die den Einsatz für klassisches Records Management stark einschränken.

    Antwort
  • Ein praktisches Beispiel für Records Management & Blockchain
    4. September 2017 um 9:05
    Permalink

    in unserem August-Newsletter (der quasi Band 2 unseres Jubiläum-Newsletters vom Juni ist) hat Sanooj Kutty (Mannai Trading Co., Qatar) ein aktuelles Beispiel für den Einsatz von Blockchain beim Records Management geliefert „Know your Expat – A case for Blockchain based Records Keeping in Qatar“ (Seite 32ff, http://bit.ly/PCNLAug2017, PROJECT CONSULT Newsletter 04/2017, August 2017). In dem Workflow geht es um Beantragung und Genehmigung von Aufenthaltsgenehmigungen für Qatar.

     

    Antwort
  • Blockchain & Archivierung
    12. Januar 2018 um 9:31
    Permalink

    Inzwischen gibt es auch in Deutschland die ersten Projekte, bei denen Blockchain-Techniken für die elektronische Archivierung eingesetzt werden. Bei der Metro geht es hier um Massendaten aus Kassen, die dem KassenG unterliegen: http://bit.ly/MetroBlockchain. Naturgemäß geht es eigentlich nicht um „Archivierung“ sondern um „Aufbewahrung“ entsprechend den Vorschriften von HGB, AO und GoBD. Im Anwendungsfall geht es nicht um dokumentorientierte Speicherung sondern um strukturierte Datensätze.

    Bei Massendaten aus Tausenden von Kassen greifen bisherige Archivierungskonzepte nicht. Diese basieren auf einer Indexdatenbank, die auf einzelne Objekte in einem separaten Speicher verweist. Perfomance- wie auch Mengengründe stellen dieses Konzept aber bei Massendaten in Frage. Jeder einzelne Index in der Datenbank hätte z.B. die gleiche Größe wie der aufzubewahrende Datensatz des Kassenbons. Das Eintragen und Prüfen der Indexinformation und das Wegschreiben der Archivobjekte ist bei großen strukturierten Datenmengen nicht performant genug. Die Nutzung von WORM-Verfahren im Speicher führt zu zusätzlichen Größen- und Performance-Problemen. Die vorgesehene Lösung erlaubt darüber hinaus die Auswertbarkeit der Daten mit Analytics-Werkzeugen.

    Es handelt sich bei der geplanten Lösung aber nicht um eine „klassische“ Blockchain, wie sie z.B. bei virtuellen Währungen zum Einsatz kommt. In den öffentlichen, verteilten Systemen mit Mining-Funktionalität kommen viel aufwändigere Verfahren als in einer Inhouse-Lösung, wo Datensätze, mit Prüfsummen versehen, verknüpft werden und in sequentieller Abfolge gegengesichert werden. Natürlich müssen in dieser auf Open-Source- und Bigdata-Werkzeugen basierenden individuellen Lösung eine Reihe von Problemen berücksichtigt werden. Hierzu gehört z.B. die Bildung von Zeitscheiben, um Informationen nach den Aufbewahrungsfristen löschen zu können, Verknüpfungen zu Laufzeitsystemen z.B. mit den zugehörigen Daten aus Materialwirtschafts- und Logistik-Programmen sowie die Behandlung personenbezogener Daten nach DSGVo in den Kassenbelegen. 

    Ob durch solche Lösungen die bisherigen Konzepte der revisionssicheren Archivierung mit Referenzdatenbank und separatem Repository in Frage gestellt werden, ist wenig wahrscheinlich. Wie auch das Records Management benötigt die effiziente Verwaltung und Erschließung von Information mehr als nur Analytics und verfälschungssichere Speicherung. Anders als eine Blockchain ermöglicht Records Management und revisionssichere Archivierung auch das gezielte, nachvollziehbare und dokumentierte Löschen – etwas, was es in einer verketteten Blockchain per Definitionem nicht geben kann.

    Die Lösung von Deepshore und Metro soll zukünftig der Open-Source-Community zur Verfügung gestellt werden.

    Antwort
    • Konsistentes Löschen in der Block Chain
      12. Dezember 2018 um 11:03
      Permalink

      Es gibt nicht die EINE Art der Blockchain sondern verschiedene. Die meisten Menschen gehen immer von der Distributed Ledger Blockchain mit verteiltem Proof-of-Work aus, wie z.B. virtuellen „Währungen“ (BITCOIN und Co.) zu Grunde liegt. Dabei bedeutet Blockchain in erster Linie eine besondere Art der Verkettung. Wikipedia sagt zu Blockchain:

      „Eine Blockchain (auch Block Chain, englisch für Blockkette) ist eine kontinuierlich erweiterbare Liste von Datensätzen, genannt „Blöcke“, welche mittels kryptografischer Verfahren miteinander verkettet sind. Jeder Block enthält dabei typischerweise einen kryptografisch sicheren Hash (Streuwert) des vorhergehenden Blocks, einen Zeritstempel und Transaktionsdaten“.

      Es geht hier eher um das Modell „Auditing“, Wikipedia schreibt hierzu (Ergänzungen im Beitrag im September 2018): 

      „Beim Auditing in der Informationstechnik geht es darum, sicherheitskritische Operationen von Softwareprozessen aufzuzeichnen. Dies betrifft insbesondere den Zugriff auf und die Veränderung von vertraulichen oder kritischen Informationen. Das Auditing eignet sich hierbei deshalb für eine Blockchain, weil es relativ geringe Datenmengen produziert und gleichzeitig hohe Sicherheitsanforderungen aufweist. Eine Blockchain kann hierbei das Audit-Log (auch als Audit-Trail bezeichnet) vor Veränderung schützen. Zudem sollten die einzelnen Einträge mit einer digitalen Signatur versehen werden, um die Echtheit zu gewährleisten. Ein dezentraler Konsensmechanismus, wie bei Bitcoin, wird nicht zwingend benötigt.“

      Gehen wir einen Schritt weiter: Verkettung plus Audit-Trail zur zusätzlichen Absicherung. Für Records-Management- und Archivsysteme, die Inhouse oder in einer eigenen private Cloud laufen, lassen sich so andere Blockchain-Architekturen aufbauen, die nicht wie die Internet-Währungen funktionieren. Sie sichern sich durch die Verkettung sowie zusätzlich durch einen Audit-Trail, der ebenfalls als Blockchain aufgebaut ist. So etwas kann man dann als „Block Chain mit Blockchain“ nennen. Zur einfacheren Unterscheidung benutzen wir für die nur verketteten Blöcke den Begriff Block Chain in zwei Worten. 

      Die Bildung von Prüfsummen mit Hash und deren Anhängen an Informationsobjekte gibt es schon sehr lange in der elektronischen Archivierung (z.B. im SIZ-Konzept für die Archivierung in der Sparkassen-Finanzgruppe). Hieraus lässt sich einfach der nächste schritt der Verkettung generieren. Dies alles wird in einem Audit-Trail protokolliert, in dem die Operationen mit den Transaktionsdaten, dem Zeitstempel und anderen Attributen kontinuierlich aufgezeichnet werden. Die Informationsobjekte (oder Dokumente) liegen vereinzelt vor und sind nicht Bestandteil des Audit-Trails selbst.  Wie das Eintragen eines neuen Blocks kann nun auch das Austragen eines Blockes geschehen. Hierfür müssen aber zusätzlich noch ID, Hashwert und Transaktionsdaten des dem zu löschenden Block vorausgehenden und folgenden eingetragen werden. Erfolgt das Lesen der Retrieval-Information vom Jüngsten zum Ältesten wird zunächst die „Block-Löschungs-Information“ gefunden. Die Audit-Trail-Daten inkl. den dort mitgespeicherten Metadaten stehen aber weiterhin zur Verfügung und sorgen für Nachvollziehbarkeit. Das Thema der Absicherung über Zeitstempel lässt sich entsprechend eIDAS auch mit zertifizierten Zeitstempeln als Fernsignaturen erreichen, die als qualifizierte Signaturen einen noch höheren Nachweiswert haben. Alternativ kann auch in verteilten Organisationen oder Verbünden über Master-Nodes nachgedacht werden.

      Blockchain-Lösungen à la Bitcoin sind weiterhin für Archivierung und Records Management nicht geeignet.

      Das Verfahren der Verknüpfung von Blöcken nebst Audit-Trail haben wir schon in mehreren Beiträgen angesprochen und auch in der Abschluss-keynote auf der EUROFACTURA-Tagung in Bielefeld am 10.10.2018 dargestellt – http://bit.ly/EuroFactura18-Keynote – dort Folie 68 bis 82.  Mehr dazu gibt es auf unserem Update Information Management 2019: http://bit.ly/updateIM19news

       

      Antwort
      • Using Blockchain for Archiving and Records Management
        21. Dezember 2018 um 10:29
        Permalink

        Almost all of the current archiving and RM systems are based on databases. To change the architecture to Blockchain is a very major change. Most suppliers will be reluctant to go that way.

        Of course, aspects of Blockchain are useful for archiving. Of course, auditing and auditing are important, and if that’s inherent in architecture, that’s very good.

        But the distributed characteristics of Blockchain are mostly not needed. And is RM really transaction-oriented? My clients are also having this discussion: How do we use Blockchain if we do not want to use everything from Blockchain? Is Blockchain worth it? Difficult question. I have not found an answer yet.

        Antwort
      • Block Chain & die DSGVO
        20. Januar 2019 um 12:35
        Permalink

        Lieber Herr Schwalm,

        auf Twitter (http://bit.ly/SchwalmDSGVO) haben Sie geschrieben „Solange Blockchain die Compliance zur DSGVO nicht ermöglicht ist Beweiswerterhaltung ein Thema von vielen“ und dies als Antwort auf unseren Beitrag http://bit.ly/PC-Blockchain gepostet. In der folgenden Diskussion haben Sie eine Reihe von Fragen und Entgegnungen zu unseren Kommentaren gepostet, die nur schwer auf Twitter zu beantworten sind. Zu einigen grundsätzlichen Aspekten Ihrer Einwürfe rund um DSGVO und Blockchain möchte ich daher hier bei uns im Blog Stellung nehmen.

        Wir sind uns, glaube ich, einig, dass es nicht die EINE Blockchain-Technologie gibt. Wir sprechen hier nicht über die public Blockchain, wie sie bei „Währungs“-Anwendungen wie Bitcoin zum Einsatz kommt. Dass das öffentliche Verfahren für Records Management und Archivierung – ebenso wie für die Erfüllung der Anforderungen der GDPR nicht geeignet ist, habe ich eingangs zu diesem Blog geschrieben. Wir sprechen über interne „private“ Anwendungen für Unternehmen und Unternehmensverbünde. Hierbei kommen einfachere Verfahren zum Einsatz, die keinen externen „Proof-of-Work“ oder die aufwändige Generierung von „Coins“ benötigen. Hier sind aktuell zwei Typen zu sehen: der Audit-Trail als Blockchain und die Speicherung von Massen-Transaktionen als Blockchain. Beim erwähnten Anwendungsfall von Deepshore bei der Metro handelt es sich um den letzteren. 

        In unseren Ausführungen geht um die Kombination zweier Ansätze: eine eher klassische Blockchain für den Audit-Trail als Nachweis der Transaktionen, Unverändertheit usw. sowie die Nutzung von verketten Blöcken, sprich Informationsobjekten (oder Dokumenten). Klassische Blockchain-Anwendungen bevorzugen strukturierte, möglichst gleichförmige Daten oder gleich aufgebaute Datensätze. Dokumente, unterschiedlich in Art, Größe und Format, sind dafür eher ungeeignet. Zumindest werden Informationsobjekte benötigt. Ein solches Informationsobjekt setzt sich aus Header, dem eigentlichen Inhalt (Content) und einem Trailer zusammen. Im Header hat man einen Unique Identifier mit Zeitstempel, der jedes Objekt identifiziert sowie weitere Metadaten, im Trailer zum Beispiel eine Prüfsumme mit Hash-Wert über das Informationsobjekt. Solche Objekte wurden z.B. bereits Anfang der 90er Jahre in Standards wie ISO 10166 und z.B. im „SIZ-Grundindex“ für die Archivierung in der Sparkassen-Finanzgruppe oder im „CCSDS OAIS“ der Weltraumbehörden umgesetzt. Natürlich gab es damals noch nicht den Begriff der Blockchain. Eine Verknüpfung von Referenzobjekten wie z.B. das Schreiben des Unique Identifiers zusammen mit der Prüfsumme in den Header des Folgeobjektes, den Audititrail oder eines Referenzobjektes, war möglich. Warum wurde aber dieses relativ aufwändige Softwareverfahren, dass auch kontrolliertes Ändern, Löschen und Referenzieren von Versionen und Renditionen erlaubt, bei der elektronischen Archivierung nicht implementiert? Ganz einfach – man vertraute damals Anfang der 90er Jahre mehr den verfälschungssicheren digitalen optischen Speichern wie optischen Platten und optischen Bändern. Dies machte damals einen zusätzlichen Schutz durch Verkettung unnötig, da dieser auf nur einmal beschreibbaren WORM-Medien Schwierigkeiten nach sich zieht. Die aktuelle Diskussion um Blockchain bei Records Management und elektronischer Archivierung greift so Verfahren und Funktionen auf, die es längst gibt.

        In unserem Vorschlag der Kombination von Block Chain – verketteten Informationsobjekten – mit der Blockchain – als zusätzlich kontinuierlich durch Hashwert-Bildung abgesichertem Protokoll (Audittrail) – wird es möglich, Informationsobjekte konsistent sowohl logisch als auch physisch aus der Block Chain zu entfernen. Das Entfernen entspricht dem Ersetzen oder Ändern unrichtiger Information ebenso wie dem Löschen nicht mehr benötigter oder unzulässiger Information. Im unveränderbaren, kontinuierlich weiter geschriebenen Audittrail werden zusätzlich zu eigentlichen Transaktion der Typ der Transaktion, die notwendigen Daten des Vorgängers in der Kette und des Nachfolgers in der Kette mit gespeichert, so dass die Lücke über das Protokoll nachvollziehbar geschlossen wird. Das Protokoll gibt außerdem den Nachweis, welches Objekt mit welchem Inhalt entfernt wurde. Dies entspricht auch den Prinzipien des Records Management, dass nicht geändert oder gelöscht wird ohne einen Nachweis. Um Fehler und Inkonsistenzen bereits programmtechnisch schneller als das Durchsuchen der Audittrail-Blockchain zu ermöglichen, empfiehlt sich ein gesichertes Extra-Protokoll oder eine Tabelle mit den Änderungen und Löschungen zu führen. Ein solches Änderungs- und Löschprotokoll gehörte bereits zu den Prinzipien der revisionssicheren Archivierung Mitte der 90er Jahre. Stößt man beim Arbeiten mit Dokumenten (Informationsobjekten) auf ein entferntes Objekt, so wird dieser Fehler zunächst performant gegen das Löschprotokoll/Löschtabelle (und andere Fehler-Tabellen) geprüft und eine entsprechende Information ausgegeben. Ob Informationsobjekte nun logisch oder physisch gelöscht werden (müssen) obliegt dem Inhalt und dem Anwendungsfall. Ältere Archivsysteme haben nur Dokumente direkt gespeichert und sind daher – leider – nicht in der Lage den Informationsobjekt-basierten Ansatz der Kombination von Blockchain mit Block Chain umzusetzen. Hier sind die Anbieter zu kurz gesprungen. 

        Sie werfen die Frage der Metadaten in Bezug auf die personenbezogenen Daten auf: Welche Daten sind wo? Wir haben hier drei relevante Komponenten: den Content des Informationsobjektes selbst, die Metadaten im Header und Metadaten im Audit-Trail (und natürlich bei herkömmlichen Systemen in der Index-Datenbank). Der Inhalt eines Informationsobjektes beinhaltet natürlich alle personenbezogenen Daten, in die ursprünglichen Datei – sei es Scan, ein PDF, eine Liste, eine E-Mail – ursprünglich enthalten waren und die natürlich unverändert nachvollziehbar gespeichert werden. Die Metadaten im Header sind grundlegende Informationen, die zu Identifizierung, Verwaltung und Schutz benötigt werden. Hier kann kontrolliert werden, dass keine Daten, die unter die DSGVO fallen, enthalten sind. Im Audit-Trail sind dann auch nur solche Daten enthalten, die die Identifikation und Nachvollziehbarkeit sowie die Unverändertheit durch Hashwerte der Objekte und Hashwerte der Transaktionen, auch bei Bedarf mit qualifiziertem Zeitstempel nach eIDAS, enthalten. Ihre eine Frage bezieht sich auf die möglicherweise in der unveränderbaren Blockchain enthaltenen personenbezogenen Daten. Auch hier gibt es bereits seit den Frühzeiten der revisionssicheren Archivierung aus den 90er Jahren entsprechende Konzepte. Bekannt und weitverbreitet ist das Prinzip der Dokumentenklasse, bei der Attributwerte auf das zugeordnete Objekt vererbt werden in dem die ID der Dokumentenklasse als Metadatum mitgespeichert wird (aber nicht die Attribute und ihre Inhalte; die liegen in der Verwaltung des Records-Management- oder Archivsystems). Das gleiche Prinzip gibt es auch für „neutrale Benutzerklassen“. Diese entsprechen Rollen, die langfristig stabil sind und auch nach Jahrzehnten noch den Zugriff auf gespeicherte Informationen erlauben. Im Konzept der 90er Jahre stand bereits im Vordergrund, dass keine personenbezogenen Daten ausgewertet werden können. So das BDSG schon damals. Daher wurde in den Metadaten nur eine ID für den Benutzer und seine Benutzerklasse (inkl. Ort und Zugriffsweg für die Daten in einem externen Verzeichnis) für die Berechtigung mitgespeichert. Dies geschah in der Indexdatenbank, in objektorientierten Systemen auch in den Metadaten des Informationsobjektes. Wenn man nun einen Anwender, der ein Objekt generiert und zur Speicherung übergeben hat, ermitteln wollte, musste man mit dem Datum des Objektes, der ID und der Benutzerklasse in ein separates Berechtigungssystem wechseln, um ermitteln zu können, welcher Benutzer zu welcher ID zu diesem Zeitpunkt gehörte. Die personenbezogenen Daten der eigenen Anwender waren so im Archivsystem selbst nicht direkt erschließbar (es sei denn, man benutzte das Berechtigungssystem des Archivsystems extensiv und hatte keine Integration mit einem separaten Directory Service). So wurden zumindest personenbezogene Daten in Metadaten, Protokollen und Indexdatenbank der eigenen User vermieden. Die User waren nur außerhalb des Archivsystems ermittelbar und so hat man das Problem der personenbezogenen User in langzeitig ausgelegten Archivsystemen umgangen. Ähnlich kann man dies nur auch mit Namen, Adressen usw. von Kunden, Interessenten, Partner etc. machen.direkt personenbezogen sind und sich nicht durch die Geschäftsbeziehung mit Funktionsträgern in Firmen ergeben. Hier werden auch nur die IDs der Personen aus dem Ursprungssystem zusammen mit den Informationen, wie man im Ursprungssystem an die jeweilige Person herankommt, gespeichert. So ist auch hier die personenbezogene Information aus dem Speicherbereich des langzeitig ausgelegten Archivsystems entfernt. Zugriffe und Nachvollziehen der Benutzung personenbezogener Daten liegt so in den Anwendungen, in denen sie entstanden und empfangen wurden. Dies erleichtert auch den Nachweis einer Anfrage, wo welche Informationen zu einer Person gespeichert ist. Im Idealfall eines gut organisierten Archiv- oder Records-Management-System sind die Daten sauber getrennt sowie in den Metadaten beim Informationsobjekt und im Audittrail sind keine personenbezogene Daten enthalten, die direkt auswertbar oder innerhalb des Systems direkt auffindbar sind. DI referenzierten Systeme (oder Tabellen) mit den personenbezogenen Daten benötigen natürlich auch eine Historisierungsfunktion um die Identifizierbarkeit und Nachvollziehbarkeit über längere Zeiträume sicherzustellen. Aber solche Anforderungen und Lösungen gab es schon bei der revisionssicheren Archivierung in den 90er Jahren – ganz ohne Blockchain und auch ohne Block Chain.

        Wie eingangs der Diskussion schon einmal erwähnt – es ist immer eine Frage, wie professionell die Verwaltung von Information organisiert ist. Es ist schon gut, wenn man überhaupt weiß, welche Information man wo hat. Dass die Systeme selbst Informationslandkarten und Verfahrensdokumentationen erstellen ist einer meiner langgehegten Wunschträume. Und nun kommt da die DSGVO/GDPR mit all ihren Anpassungsgesetzen und Schlenkern. Ehrlich gesagt, personenbezogene Daten sind nahezu in jedem Schriftstück, in jeder E-Mail, in jedem Datensatz – halt überall. Die DSGVO ist daher beim besten Willen überhaupt nicht vollständig zu erfüllen. Hier muss man auch Risiko-Bewertung betreiben, was man in welchem Umfang nun umsetzt. Daten und Dokumente in einer Blockchain + Block Chain, die entsprechend Geschäftszweck, den Vorgaben von HGB, AO, GoBD, Zoll usw. aufbewahrt werden müssen, stellen da in Bezug auf die personenbezogenen Daten nach DSGVO das geringste Problem dar.

        Mit den besten Grüßen,

        Dr. Ulrich Kampffmeyer

        Antwort
      • Blockchain, DSGVO und das kontrollierte Löschen von Records
        4. März 2019 um 9:04
        Permalink

        Das Thema „Konsistentes Löschen in der Blockchain“ haben wir noch einmal zusammenfassend in einem Newsletterbeitrag aufgegriffen und um eine Zusammenfassung von Grafiken aus unserem Update Information Management 2019 ergänzt: http://bit.ly/Kff-BlockChain
         

        Blockchain + Block Chain - Deleting Records

        Den vollständigen Vortrag inkl. Video, Theum, PPTX-Folien usw. gibt es dann irgendwann im Sommer öffentlich, kostenfrei, registrierungsfrei im Open Access unter Creative Commons CC by-nd-nc bei uns auf der Webseite.

        Antwort
  • Manipulationsresistente Audittrail-Logs und Blockchain
    14. Dezember 2018 um 8:31
    Permalink

    Eine Blockchain im engeren begrifflichen Sinne einfach als hash-verkettete Liste aufzufassen, ist mir persönlich zu trivial, auch wenn dies die offizielle Wikipedia-Definition ist. Die eigentliche Blockchain-Innovation ist die verteilte Konsensfindung per „proof-of-work“. Ich halte es für wesentlich sinnvoller, Krypto-Logfiles und „echte“ Blockchain klar zu trennen, siehe z.B. auch den Vortrag von Felix von Leitner (FeFe) zu Hype-Themen für Banker: https://ptrace.fefe.de/hype/#0 (Blättern im Vortrag mit Pfeiltasten).

    Tatsächlich sichern wir in Doxis4 unsere Audittrail-Einträge seit dem damailigen Launch der neuen Produktgeneration in 2008 mit einer Hash-Verkettung. Da stehen auch die Löscheinträge eines Informationsobjekts mit drin. Die Chain kann man zudem nicht nur linear lesen, sondern sich auch z.B. direkt alle Einträge eines Informationsobjekts abrufen, um alle Einträge zu diesem zu haben (nur die Verifikation, ob die Hashwerte noch stimmen, muss über die Chain laufen; das muss man nur bei Bedarf tun und diesen gibt es normalerweise ja gar nicht).
    Damals wurde noch nicht über Blockchain geredet und trotzdem war das schon im Produkt. Das war so trivial, dass man das gleich mit gemacht hat, wenn man ein System schon neu entwirft. Wir werden uns damit aber auch weiterhin nicht im Lichte der Blockchain sonnen, dafür ist es zumindest mir wirklich zu einfach. Ein valides Verfahren zur Sicherung eines Audittrails ist es aber natürlich.

    Vielleicht sollte man den Decision Tree von https://spectrum.ieee.org/computing/networks/do-you-need-a-blockchain , der beschreibt, wann man eine (echte) Blockchain braucht, noch um einen Punkt erweitern: „wenn eine hash-verkettete Liste reicht, machen sie es einfach und planen 1 PT dafür ein“.

    Antwort
    • Block Chain + Blockchain
      18. Dezember 2018 um 7:47
      Permalink

      Lieber Kollege Joeris,

      schön, dass Sie bereits 2008 Block Chain in SER Produkten einsetzten (bei einzelnen unserer Kunden bereits 1995). Dass das Verknüpfen von einzelnen „Blöcken“ relativ einfach ist, ist unbestritten. Wenn es dann aber um den Ansatz „Löschen“ geht, schon schwieriger. 

      Gegenstand meines Beitrages oben (http://bit.ly/Block__Chain) war jedoch weitergehend: die Kombination verknüpfter Blöcke (Block Chain) mit einer „echten“ Blockchain, wobei aber bei Inhouse-Lösungen nicht das verteilte Prinzip mit zahllosen Beteiligten gegeben ist, sondern eher an eine Lösung mit einem Master-Node, der selbst oder per Fernsignatur mit einem qualifizierten Zeitstempel sowohl die Verknüpfung der einzelnen Blöcke wie auch die Verifkation und Absicherung der Transaktionen in der echten „Audit-Trail-Blockchain“ ermöglicht. 

      Erfahrungsgemäß ist eine solches sichereres Konzept, dass auch den Anforderungen des Einsatzes der qualifizierten Signatur in Deutschland gerecht wird, nicht mit einem Personentag zu erledigen. 🙂

      Mit den besten Grüßen,
      Dr. Ulrich Kampffmeyer

      Antwort
    • Zentrale oder Dezentrale Architektur
      21. Dezember 2018 um 10:23
      Permalink

      Insgesamt eine sehr spannende Diskussion hier, auf die mich mein Kollege Falk Borgmann (der hier ebenfalls bereits kommentiert hat) aufmerksam gemacht hat. Ich möchte gerne nochmal Bezug auf die hier gegebene Einschätzungen nehmen, was eine Blockchain ist, und wo man den (durch Hypes tatsächlich sehr strapazierten) Begriff „Blockchain“ richtig verwendet. Im Prinzip ist es natürlich richtig, dass die kryptografische Verkettung der Datensätze ein elementarer Bestandteil von Blockchain-Artigen Technologien ist. Es ist aber auch richtig, dass diese Art der Verkettung auch bereits in der Pre-Blockchain Phase existierte und ggf. sinnvoll eingesetzt werden konnte (wie die Verwendung von SER ja auch zeigt). Jedoch sonnt man sich damit aus meiner Sicht zu Recht nicht im „Lichte der Blockchain“, da hier ein elementarer Punkt, nämlich der Aspekt des verteilten Systems, keine Berücksichtigung findet. Und genau dieser ermöglicht eben, dass etablierte Verfahren technisch anders umgesetzt werden können.
      Ich selber arbeite seit über 15 Jahren im Bereich der DMS/ECM/EIM/CS Systeme (oder was auch immer gerade die aktuelle Definition gerade ist) und es galt technisch im Bereich der Beweiswerterhaltung und Löschbarkeit häufig das Prinzip: Es ist sicher, weil es in einem abgeschotteten, monolithischen System liegt, welches eben genau nicht offen und transparent ist, sondern den Zugriff auf die Daten (insebsondere das Löschen und Verändern) mittels singulärer Autorität unterbindet. Mit diesem Prinzip der abgeschotteten Appliance verdienen insbesondere auch Storage Anbieter mittels magnetic WORM signifikant Geld – durchaus zurecht, denn Sie lösen damit ein Problem hinsichtlich der Vertrauenswürdigkeit. Daten können selbst durch den obersten Admin im Unternehmen nicht mehr unbemerkt gelöscht oder verändert werden, da der „Schlüssel“ dafür nur dem Hersteller bekannt ist. Ein durchaus praktikabler Ansatz, bei dem man sich aber eben komplett vom Hersteller und dessen Mechanismen (und dies kann auch eine Hashkette als ergänzendes Feature sein) abhängig macht.
      Und genau hier schaffen die Mechanismen aus der Blockchain-Technologie eine Alternative, wo der monolithische „Single Point of Truth“ gegen ein mehrheitliches Konsensverfahren getauscht wird. Genau das ist der Kern der Technologie, der es ermöglicht Vertrauen zu generieren, sofern eine gewisse Heterogenität und „Seperation of Power“ gegeben ist. Und für die Konsensverfahren existieren eben nicht nur der durch Bitcoin bekannte „Proof of Work“, sondern noch etliche weitere, die insbesondere in konsortialen oder private permissioned Blockchains hervorragend geeignet sind mittels byzantinischer Fehlertoleranz ein 4-Augen Prinzip zu unterstützen und abzusichern (Für einen Vergleich der Konsensverfahren siehe z.B. https://hackernoon.com/consensuspedia-an-encyclopedia-of-29-consensus-algorithms-e9c4b4b7d08f, für eine Erklärung der BFT z.B. https://deepshore.de/de/beitraege/item/26-der-byzantinische-fehler-abwehr-einer-attacke). Und dies ist auch technisch mehr, als hashverkettete Datensätze in eine zentrale Datenbank zu schreiben.
      Die technische Implementierung ist hier dennoch nicht besonders aufwändig (dies könnte man, entsprechende Infrastruktur vorausgesetzt, auch mit 1 PT realisieren). Der sehr viel aufwändigere Teil ist, wie immer, der gesamte Prozess und das Verfahren drum herum. Denn die Technologie selbst, löst kein einziges regulatorisches Problem „einfach so“. Im besten Fall kann es einen entsprechenden Prozess unterstützen und in geeigneten Umgebungen dafür sorgen, dass Vertrauen auch technisch erhalten bleibt. Es befreit einen aber, wie in der Vergangenheit auch, nicht davon, den fachlichen Gesamtprozess zu planen, zu implementieren und zu dokumentieren. Ein Vorteil für die Kunden ergibt sich dann eher im laufenden Betrieb und der TCO, da sie eben nicht mehr von einer proprietären Technologie oder einem dedizierten CloudService abhängig sind, sondern Infrastrukturagnostisch agieren können.

      Antwort
      • Blockchain & Block Chain - verteilt vs. zentral
        21. Dezember 2018 um 10:53
        Permalink

        Hallo Herr Bruenker,

        Sie sprechen das Thema „Vertrauen“ an und stellen dar, dass es in einer verteilten Umgebung das Konsensverfahren Vorteile gegenüber den bisherigen monolithischen, sich direkt im Unternehmen abgeschottet befindlichen Archiv- und Records-Management-Verfahren habe.

        Dagegen spricht der Charakter der Informationen in Archiv- und Records-Management-Systemen, die im Regelfall vertraulich sind, z.B. kaufmännische Daten. Auch im Sinne des aktuellen Gesetzes zum Schutz von Betriebsgeheimnissen besteht die Anforderung, die Information sicher und vertraulich zu bewahren. Eine (öffentliche) verteile Blockchain öffnet aber die Information allen Beteiligten. Daher sehe ich für herkömmliche Records-Management- und Archivierungsanwendungen eher den von mir beschriebenen internen Ansatz aus Block Chain und einer Audit-Trail-Blockchain (in der die Inhalte selbst nicht enthalten sind). Die Audit-Trail-Blockchain kann man dann durchaus dezentral und verteilt aufbauen, wenn denn keine kritischen Unternehmensdaten darin enthalten sind. 
        Anders mag dies in verteilten Organisationen, Supply-Chain-Verbünden oder Filialunternehmen für bestimmte Geschäftsprozesse aussehen. Hier kann man dezentrale Lösungen a la Blockchain nutzen, jedoch ist auch hier die Lösung auf eine definierte, eingeschränkte, begrenzte und bekannte Nutzergemeinschaft beschränkt. 

        Letztlich entscheidet, welche Daten für welchen Zweck wie geschützt werden sollen. Für interne Archiv- und Records-Management-Anwendungen stellt ein Ansatz mit verketten Blöcken und einer Audit-Trail-Blockchain, die durch externe Signaturen (Fernsignatur) als vertrauenswürdigem Drittem (Vertrauensdiensteanbieter nach eIDAS) eine Alternative für herkömmliche Referenzdatzenbank-Architekturen mit Index-Datenbank und separat gehaltenen Objekten dar.

        Übrigens – in China werden Blockchain Records schon als Legal Evidence, also als Beweis, gesetzlich anerkannt.

        Mit den besten Grüßen und Wünschen für die Festtage,
        Dr. Ulrich Kampffmeyer
         

        Antwort
    • Erfolgreiche Blockchain-Projekte?
      18. Dezember 2018 um 7:57
      Permalink

      Lieber Kollege Hartbauer,

      wie ich bereits erwähnte, gibt es nicht die „eine“, allein-seligmachende Blockchain. Unterschiedliche Architekturansätze, von der verketteten öffentlichen Blockchain á la Bitcoin über zentral gesteuerte Blockchains mit Master-Node bis hin zu Inhouse-Lösungen mit verketten Blöcken und/oder abgesicherten verketteten Audittrails.

      Im Bereich von Archivierung und Records Management machen nur die letzteren, die Kombination von Block-Chain mit „echter“ Blockchain einschließlich der Möglichkeit kontrolliert zu ändern, löschen und zu ergänzen, Sinn. Solche Lösungen kann man sogar mit einer traditionellen Index-Datenbank für die Metadaten des Records Management sinnvoll kombinieren. Die Prinzipien von Ordnung und Ordnungsmäßigkeit können so zusätzlich zur Konsistenz, Nachvollziehbarkeit und Unveränderbarkeit gewahrt werden. Diese Lösungen sind noch nicht weit verbreitet und andererseits auch wenig bekannt, da es sich um Inhouse-Lösungen eines Unternehmens oder eines Verbundes von Unternehmen oder Filialen handelt. Es kommt also auch darauf an, wonach man sucht, wenn man eine solche Bewertung wie „Keine erfolgreichen Projekte“ abgibt. Selbst Anbieter aus Deutschland wie Nextevolution/Deepshore sehen das vielleicht anders.

      Wir stehen bei der Entwicklung der unterschiedlichen Ansätze erst am Anfang (zusammenfassende akademische Literatur gibt es ja auch erst seit 2008 mit dem Aufkommen von Bitcoin). Blockchain wird sich weiterentwickeln. Und Block()Chain ist eine Alternative zu bisherigen Konzepten der revisionssicheren Archivierung.

      Mit den besten Grüßen,
      Dr. Ulrich Kampffmeyer

      Antwort
    • ...das ist eine gewagte Aussage
      18. Dezember 2018 um 12:58
      Permalink

      Sehr geehrter Hr. Hartbauer,
      über die o.g. genannte Studie sind wir auch schon gestolpert. In Teilen kann man einige Aspekte auch nachvollziehen, jedoch teilen wir als Deepshore nicht die Conclusio.
      Nachvollziehen können wir den beschriebenen Eindruck, dass hinter sehr vielen „Blockchain-Basierten“ Lösungen tatsächlich kein tragfähiges technisches Fundament steht. Wir haben als Deepshore dieses Jahr an sehr vielen Konferenzen und Veranstaltungen im Bereich „Distrubuted Ledger“ teilgenommen und es ist wahrlich erschreckend, mit wie wenig konkret umgesetzten Use-Cases einige große, wie auch kleine Firmen sehr marktschreierisch behaupten, sie hätten ein erfolgreiches Blockchain-Projekt umgesetzt. Allzu häufig findet man hier wirklich bestenfalls Prototypen hinter den vollmundigen Versprechungen – häufig nicht mal das (Einige Unternehmen verkaufen grobe Ideen in Form eines „Whitepapers“ als Produkt – Hauptsache man sagt „Blockchain“). An dieser Stelle können wir die Ergebnisse der Studie durchaus nachvollziehen. Dennoch finde ich die Aussage „0 Succesfull Blockchain Projects“ mehr als nur gewagt. Wir wurden zum Beispiel nicht angefragt und hätten nur zu gerne unseren Stack und den Mehrwert von Blockchain-Technologie zur Beweiswerterhaltung von digitalen Informationen dargestellt. Hierbei ist Blockchain tatsächlich nur ein Teil der Lösung, aber er trägt eben auch einen relevanten (und monetär bewertbaren) Teil zur Lösung bei. Die METRO verarbeitet mittlerweile mit unserem Blockchain-Stack tatsächlich produktive Daten.
      Die Deepshore arbeitet aber nicht am einzigen Use-Case, der bereits produktiv Nutzen generiert. Wir kennen einige andere Startups die Blockchain-Basierte Systeme praxisrelevant erfolgreich einsetzen.
      Trotzdem, der Hype um Blockchain hat die Erwartungen sehr hoch geschraubt, und viele Projekte die mit dem Versprechen „Disruptive Use-Cases“ zu formen an den Start gegangen sind, haben einfach ihre Versprechen nicht gehalten. Es gibt dennoch auch erfolgreiche und sinnvolle Implementierungen, die einen echten Mehrwert generieren.

      MfG
      Falk Borgmann

      Antwort
    • McKinsey und die Blockchain
      14. Januar 2019 um 18:59
      Permalink

      Nun erklärt auch McKinsey, dass die Blockchain nicht so toll sei wie ursprünglich gedacht: „Blockchain’s Occam problem“ (https://mck.co/2SWcFEs). Matt Higginson, Marie-Claude Nadeau und Kausik Rajgopal schreiben darin „Blockchain has yet to become the game-changer some expected. A key to finding the value is to apply the technology only when it is the simplest solution available.„. McKinsey bezieht sich aber in ihrer Studie auf die Finanzwirtschaft, und nicht auf das von PROJECT CONSULT hier beschriebene Anwendungsgebiet von „Audit-Trail-Blockchain“ und „Block Chain + Blockchain“. Vom Niedergang diverser Crypto-Währungen und mangelnden Anwendungen für die „public-distributed-ledger-proof-of-work-blockchain“ sind der Nutzen von verketteten Objekten (selbstbeschreibende Informationsobjekte, sprich Dokumente mit XML-Header und XML-Trailer) mit Blockchain-Audit-Trail-Protokollen wenig bestritten. Übrigens war McKinsey eines derjenigen Analysten-Häuser, die die Blockchain als den „Game Changer“ im Finanzdienstleistungsmarkt hochgejubelt haben,

      Antwort
  • BSI veröffentlicht Studie zu Blockchain
    24. Mai 2019 um 11:00
    Permalink

    Auf ihrer Webseite http://bit.ly/BSI-Blockchain hat das BSI Bundesamt für Sicherheit in der Informationstechnik im Kapitel „Kryptografie“ einen neuen Leitfaden veröffentlicht: „Eine umfassende und tiefgehende Analyse der Blockchain-Technologie hat das BSI im Mai 2019 veröffentlicht. Schwerpunkt der Betrachtung sind die IT-Sicherheitseigenschaften, aber auch die Auswirkungen der technischen Grundkonzeption etwa auf die Effizienz und Erfüllbarkeit datenschutzrechtlicher Vorgaben, die Erfüllbarkeit der Sicherheitserwartungen und der aktuelle Rechtsrahmen.“ (http://bit.ly/BSI-BLOCKCHAIN). Auf der Webseite gibt es noch weitere Dokumente zum Thema.

    In jedem Fall sollte mehr Augenmerk darauf gelegt werden, dass es nicht die „eine“ Blockchain gibt und dass auch „distributed Ledger“ unterschiedliche Ausprägungen hat. Auf jeden Fall sollte unterschieden werden, ob es sich um eine öffentliche Blockchain, eine Blockchain in einer geschlossenen Gemeinschaft oder um eine private Blockchain innerhalb einer Organisation handelt. Dies hat besondere Auswirkungen, wer am „distributed Ledger“ teilnimmt, „jeder“, eingeschränkte, genau definierte Teilnehmer oder nur virtuelle in einer hausinternen, aus Sicherheitsgründen verteilten Installation. Ein weiterer wesentlicher Unterschied ist, ob die Informationsobjekte selbst Bestandteil der BLockchain sind, wie z.B. bei einer Kryptowährung, oder aber ob es sich um eine Audittrail-Blockchain handelt, die auf externe Informationsobjekte verweist. Bei letzterer kann eine zusätzliche Verkettung der Objekte selbst erfolgen. Diese Art von Block-Chain-Architektur erlaubt auch das DSGVO-konforme kontrollierte und nachvollziehbare Löschen, ohne dass die Konsistenz der Blockchain gebrochen wird (http://bit.ly/Kff-BlockChain). Einen zusätzlichen Integritätsnachweis mittels einer elektronischen Signatur braucht es bei einer sicheren Blockchain eigentlich, aber es empfiehlt sich einen Zeitstempel bei der Prüfsummen/Hash-Code-Bildung zu nutzen. Ähnliche bewährte Konzepte existieren auch bei der Bildung von Unique Identifiern für Informationsobjekte in herkömmlichen Archivsystem-Architekturen mit Referenz-Datenbank-Modell. Solche herkömmlichen Archivsysteme mit Index-Datenbank und referenzierten, separat gehaltenen Informationsobjekten, sind immer noch der Kern des Geschäftes mit der elektronischen Archivierung. In dieser Architektur ist konsistentes Löschen immer möglich gewesen. Wenn man mit der Blockchain in die Archivierung oder das Records Management einsteigen will, braucht man halt andere Architekturen wie sie hier beschrieben wurden oder wie vorgestellt mit Root Key/Merkle-TreeCortex oder BoneBits. Letztlich kommt es immer auf die Art der vorgesehenen Anwendung und Nutzung an.

    Antwort
  • EU ERPS Studie zu Blockchain und Datenschutz
    13. August 2019 um 11:12
    Permalink

    Der EPRS European Parliamentary Research Service (Scientific Foresight Unit (STOA)) hat im Juli 2019 eine Studie zum Thema „Blockchain and the General Data Protection Regulation – Can distributed ledgers be squared with European data protection law?“ herausgegeben: http://bit.ly/ERPS_Blockchain_GDPR. Die Zusammenfassung.

    <Zitat> „Blockchain is a much-discussed instrument that, according to some, promises to inaugurate a new era of data storage and code-execution, which could, in turn, stimulate new business models and markets. The precise impact of the technology is, of course, hard to anticipate with certainty, in particular as many remain sceptical of blockchain’s potential impact. In recent times, there has been much discussion in policy circles, academia and the private sector regarding the tension between blockchain and the European Union’s General Data Protection Regulation (GDPR). Indeed, many of the points of tension between blockchain and the GDPR are due to two overarching factors.
    First, the GDPR is based on an underlying assumption that in relation to each personal data point there is at least one natural or legal person – the data controller – whom data subjects can address to enforce their rights under EU data protection law. These data controllers must comply with the GDPR’s obligations. Blockchains, however, are distributed databases that often seek to achieve decentralisation by replacing a unitary actor with many different players. The lack of consensus as to how (joint-) controllership ought to be defined hampers the allocation of responsibility and accountability.
    Second, the GDPR is based on the assumption that data can be modified or erased where necessary to comply with legal requirements, such as Articles 16 and 17 GDPR. Blockchains, however, render the unilateral modification of data purposefully onerous in order to ensure data integrity and to increase trust in the network. Furthermore, blockchains underline the challenges of adhering to the requirements of data minimisation and purpose limitation in the current form of the data economy.
    This study examines the European data protection framework and applies it to blockchain technologies so as to document these tensions. It also highlights the fact that blockchain may help further some of the GDPR’s objectives. Concrete policy options are developed on the basis of this analysis.“ </Zitat>

    In Teil 1 der Studie des STOA | Panel for the Future of Science and Technology | geht auf die technologischen Ansätze von Blockchain ein.
    Im zweiten Teil werden zunächst die die Grundlagen des Datenschutzes nach GDPR/DSGVO/BDSG der Technologie gegenübergestellt. „Applying European data protection law to blockchain“ und die Erläuterung von personenbezogenen Daten „The definition of personal data“ betrachten die rechtlichen Details. Kapitel 4 „Responsibility for GDPR compliance: the data controller“ beschreibt die Verantwortlichkeit für die Sicherstellung der Compliance. In Kapitel 5 „Data processors and third parties“ wird die Betrachtung auf das Hosting und Cloud-Lösungen ausgeweitet. Kapitel 6 „Key principles of personal data processing“ beschreibt zusammenfassend die grundlegenden Voraussetzungen und ist auch für „Nicht-Blockchain“-Lösungen relevant. Kapitel 7 „Data subject rights“ geht auf den kritischen Bereich des Löschens personenbezogener Daten ein, die GDPR Paragraphen 15 bis 22. Kapiel 8 „Data protection by design and by default“ betont noch einmal, dass für alle IT-Lösungen der Datenschutz bereits im Design und als Standard-Funktionalität vorhanden sein muss. Kapitel 9 „9. Data protection impact assessments“ bschreibt die Überprüfung der Auswirkungen. Kapitel 10 „Personal data transfers to third countries“ geht auf die Übermittlung personenbezogener Daten ins außer-EU-Ausland ein (sollte man nicht tun). Interessant wird es auch noch einmal in Kapitel 11 „Blockchains as a means to achieve GDPR objectives“, wo auf den Nutzen von Blockchain für Data Governance eingegangen wird. Hier wird auch Blockchain als Werkzeug um GDPR Ziele zu erreichen positioniert.
    Im Abschnitt 3 geht es dann um die Auswirkungen auf zukünftige Direktiven und Vorgaben der EU. Kapitel 12 „Policy options“ betrachtet, wie Blockchain in zukünftigen Richtlinien zur „Regulatory guidance“ und „Support codes of conduct and certification mechanisms“. Kapitel 13 bringt eine Zusammenfassung, die hier noch einmal wiedergegeben werden soll:

    <Zitat> Conclusion
    Regulation to blockchain technologies. It has been observed that many points of tension between blockchains and the GDPR can be identified. Broadly, it can be maintained that these are due to two overarching factors. First, the GDPR is based on the underlying assumption that in relation to each personal data point there is at least one natural or legal person – the data controller – that data subjects can address to enforce their rights under EU data protection law. Blockchains, however, often seek to achieve decentralisation in replacing a unitary actor with many different players. This makes the allocation of responsibility and accountability burdensome, particularly in light of the uncertain contours of the notion of (joint)-controllership under the Regulation. A further complicating factor in this respect is that in light of recent developments in the case law, defining which entities qualify as (joint-) controllers can be fraught with uncertainty. Second, the GDPR is based on the assumption that data can be modified or erased where necessary to comply with legal requirements such as Articles 16 and 17 GDPR. Blockchains, however, render such modifications of data purposefully onerous in order to ensure data integrity and increase trust in the network. Determining whether distributed ledger technology may nonetheless be able to comply with Article 17 GDPR is burdened by the uncertain definition of ‚erasure‘ in Article 17 GDPR.
    The study has concluded that it can be easier for private and permissioned blockchains to comply with these legal requirements as opposed to private and permissionless blockchains. It has, however, also been stressed that the compatibility of these instruments with the Regulation can only ever be assessed on a case-by-case basis. Indeed, blockchains are in reality a class of technologies with disparate technical features and governance arrangements. This implies that it is not possible to assess the compatibility between ‚the blockchain‘ and EU data protection law. Rather, this study has attempted to map various areas of the GDPR to the features generally shared by this class of technologies, and to draw attention to how nuances in blockchains‘ configuration may affect their ability to comply with related legal requirements. Indeed, the key takeaway from this study should be that it is impossible to state that blockchains are, as a whole, either completely compliant or incompliant with the GDPR. Rather, while numerous important points of tension have been highlighted and ultimately each concrete use case needs to be examined on the basis of a detailed case-by-case analysis.
    The second key element highlighted in this study is that whereas there certainly is a certain tension between many key features of blockchain technologies setup and some elements of European data protection law, many of the related uncertainties should not only be traced back to the specific features of DLT. Rather, examining this technology through the lens of the GDPR also highlights significant conceptual uncertainties in relation to the Regulation that are of a relevance that significantly exceeds the specific blockchain context. Indeed, the analysis has highlighted that the lack of legal certainty pertaining to numerous concepts of the GDPR makes it hard to determine how the latter should apply to this technology, but also others. This is, for instance, the case regarding the concept of anonymous data, the definition of the data controller, and the meaning of ‚erasure‘ under Article 17 GDPR. A further clarification of these concepts would be important to create more legal certainty for those wishing to use DLT, but also beyond and thus also to strengthen the European data economy through increased legal certainty.
    The study has, however, also highlighted that blockchains can offer benefits from a data protection perspective. Importantly, this is by no means automatically the case. Rather, blockchains need to be purposefully designed in order for this to realize. Where this is the case, they may offer new forms of data management that provides benefits to the data-driven economy and enable data subjects to have more control over personal data that relates to them.
    </Zitat>

    Ergebnis: Lange Rede, kurzer Sinn – eigentlich aktuell nein, Einzelfallbetrachtung, aber das kann sich ja zukünftig ändern, da die Entwicklung weiterläuft.

     

     

    Antwort
  • There is no good Reason to trust Blockchain
    26. September 2019 um 16:46
    Permalink

    … lautet der Titel des Artikels von Bruce Schneier auf WIRED http://bit.ly/BlockChainTrust . In dem Meinungsbeitrag „Cryptocurrencies are useless. Blockchain solutions are frequently much worse than the systems they replace. Here’s why.“ wird argumentiert, dass es eigentlich keine richtig nützlichen Anwendungsfälle für Blockchain gibt. Er bezieht sich auf die Public Blockchain mit Mining-Mechanismen. Private Blockchains hält er anders – als hier im Thread argumentiert – für total überflüssig. Letztlich geht es um Vertrauen. Dieses wird bei Public Blockchain nach Irgendwo draußen verlagert und technisiert (So ähnlich ist es auch mit dem Vertrauen in die Trust-Center für eIDs und Signaturen). Die Definition von Trust, Vertrauen, der Technologieenthusiasten ist nach seiner Meinung zu eng. Sie basiere auf „in code we trust,” “in math we trust,” und “in crypto we trust.” Schneier verweist hier auf Erkenntnisse, die erbereits 2012 in seinem Buch „Liars and Outliars“ publiziert hat. Technische Systeme werden nie ganz sicher gegen Veränderung, Verfälschung, Verlust und Manipulation sein. Er verweist zu den unterschiedlichen Aspekten von Vertrauen auf Kevin Werbach Blockchain and the New Architecture of Trust, der verschiedene Arten wie Peer-to-Peer, Institutional Trust, Intermediary Trust und Distributed Trust – letzteres also die Public Blockchain. Hierbei wird das Vertrauen, dass bei Peer-to-Peer und Institutional Trust noch vorhanden ist nach Draußen ins Unbekannte verschoben. Die offenen Flanken zeigen Diskussionen um die Änderung von Block-Sizes, Hacks, Verlust der Anonymität und DAO Angriffe. Die Blockchain hat zudem versteckte Kosten, von der Umweltbelastung und Energieverschwendung bei Crypto-Währungen wie Bitcoin einmal ganz zu schweigen. Das Vertrauen in Blockchain-Lösungen ist sehr volatil. Sie werden nach Schneier auch außerhalb der Finanzbranche eher die Ausnahme bleiben. 

    Diskussion "Blockchain - No"  https://twitter.com/vgcerf/status/1019987651301081089

     

    So weit so gut. Nun kommt aber die Bundesregierung und das BSI Bundesamt für Sicherheit in der Informationstechnik mit einer eigenen Blockchain-Strategie „um die Ecke“: http://bit.ly/Bundesregierung-Blockchain-Strategie . Diese zielt auf innerbehördlich (also eine Variante wie Private, Inhouse, Konsortium oder ähnlich) und Bürger, Unternehmen und sonstige Dritte der Öffentlichkeit (also das klassische Public Distributed Ledger Blockchain oder doch nur eine Blockchain mit institutioneller Absicherung?).

    Auch in der Information-Management-Branche wird immer wieder kolportiert, „Blockchain suche noch nach sinnvollen Anwendungen„. Trotz aller Diskussionen um das Thema Vertrauen: Blockchain … kann .. auch eine Lösung für Archivierung von Daten und Audittrails sein. Aber halt nur als Inhouse Private Blockchain ohne die Notwendigkeit auf „externes Vertrauen“ zurückgreifen zu müssen.

    Blockchain  __kann__ eine Alternative zu herkömmlicher elektronischer Archivierung sein

    Antwort
  • Archivierung mit Blockchain
    14. Dezember 2021 um 15:04
    Permalink

    DeepShore (https://www.DeepShore.de) aus Hamburg bewirbt eine neue Blockchain-Lösung (https://deepshore.de/knowledge/2021-11-25), die in der Cloud einfach installier- und nutzbar ist. Sie kann auch als Speichersystem unter traditionelle ECM- und Archivsystemlösungen „geschraubt“ werden. Es wird auch damit geworben, dass die Deepshore Cloud Native Archive Lösung DSGVO-compliant sei. Wie geht das aber wenn gezielt und dokumentiert gelöscht werden muss? Das von PROJECT CONSULT vorgeschlagene Verfahren (https://www.project-consult.com/medien/geht-kontrolliertes-loeschen-in-blockchain-mit-block-chain-auszug-aus-update-information-management-2019/) kommt wohl nicht zum Einsatz.  DeepShore schreibt, dass durch den kombinierten Einsatz einer Blockchain-Beglaubigung und einer Streamverschlüsselung das geforderte Schutzniveau für Originaldaten und die Einhaltung von Löschpflichten autonom abbildbar sei. Durch „kryptografische Verfahren, unfälschbare Zeitstempel und lückenlose Transaktionsverfolgung“ sei die Sicherheit „garantiert„. Deepshore bezieht sich hierbei auf die „Testierung der Lösung nach Prüfstandard IDW PS 880 des Instituts der Wirtschaftsprüfer„. Deepshore arbeitet auch intensiv bei GAIA-X und im DIN (https://deepshore.de/knowledge/2021-09-15) mit, jedoch soll das neue Deepshore Cloud Native Archive ein anderen Ansatz als z.B. Gaia-X verfolgen. Es wäre schon interessant, wenn sich auf der DeepShore-Webseite außer vielen Bildern, Podcasts und Presseberichten auch mal eine technische Beschreibung finden ließe, wie denn sowohl GoBD als auch DSGVO gemeinsam durch eine Blockchain erfüllbar sein sollen.

    Antwort
    • Quadratur des Kreises?
      14. Dezember 2021 um 18:30
      Permalink

      Vorab ein Full Disclosure: Ich arbeite bei Deepshore und bin dort u.a. technisch mitverantwortlich für die Implementierung des Cloud Native Archive.

      Zunächst einmal freut es mich sehr, dass Sie sich mit den aktuellen Entwicklungen im Bereich der revisionskonformen Archivierung unter Berücksichtigung von GDPR/DSGVO Gesichtspunkten beschäftigen und sich hierbei auch mit unserem Engagement in diesem Umfeld auseinandersetzen.
      Anfänglich war ich ein wenig irritiert, dass Sie den Eindruck gewonnen haben, dass die Umsetzung unseres Stacks nicht hinreichend transparent gemacht wurde. Insbesondere, da unsere Mitarbeit an der zwischenzeitlich verabschiedeten DIN/TS 31648 (die u.a. in Kapitel 7 explizit das Thema DSGVO adressiert) ja bekannt ist. Ferner ist die grundsätzliche Funktionsweise unserer Implementierung natürlich auch in unserer Patentschrift DE102018129366 veröffentlicht und nachvollziehbar.
      Ich nehme Ihren Hinweis aber gerne zum Anlass die entsprechenden Informationen für das technisch Interessierte Publikum noch leichter zugänglich zu machen.

      Auf Ihre konkreten Fragen möchte ich aber natürlich gerne direkt einmal eingehen. Die Fragestellung, wie eine beweiswerterhaltende Speicherung von Informationen mit einer verbindlichen Aufbewahrungszeit vereinbar mit den Anforderungen der DSGVO ist, mutet ja – unabhängig von Distributed Ledger Technologie – erstmal wie die Quadratur des Kreises an. Da existieren zwei – im Detail konträre – Anforderungen, die technisch nicht mit einer Funktion abgebildet werden können.
      So wenig, wie sich die DSGVO z.B. allein mit der Speicherung auf UDO vereinbaren ließe, würde sie sich mit der Speicherung des Payloads in der Blockchain vereinbaren. Mal unabhängig davon, dass dies aus Architektursicht für gängige DLT auf Basis der Datenbeschaffenheit ein ohnehin Antipattern wäre, könnten Daten nach einmaliger Speicherung nie wieder gelöscht werden, ohne die Integrität der Blockchain zu tangieren. Die einzige Möglichkeit die hier bliebe wäre die (schlechte) Variante einer Partitionierung, aber auch hier blieben offensichtlich essentielle Fragen offen.
      Unsere auditierte und praxiserprobte Umsetzung im Cloud Native Archive verwendet daher die Blockchain primär als Data Verification Layer und Audit-Log der (auch in Anlehnung an die DIN/TS 31648) die Relation zum eigentlichen Payload und dessen Integrität sichert. Die eigentlichen Wirkdaten (die auch DSGVO-Relevant sind) werden Off-Chain in einem verteilten Dateisystem, welches mit dem Blockchain-Layer technisch verknüpft und vollständig integriert ist, gespeichert. Hierbei folgt die Verteilung der Daten auf dieser Ebene den Prinzipien des DLT um auch hier von der byzantinischen Fehlertoleranz zu profitieren. On-Chain selbst werden jedoch nur Hashes und abstrakte Events (Create, Delete, Extend etc.) gespeichert. Es werden bewusst keine inhaltlichen oder personenbezogenen Metadaten On-Chain gespeichert. Gleichzeitig werden sämtliche relevanten Lebenszyklusinformationen On-Chain zum Objekt gehalten. Hierdurch besteht auch die Möglichkeit eines privileged Delete, welcher, mit entsprechender Authentifizierung und Validierung, eine vorzeitige Löschung von Daten (vor Ablauf der Aufbewahrungszeit) ermöglicht. Entsprechende Löschevents werden hierbei natürlich auch geankert, um einen umfassenden Audit-Trail zu erstellen.

      Ein wichtiger Punkt bei der Erreichung der byzantinischen Fehlertoleranz in diesem verteilten System ist die „Separation of Power“, also übersetzt die Einhaltung des Vier-Augen Prinzips (also eigentlich ein „alter Hut“). Sämtliche relevante Funktionalitäten (sowohl im Blockchain, wie im Encryption- und Storage-Layer) sind in unserer Implementierung darauf ausgelegt, dass diese nicht von einer einzelnen Person / Entität durchgeführt werden können sondern unter Einsatz z.B. von „Shared shamir keys“ über mehrere Einheiten verteilt werden.Ich hoffe diese ersten Informationen konnten bereits ein wenig Licht ins Dunkel bringen.

      Bei Bedarf stehe ich Ihnen gerne noch für tiefere technische Einblicke in unsere Umsetzung zur Verfügung.

      Antwort
      • Also doch so wie von uns postuliert?
        14. Dezember 2021 um 18:41
        Permalink

        Hallo Herr Bruenker, also doch so wie von uns vor einiger Zeit postuliert, z.B. in diesem Vortrag 2018 ? 😉 https://www.slideshare.net/DRUKFF/de-zum-nachdenken-auf-dem-nachhauseweg-the-future-of-finance-applications-information-mangement-dr-ulrich-kampffemeyer-euro-factura-bielefeld-2018 oder hier https://www.slideshare.net/DRUKFF/de-geht-kontrolliertes-lschen-in-blockchain-mit-block-chain-dr-ulrich-kampffmeyer-update-im-2019-hamburg  … Schöne Grüße, Ulrich Kampffmeyer

        Antwort
        • Ganz Genau ;-)
          14. Dezember 2021 um 19:47
          Permalink

          Hallo Herr Kampffmeyer,

          Ihre Veröffentlichungen von damals treffen das Prinzip ziemlich genau. Im Detail sind einige Orchestrierungen verschiedener Technologien (die Blockchain ist hier ja nur eine und löst alleine kein Problem) notwendig, aber das Prinzip (welches wir ja übrigens auch bereits in unserem Patentantrag von 2018 manifestiert haben) entspricht dabei dem von Ihnen dargestellten Vorgehen.

          Eine Anmerkung sei mir an dieser Stelle noch erlaubt: 2018/19 war Blockchain alleine ein Themenkomplex, der auf Basis des Hypes rund um das Thema Interesse im Markt erzeugt hat. Diese Zeiten sind, aus meiner Sicht glücklicherweise, vorbei. Es ist eine technisch fundiertere Situation eingetreten. Viele der PoC-Marketingblasen rund um Blockchain haben sich in Wohlgefallen aufgelöst. Einige gute UseCases überdauern und binden die Technologie auf eine sinnvolle Weise ein. Dabei darf man sich aber immer selber überprüfen: Wenn Blockchain die Antwort ist, was ist die dazu passende Frage?

          Die von Ihnen erhobenen „10 PROJECT CONSULT Trends“ zeigen ja deutlich, dass das Thema Blockchain alleine kein tragfähiges Thema ist. In diesem Kontext ist der von uns propagierte Stack auch primär darauf ausgerichtet ein konkretes Problem zu lösen: Echte Datenautonomie in der Cloud, ohne Vendor Lock-In bei einem Hyperscaler – und das nicht auf Kosten der (Revisions)Sicherheit. Wir merken hierbei an der Resonanz im Markt deutlich, dass dieses Thema bei potentiellen Kunden auf Interesse stößt. Viele von Ihnen haben mittlerweile Ihre ersten Erfahrungen mit der Abhängigkeit von spezifischen Implementierungen (wie Azure Blob, Glacier oder S3 mit „Retention“)  und den Folgen daraus gemacht und suchen einen validen Ausweg.

          Die Blockchain ist dabei ein essentieller Teil des Stacks, aber eben bei Leibe nicht „die Lösung“. Auch das wird ja auf Ihren Folien aus dem Jahr 2018/2019 deutlich. Was ich somit gerade eigentlich nur sehr wortreich ausgeführt habe ist: Es ist so, wie von Ihnen postuliert 😉

          Beste Grüße,

          Michael Bruenker

          Antwort
          • Blockchain & Block Chain
            14. Dezember 2021 um 19:55
            Permalink

            Hallo Herr Bruenker,
            vielen Dank für die Antwort und die Anerkennung. Vielleicht für Sie noch zur Information: 1995 hatten wir bereits im Rahmen eines Archivierungs-Standardisierungs-Projektes für die Sparkassen-Finanzgruppe die Verkettung von Informationsobjekten mittels UID aus dem Header und Prüfsumme aus dem Footer im jeweils folgenden Informationsobjekt designt. Dazu kamen Transaktions- und Archiveingangsprotokolle, die ebenfalls archiviert werden und als Nachweis dienen – allerdings Logs und Journale herkömmlicher Art. Ähnliches hatten wir auch im OAIS nach CCSDS (heute ISO 17421) mit den AIPs angedacht. Erschien damals aber zu komplex.
            Mit den Themen der „sicheren“, oder nach Kampffmeyer 1992 „revisionssicheren“ Archivierung beschäftige ich mich nunmehr seit fast 40 Jahren – aber die elektronische Archivierung wird ein nie endendes Dauerthema bleiben.
            Schöne Grüße – auch an Ihr Team -, fröhliche Weihnachten und einen guten Rutsch ins Neue Jahr.
            Ulrich Kampffmeyer

Schreibe einen Kommentar zu Dr. Ulrich Kampffmeyer Antworten abbrechen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich stimme zu, dass die von mir eingegebenen Daten einschließlich der personenbezogenen Daten an PROJECT CONSULT übermittelt und dort zur Prüfung der Freischaltung meines Kommentars verwendet werden. Bei Veröffentlichung meines Kommentars wird mein Name, jedoch nicht meine E-Mail und meine Webseite, angezeigt. Die Anzeige des Namens ist notwendig, um eine individuelle persönliche Kommunikation zu meinem Beitrag zu ermöglichen. Anonyme oder mit falschen Angaben eingereichte Kommentare werden nicht veröffentlicht. Zu Nutzung, Speicherung und Löschung meiner Daten habe die Datenschutzerklärung zur Kenntnis genommen.

Ich versichere, mit meinem Kommentar alle gültigen Vorgaben des Urheberrechts beachtet zu haben. Ich habe keine Bilder, Grafiken, Texte oder Links in meinem Beitrag verwendet, die durch CopyRight, Leistungsschutzrecht oder Urheberrecht geschützt sind. Für den Inhalt meines Kommentars bin ich trotz Prüfung und Freischaltung durch PROJECT CONSULT ausschließlich selbst verantwortlich. Meine Rechte am Beitrag werden bei PROJECT CONSULT nur durch die CC Creative Commons by-nc-nd Vorgaben gewahrt.