Back to top

Sicherheit im Datensee

Vier zentrale Bereiche, die für die Sicherheit im Datensee berücksichtigt werden müssen

data lake securityIn letzter Zeit mussten wir uns mit einigen neuen als auch interessanten Situationen und Anforderungen hinsichtlich der Sicherheit im Datensee befassen. Auf den ersten Blick scheint dies ein recht einfacher Gesamtbegriff zu sein. Wenn man aber einen genaueren Blick auf die beiden Teilbegriffe wirft, erkennt man schnell, wie komplex diese drei Worte im Detail sein können.

Zunächst könnte der Begriff „Datensee“ („Data Lake“ oder „Datenhub“) für manche neu sein. Selbst wenn das Konzept bekannt ist, kann die eigene Definition von jener abweichen, die von anderen Leuten genutzt wird. Und als Zweites haben wir den Begriff „Sicherheit“. Vermutlich hat jeder eine eigene Vorstellung davon, was Sicherheit ist und was die Wasser unseres Datensees trüben könnte ...

Da die Sicherheit im Datensee jedoch ein solch komplexes Konzept ist, möchte ich in diesem Beitrag:

  • Etwas Hintergrund zu den unterschiedlichen Konzepten bieten
  • Auf dieser Grundlage die Schichten des Sees durchforschen; insbesondere die Hauptbereiche, die abgesichert werden müssen
  • Und schließlich etwas tiefer in den See eintauchen und einen Blick auf die Document-Level-Security werfen - ein Konzept, mit dem wir viel Erfahrung haben. Dabei können wir uns auch ansehen, wie das bekannte Konzept der Document-Level-Security um eine weitere Definitionsvariante erweitert werden kann, damit es dem See gerecht wird


Was ist Sicherheit im Datensee?

Wie versprochen, werden wir grob die Teilkonzepte definieren, so dass wir uns dem Datensee sicher und auf ähnlichem Wissensstand nähern können. Zu diesem Zweck definieren wir den Datensee wie folgt: 

„Der Datensee ist ein Speicher, in dem alle Daten des Unternehmens im Rohzustand lagern. Kombiniert mit Big Data und Suchmaschinen kann er beachtliche Vorteile bieten. Der Datensee bringt Daten aus verschiedenen Quellen zusammen und macht diese für die Suche verfügbar, um damit die Fähigkeiten zur Auffindung, Analyse und Auswertung für den Endbenutzer zu maximieren.“

Vielleicht können wir noch einen Schritt weitergehen und das Wort „Unternehmen“ voranstellen? In diesem Fall wäre der Unternehmens-Datensee privat, da nur Mitglieder des Unternehmens Zugriff darauf hätten.

Mehr über Datenseen und ihre Architektur finden Sie auch in unserem umfassenden Blogbeitrag Eine Architektur für den Datensee, über Hadoop und Open-Source-Suchmaschinen

Gehen wir jetzt also zum Sicherheitsaspekt des Datensees über. Dieser ist gleichzeitig leichter und schwerer zu definieren als der Datensee selbst. Es ist einfacher, weil wir alle wissen, was Sicherheit bedeutet. Gleichzeitig ist es aber auch schwerer, weil dieses Verständnis stark von dem Kontext abhängt, in dem sie genutzt wird.

Betrachten wir als Beispiel ein Projekt zur Sicherheit in einem Datensee, das wir kürzlich abgeschlossen haben. Hierbei war der erste Schritt, zu verstehen, welche Daten dem Endbenutzer über die Benutzeroberfläche der Suchanwendung zur Verfügung stehen sollen. Nachdem wir diese Anforderungen an die Sicherheit in der Suche besprochen hatten, mussten wir als nächstes bestimmen, wie der Inhalt im Datensee selbst abgesichert wird, damit selbst Benutzer mit direktem Zugriff auf den Datensee Daten nicht löschen oder ändern können. Kontaminierung oder Überfischung müssen schließlich verhindert werden.

Hierfür mussten verschiedene Aspekte durchgesprochen werden, z.B. die Administration der Plattform, die Rechner, auf denen die verschiedenen Komponenten des Systems ausgeführt werden, wie und wo die Daten gespeichert werden, wer was und wo ausführen darf. Darauf werden wir gleich noch eingehen.

Zusammengefasst: Die Sicherheit im Datensee stellt sicher, dass diejenigen, die Zugriff auf den Datensee, auf bestimmte Systemkomponenten oder bestimmte Bereiche der Daten haben sollen, nur entsprechend den für das Datensee-System definierten Sicherheitsregeln Zugriff erhalten.

Navigieren im Datensee: Vier abzusichernde Bereiche

