Datensicherheit und Compliance Sicherheitsbedenken behindern Datenintegration

Für Business-Analysen ist es längst üblich, Informationen aus verschiedenen Datenbanken zusammenzuführen (zu integrieren). Dabei kommt es nicht nur zu Verletzungen der Quelldaten, sondern es treten auch gleichzeitig riskante Verletzungen von Sicherheits- und Compliance-Regeln auf. Es geht aber auch anders.

Anbieter zum Thema

Arvato Systems

SEPPmail - Deutschland GmbH

Keeper Security EMEA Ltd.

MarkLogic Corporation Headquarters

Es häufen sich die Schlagzeilen über Cyberattacken, Ransomware und andere Beeinträchtigungen der Datensicherheit. Laut der Veris Community Database wurden 2011 gerade einmal 468 größere Datensicherheitsverletzungen gemeldet. Ein Jahr darauf waren es 1175, 2013 bereits 1731. Nach einer Kalkulation von IBM kostet jeder Cybervorfall US-Unternehmen durchschnittlich 7,1 Millionen Dollar beziehungsweise 221 Dollar pro Datensatz.

Datensicherheit hat jetzt oberste Priorität, ohne Zweifel sind Anwenderunternehmen zunehmend sensibilisiert. Aber es gibt – vielleicht bedingt durch den Zwang, permanent die IT up-to-date halten zu müssen – gravierende Lücken. So meldet Thales eSecurity im 2017 Thales Data Threat Report (pdf), fast zwei Drittel (63 Prozent) der Unternehmen setzten neue IT-Ressourcen ein, ohne sich zuvor um geeignete Sicherheitsmaßnahmen gekümmert zu haben. Es ist um die Datensicherheit zunehmend schlechter gestellt, zumindest gemessen an der Zahl der Angriffe und der Höhe des Schadens.

Dabei sind fast alle Unternehmen auf der Suche nach besseren Lösungen, aber angesichts groß angelegter Datenintegrationsprojekte, die eine Vielzahl von Datensilos mit unternehmenskritischen Daten beinhalten, ist das Problem auch weiterhin nicht zu unterschätzen. Organisationen, die keinen umfassenden Ansatz zur Datensicherheit nutzen und sich nur auf taktische Details oder die Perimetersicherheit konzentrieren, setzen sich einem enormen Cyberrisiko aus.

Herkömmliche Datenintegration schafft Risiken

Beim Bestreben, Daten zusammenzuführen und zu integrieren, treffen Unternehmen auf fünf grundlegende Herausforderungen.

• Es gilt allgemein als unerlässlich, mit rollen- und richtlinienbasierte Zugriffskontrollen Daten und die damit verbundenen Zugriffsrechte zu verwalten, zu bewahren und zu überprüfen. Leider gibt es in den meisten Organisationen viele verschiedene relationale Datenbank-Silos. Jeder besitzt unterschiedliche Zugriffskontrollen, die es praktisch unmöglich machen, die Gesamtheit der Daten adäquat zu verfolgen und zu schützen. Mit einer wachsenden Zahl von Datensilos steigt auch die Anzahl von Möglichkeiten, Schwachstellen auszunutzen.

• Darüber hinaus gibt es für die Datenzusammenführung mehrere ETL-Tools (Extract, Transform, Load) mit verschleiertem Code und entsprechenden Integrationspunkten. Jedes dieser Tools verwendet eigene Zugriffskontrollen, und mit jedem steigt der Aufwand für deren Administration.

• Oft werden mehrere relationale Datenbanken mit Hilfe eines eigens dafür erstellten, komplizierten ETL-Prozesses mit einem zentralen Analytical Data Warehouse verbunden. Der ETL-Prozess dient zwei Zwecken gleichzeitig: erstens, um das System funktionsfähig zu machen und zweitens, um die Daten zu bereinigen, damit sich Zählungen oder Berechnungen durchführen oder Daten unterscheiden lassen. Leider erzielt die Datenbereinigung oft nicht die gewünschten Ergebnisse. Häufig beeinträchtigt die Reinigung sogar die Datenqualität, weil wichtige Informationen verlorengehen.

Die Ursache liegt in einer unterschiedlichen Interpretation der Metadaten: Einige davon mögen einem Datenanalysten wie „Daten-Flusen“ vorkommen, die zu entfernen sind. Für einen Compliance-Analysten oder Datenmodellierer sind diese Flusen aber aus wichtigen geschäftlichen Gründen zwingend erforderlich, beispielsweise um einer Aufsichtsbehörde zu beweisen, dass bestimmte Geschäfte legal waren, und so Geldstrafen zu vermeiden. Folglich wird es im Laufe der Zeit immer schwieriger, die Data Governance (Qualität, Abstammung und Herkunft, Sicherheit und Datenschutz, Compliance-Anforderungen, Verfügbarkeit) zu gewährleisten.

Datensicherheit überlastet Anwendungsentwickler

