Dieser Artikel ist Teil unseres Guides: Big Data: Anwendung, Datenschutz und Technologie

NoSQL-Herausforderungen: Wie es um Big Data und Security steht

Die horizontale Skalierbarkeit von Big Data ist zwar attraktiv, doch wie erreichen Security-Experten die benötigte Sicherheit der NoSQL-Datenbanken?

Security-Teams vieler Unternehmen sind über den Punkt hinaus, Big Data eine Modeerscheinung zu nennen. Sie erkennen, dass sie auf die nächste Generation von Data-Storage-Plattformen zusteuern. Es sind nicht nur Google, Facebook und die NSA, die Big Data für Ihre Geschäftsmodelle brauchen. Tausende von Firmen, inklusive Start-ups, wollen von Big-Data-Architekturen profitieren.

Viele Security-Profis, die zum ersten Mal mit einer Big-Data-Umgebung in Berührung kommen, erkennen nicht, warum Security ein großes Problem ist. Sie gehen davon aus, dass Sie auf die gleichen Tools und Techniken setzen können, die relationale Datenbanken schützen.

Das funktioniert aber nicht, denn die meisten in ein RDBMS eingebauten Security-Funktionen finden Sie in Big-Data-Plattformen nicht. Viele Security-Tools von Drittanbietern, die Sie vielleicht besitzen, funktionieren ebenfalls nicht mit Big Data. Diese nicht-relationalen Datenmanagement-Plattformen sind in ihrer Architektur so unterschiedlich, dass Sie die Datenbank-Security überdenken müssen.

Big-Data-Technologie ist attraktiv, weil es Open Source ist. Es bietet praktisch freie Analyse- und Datenmanagement-Leistungsmerkmale. Ein herkömmliches Data Warehouse kostet möglicherweise Millionen Euro, um es auf proprietären Systemen laufen zu lassen. 

Big Data lässt sich hingegen komplett auf Hardware von der Stange betreiben. Kombinieren Sie das mit den riesigen Mengen an Daten, die von all den elektronischen Geräten generiert werden, können Unternehmen jeder Größe wertvolle Informationen zu relativ niedrigen Preisen erhalten.

Big-Data-Systeme sind aber auch Datenbanken. Es ist wie bei allen Datenbanken: Qualitativ hochwertige Daten bringen bessere Analyse-Resultate ans Tageslicht. Die Geschäftsleitung wird in der Regel nicht darüber in Kenntnis gesetzt, wie man entsprechende Ergebnisse erzielt. Sie interessieren sich lediglich für die Qualität der Resultate und wie sie dem Geschäft dienen.

Big-Data-Architekten nehmen Kundendaten, Transaktionsinformationen, geistiges Eigentum, Lieferketten-Details und finanzielle Informationen, um Business Intelligence (BI) zu unterstützen und qualitativ hochwertige Analysen zu liefern. 

Es stellt sich weniger die Frage, ob sensible Daten innerhalb eines Clusters gespeichert sind, sondern wie man diese Informationen nutzt. Durch die immer breitere Annahme von Big-Data-Projekten werden die Plattformen schnell fortschrittlicher und die Bedenken über sensible Daten größer. Daher ist es an der Zeit zu analysieren, wie sicher diese Systeme und die darin gespeicherten Daten sind.

Das Problem mit Big Data

Es gibt viele Unterschiede zwischen herkömmlichen Datenbanken und Big-Data-Architekturen. Drei davon stechen jedoch hervor. Zunächst einmal realisiert man Big Data mithilfe eines Clusters an Servern und jeder davon enthält einen Teil der gespeicherten Daten. 

Das ist auch der wichtigste Unterschied. Anwendungen kommunizieren nicht mit einem einzigen Knoten in diesem Cluster. Stattdessen kommunizieren sie mit Hunderten oder gar Tausenden Knoten. Big Data zu schützen ähnelt mehr der Absicherung eines kompletten Data Centers und weniger dem Schutz eines einzelnen Servers.

