Beiträge

Blockchain im Zusammenspiel Mit KI und Edge Computing

FUTURE TECHNOLOGIES IN ACTION @ 7P

Wie können wir den Zug der Zukunft noch praktischer und das Reisen noch angenehmer gestalten? Wie können wir die Sicherheit beim Reisen gewährleisten und dabei gleichzeitig die Richtlinien der DSGVO einhalten? Wird der Zug der Zukunft intelligent sein und Daten in Echtzeit verarbeiten können? Blockchain im Zusammenspiel mit KI und Edge Computing könnte eine Antwort auf diese Fragen sein. Als beratende Experten für innovative IT-Lösungen für die Digitalisierung beschäftigen wir uns bei SEVEN PRINCIPLES mit genau diesen und ähnlich komplexen Fragestellungen und Themen. Unser Use Case führt einen Schritt näher zum Bahnbetrieb der Zukunft. Doch wie sollen all diese neuen Technologien im Zusammenspiel einwandfrei funktionieren? Und welche Rolle spielt dabei die Blockchain?

DIE KOMPONENTEN

Blockchain sichert Nachvollziehbarkeit

In der Blockchain können wichtige Daten kryptografisch geschützt, fälschungssicher protokolliert und redundant gespeichert werden. Sicherheitsrelevante Informationen werden auditierbar vorgehalten und vor Manipulation geschützt. Prozessdaten sind über die verteilte Blockchain schnell an allen relevanten Stellen verfügbar, auch über Unternehmensgrenzen hinweg.

Künstliche Intelligenz (KI) erhöht Sicherheit

Daten sind über Sensoren und Datenspeicher der verschiedensten Prozesse meistens in ausreichendem Maß, häufig sogar im Übermaß vorhanden. KI hilft nicht nur bei der Auswertung und Nutzengewinnung. Sie verschafft häufig erst die Sicherheit in der Bewertung und das Vertrauen in die abgeleiteten Ergebnisse und Regeln, die für eine erfolgreiche Anwendung benötigt werden. Und mit den richtigen Daten lässt sich die Technik so verfeinern, dass eine KI in der Lage ist, gefährliche Situationen eigenständig zu identifizieren und zu melden.

Edge Computing vereinfacht Datenschutz

Edge Computing bringt die erforderliche Rechenleistung zu den Daten, datenschutzrelevante Vorgänge wie Übertragung oder Speicherung können so minimiert oder ganz vermieden werden. Weitergegeben werden nur noch aufbereitete Ergebnisse oder (Warn-) Signale – auf die Informationsverarbeitung bezogen ist das Datenschutz by Design.

Architektur des SEVEN PRINCIPLES Showcase Network, Blockchain im Zusammenspiel mit KI und Edge Computing
Architektur des SEVEN PRINCIPLES Showcase Network, Blockchain im Zusammenspiel mit KI und Edge Computing

ANGENEHMES UND SICHERES REISEN

Sitzplätze per App identifizieren

Bereits heute erfassen Kameras das Geschehen in Zügen und spielen somit eine entscheidende Rolle, wenn es um sicherheitsrelevante Themen geht. Der SEVEN PRINCIPLES Use Case zeigt, dass die Kombination aus Edge Computing, Kameras und KI (Computer Vision, Tensorflow) eine Objekterkennung von Personen oder Gegenständen ermöglicht. In Kombination mit Umgebungssensoren lässt sich die Technik so verfeinern, dass die KI in der Lage ist, gefährliche Situationen eigenständig zu identifizieren und zu melden. Solche Situationen können einem Zugbegleiter angezeigt und bei wirklicher Gefahr zusammen mit den Metadaten auf einer Blockchain fälschungssicher persistiert werden. Natürlich sollte der Zug der Zukunft – die Sicherheit vorausgesetzt – auch praktisch und angenehm für die Reisenden sein.

