Posts

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Die Motivation für eine unternehmenskonforme Sicherheitsarchitektur für Hadoop

Hadoop und die damit einhergehenden Technologien und Applikationen (Hadoop Ecosystem) stellen keine neue Idee mehr dar. Zugegebenermaßen hat man jedoch das Gefühl, dass Hadoop noch lange nicht reif genug für dessen Integration an die IT Infrastruktur und an die Prozesse eines Unternehmens ist. Bei fast jeder Hadoop Distribution mangelt es an bestimmten nicht-funktionalen Aspekten. Die Hadoop Community hat sich sehr lange um die Erfüllung der funktionalen Anforderungen gekümmert und dabei Aspekte wie Sicherheit, Monitoring, Data Governance und Auditing vernachlässigt.

Eine berechtigte Frage wäre nun: Warum ist das so?

Zum besseren Verständnis der Leser werde ich zunächst auf diese Frage und die Geschichte von Hadoop eingehen, bevor ich mich mit dem Aufbau einer sicheren Hadoop Infrastruktur beschäftige.
Hadoop hat eine, für IT Verhältnisse, relativ lange Geschichte hinter sich. Das erste Release fand im Februar 2006 statt, wobei Yahoo bereits von Beginn an Interesse an der Mitwirkung und Benutzung bekundete. Am Anfang waren alle Applikationen, die für Hadoop geschrieben wurden, Backend Data-Crunching Jobs. Diese führten eine Art von Datenanalyse, basierend auf großen Datenmengen,  durch, die sonst, ohne die Verwendung der von Hadoops verteilter Architektur und Prozessframework, viel länger gedauert hätte. Dabei haben die Entwickler mithilfe der MapReduce Ausführungsengine Aggregierungen und  anderen SQL-ähnliche Abfragen von Datenbeständen geschrieben. Sämtliche Applikationen waren von ihrer Natur her Batchjobs, die regelmäßig auf dem Cluster angestoßen wurden, um Resultate zu berechnen und diese weiter an standardisierte Visualisierungstools zu leiten. Normale User brauchten daher keinen direkten Zugriff auf den Cluster selbst, sondern nur auf die Tools, die die Resultate der Hadoop Jobs sammelten. Das hat die Arbeit der ITler stark vereinfacht, da sie  den Hadoop Cluster, der viele sensible Daten über ihr Unternehmen beherbergt , komplett von der restlichen IT Infrastruktur abtrennen und durch Firewalls sichern konnten. Die Kommunikationskanäle zwischen Hadoop und anderen Tools waren dabei auf das absolut Notwendigste –   sprich Daten rein, Resultate raus –  begrenzt. Durch diese Limitierung fiel das zeitaufwendige Installieren und Verwalten von Usern und das Schreiben von Autorisierungspolicies weg.
Mit dem Zuwachs der Datenmenge in modernen Unternehmen und der wachsenden Popularität des Hadoop Ecosystems kamen weitere Use Cases und mehrere Tools hinzu. Hadoop2 hat in diesem Zuge eine komplett neue Architektur veröffentlicht, in der man nicht mehr vom MapReduce abhängig ist. Andere Ausführungsengines sind aufgetaucht, die auf bestimmte Use Cases abzielen und sich in diesen Fällen durch bessere Leistung als das MapReduce Framework auszeichnen. Mehr und mehr Business- und Daten-Analysten wurden daraufhin auf Hadoop aufmerksam und wollten die Technik für sich nutzen.. Insbesondere Banken und Finanzdienstleister erkannten das gewaltige Potenzial dieser Technologie und wollten sie nutzen, um ihre Kunden besser zu verstehen.
Das war der Moment, in dem Unternehmen weltweit den Druck empfanden, eine ernste Sicherheitsarchitektur für Hadoop zu entwickeln. Dabei stießen ihre Ingenieure jedoch auf erste Probleme:
Wie gewährleistet man nutzerbasierten Zugriff auf Tools, die sich normalerweise innerhalb eines Hadoop Clusters befinden? Und noch wichtiger: Wie beschützt man sensible Daten vor unbefugtem Zugriff? Welcher Nutzer darf auf welche Daten zugreifen?
All diese Fragen, die sich mit dem Thema „Personalisierter Zugriff“  befassten, brauchten umgehend eine Antwort.

Die Sicherheitsanforderungen einer Data Science Plattform

Den Bedarf an höheren Sicherheitsvorkehrungen haben insbesondere die Hadoop Plattformen, die ihren Usern interaktive und adhoc Jobs/Abfragen ermöglichen möchten. Solche Plattformen sind in der BigData Welt als interaktive oder explorative (abgeleitet vom englischen Wort Exploration) Umgebungen bekannt. Ihr Hauptziel ist es, eine BigData Umgebung anzubieten, die den Usern erlaubt, neue Techniken und maschinelles Lernen auf Datensätze anzuwenden, um versteckte Muster zu erkennen.