Zudem gibt es kein Standard-Cluster. Es sind mehr als 150 Big-Data-Varianten verfügbar. Jede davon ist auf etwas anderes spezialisiert. Dazu gehören Graph-Daten, Tuple Stores, Dokumentenspeicher und spaltenorientierte Datenspeicher, um nur einige zu nennen. Viele dieser Varianten erlauben es, die Komponenten auszutauschen: Datenmodell, Ressourcenmanager, Datenzugriffsebene, Abfragemöglichkeiten und Orchestrierungs-Tools sind untereinander auswechselbar.

Da diese Plattformen relativ neu sind, fokussierten sich die zuständigen Architekten auf Skalierbarkeit, Performance und die Optionen, eine spezielle Datenverarbeitungsaufgabe auf einzigartige Weise zu realisieren. Security befand sich dabei bisher nicht auf der Agenda. Einige kommerzielle Versionen von Big-Data-Plattformen schließen diese Lücken. Die Security bei Open-Source-Varianten wird meist nachträglicher implementiert und ist nur begrenzt leistungsfähig.

Eine weitere Schwierigkeit von Big-Data-Security ist, dass einige herkömmliche Tools nicht sehr gut funktionieren. Das hängt mit der Multi-Node-Architektur, der unglaublichen Menge, Vielfalt und Schnelligkeit der Daten zusammen. 

Diese sprengen die Möglichkeiten von herkömmlichen Security-Produkten. Einige Security-Produkte haben Probleme mit der Skalierbarkeit (Verschlüsselung auf Zeilenebene, Maskierung, Paket-Analytik) oder sie funktionieren mit so vielen NoSQL-Clustern einfach nicht (Inhaltsfilter, Abfrage-Monitoring). Sieht man sich nun das Gesamtbild an, ist die Security bei Big Data eine große Herausforderung.

Referenz-Architekturen für NoSQL-Security

Unternehmen gehen unterschiedlich an die Absicherung ihrer Big-Data-Cluster heran. Die meisten Firmen sichern nur minimal ab. Einige Unternehmen setzen auf ein Security-Modell, das sich daraus ableitet, wie Sie den Cluster konfiguriert haben. 

Sie haben nach dem Start implementiert, was möglich war. Vier häufig angewandte Maßnahmen adressieren die Security und erlauben es trotzdem, Big Data horizontal zu skalieren. An dieser Stelle sei angemerkt, dass es keine richtige oder falsche Herangehensweise gibt. Bei jedem Modell kommt es auf das Fachwissen, die Infrastruktur und Risiken an, die von einem Unternehmen als wichtig erachtet werden.

Der mit Abstand beliebteste Ansatz für die Security von Big Data ist das Walled-Garden-Modell. Es ähnelt dem Moat-Modell, das viele Jahre bei der Mainframe-Absicherung zum Einsatz kam. Die IT platziert den kompletten Cluster in ein eigenes Netzwerk und kontrolliert mithilfe von Firewalls und Zugriffskontrollen die logischen Zugriffe.

Bei diesem Security-Modell sichert sich der NoSQL-Cluster nicht selbst ab, sondern die Datenbanken-Security hängt von der äußeren Schutzschicht des Netzwerks und den Applikationen ab, die die Datenbanken umgeben. 

Der Vorteil ist die Einfachheit. Jedes Unternehmen kann dieses Security-Modell mit existierenden Tools und Fachwissen implementieren. Eine Verschlechterung der Performance oder Funktionalität der Datenbanken gibt es nicht. 

Der Nachteil ist die fragile Sicherheit. Sobald es ein Problem mit der Firewall oder einer Applikation gibt, ist das System unsicher. Außerdem stellt dieses Modell die Einschränkungen nicht zur Verfügung, dass berechtigte Anwender das System missbrauchen oder im Cluster gespeicherte Daten ansehen und modifizieren können. Sorgen sich Firmen nicht allzu sehr um die Security, ist das ein einfacher, Kosten-effizienter Ansatz.

Ein weiterer Ansatz für Big-Data-Security sehen Sie in Abbildung 1. Hier verwendet man Security-Tools oder Produkte von Drittanbietern, die im NoSQL-Cluster integriert und Teil der Grundfunktion sind. Dabei beinhalten die Tools SSL/TLS für sichere Kommunikation, Kerberos für Authentifizierung an den Nodes und transparente Verschlüsselung für Data-at-Rest-Security. Auch Identitäts- und Autorisierungs-Management (Gruppen, Rollen) ist möglich.