Wäre es nicht schön, wenn die aktuelle Anzahl der freien (und belegten) Sitztplätze ermittelt und grafisch angezeigt würde? Die Verarbeitung dieser Daten wäre in Echtzeit möglich, und für die Validierung der Ergebnisse könnten Funk und WLAN herangezogen werden. Für ein optimiertes Ergebnis würden zusätzlich Sitzplatzreservierungen und Belegungsprognosen einbezogen werden. Reisende könnten sich freie Plätze anzeigen lassen und diese reservieren, sowohl am Bahnsteig, als auch im Zug selbst, und das ganz einfach über eine Anzeige bzw. über eine App.

Reisen ohne Stress dank Blockchain

Wir geben Ihnen ein Beispiel: Stellen Sie sich vor, Sie stehen am Bahnsteig. Es ist Feierabendverkehr und Sie wissen, dass der Zug sehr ausgelastet sein wird. Plötzlich weist Ihr Handy Sie darauf hin, dass der ICE Sprinter von Frankfurt nach Köln einfährt und die Wagons 3 bis 5 bereits belegt sind, sich jedoch ausreichend Plätze in den Wagons 6 bis 9 befinden. Es wäre nun ein Leichtes für Sie, sich am Bahnsteig richtig zu positionieren und sofort ohne große Umwege einen freien Sitzplatz zu finden. Sollte der Zug vollkommen überfüllt sein, bestände darüberhinaus die Möglichkeit, Ihnen alternative Züge oder sogar Verkehrsmittel
vorzuschlagen. – Reisen ohne Stress.

Angenehme Temperaturen

Zum angenehmen Reisen gehört nicht nur ein gemütlicher Sitzplatz, auch die Temperatur, der Luftdruck und die Luftfeuchtigkeit sollten stimmen, um besonders lange Fahrten – auch in Rekordsommern – angenehm und komfortabel zu gestalten. Umgebungssensoren in den Wagons könnten den Zugbegleiter informieren, sobald ein festgelegter Wert über- oder unterschritten wird, damit er entsprechende Maßnahmen einleiten kann.

Der Usecase verdeutlicht, dass die Verbindung der Komponenten Blockchain, KI und Edge Compting die Bahn-IT revolutionieren und das System Bahn im Hinblick auf die Digitalisierung deutlich voran bringen könnte.

DIE TECHNIK HINTER DER IT LÖSUNG

Klingen die beschriebenen Szenarien genau so verlockend für Sie wie für uns? Die SEVEN PRINCIPLES Blockchain-, KI- und Edge Computing-Experten haben die nötige Grundlage für diese kosteneffiziente und effektive IoT-Lösung entwickelt. Für den Datenaustausch zwischen den Zügen, den Eisenbahnverkehrsunternehmen und dem Benutzer wird im Showcase eine Blockchain-/Distributed Ledger-Lösung auf Basis des Hashgraph-/ Babble-Konsensalgorithmus angebunden. Somit wäre neben der Übertragung in Echtzeit, der erhöhten Sicherheit und der Einhaltung der DSGVO eine höhere Toleranz gegen Netzwerk- bzw. Kommunikationsabbrüche bei gleichzeitiger Auditierbarkeit möglich. Aufgrund dieser Eigenschaften bietet sich diese Lösung auch als Basis für andere Zug-ITSysteme an, z.B. zur Ticket-Kontrolle. Besonders sicherheitskritische Informationen wie Bauteil- Wartungszyklen könnten transparent kommuniziert und dauerhaft fälschungssicher abgespeichert werden. Und das dank Blockchain.

FAZIT

Die Verbindung von Blockchain, KI und Edge Computing würde den Bahnbetrieb, wie wir ihn heute kennen, revolutionieren. Das Reisen würde sicherer und komfortabler, Züge würden intelligenter werden und Informationsverarbeitung fände in Echtzeit statt. Der Datenschutz der Passagiere wäre zu jedem Zeitpunkt des Prozesses sichergestellt. Wie stellen Sie sich den Zug der Zukunft vor? Würden Sie sich so einen Zug wünschen? Wir freuen uns über Ihre Meinung in unserem Kommentarfeld.