Ein natürlicher oder vom Menschen angelegter See hat mehrere Bereiche. Manche sind flach, andere sehr tief. Die Pflanzen und Tiere im See sind auch sehr divers, immer abhängig von der Größe, der Tiefe und dem Ort des Sees. Tore, Zäune und vielleicht auch natürliche Barrieren schränken den Zugang zum See ein. Weiterhin kann es auch Boote, Besucher und Sicherheitspersonal auf dem See geben. Ebenso hat auch der Datensee unterschiedliche Bestandteile, die mit Hinsicht auf die Sicherheit des Datensees in vier Hauptbereiche gruppiert werden können.

datensee-sicherheit.jpg


1.   Plattformzugriff und Privilegien

Die Plattform enthält alle Komponenten, um Daten zu speichern, Aufgaben auszuführen sowie das System und Datenspeicher zu verwalten. Die Anforderungen an die Sicherheit sind für jede ihrer Ausprägungen oder jede einzelne Komponente unterschiedlich. Nehmen wir an, der Datensee nutzt Hadoop als Plattform. Die folgenden Punkte sind Beispiele für die Ausprägungen von Sicherheit, die Plattformkomponenten aufweisen müssen:

  • Zugriff auf Server und Benutzerrollen – Welche Konten haben Zugriff auf einen bestimmten Server und welche Rollen sind diesen zugeordnet?
  • HDFS und Dateisysteme, die auf verschiedenen Servern eingesetzt werden – Dateien in HDFS oder jene, die von solchen Programmen genutzt werden, die als Teil des Datensee-Systems laufen, sollten eingeschränkten Zugriff haben. Access Control Lists (ACLs) im Posix-Stil werden verwendet, um Berechtigungen für Dateien und Ordner zu verwalten, z.B. <rwxrwxrwx owner group>.
  • HBase, Impala oder ähnliches – Metadaten oder gar Dateien können in einem NoSQL-Speicher abgelegt werden – als Alternative oder als Ergänzung zu dem in HDFS gespeicherten Inhalten. Namensraum und Zugriff auf Konten (wie bei traditionellen RDBMS) werden verwendet, um diese Datenspeicher zu schützen.
  • Jobausführung – Berechtigungen, um MapReduce, YARN oder ähnliche Anwendungen auszuführen.
  • Administrationswerkzeuge – Zugriffsberechtigungen auf Werkzeuge zur Verwaltung von Plattformkomponenten.


2.   Netzwerkisolierung

Ungewollter Zugriff auf die Umgebung muss verhindert werden, indem die Komponenten des Datensees angemessen geschützt werden. Für die IT-Infrastruktur vor Ort (oder beim Hoster) sollte ein solcher Schutz bereits bestehen. Außerdem wird inzwischen auch die Cloud-Technologie als sicher genug angesehen, um Unternehmensanwendungen außerhalb der traditionellen Grenzen des lokalen (oder gehosteten) Netzwerks zu betreiben. Virtuelle private Netzwerke in der Cloud ermöglichen gemeinsam mit Firewalls und anderen Mechanismen, die Netzwerkisolierung in einer cloudbasierten Lösung zu realisieren.


3.   Datenschutz

Da Datenseen Inhalte speichern, die aus verschiedenen Quellen stammen, muss man darüber nachdenken, wie man die Daten genauso schützen kann, wie es schon in den ursprünglichen Datenquellen geschehen ist. Datenverschlüsselung ist eine übliche Möglichkeit, um Inhalte zu schützen. Zur Gewährleistung eines starken Datenschutzes sollte die Verschlüsselung sowohl auf Speicherebene (Daten im Ruhezustand), als auch während des Transports im Netzwerk (Daten im Transfer) geschehen.


4.   Document-Level-Security (oder sichere Suche)

Zu den oben angesprochenen Bereichen gibt es zahlreiche Abhandlungen und Erklärungen von Experten. Da wir auf Suchmaschinen spezialisiert sind, wollen wir hier auf diesen vierten Punkt genauer eingehen. Viele Details zu diesem Thema finden Sie schon in unserer Blogreihe Document-Level-Security für die Unternehmenssuche, wie auch weitere wichtige Informationen in dem Beitrag Branchenweite Standards für Document-Level-Security bei Unternehmenssuche. An dieser Stelle wollen wir daher nicht noch einmal wiederholen, was in diesen Beiträgen bereits beschrieben wurde, sondern stattdessen lieber einige neuere Erfahrungen beschreiben, die wir mit der Document-Level-Security, speziell in der Implementierung von Datenseen, gemacht haben.