Es ist wirklich nicht einfach, Daten über eine Vielzahl von Datensilos hinweg auf jeder Schicht abzusichern. Leider werden Daten nicht an einem zentralen Ort und nicht in der Datenbankschicht geschützt. Weil Unternehmen neue Datenschutzverordnungen und Sicherheitsanforderungen erfüllen müssen, wächst das Risiko und die Belastung für die Mitarbeiter.

In der Regel müssen Anwendungsentwickler ihr Bestes tun, um die Daten auf der Anwendungsebene bei jeder neuen Anwendung abzusichern. Dies ist besonders problematisch, weil die Entwicklungs- und Sicherheitsabteilungen oft nicht zusammenarbeiten. Diese Trennung ist durch die Umstellung auf DevOps und agile Entwicklungsmethoden noch gewachsen. Dabei sind Beide eigentlich positive Verbesserungen für die Softwareentwicklung, die kürzere Release-Zyklen ermöglichen.

Doch damit können die Sicherheitsteams dann wieder nicht Schritt halten. Sicherheits-Prüfzyklen sind auf Wochen und Monate ausgelegt, und Sicherheitszertifizierungen und -zulassungen basieren auf Wasserfallmodellen und nicht auf kontinuierlichen Verbesserungsprozessen. Die meisten Entwickler kennen zwar die OSWAP Top Ten, aber echte Sicherheitsexperten werden lediglich für eine Abschlussprüfung vor dem Go-live hinzugezogen.

Die Folge ist vorhersehbar. Laut Gartner spielt die Sicherheit für 90 Prozent der Unternehmen, die auf DevOps setzen, lediglich eine untergeordnete Rolle. Da verwundert es nicht, dass laut dem US-amerikanischen Heimatschutzministerium (pdf) 90 Prozent der Exploits auf fehlerhafte Software zurückzuführen ist.

Ein gutes Beispiel für diese Trennung ist Intuit, das seinem 3000 Mitarbeiter starken Team einen agilen DevOps-Ansatz verordnete. Shannon Lietz, eine leitende Führungskraft im Bereich Cloud-Sicherheit bei Intuit, sagte in einem Interview: „Wir erkannten, dass die DevOps-Teams die Verantwortung einfach auf die Sicherheitsabteilung abwälzten, die über sämtliche Informationen verfügte und über alle eingehenden Angriffe auf dem Laufenden war. Doch leider fehlten den DevOps-Mitarbeiter diese Informationen, sodass sie keine fundierten Entscheidungen treffen konnten."

Obwohl die meisten Unternehmen nicht so groß sind wie Intuit, sind die Herausforderungen doch ähnlich. Ein Entwicklerteam bekommt die Aufgabe, eine Vielzahl von Technologien mit verschiedenen, in der Regel sehr begrenzten Sicherheitsfunktionen zusammenzustückeln. Das Sicherheitsteam ist in der Regel nicht auf dem aktuellen Stand und kann nicht Schritt halten.

Um dieses Problem in den Griff zu bekommen, sollten Unternehmen eine Reihe von taktischen Empfehlungen umsetzen. Dazu gehören unter anderem, aber vorrangig:

• Engere Integration zwischen Sicherheits- und DevOps-Teams, um die Feedback-Schleife zu schließen,

• Sicherheitsüberprüfung durch dynamische Code-Analyse automatisieren (und derartige Kontrollen früher und häufiger im Sprint-Lebenszyklus durchführen),

• Identity- and Access-Management-Systeme (IAM) verbessern,

• Aufgabentrennung durchsetzen sowie

• Risiko- und Bedrohungsmodellierung für Anwendungen durchführen.

Darüber hinaus ist es entscheidend, allgemeiner und strategischer zu betrachten, wie Daten auf der untersten Ebene – in der Datenbank – verwaltet werden. Denn Ziel ist es, die Data Governance über den gesamten Stack hinweg kontrollierbar zu machen.

Die Risiken durch Insider-Bedrohungen

In der Regel konzentrieren sich die meisten Unternehmen aus gutem Grund zuallererst auf Maßnahmen zur Sicherung von Endpunkten, Anwendungen, Perimeter und Netzwerk. Ein Eindringen in ihr Netzwerk zu verhindern, ist ein wichtiger Beitrag zum Schutz ihrer Infrastruktur. Bei einigen Unternehmen kommt es täglich zu Tausenden Einbruchsversuchen in das Netzwerk. Sich jedoch ausschließlich auf die Netzwerksicherheit zu konzentrieren, schafft eine harte Schale mit einem weichen Kern in der Mitte. Wenn diese erst einmal überwunden ist, geht alles verloren. Tatsächlich ist keine Netzwerkverteidigung unüberwindbar.

Doch die Schadensakteure befinden sich wahrscheinlich bereits innerhalb des Netzwerks. Einige der größten Datenlecks gehen auf das Konto von Insidern. Und die Anzahl der Vorfälle, in die interne Akteure verwickelt sind, häufen sich. Die genauen Angaben variieren, allgemein schätzt Verizon, dass interne Akteure an einem Viertel aller Verstöße gegen die Datensicherheit beteiligt sind.