Oder nehmen Sie direkt Kontakt zu unserem Blockchain-, KI- und Edge-Computing-Expertenteam auf:
https://www.7p-group.com/kontakt-3/

Data Lake und Datenschutz: Alles schwimmt in eigenen Bahnen

Sandboxing und logische Trennung von Bereichen

Ein Begriff, der in Diskussionen zur Architektur von Hadoop-basierten Data Lakes immer wieder fällt, ist „Sandboxing“. Damit ist gemeint, dass es für bestimmte Zwecke nützlich, für manche sogar notwendig ist, vom „eigentlichen“ Data Lake getrennte Bereiche zu haben. Diese können auch außerhalb der Data Lake Infrastruktur liegen. Ein Beispiel hierfür sind analytische Sandboxes, die maßgeschneiderte Umgebungen und Daten nur für Data Scientists bereitstellen. In solchen Umgebungen können verschiedene Methoden und Verfahren entwickelt und erprobt werden, ohne die große „Allgemeinheit“ der Data Lake User zu stören. Da solche Sandboxes typischerweise kleine Varianten derselben Hadoop Distribution sind, ist es in der Regel sehr einfach, später die Ergebnisse in den großen Data Lake zu übertragen. „Klein“ bedeutet hierbei, dass die Anzahl der Worker Nodes und damit auch des Speicherplatzes gegenüber dem eigentlichen Data Lake kleiner ausfallen. Es kann sogar Sinn machen, einen Single Node Cluster aufzusetzen, beispielsweise um bestimmte Funktionalitäten initial auszuprobieren.

Was natürlich auch in Hinblick auf Kosten und gemeinsame Verwendung von Ressourcen oftmals angestrebt wird, ist die Realisierung von „Sandboxes“ in der eigentlichen Data Lake Infrastruktur als alternative Variante. Neben der Notwendigkeit, für alle Benutzerkreise ein passendes Ressourcenmanagement zu entwickeln – hier ist YARN eine wichtige Komponente zur Steuerung – muss man auch Daten und Zugriffsbereiche separieren. Oder anders gesagt: Hier ist nicht nur aus Gründen des Datenschutzes ein passendes Sicherheits- und Zugriffskonzept zu entwickeln – in der Regel gibt es User, die nur auf bestimmte Daten in bestimmten „Sandboxes“ zugreifen dürfen! Jeder Benutzerkreis schwimmt also in seinen eigenen Bahnen.

 

 

 

 

Das läuft darauf hinaus, dass man abgegrenzte Bereiche einrichtet, auf die der eigentliche Data Lake keinen Zugriff hat, sondern nur ein bestimmter Kreis von Usern und / oder Mandanten. Ein typisches Beispiel sind spezielle Klardatenbereiche, die nur dann zulässig sind, wenn man nachweisen kann, dass nur berechtigte Personen mit diesen Daten etwas „machen dürfen“. Das Managen und Nutzen dieser Daten obliegt dann auch ausschließlich diesem Personenkreis. Genauso aber können das auch anonymisierte oder pseudonymisierte Bereiche sein, für die ähnliches gilt. Was also generell gefordert wird ist eine Mandantenfähigkeit des Data Lakes, also die Möglichkeit klar abgegrenzte Bereiche einzurichten

  • mit feingranularer Zugriffsteuerung
  • mit der Möglichkeit einer passenden Ressourcensteuerung

Es ist natürlich innerhalb eines großen Data Lakes viel schwieriger das alles einzurichten, zu steuern und zu administrieren. Deshalb muss immer auch eine Abwägung vorgenommen werden, ob es vielleicht einfacher ist, mit separaten Umgebungen zu arbeiten. Hier sind die Bereiche auch „physisch“ getrennt. Eine Forderung, die von Seiten des Datenschutzes oftmals erhoben wird. Aber nehmen wir mal an, wir könnten mit „logisch“ getrennten Bereichen im Data Lake arbeiten. Wie kann man das erreichen?

Mandantenfähigkeit