Datenseen sollen die von Silos geschaffenen Barrieren aufbrechen, indem sie ihren Benutzern erlauben, auf zentralisierte Inhalte zuzugreifen. Dennoch ist für einige Anwendungen, oder besser gesagt einige Daten, eine Zugriffsbeschränkung auf Dokumentebene notwendig: Die Benutzer dürfen nur Dokumente sehen, für die sie auch die Leseberechtigung haben. Doch wo wird diese Zugriffskontrolle definiert? Es gibt möglicherweise unterschiedliche Geschäftsregeln je nach Inhalt des Datensees. Daher wollen wir kurz auf verschiedene mögliche Szenarien eingehen. 

Szenario 1: Replikation der Zugriffsberechtigungen von der Datenquelle

Hierzu müssen für den Datenzugriff dieselben Berechtigungen durchgesetzt werden, die auch in der ursprünglichen Datenquelle vorhanden waren. Auf den ersten Blick scheint es, als ob wir einfach nur ein Silo replizieren, indem wir die Sicherheitseinstellungen der Datenquelle im Datensee beibehalten. Man muss aber bedenken, dass ein Datensee deshalb wichtig ist, weil er Mehrwert bietet und nicht einfach nur Inhalte aus verschiedenen Quellen aufbewahrt. So bietet er:

  • die Möglichkeit, Dokumente an einem zentralen Ort effizient abzurufen oder zu finden, unterstützt durch Suchergebnisse oder Auswertung von Inhalten aus verschiedenen Quellen
  • die Anreicherung von Inhalten während des Hinzufügens zum Datensee, z.B. durch Normalisierung, Bereinigung oder Extrahierung von Entitäten, was in der Datenquelle nicht möglich wäre
  • die Erstellung von schreibgeschützten Kopien einer Datenquelle, die nicht mehr aktiv zugänglich ist. Z.B. alte Systeme, die außer Betrieb genommen wurden, nachdem die Daten in den Datensee repliziert wurden (möglicherweise sogar als Ersatz der ursprünglichen Datenquelle)

Szenario 2: Replikation der Zugriffsberechtigungen von der Datenquelle, jedoch nur für einen Teil der Daten

Eine Variante dieses Szenarios wäre, die Zugriffsberechtigungen nur für einen Teil der Daten durchzusetzen, z.B. nur für die kritischsten und vertraulichsten Teile. Der Rest der Daten dieser Quelle würde dann mit abgeschwächten Berechtigungen behandelt werden. Vielleicht würde man auch jedem Benutzer mit Zugriff auf das ursprüngliche System erlauben, den gesamten nicht-sensiblen Inhalt dieser Quelle im Datensee einsehen zu dürfen, unabhängig von seinen oder ihren Berechtigungen im Quellsystem.

Szenario 3: Zugriff für alle Benutzer aus Teilen des Unternehmens erlauben

Man könnte z.B. bestimmte Teile des Datensees allen Benutzern einer bestimmten Geschäftseinheit oder Abteilung zur Verfügung stellen. Dies ist nützlich, wenn z.B. das Quellsystem beschränkte Kapazitäten hat, die potenzielle Benutzer davon abhalten könnten, auf den Inhalt der Quelle zuzugreifen – vielleicht aufgrund einer eingeschränkten Anzahl von verfügbaren Lizenzen oder durch Beschränkungen bei Plattform- bzw. Software-Kapazität aufgrund einer veralteten Software. Der Datensee könnte diese Beschränkungen des Silos überwinden und damit allen Benutzern desselben Unternehmensbereichs (z.B. Produktion, Forschung & Entwicklung, Finanzen, andere Unternehmensteile oder Kombinationen dieser) Zugriff auf den Content ermöglichen.

Szenario 4: Zugriff für alle Benutzer des Datensees genehmigen

Sind keine speziellen Berechtigungen definiert, ist die Minimalanforderung an die Document-Level-Security, den Inhalt nur für Benutzer verfügbar zu machen, die für die Arbeit mit Datenseeanwendungen autorisiert sind.

Document-Level-Security für Datenseen: Zusätzliche Betrachtungen

Ein Datensee sollte auf Jahre hinaus als lebendige, sich anpassende Plattform angelegt sein. Daher können sich die oben beschriebenen Szenarien der Zugriffskontrolle und die aktuell herrschenden Umstände weiterentwickeln oder neue Gegebenheiten hinzukommen. Also sollte man am besten auf diese Änderungen vorbereitet sein, indem man mindestens die beiden folgenden Erkenntnisse bedenkt, die wir in vergangenen Implementierungen gewonnen haben: 

1.   Berechtigungen für Content für alle Dokumente immer im Datensee speichern

