Viele der grundlegenden Prinzipien zur Absicherung eines Data Lakes dürften jedem vertraut sein, der bereits einen Cloud-Sicherheits-SpeicherContainer. Da die meisten kommerziellen Data Lakes auf bestehender Cloud-Infrastruktur aufbauen, ist das natürlich zu erwarten.
Data Lakes fügen jedoch zusätzliche Elemente wie Datenfeeds, Datenanalysen (Data-Lake-House, Analysewerkzeuge von Drittanbietern usw.) hinzu, die die Komplexität der Interaktionen über einen einfachen Speichercontainer hinaus erhöhen. Im Wesentlichen sichern wir eine Anwendung im großen Maßstab ab – mit enormen Anforderungen an gespeicherte Daten, eingehende Daten, Dateninteraktionen und Netzwerkverbindungen. Angesichts der Bedeutung von „Big Data“-Analysen und -Anwendungen für die finanzielle Leistungsfähigkeit eines Unternehmens hat die Absicherung von Data Lakes für Sicherheitsteams höchste Priorität.
Es gibt zu viele mögliche Varianten von Data Lakes, um für jeden Sicherheitsanwendungsfall konkrete Schritte vorzugeben. Wie bei einem Server, einem Netzwerk oder jeder anderen IT-Infrastrukturkomponente lassen sich jedoch Sicherheitsprinzipien formulieren. Diese Prinzipien helfen Teams, die Ziele zu verstehen. Anschließend müssen wir die verschiedenen verfügbaren Optionen durchgehen und sicherstellen, dass sie mit unseren Zielen, Prinzipien und Richtlinien übereinstimmen.
Sicherheitsumfang von Data Lakes
Ein Daten-GovernanceManager wird sich intensiv auf den Zugriff, die Übertragung und die Speicherung von Daten konzentrieren. Ein IT-Sicherheitsmanager muss jedoch eine umfassendere Perspektive einnehmen, die Infrastruktur und Werkzeuge einschließt. Zwar reicht der Umfang möglicher Aspekte von Bare-Metal-Geräten bis zum Code innerhalb der Anwendungen, doch der realistische Umfang ist enger gefasst und hängt davon ab, wie unser konkreter Data Lake eingerichtet wurde.
Einige Data Lakes orientieren sich an einem Software-as-a-Service-Modell (SaaS), bei dem die meisten Sicherheitsfunktionen bereits in die Software integriert sind und IT-Sicherheitsteams nur einige Details überprüfen müssen. Am anderen Ende des Spektrums kann die Absicherung unternehmensinterner Data Lakes sogar die Bare-Metal-Geräte sowie die Räume und Gebäude umfassen, in denen sie untergebracht sind.
Trotz dieses Spektrums möglicher Implementierungen sollten IT-Fachleute bereits ein solides Verständnis davon haben, wie eine typische SaaS-Lösung oder ein Bare-Metal-Rechenzentrum abgesichert wird. Daher konzentriert sich dieser Artikel auf Data-Lake-spezifische Aspekte und lässt allgemeine, gut verstandene Sicherheitsmaßnahmen außer Acht, etwa: Identitätsüberprüfung, das Scannen auf Malware, Ausfallsicherheit (Backups, usw.), Firewalls, Erkennung von Netzwerkbedrohungen und Incident Response.
Siehe die besten Zero-Trust-Sicherheitslösungen
Kritische Sicherheitsaspekte von Data Lakes: Transparenz und Kontrollen
Ein Data Lake kann potenziell sämtliche Daten eines Unternehmens enthalten. Wenn alle Daten an einem Ort liegen, vervielfachen sich die Risiken.
Angreifer werden ihre Anstrengungen darauf konzentrieren, Zugriff auf den Data Lake zu erlangen, um wertvolle Informationen abzuschöpfen. Insider-Bedrohungen werden versuchen, ihre Zugriffsberechtigungen zu überschreiten oder wertvolle Informationen unzulässig herunterzuladen. Selbst autorisierte und angemessene Datenzugriffe müssen verwaltet werden, um versehentliche Verstöße zu verhindern, bei denen streng geheime oder regulierte Daten in die Hände unbefugter Personen gelangen.
Um unzulässigen Zugriff zu verhindern, müssen Sicherheitsteams ihre Daten und Benutzer kennen und den autorisierten Zugriff definieren. Nach der Implementierung geeigneter Zugriffsrechte muss das Sicherheitsteam diese testen und die laufenden Zugriffe auf unzulässige Nutzung überwachen.
Diese Sicherheitsaspekte von Data Lakes lassen sich allgemein in Transparenz und Kontrollen unterteilen. Ohne diese beiden Aspekte zu beherrschen, ist jeder andere Sicherheitsbereich potenziell gefährdet.
Transparenz in Data Lakes
Um die angemessene Nutzung von Daten sicherzustellen, muss das Datensicherheitsteam zunächst Transparenz über die Daten schaffen. Sobald die Daten bekannt sind, sollten Kontrollen den angemessenen Zugriff erzwingen. Doch auch dann benötigt das Sicherheitsteam Transparenz über die Nutzung, um zu überprüfen, ob die Kontrollen ordnungsgemäß funktionieren.
Datentransparenz in Data Lakes: Klassifizierung
Die Klassifizierung der Daten ist entscheidend für eine effektive Zugriffskontrolle innerhalb des Data Lakes. Während eine erste Klassifizierung anhand der Quellen der eingehenden Daten erfolgen kann, müssen die Dateien im Data Lake letztlich auf sensible Daten untersucht werden.
Die verschiedenen Data Lakes verfügen aufgrund integrierter Funktionen über unterschiedliche Möglichkeiten; zusätzlich können Funktionen über separate Produkte oder Erweiterungen von Drittanbietern verfügbar sein. Auch der Funktionsumfang variiert: Manche Produkte können Dateien klassifizieren, während andere Klassifizierungen nur den aus den Dateien extrahierten Daten hinzufügen.
Zur Veranschaulichung dessen, was das bedeuten kann, folgen einige Beispiele:
- AWS
- Bietet einen Zusatzdienst: Amazon Macie.
- Macie wird pro verarbeitetem GB abgerechnet
- Macie durchsucht Dokumente mithilfe von Algorithmen des maschinellen Lernens (ML), um sensible Informationen zu identifizieren und zu kennzeichnen
- Bietet einen Zusatzdienst: Cloud DLP
- Cloud DLP wird pro verarbeitetem GB abgerechnet.
- Cloud DLP erkennt über 100 integrierte Identifikatoren
- Snowflake
- Die Klassifizierung gilt für in Tabellen und Ansichten gespeicherte Daten
- Die Klassifizierung verursacht Rechenkosten, aber keine zusätzlichen Lizenzgebühren
- Die Klassifizierung nutzt maschinelles Lernen, um Kategorien vorzuschlagen
- Zu den Klassifizierungskategorien gehören
- Semantische Kategorien (Name, Adresse, Alter usw.)
- Datenschutzkategorien (Unterkategorien der semantischen Kategorien)
- Direkte Identifikatoren (Name, Sozialversicherungsnummer usw.)
- Indirekte Identifikatoren (Alter, Geschlecht, Postleitzahl usw.)
- Persönliche Merkmale (Gehalt, Gesundheitsstatus usw.)
Angesichts des enormen Umfangs eines typischen Data Lakes erfordert die bewährte Vorgehensweise eine automatisierte Erkennung und Klassifizierung der Daten, während diese in den Data Lake geladen werden. Nach der Kategorisierung können die Daten außerdem organisiert, bereinigt und verschoben werden, um strenge Kontrollen zu ermöglichen.
Auch wenn dies eher eine Frage der Data Governance ist, müssen Datensicherheitsteams wissen, wie regulierte Daten behandelt werden sollen, damit sie die Daten ordnungsgemäß kategorisieren und entsprechende Kontrollen einrichten können. Was geschieht beispielsweise, wenn eine Sozialversicherungsnummer oder personenbezogene Daten eines Bürgers der Europäischen Union (EU) gefunden werden?
Databricks empfiehlt einen proaktiven Ansatz und das Löschen von EU-PII während der Datenaufnahme, weil die Datenschutz-Grundverordnung (DSGVO) gegen Verstöße Geldbußen von bis zu 20 Millionen Euro oder mehr vorsieht. Verstöße können durch Datenschutzverletzungen entstehen oder sogar dadurch, dass Daten nicht ordnungsgemäß gelöscht werden (aufgrund des in der EU geltenden Rechts auf Vergessenwerden).
Selbst wenn sich das Unternehmen entscheidet, die Daten aufzubewahren, muss die Data Governance festlegen, wer die Daten sehen oder durchsuchen darf und unter welchen Umständen. Eine Möglichkeit zur ordnungsgemäßen Handhabung besteht darin, Daten in bestimmte Ordner zu verschieben (bei Azure, Google usw.) oder sie mit der Kategorie „eingeschränkte Daten“ zu versehen, um sie innerhalb der Datenbank zu kennzeichnen (bei Snowflake, Databricks usw.).
Wie weiter unten ausführlicher erläutert, lassen sich Sicherheitskontrollen auf Ordnerebene deutlich besser skalieren als granularere objektbasierte Kontrollen (für Dateien, Tabellen usw.), die separat zugewiesen, überwacht und gepflegt werden müssen. Data-Lake-Werkzeuge können Kategorien erkennen und Daten während der Aufnahme verschieben, sodass die Daten schnell und im großen Maßstab automatisch kategorisiert und geschützt werden können.
Lesen Sie auch: Sicherheitskonformität und Datenschutzbestimmungen
Transparenz bei der Nutzung von Data Lakes: Überwachung und Protokollierung
Sobald ein Sicherheitsteam die perfekte Kategorisierung und die entsprechenden Kontrollen eingerichtet hat, ist der Data Lake geschützt! Zumindest theoretisch. Das Sicherheitsteam benötigt Transparenz über die Aktionen der Benutzer und APIs, um zu prüfen, ob die Theorie auch in der Praxis Bestand hat.
Sicherheitsteams müssen verschiedene Protokolle und Warnmeldungen innerhalb der Data-Lake-Umgebung einrichten, pflegen und prüfen. Angesichts des Umfangs eines Data Lakes ist für die meisten Warnmeldungen möglicherweise eine Automatisierung erforderlich, um verdächtige Aktivitäten zu blockieren.
Sicherheitsteams müssen die Audit-Protokollierung innerhalb des Data Lakes überprüfen, um abhängig von Kapazitäten und Budget des Sicherheitsteams festzulegen, was aktiviert werden muss. Bei Google Data Lakes ist beispielsweise die Administratoraktivität standardmäßig aktiviert, während Datenzugriffsprotokolle standardmäßig deaktiviert sind, um Rauschen und Speichervolumen zu reduzieren.
Im Falle eines Vorfalls sollten die üblichen Verfahren der Incident Response für den Data Lake ebenso gelten wie für jede andere Ressource. Sicherheitsteams müssen jedoch den korrekten Fluss von Warnmeldungen und Beweismitteln an das Incident-Response-Team überprüfen.
Lesen Sie auch: So erstellen Sie einen Incident-Response-Plan
Kontrollen für Data Lakes
Sobald Data-Governance-Teams festgelegt haben, wie Daten behandelt werden sollen, setzen Datensicherheitsteams Kontrollen durch, um diese Regeln umzusetzen. Oft sind diese Regeln Erweiterungen bestehender IT-Richtlinien, doch einige Richtlinien müssen möglicherweise überprüft und überarbeitet werden. Die wichtigsten Arten von Sicherheitskontrollen für Data Lakes fallen in die Kategorien Isolation, Autorisierung, Verschlüsselung, Übertragung und Speicherung.
Isolation von Data Lakes
Als Sicherheitsexperten wollen wir die Zahl der Verbindungen begrenzen, die wir für unsere IT-Infrastruktur kontrollieren und verwalten müssen. Viele Anbieter empfehlen die Isolation als ersten Schritt bei der Einrichtung eines Data Lakes.
Auch wenn die Terminologie je nach Lösung variieren kann, lassen sich Data Lakes privat und verborgen einrichten, um eine beiläufige Entdeckung durch externe Parteien zu verhindern. Einige Anbieter empfehlen lediglich, den Zugriff auf den Data Lake aus einem gesicherten Unternehmensnetzwerk zu erlauben. Angesichts der zunehmenden Verbreitung einer perimeterlosen Sicherheit könnten in dieser Empfehlung sichere Gateways oder andere Zero-Trust-Netzwerk-Setups an die Stelle von Unternehmensnetzwerken treten.
Eine strikte Einschränkung der Kommunikation zwischen dem Data Lake und der Außenwelt kann die Fähigkeit von Angreifern verringern, Daten abzuschöpfen. Zusätzlich sollten Maßnahmen zur Verhinderung von Datenverlust (Data Loss Prevention, DLP) eingerichtet werden, um Insider-Bedrohungen und das Abschöpfen von Daten durch erfolgreiche Angriffe zu verhindern.
Siehe die wichtigsten Lösungen zur Verhinderung von Datenverlust (DLP)
Ähnliche Isolationskontrollen sollten auf Computercluster angewendet werden, die von der Organisation verwaltet werden und Abfragen ausführen. Solche Kontrollen können unter anderem die Einschränkung von Secure Shell (SSH) und Netzwerkzugriff umfassen.
Azure Private Link und AWS PrivateLink bieten cloudnative Lösungen unter eigener Marke, die private Netzwerkverbindungen zwischen Unternehmensressourcen herstellen und den Data Lake vom Internet oder anderen öffentlichen Ressourcen isolieren. Natürlich können Unternehmen auch zusätzlichen Aufwand betreiben und eigene sichere Gateways für ein ähnliches Ergebnis einrichten.
Einige Anbieter wie Databricks integrieren einige dieser Sicherheitsfunktionen standardmäßig in den Cluster. Es liegt jedoch in der Verantwortung des Sicherheitsteams, die konkreten Details zu überprüfen und mögliche Schwachstellen zu berücksichtigen, die eine Abhilfe erfordern könnten.
Autorisierungskontrollen für Data Lakes
Bei der Autorisierung geht es darum, den Zugriff auf Grundlage der Datenkategorisierung zu kontrollieren. Der Zugriff wird anhand des Benutzers, der API oder sogar der Abfrage festgelegt.
Im Einklang mit modernen Zero-Trust-Prinzipien sollte der standardmäßige Datenzugriffsstatus so eingestellt sein, dass der Zugriff vollständig verweigert wird. Zugriffe sollten aktiv und nur bei bestehendem Bedarf gewährt werden.
Um Benutzern den Zugriff auf den Data Lake zu ermöglichen, integrieren die meisten Data Lakes standardmäßig die Technologie der Identitäts- und Zugriffsverwaltung (IAM)obwohl die Details je nach Implementierung variieren können. Jede Technologie kann dann zusätzliche Sicherheitsebenen hinzufügen, um bestimmte Benutzer, Gruppen, Projekte oder Unternehmen mit bestimmten Daten-Repositorien (Ordnern, Dateien oder Datenspalten) zu verknüpfen.
Einige Beispiele für zugehörige IAM-Tools:
- Azure Data Lakes
- Azure Active Directory (AAD)
- Azure-Sicherheitsgruppen
- AWS Data Lakes
- AWS Identity and Access Management
- AWS Directory Service
- DataBricks
- Integriert sich sowohl in Azure-IAM als auch in AWS-IAM
- Snowflake
- Kompatibel mit verschiedenen OAuth-, Multi-Faktor-Authentifizierung (MFA), Single-Sign-On (SSO) und föderierter Authentifizierung
Nachdem ein Benutzer zur Verbindung mit dem Data Lake autorisiert wurde, müssen wir die Dauer der für Benutzer erlaubten Verbindung festlegen. Die meisten Data Lakes sollten eine standardmäßige Sitzungszeitüberschreitung anwenden, die an die üblichen Unternehmensrichtlinien angepasst werden kann. Sicherheitsteams müssen jedoch mit den Datenwissenschaftlern zusammenarbeiten, um sicherzustellen, dass Konten nicht mitten in langen Datenbankabfragen wegen einer Zeitüberschreitung beendet werden.
Beim Zugriff auf die Daten selbst arbeiten die meisten Data Lakes mit einer Art Hierarchie, die grob der traditionellen IT-Infrastruktur entspricht.
Einige Data Lakes (Azure usw.) legen Rohdaten in Ordnern ab und sichern die Ordner so, wie man Ordner auf einem gemeinsam genutzten Server sichern würde. Ordner können bestimmten Benutzergruppen, Projekten oder sogar einzelnen Benutzern zugewiesen werden. Unterordner können entweder die Rechte des übergeordneten Ordners übernehmen oder mit eigenen Rechten versehen werden.
Die zugewiesenen Rechte können vollständiges Lesen, Schreiben, Kopieren und Abfragen umfassen oder eingeschränkt sein (nur Lesen usw.). Sicherheitsteams müssen überprüfen, wie ihre konkrete Data-Lake-Implementierung mit zusätzlichen untergeordneten Ordnern umgeht, um die Rechte des übergeordneten Ordners und die Vererbung für Benutzer sicherzustellen.
Andere Tools (Snowflake usw.) verwenden eine Kombination aus Discretionary Access Control (DAC) und rollenbasierter Zugriffskontrolle (RBAC), um ähnliche Rechte bereitzustellen, allerdings basierend auf bestimmten Objekten (Warehouse, Datenbank usw.) statt auf Ordnern. In beiden Fällen müssen Benutzer sorgfältig Gruppen oder Rollen zugewiesen werden, damit sie die entsprechenden Rechte erhalten.
Einige Tools stellen Inhabern von Hauptkonten viele verschiedene vordefinierte Rollen und Beschränkungen bereit. Beispielsweise unterstützt jede Richtlinie im Data Lake von Google nur 1.500 Principals, umfasst aber viele vordefinierte Rollen wie „Actions Admin“, „ApiGateway Viewer“ und „Monitoring Dashboard Configuration Editor“.
Bei der Integration in AD können diese Rechte von der zugrunde liegenden IT-Infrastruktur der Organisation übernommen werden. Sicherheitsteams müssen diese Rollen jedoch überprüfen, um sicherzustellen, dass:
- Rollen in AD korrekt übertragen wurden
- Benutzer den passenden Rollen angehören
- die passenden Rollen den richtigen Daten im Data Lake entsprechen.
Siehe die Top-Tools für die Active-Directory-Sicherheit
Verschlüsselung von Data Lakes
Was die Verschlüsselung betrifft, stellen die meisten Tools integrierte Verschlüsselungsschlüssel bereit. Viele lassen sich jedoch auch in verschiedene Schlüsselverwaltungstechnologien integrieren, damit eine Organisation die Verschlüsselungsschlüssel direkt kontrollieren kann.
Beispiele:
- Azure verwendet standardmäßig die Technologie Azure Key Vault
- Bei AWS Data Lakes ist standardmäßig AWS Key Management Services aktiviert
- Databricks lässt sich in Azure, AWS und die internen Schlüsselverwaltungsdienste des Kunden integrieren
- Snowflake generiert private Schlüssel und unterstützt die interne Schlüsselverwaltung des Kunden; erforderlich ist dabei ein RSA-Schlüsselpaar mit mindestens 2.048 Bit.
Die Verschlüsselung sollte auf Daten während der Übertragung, bei der Speicherung und auch auf Daten angewendet werden, die zum Laden bereitgestellt wurden.
Sicherheitsteams sollten überprüfen, ob die standardmäßig angewendete Verschlüsselung die Mindestanforderungen der Sicherheitsstandards der Organisation erfüllt. Einige Data Lakes erlauben außerdem die regelmäßige erneute Verschlüsselung verschlüsselter Daten. Sicherheitsteams, die dieses höhere Sicherheitsniveau einführen möchten, sollten prüfen, wie viel Zeit eine erneute Verschlüsselung in Anspruch nimmt und welche Kosten möglicherweise anfallen.
Lesen Sie auch: Laut Unternehmen lässt sich Datenabfluss durch Verschlüsselung während der Datennutzung verhindern
Übertragungssicherheit von Data Lakes
Wenn wir über Datenübertragung sprechen, denken wir in erster Linie an Netzwerke. Die meisten Data Lakes verwenden standardmäßig eine verschlüsselte Datenübertragung, doch Sicherheitsteams müssen noch einmal prüfen und verifizieren, dass die Verschlüsselung tatsächlich aktiviert ist.
Data Lakes sollten ihre Netzwerkexposition begrenzen, indem sie Verbindungen zum Data Lake über einzelne IP-Listen oder IP-Adressbereiche auf interne Netzwerke oder Netzwerk-Gateways beschränken (siehe oben: Isolation). Einige Data-Lake-Tools (z. B. Snowflake als Beispiel) erlauben die Anwendung von Netzwerkrichtlinien auf einzelne Benutzer, wobei diese Granularität bei großen Benutzer- und Anwendungszahlen möglicherweise nur schwer skalierbar aufrechtzuerhalten ist.
Bei Tools, die Verbindungen zu mehreren Cloud-Ressourcen herstellen (Databricks, Snowflake), müssen Netzwerkverantwortliche außerdem sicherstellen, dass die Verbindungen – selbst wenn sie automatisch durch die Anwendung hergestellt werden – korrekt konfiguriert sind. Möglicherweise gibt es auch manuelle private Netzwerkverbindungen (z. B. AWS PrivateLink usw.), für deren Herstellung, Absicherung und Wartung vollständig das Sicherheitsteam der Organisation verantwortlich ist.
Sicherheitsteams müssen beachten, dass nicht alle Tools standardmäßig verschlüsselte Kommunikation verwenden. Bei Microsoft Azure muss „Secure transfer required“ aktiviert sein, um unverschlüsselte HTTP- und SMB-Verbindungen zu blockieren.
Über diese Netzwerkverbindungen hinaus müssen Sicherheitsteams bei Data Lakes jedoch auch API-Verbindungen oder spezifische Abfrageverbindungen sowie die Metadaten oder Informationen zu Datenbankspalten berücksichtigen, die diese möglicherweise zurückgeben. Viele Tools verwenden zusätzliche Schnittstellenkontrollen, die weitere Sicherheitsfunktionen hinzufügen können. Oder die Tools selbst fungieren als Vermittler, die Daten empfangen und entlang der Abfragen weiterleiten, aber verhindern, dass der Anforderer direkt auf die Daten zugreift.
Bestimmte sensible Daten werden für Abfragen gespeichert und verfügbar gehalten, stehen aber nicht zur Anzeige bereit. Bestimmte Metadatenspalten können so festgelegt werden, dass sie verschleiert werden für bestimmte Datentypen oder Benutzerklassifizierungen, die die Ergebnisse sehen, wobei sensible Daten durch Sternchen ersetzt oder anderweitig verschlüsselt oder blockiert werden.
Die Übertragungssicherheit sollte auch für jedes mit dem Data Lake verbundene Tool gelten. Jedes Data-Lake-Tool verfügt über eigene spezifische Konnektoren, APIs und Treiber, die bestimmte Formatierungen, Konfigurationen und Verfahren für eine sichere Verbindung mit dem Data Lake erfordern.
Snowflake kategorisiert Verbindungen als Snowflake-Ecosystem-Tools, Snowflake-Partnerverbindungen, allgemeine Konfigurationen (Diagnosetools, Beschränkungen der Abfragetextgröße usw.), den SnowSQL-Befehlszeilenclient sowie weitere Verbindungen und Treiber für Python, Spark usw. Sicherheitsteams müssen die entsprechenden Verbindungen für ihre konkrete Data-Lake-Implementierung überprüfen und den Data Lake überwachen, um unbefugte Verbindungen zu verhindern.
Speicherkontrollen für Data Lakes
Die häufigste Sicherheitskontrolle für die Datenspeicherung ist die Verschlüsselung, die wir bereits behandelt haben. Solange die Daten ordnungsgemäß klassifiziert wurden, sollten die Zugriffskontrollen die meisten Zugriffsberechtigungen für gespeicherte Daten regeln.
Sicherheitsteams müssen jedoch auch prüfen, welche Arten von standardmäßigen Sicherheitsfunktionen im Data Lake vorhanden sind und welche möglicherweise aktiviert werden müssen. Microsoft Azure empfiehlt beispielsweise, Microsoft Defender für die Cloud zu aktivieren für alle Speicherkonten, um in den Data Lake geladene Malware zu erkennen und zu beseitigen.
Kritische Daten können üblicherweise für die Speicherung in unveränderlichen Daten bestimmt werden, wo sie nicht durch Benutzeraktionen im Data Lake geändert oder gelöscht werden können. Möglicherweise sind auch Optionen zum verzögerten Löschen verfügbar, die innerhalb eines bestimmten Zeitraums nach dem Löschen die Wiederherstellung von Containern oder Daten ermöglichen.
Daten können außerdem abhängig von ihrer Nutzung oder ihrem Alter automatisch zur Übertragung in einen kalten Speicher oder zur Löschung bestimmt werden. Datensicherheitsteams sollten mit Data-Governance-Teams zusammenarbeiten, um die Daten im Data Lake für unveränderliche Speicherung, verzögertes Löschen, kalte Speicherung und automatisierte Löschung ordnungsgemäß zu klassifizieren und zu aktivieren.
Zusammenarbeit erforderlich
Die Grundlagen der Data-Lake-Sicherheit bauen auf bewährten Grundprinzipien der IT-Sicherheit auf: Transparenz und Kontrolle. Wie bei jeder anderen IT-Infrastruktur können diese Grundlagen jedoch untergraben werden, wenn wir die Details der konkreten Implementierung ignorieren.
Data Lakes werden komplizierter, weil unsere IT-Sicherheitsteams direkter mit Fachleuten für Data Governance und Data Mining zusammenarbeiten müssen als bei vielen anderen Anwendungen. Wenn jedoch alle Beteiligten effektiv kommunizieren können, lassen sich Governance-Richtlinien implementieren, um die Daten innerhalb eines Data Lakes effektiv automatisch zu klassifizieren und zu sichern.