Typische Hadoop Distributionen wie z.B. Hortonworks enthalten Mittel für solche Zwecke. Das sind Services und Tools, die die Trennung von Mandanten unterstützen. Wichtig ist dabei, dass eine zentrale Security und Governance Infrastruktur eine Klammer um das Ganze bilden kann.

Im Fall von Hortonworks ist hierbei Apache Ranger eine wesentliche Komponente. Über Ranger lassen sich User, Gruppen / Rollen und deren Berechtigungen feingranular in den folgenden wichtigen Hadoop Komponenten verwalten:

  • Apache Hadoop HDFS
  • Apache Hive
  • Apache HBase
  • Apache Solr
  • Apache Storm
  • Apache Knox
  • Apache Kafka
  • Apache Nifi
  • Apache YARN

Mandanten sind hierbei Gruppen / Rollen und deren Berechtigungen. Grundsätzlich sind das zunächst die Berechtigungen zu schreiben, zu lesen, Daten zu löschen, Objekte anzulegen und zu löschen. Aber es geht auch noch spezieller: In Hive lässt sich beispielsweise der Zugriff auf Tabellen und Views, bestimmte Spalten und sogar eine „row-level“ Security in den Daten selbst realisieren. Das heißt es lässt sich eine Filterung der Daten abhängig vom Security Kontext über eine implizite „where-clause“ des SQL (HiveQL) Statements erreichen. Genauso lassen sich im Hadoop Filesystem HDFS Bereiche (Folder) nur für Mandanten einrichten, dasselbe gilt für Kafka Topics, also die Kafka Messages Bereiche, die nur für bestimmte Mandanten gedacht sind. Ranger wiederum nutzt die nativen Security Mechanismen der einzelnen Komponenten via Plug-Ins.

Und „Sandboxes“?

Sandboxes sind dann einfach die jeweils für bestimmte Nutzergruppen und / oder Mandanten zugänglichen Bereiche wie Hive und HBase Tabellen, bestimmte Directories im HDFS, bestimmte Kafka Topics und auch Solr Collections, beziehungsweise in Hive auch Views und noch tiefergehende Berechtigungen wie „Row-level Security“, die an einer „Mandanten-ID“ in der jeweiligen Tabelle festgemacht werden kann. Wichtig ist eigentlich nur, dass man allen anderen Usern / Gruppen / Rollen, die auch Zugriff auf den Data Lake haben, den Zugriff auf die solchermaßen geschützten Ressourcen entzieht. Für Klardaten bietet sich zusätzlich auch die Verwendung von „Encryption Zones“ im HDFS an, d.h. nur ein Mandant mit dem entsprechenden Schlüssel kann die Daten in Klarform abgreifen, alle anderen bleiben hier außen vor, selbst wenn sie unberechtigterweise sich Zugriff auf die Daten verschaffen können. Das generelle Verschlüsseln von Daten jenseits der speziellen Anforderungen der Anonymisierung und Pseudonymisierung ist besonders für den Cloud Betrieb relevant. Dazu demnächst mehr.

Data Lake und Datenschutz: Eine schwierige Beziehung

Focus von Hadoop-basierten Systemen