Diese Herangehensweise für Cluster-Security ist schwieriger, da man diverse Sicherheitsfunktionen konfigurieren muss, die spezielle Risiken der Datenbank-Infrastruktur abdecken. Da man hierfür oft Security-Tools von Drittanbietern benötigt, ist das in der Regel mit mehr Kosten verbunden. Es schützt einen Cluster allerdings vor Angreifern, falschen Administratoren und gedankenlosen Programmierern. Es ist der effizienteste und umfassendste Ansatz für NoSQL-Security.

Abbildung 1: Bei diesem Ansatz setzt man auf integrierte Tools. Die Konfiguration ist komplizierter, da man verschiedene Security-Funktionen einrichten muss, um spezielle Risiken für die Datenbank-Infrastruktur zu minimieren.

Datenzentrierter Ansatz für Big-Data-Security

Big-Data-Systeme teilen sich in der Regel Daten von Dutzenden Quellen. Firmen wissen nicht immer, wohin die Daten übertragen werden oder welche Security-Kontrollen aktiv sind, wenn sie gespeichert werden. Deswegen leiten sie Schritte ein, um die Daten zu schützen, egal wo diese genutzt werden. 

Das dritte NoSQL-Security-Modell nennt sich datenzentrierte Security, da die Kontrollmechanismen Teil der Daten und nicht der Datenbank sind. Die Daten werden somit geschützt, bevor Sie in ein Big-Data-Repository wandern.

Die drei grundsätzlichen Tools, die datenzentrierte Security unterstützen, sind Tokenisierung, Maskierung und Datenelement-Verschlüsselung (siehe Abbildung 2). Dabei präsentiert man einen Daten-Token anstelle der Daten. Tokenisierung verwendet man häufig bei Systemen, die Kreditkarten verarbeiten, um damit die Kreditkartennummer zu ersetzen. Der Token hat eigentlich keinen Wert, sondern ist lediglich eine Referenz auf den ursprünglichen Wert in einer oder mehreren Datenbanken.

Maskierung ist ein weiteres Tool, das häufig zur Datensicherung eingesetzt wird. Damit schützt man Datenelemente, wobei man den kumulierten Wert eines Datensatzes beibehält. Unternehmen tauschen die Sozialversicherungsnummer einer Person zum Beispiel durch eine zufällige Nummer. Vielleicht ändern sie den Namen willkürlich oder tauschen ein Datum mit einem, das sich in der näheren Umgebung befindet. 

Somit sind die sensiblen Originaldaten komplett entfernt. Der Wert des Datensatzes wird allerdings für weitere Analysen aufbewahrt. Schließlich lassen sich Datenelemente verschlüsseln, so dasss man nicht fürchten muss, dass sie kompromittiert werden. Nur legitimierte Anwender mit dem richtigen Schlüssel können den Originalwert sehen.

Abbildung 2: Die drei grundlegenden Tools, die datenzentrierte Sicherheit unterstützen: Tokenisierung, Maskierung und Verschlüsselung von Datenelementen.

Das datenzentrierte Security-Modell bietet hohe Sicherheit, wenn man den Systemen nicht komplett vertrauen kann, die die Daten verarbeiten. Da die Technologie noch recht jung ist, trauen aber viele Unternehmen den Big-Data-Cluster-Systemen für den Schutz der Informationen nicht. Ein datenzentriertes Security-Modell muss vorsichtig geplant und die Tools müssen mit Bedacht ausgewählt werden, da es mehr ein Lebenszyklus-Management der Daten ist. 

Sie definieren die Protokolle, über die sich Daten bewegen lasse, und welche Art an Schutz vorhanden sein muss. Sensible Daten erst gar nicht zu löschen, ist der beste Ansatz, wenn Sie einen Big-Data-Cluster für Analytics-Prozesser bestücken müssen, aber die Security nicht garantieren können.

Umgestaltung für die Cloud

Kommen wir zum vierten Security-Modell für Big Data, das immer mehr Unternehmen nutzen. Es handelt sich hier um die integrierten Services, die von Cloud-Providern für Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) zur Verfügung gestellt werden. Cloud-Computing-Umgebungen bieten viele Vorteile, wenn es um sichere Einsatz-Optionen, Security-Orchestrierung und eingebaute Funktionen für die Absicherung von Plattformen und Netzwerken geht. 