Leider sind viele Systeme für derartige Angriffe anfällig, weil sie nur Datenzugriff nach dem Alles-oder-nichts-Prinzip ermöglichen und keine granularen Sicherheitsstufen und -kontrollen bieten. Verschärfend wirkt das Problem der Insider-Bedrohunge. dadurch, dass in modernen Unternehmen Mitarbeiter, Auftragnehmer, Subunternehmer, Handelspartner, Berater, Wirtschaftsprüfer und andere Beteiligte Zugriff auf Daten benötigen. Oft ist es deshalb schwierig zu unterscheiden, wer nun "drinnen" und wer "draußen" ist.

Manchmal sind es gerade die relativ harmlosen Daten-Management-Entscheidungen, die zu den größten Insider-Bedrohungen führen. Zum Beispiel besitzen viele Organisationen Data Lakes, die allgemein zugänglich sind und wahre Fundgruben darstellen.

Eine international tätige Bank beispielsweise arbeitete jahrelang am Aufbau eines Data Lake mithilfe einer Drittanbieter-Technologie. Aber sie nahm das System aus Sicherheits- und Compliance-Gründen außer Betrieb, als sie merkte, dass es über keine geeigneten Kontrollen verfügte und die Bank damit potenziell gegen bestimmte Regeln und Vorschriften bezüglich Kundendaten verstoßen hätte.

Unternehmen brauchen heute bessere Datensicherheit. Die Lösung kann jedoch nicht darin bestehen, das gesamte System vollständig abzuriegeln. Das Ziel der Datensicherheit muss stets mit einem praktikablen Maß an Datennutzbarkeit vereinbar bleiben.

Unternehmen müssen deshalb über geeignete Sicherheitskontrollen verfügen, um zu gewährleisten, dass freigegebene Daten für Akteuren mit entsprechenden Zugangsberechtigungen innerhalb und außerhalb des Unternehmens zugänglich sind. Zugleich muss eine Aufgabentrennung gegeben sein, damit die Administratoren, welche die Berechtigungen erteilen, nicht selbst Zugriff auf die Daten haben.

Was tun?

Wesentlich einfacher, schneller und sicherer lässt sich der Schutz der Daten verbessern, wenn die Daten in den Silos unberührt bleiben und nur für die einzelnen Analyseprojekte in eine zentrale Datenbank kopiert und dort zusammengeführt werden. Das bietet für die bestehenden Datensilos und die zentrale Datenbank wesentliche Sicherheitsvorteile.

Die Bestandsdaten in den Silos bleiben samt ihren Metadaten unverändert. Überlegungen, welche Metadaten nun wichtig oder nicht sein könnten, sind unnötig. Sämtliche Daten stehen unverändert für Compliance-Nachweise zur Verfügung. In den Silos lassen sich die Daten verschlüsseln und zum Schutz vor Veränderungen auf WORM-Medien (Write Once, Read Many) langfristig speichern.

In der zentralen Datenbank lassen sich die Daten in ihrem Ist-Zustand bearbeiten, ohne den Datenbestand zu gefährden. Vor allem wird für unterschiedliche Analysen immer nur diese eine zentrale Datenbank adressiert. Eine Software zum Zugriff auf diese Datenbank sollte es möglich machen, Aufgaben der Data Governance zentral zu steuern. Der Vorteil ist, dass sich eine Änderung der Datenschutzrichtlinien auf Datenbankebene automatisch auf hunderte Anwendungen übertragen lässt.

Diese Steuerung umfasst nicht einfach eine rollenbasierte Zugriffskontrolle, sondern eine, die bis in die Ebenen einzelner Dokumente reicht. Denn in jedem Fall sollten sich einzelne Elemente von Dokumenten vor Augen schützen lassen, die ansonsten bestimmte Rechte haben. Für die Erstellung und Ausführung der Richtlinien muss diese Steuerungssoftware entsprechende Programmier-APIs besitzen.

Sehr zu empfehlen ist als zentrale Instanz eine NoSQL-Datenbank. Denn auf dieser Basis lassen sich nict nur „zweidimensionale“, relationale Daten zusammenführen, sondern auch unstrukturierte. Auf Seiten der Silos sind inzwischen NoSQL-Datenbanken sehr verbreitet. Sie werden künftig noch mehr Daten bergen, die für Analyseprozesse unverzichtbar sind. Deshalb muss die zentrale Datenbank ebenso ausgelegt sein.

Die Trennung von Datenbeständen und ihrer Verarbeitung ist gleichermaßen ein Gebot aus den gesetzlichen Anforderungen für den Schutz persönlicher Daten, Compliance und IT-Sicherheit. Werden diese Themen nicht mit einer zentralisierten Datenbank angegangen, führt dies unweigerlich zu einer unübersichtlichen Architektur mit noch mehr Schwachstellen.

Über den Autor: Stefano Marmonti ist Director DACH bei MarkLogic.

(ID:45290203)