Nachdem der Focus von Hadoop-basierten Big Data Systemen in der Vergangenheit im Wesentlichen auf dem Managen und Bereitstellen von Daten für Analysen und operative Zwecke gelegen hat, ohne große Anforderungen in Sachen Datensicherheit und Governance realisieren zu müssen, ändert sich dieses Bild stark in letzter Zeit. Mit dem Bekanntwerden der europäischen Datenschutz Grundverordnung https://dsgvo-gesetz.de/, welche zusammen mit einer Erneuerung des Bundesdatenschutzgesetzes ab Ende Mai 2018 zwingend angewendet werden muss und einen grundlegenden Paradigmenwechsel darstellt, wurde vielen Organisationen und Unternehmen deutlich, dass bisher eingeschlagene Wege und ein gewisser „sorgloser“ Umgang mit Daten in der Datenverarbeitung in Zukunft nicht mehr gangbar sind. Die europäische Datenschutzgrundverordnung soll jedem ein Recht einräumen, über seine Daten grundsätzlich selbst zu bestimmen. In diesem Zusammenhang sind auch traditionell so verstandene vom Kunden selbst eingeräumte Rechte an seinen Daten mit Hilfe von pauschalen Formulierungen nicht mehr tragbar. Die Rechte müssen stattdessen zukünftig sehr feingranular behandelt werden. Was heißt das? Technisch bedeutet das, dass auf Kundenanforderung  die von ihm gesammelten Daten zugänglich gemacht und von diesem beanstandete Daten schnell aus den Systemen gelöscht werden müssen, siehe dazu auch https://www.datenschutzbeauftragter-info.de/eu-datenschutzgrundverordnung-das-sind-die-neuerungen/. Besonders heikel sind die bei Verstößen gegen die Verordnung möglicherweise zu zahlenden Bußgelder. Diese können bis zu 4 Prozent der Jahresumsätze eines Unternehmens betragen! Klar, dass hier Handlungsbedarf besteht.

Personenbezogene Daten sind schwierige Daten…

Zu personenbezogenen Daten und dem gewünschten (geforderten!) Umgang mit diesen kann man dazu in Datenschutz-Handbüchern in etwa folgendes lesen:

Personenbezogene Daten sollen jederzeit gelöscht werden können, soweit nicht gesetzliche oder vertragliche Aufbewahrungspflichten entgegenstehen. Dasselbe gilt, wenn Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des Betroffenen beeinträchtigt würden. In diesen Fällen wird typischerweise gefordert, dass an die Stelle einer Löschung eine Sperrung tritt.

Diese Daten sind also in den folgenden Fällen zu löschen:

  • Ihre Speicherung ist per se unzulässig
  • Es handelt sich um „schwierige“ Daten über die rassische oder ethnische Herkunft, politische, religiöse oder philosophische Meinungen und Überzeugungen, sexuelle Vorlieben, Vorstrafen und ähnliche Dinge, wobei ihre Richtigkeit von der verantwortlichen Stelle nicht bewiesen werden kann. Aber: Der Beweis ist zu erbringen, sobald der Betroffene die Richtigkeit bestreitet.
  • Wenn sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des Zweckes der Speicherung nicht mehr erforderlich ist. Das trifft in der Regel für dispositive Systeme wie Data Lakes, Data Warehouses und Artverwandte zu.

Recht auf Vergessenwerden

Das sogenannte „Recht auf Vergessenwerden“ soll sicherstellen, dass digitale Informationen mit einem Personenbezug nicht dauerhaft zur Verfügung stehen. In der am 24. Mai 2016 in Kraft getretenen und ab dem 25. Mai 2018 in allen EU-Mitgliedstaaten unmittelbar geltenden Datenschutz-Grundverordnung wird das Recht auf Löschung in Art. 17 geregelt. Näheres dazu kann man in der deutschen Version des Artikels 17 der DSGVO nachlesen. Kurz zusammengefasst hat eine betroffene Person hat das Recht, zu verlangen, dass sie betreffende personenbezogene Daten unverzüglich gelöscht werde, wenn

  • die personenbezogenen Daten für die Zwecke, für die sie erhoben oder auf sonstige Weise verarbeitet wurden, nicht mehr notwendig sind
  • die betroffene Person ihre Einwilligung, auf die sich die Verarbeitung stützte, widerruft, und es sonst an einer anderweitigen Rechtsgrundlage für die Verarbeitung fehlt. Solche können zum Beispiel gesetzliche Aufbewahrungspflichten sein oder aber das Einfrieren der Daten zur Beweissicherung („Legal Hold“).