Zum Beispiel haben Sie die Möglichkeit, vertrauenswürdige Server-Abbilder laufen zu lassen. Sie können diese dynamisch umkonfigurieren und die Server-Instanz vor einem Einsatz validieren. Somit stellen Sie für den Cluster eine vertrauenswürdige Umgebung zur Verfügung. Dynamische und auf Abruf bereite Cloud-Services limitieren die Performance von Big-Data-Datenbanken nicht.

Tools wie zum Beispiel Identitäts-Management, Session-Verschlüsselung, Datenverschlüsselung, Monitoring und Logging sind in der Cloud implementiert. Viele Provider von Big-Data-Plattformen bieten vertrauenswürdige Sätze von Hadoop- oder Cassandra-Varianten als Teil des Services an. 

Dazu gehören unter anderem Cloudera, DataStax, Hortonworks, MapR und Zettaset. Selbst wenn die von Ihnen eingesetzte NoSQL-Variante keine Security-Leistungsmerkmale mitbringt, können Sie die meisten der Lücken mithilfe der Tools schließen, die die Plattform-Provider im Angebot haben.

Der Nachteil dieser Strategie ist, dass die Firmen die Cloud verstehen müssen. Aus diesem Grund ist es erforderlich, dass man die Konfigurationen umbaut, um diese nutzen zu können. Sie können sich nicht in die Cloud begeben und denken, dass ein Netzwerk-Monitoring- und Firewall-Security-Modell Ihre Risiken adressiert. Der Fokus muss sich auf die Orchestrierung, Management-Ebene und Datensicherheit verschieben. Sollten Sie mit Big Data noch nicht begonnen haben, sollten Sie sich diese Option ernsthaft überlegen.

Datenbank-Security muss überdacht werden

Big Data ist die Datenbank der Zukunft: Es ist das, was Unternehmen wählen, wenn Sie neue Projekte beginnen. Die Technologie ist schnell und lässt sich einfach für spezielle Aufgaben anpassen. Dabei ist es immer noch Kosten-effizient. Dennoch muss man anmerken, dass wir uns am Anfang von Big-Data- und NoSQL-Security befinden. 

Keiner hat behauptet, dass dies einfach wird. Mit fortschreitender Reife der Plattform wird es auch mehr Bedenken geben. Big Data wird viele Facetten aufweisen, an die Sie Security-Aufgaben anpassen müssen, obwohl Sie vielleicht gedacht haben, dass Sie diese schon beherrschen.

Es ist wichtig, dass Sie niemals davon ausgehen, keine sensiblen Daten gespeichert zu haben. Möglicherweise ist das der Fall oder es wird in der nahen Zukunft so sein. Nehmen Sie die NoSQL-Security-Referenzen in Augenschein und entscheiden sich dann, welches Konfigurationsmodell am besten zu Ihrem Unternehmen, zum Fachwissen der Mitarbeiter und zum Budget passt. Es ergibt keinen Sinn, wenn Sie einen geclusterte Security-Ansatz wählen und dafür nicht das Budget oder die Mitarbeiter haben, um die Security-Kontrollen zu etablieren.

Nutzen Sie darüber hinaus die Audit-Logs so oft wie möglich. Es geht dabei darum, wie Sie Daten sammeln, um die Datenbank-Security zu überwachen. Diese Daten lassen sich aber auch für Performance-, Betriebs- und Business-Analysen nutzen. Das hilft Ihnen zu verstehen, was Sie bisher noch nicht wußten.

Über den Autor:
Adrian Lane ist CTO der Analysten-Firma Securosis. Adrian ist auf Datenbank- und Datensicherheit sowie auf Softwareentwicklung spezialisiert. Er hat früher als leitender Angestellter bei Security- und Software-Unternehmen wie Ingres, Oracle, Unisys und IPLocks gearbeitet und tritt regelmäßig bei Branchen-Eventsauf. Lane hat einen Abschluss von der University of California in Berkeley und danach an Betriebssystemen an der Stanford University gearbeitet. Sie können ihn unter alane@securosis.com erreichen.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Big Data

ComputerWeekly.de

Close