Selbst wenn aktuelle Anforderungen keine Replikation der Zugriffsberechtigungen für die Datenquellen enthalten, sollten diese Berechtigungen zusammen mit den Dokumenten abgerufen und im Datensee gespeichert werden. Man sollte bedenken, dass der Datensee ein Speicher für unternehmensweite Rohdaten ist. Berechtigungen auf Dokumentenebene sind Teil dieser Rohdaten.

Damit wird es möglich, die Document-Level-Security mit Hilfe dieser Zugriffsberechtigungen schneller zu implementieren, falls Anwendungen dies zu einem späteren Zeitpunkt erfordern. Weil die Berechtigungen zusammen mit anderen Metadaten und Volltext gespeichert werden, müssen diese später nicht erneut an der Datenquelle angefragt werden. Dies ist besonders wichtig für Datenquellen, die zu langsam oder zu groß sind, bald nicht mehr verfügbar sein könnten oder bei denen die Gefahr besteht, dass irgendwann kein Zugriff mehr auf die Daten möglich ist (wie etwa gehostete Systeme bei Drittanbietern oder Lizenzsysteme, die den Zugriff sperren, sobald die Lizenz ausgelaufen ist).

2.   Berechtigungen im Datensee gespeicherter Inhalte aktualisieren

Aufgrund der Art und Weise, wie die Berechtigungen in der Datenquelle gehandhabt werden, kann es zu Effizienzeinbußen bei der Aktualisierung von Berechtigungsinformationen im Datensee kommen. Es reicht, die folgenden, minimalen Änderungen an der Datenquelle zu betrachten, die zahlreiche Dokumente im Speicher betreffen könnten:

  • Ändern der Berechtigungen eines Ordners (oder anderer Container), die von den Dateien (oder Datensätzen) und Unterordnern innerhalb dieses übergeordneten Containers geerbt werden
  • Hinzufügen oder Entfernen von Benutzern aus einer Sicherheitsgruppe oder -rolle
  • Ändern der Berechtigungen, die Benutzer, Gruppen oder Rollen zugewiesen sind
  • Andere dokumentunabhängige Änderungen an den Zugriffsberechtigungen

Für alle oben genannten Fälle gilt, dass aufgrund nur einer einzigen Änderung die Zugriffsberechtigungen für mehrere Dokumente aktualisiert werden müssen. Der Mechanismus für diese Aktualisierungen muss in der Lage sein, die gespeicherten Berechtigungen aller betroffenen Dokumente im Datensee zu aktualisieren. Dies gilt auch für solche Anwendungen, die Document-Level-Security benötigen, wie z.B. die Suchmaschine.

Es ist sehr wahrscheinlich, dass einige Einschränkungen in der Implementierung des Datensees erfordern, alle dort gespeicherten Dokumente in regelmäßigen Abständen zu aktualisieren, um sicherzustellen, dass alle über die korrekten Access Control Lists verfügen, d.h. denen in der Datenquelle entsprechen. Ist dies der Fall, sollte man sicherstellen, dass Prozesse und Werkzeuge erstellt sind, um dies zu erledigen, solange die Datenquellen noch verfügbar sind!

Zurück zu den Ufern des Sees

Wir Menschen ordnen die Welt, in der wir leben, gerne in Konzepte ein. Gemäß einer Abhandlung der Association for Academic Psychiatry (AAP) ist „Konzeptionalisierung der Vorgang, bestehende Ideen zu durchdenken und über sie hinaus zu blicken, um Ideen höherer Ordnung aus dem eigenen Geist zu entwickeln.“ Stellen Sie sich vor, ein komplexes System wie einen Datensee mit umfassender Sicherheit zu implementieren und sich dabei um alle Details kümmern zu müssen. Selbst die einfachste Aufgabe würde damit extrem schwer. Wir verwenden daher Konzepte: unser Geist ermöglicht es, damit alle Informationen zu verwalten, ohne dass uns der Kopf explodiert.

Wenn man also die Sicherheit im Datensee angeht, sollte man sich immer auf die eigene Fähigkeit verlassen, berechnend zu denken und einzuordnen. Ein Ansatz, der für unsere Kunden gut funktioniert hat, war es, die Herausforderungen an die Sicherheit im Datensee gemäß den oben beschriebenen Kategorien in kleinere, leichter handhabbare Teilbereiche zu unterteilen. Man kann sich damit auf den Partner für die Implementierung des Datensees oder die internen Experten für die einzelnen Bereiche verlassen, um sicherzustellen, dass der Datensee sowohl sicher als auch gut verwaltet ist. Nur so bleiben die Anwendungen für Suche und Analyse leistungsfähig und skalierbar.

- Carlos

0

Wir freuen uns, bekannt zu geben, dass wir jetzt Teil von Accenture sind! Lesen Sie die Ankündigung hier.