Was ist also zu tun? Prinzipiell muss ich beim Aufbau von Data Lakes (und natürlich auch von anderen Systemen) die Forderungen „Data protection by design“ und „Data protection by default“ beachten, sonst laufe ich in eine gefährliche Sackgasse. Sackgasse kann im Extremfall bedeuten, dass ich die ganze „illegale“ Datenhaltung forensisch löschen muss – ein Albtraum für alle Beteiligten. Damit das nicht passiert, ist von Anfang an sauber zu trennen zwischen Daten, die personenbeziehbar sind und klar vorliegen müssen und solche, die lediglich anonymisiert, eventuell auch pseudonymisiert gespeichert werden können. Diese „Datentöpfe“ müssen in der Regel mindestens logisch voneinander separiert gespeichert und geschützt werden – Stichwort logische „Sandboxes“. Hierzu ist ein Mandantenkonzept zu entwickeln und im Data Lake auch konsequent umzusetzen.

Klardaten…

Zu den klar vorliegenden Daten, aber auch bei anderweitig problematischen Daten, ist immer eine Prüfung  der vom Kunden gegebenen Einverständnisse zu diesen Daten vorzunehmen. Diese müssen auch ohne größeren Zeitverzug bei Entzug dieser gelöscht werden können. Das impliziert natürlich, dass man in geeigneter Weise jeden (!) Datensatz mit den dazu gegebenen Permissions verknüpfen können muss. Üblicherweise wird von Datenschutzseite auch eine maximale Aufbewahrungsdauer gefordert, falls der Data Lake in einem solchen Fall nur als bereitstellendes System dient. Ein Ausweg aus diesem Dilemma bietet der Ansatz, nicht  einen zentralen Data Lake zu bauen, sondern im Rahmen eines „Sandboxing“ auch physikalisch getrennte Umgebungen für verschiedene klar definierte Anwendungszwecke aufzubauen.

Das Bereitstellen der aktuellen Kunden-Permissions erfordert in der Regel ein separates System. Dies muss in der Regel in Lage sein, in nahezu Echtzeit die Permissions aktualisieren zu können. Üblicherweise stellt ein solches System über einen Service die Informationen zu den Berechtigungen bereit. Vorteil der Entkoppelung ist, dass man im Data Lake nicht mit Aufgabe konfrontiert ist, das operative Handling rund um die Kunden-Permissions zu implementieren – es recht in der Regel der Aufruf eines solchen Services bei Bedarf.

Implikationen für den Betrieb des Data Lakes

Was ist ein solcher Bedarf? Nun, im Grunde genommen alles, wo Daten, die im Data Lake gespeichert sind, verwendet werden beziehungsweise auch für den Fall, das regelmäßig Löschroutinen über den Bestand des Data Lakes laufen (müssen). Für Anwendungen, die operativen Charakter haben, sind Klardaten meist  notwendig. Die Verarbeitung ist in Regel durch den Zweckbezug gedeckt, wenn der zeitliche Rahmen auch dazu passt. Ein Beispiel: Um Verspätungen im öffentlichen Verkehr berechnen zu können und personalisierte Verspätungsmeldungen und Empfehlungen geben zu können, braucht man neben den Streckendaten, Fahrtdaten und weiteren nützlichen Informationen auch personenbezogene Daten. Diese werden für die Berechnung von Prognosen bereitgestellt und können auch verarbeitet werden, wenn dieses zeitnah erfolgt, also zeitnah zur tatsächlichen Reise oder Fahrt. Genauso können daraus abgeleitete Empfehlungen an den Kunden weitergegeben werden. Voraussetzung ist natürlich, dass der Kunde sein Einverständnis zum Empfang solcher Information gegeben hat. Die Daten selbst, sofern sie noch personenbeziehbar sind, müssen allerdings dann auch zeitnah wieder gelöscht werden.

Umgekehrt dürfen diese Informationen nicht ohne weiteres für andere analytische Zwecke verwendet werden, zumindest nicht, wenn hierbei noch ein Personenbezug herstellbar ist. Hier kommen jetzt verschiedene Möglichkeiten in Betracht, die die Situation trotzdem „retten“ können. Wichtige Stichwörter sind Pseudonymisierung und Anonymisierung und der Aufbau mindestens logisch streng getrennte Bereiche. Was dahinter steckt und wie man sich ein weiteres Vorgehen vorstellen kann? Dazu demnächst mehr.