Hier sind einige der wichtigsten Ziele, die ein sicheres Hadoop Umfeld erfüllen muss:

  1. Jeder User muss in der Lage sein, selber Abfragen oder Machine Learning Algorithmen auf große Datenmengen anzustoßen.
  2. User müssen sogar in der Lage sein, selber Daten einzufügen und zwar in einer kontrollierten Art und Weise.
  3. Resultate müssen direkt auf dem Cluster abrufbar sein, damit die neuesten BigData Visualisierungstechnologien genutzt werden können
  4. Unbefugter Zugriff auf Datensätze einer dritten Abteilung durcheinzelne Personen oder Gruppen muss verhindert werden.
  5. Jeder Datenzugriff muss kontrolliert und auditiert werden können.

Dieser Artikel ist der Start der drei-teiligen Serie zum Thema Sicherheit auf Enterprise-Niveau für Hadoop. 


Weiter zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Mobilgeräte-Sicherheit

Safety first! Testen Sie Ihr Wissen rund um Mobile Device Management!

Mobile Device Management (MDM) unterstützt nicht nur der Verwaltung von mobilen Endgeräten und die Software- und Datenverteilung. Es ermöglicht vor allem, die nötige Sicherheit, Transparenz und Kontrolle beim Einsatz von Smartphones und Tablets zu schaffen.

Sicherheit ist das A und O bei der unternehmensinternen Nutzung von Mobilgeräten. Neben der klassischen Geräteverwaltung bilden deshalb Security-Funktionen wie Datenverschlüsselung, Remote-Recovery, App Blacklists und ein Malware-Schutz die Hauptpfeiler von MDM-Lösungen.

Zuverlässige Schutzfunktionen sollen vor allem verhindern, dass interne Daten unkontrolliert das Unternehmen verlassen. Zu diesem Zweck sorgt ein MDM-Client auf dem mobilen Device für die Einhaltung der Corporate-Regeln. Solche Regeln könnten beispielsweise die Nutzung von Kamera oder Bluetooth verbieten oder die Installation bestimmter Apps und Browser. Auch Jailbreak und Rooten stehen oft auf der Verbotsliste.

Neben Unterlassungen lassen sich auch Gebote vorschreiben, etwa, dass die Geräte beim Einschalten durch eine PIN-Eingabe entsperrt werden müssen, dass Daten auf den Devices per Backup vor Verlusten geschützt und gestohlene oder verlorene Geräte bereinigt werden müssen.

Solche Policy-Vorgaben werden per Echtzeitüberwachung kontrolliert – gerade beim Arbeiten mit kritischen Datensätzen wie personenbezogenen Daten, Kontodaten und anderen vertraulichen Informationen eine absolute Notwendigkeit. Verstößt ein Nutzer gegen eine oder mehrere dieser Regeln wird der Zugriff auf die geschäftskritischen Ressourcen blockiert. Als letzte Konsequenz und bei Verlust oder Diebstahl kann das Smartphone oder Tablet auch gesperrt oder dessen Inhalte kontrolliert gelöscht werden. Die Lokalisierung, das Sperren und Löschen der mobilen Devices sollte deshalb auch über die Luftschnittstelle möglich sein.

Herausforderung BYOD

Eine weitere Sicherheitshürde ist zu bewältigen, wenn das Unternehmen seinen Mitarbeitern die berufliche Nutzung ihrer privaten Geräte erlaubt: In solchen BYOD-Szenarien (BYOD = Bring Your Own Device) ist die strikte Trennung privater und geschäftlicher Daten ein Muss. Während Unternehmen stets im Auge behalten müssen, welche geschäftskritischen Daten ihre Mitarbeiter erheben, verarbeiten und nutzen, müssen deren private Daten privat bleiben. Hier haben sich Container-Lösungen etabliert. Diese stellen sicher, dass die Anwendungen und ihre Daten in einem abgeschotteten Umfeld (Container) – sauber getrennt voneinander – laufen.

Mit einer Container-Lösung lässt sich beispielsweise verhindern, dass Firmeninformationen per Copy & Paste auf Facebook oder Twitter landen. Ein Zugriff aus dem Firmenkontext auf die private Facebook- oder Twitter-App wäre damit schlichtweg nicht möglich. Durch Container lassen sich somit viele Schwachstellen eliminieren.

Für einen absolut sicheren, rollenbasierten Datenaustausch hochsensibler Dokumente empfiehlt sich die Einrichtung eines Secure Data Rooms. Dieser ist vollständig isoliert und durch multiple Sicherheitsstandards vor unbefugten Zugriffen gesichert. Dem Secure Data Room sind Rollenrechte hinterlegt, so dass nur bestimmte, authentifizierte Nutzergruppen auf diesen Raum zugreifen können. So lässt sich zum Beispiel für die Vorstandsebene ein Secure Data Room anlegen, in dem Geschäftsberichte und Verträge abgelegt und – je nach erlaubten Bearbeitungsstufen – eingesehen oder auch bearbeitet werden können.

In Zusammenarbeit mit IBM