DarkShield

Dies variiert je nach Anwendungsfall, aber soweit RDB-Quellen oder -Ziele involviert sind, werden DBA-Kenntnisse während der Einführung bevorzugt, zusammen mit Wissen über Datenstrukturen und -quellen.

CDO/CISO oder Data Governance/Sicherheitsinteressenvertreter sollten auch an der Definition (Klassifizierung) der sensiblen Datentypen und der auf die Datenklassen anzuwendenden Maskierungsfunktionen (Regeln) beteiligt sein.

Datenwissenschaftler wären hilfreich bei ML/AI-Aspekten im Zusammenhang mit dem Einsatz des DarkShield NER-Modells. BI-/Analytik-Architekten, die mit bestehenden Visualisierungsplattformen vertraut sind, sind hilfreich, um anonymisierte Ausgabedaten, PII-Suchberichte und Betriebsprotokolle für Erkenntnisse und Maßnahmen zu nutzen.

Vertrautheit mit Eclipse, Git, 4GL/3GL (für die API-Nutzung) sowie relevanten Cloud-Verbindungen wäre auch für Produktionsanwender ein gutes Know-how.

TDM-Architekten können auch bei der Definition/Konfiguration sowie bei der Bereitstellung von maskierten, subsettierten oder synthetisierten Daten von Nutzen sein.

Das hängt von Ihren Datenquellen, Zielen und bis zu einem gewissen Grad von der Art der benötigten Funktionalität ab. Es sind zusätzlich weitere Funktionen für das Datenbank-Subsetting und die synthetische Testdatengenerierung vorhanden.

Durch die konsistente Anwendung derselben Maskierungsfunktion auf denselben Klartext, jedes Mal automatisch und global. Dies geschieht durch Regeln, die mit mustergleichen Spaltennamen verknüpft sind, oder, noch zuverlässiger, durch integrierte Datenklassen, die an identifizierte Daten gebunden sind. Klassifizierte Daten werden durch robuste integrierte Wertesuchmethoden wie RegEx-Musterübereinstimmungen mit benutzerdefinierten Genauigkeitsschwellenwerten, Nachschlagewertübereinstimmungen, Fuzzy-Match-Algorithmen, benannte Entitäts- und Gesichtserkennungsmodelle oder JSON/XML/CSV/DB-Pfad-(Spalten-)Filter entdeckt/geprüft. Beachten Sie, dass alle IRI Shield-Produkte - FieldShield, DarkShield und CellShield EE - dieselben Datenklassen und deterministischen Maskierungsfunktionen nutzen, um die Konsistenz und damit die Daten- und Referenzintegrität nach der Maskierung in Ihren strukturierten, halbstrukturierten und unstrukturierten Unternehmensquellen zu gewährleisten.

Die integrierte Datenklassifizierungsfunktionalität von IRI macht außerdem formell definierte Primär- und Fremdschlüssel bei der Erstellung von Datenbankschemata überflüssig. Dies unterstützt die Datenintegrität in relationalen Datenbanken ohne Einschränkungen genauso wie in Dateien, Dokumenten und Bildern.

Die Stellen, an denen Einschränkungen definiert werden müssen, um die referentielle Integrität in künstlich erzeugten RDB-Testdaten automatisch zu unterstützen, befinden sich in den IRI-Assistenten für die DB-Subsetierung und die DB-Testdatensynthese. Wenn diese Einschränkungen nicht definiert sind, ist es zwar immer noch möglich, Testdaten für DBs zu subsetten und zu synthetisieren, aber es sind mehr manuelle Eingriffe erforderlich.

Richtig, da es mehr Anwendungsfälle und Aufrufmethoden gibt, als wir derzeit veröffentlichen können. Es gibt jedoch einige Demo-Videos, die auf unserer Seite zum Selbstlernen im Abschnitt zu den unstrukturierten Quellen verlinkt sind (scrollen Sie nach unten). Und wir können spezifische Lösungen über https://www.iri.com/products/live-demo demonstrieren.

Ja, über einen externen Befehlszeilenaufruf (CLI), der in diesem Dokument mit Beispielen beschrieben wird. DarkShield verfügt auch über eine RPC-API, die über Webanfragen von einem benutzerdefinierten Aufrufprogramm genutzt werden kann.

Die Techniken, die Ihren geschäftlichen Anforderungen gerecht werden. In IRI FieldShield (oder dem Programm SortCL in IRI CoSort) können Sie jede dieser Techniken auf einer Feld-/Spaltenbasis anwenden:

• Verschlüsselung
• Maskierung
• Hashing
• Pseudonymisierung
• Zufallsgenerierung
• De-ID
• Ausdruckslogik (Berechnung/Funktion)
• Teilstring- und Byteverschiebung
• Datentyp-KonvertierungBenutzerdefinierte Funktion

Die Entscheidungskriterien dafür, welche Schutzfunktion für die einzelnen Daten zu verwenden ist, sind:

1. Sicherheit - wie stark (unknackbar) muss die Funktion sein
2. Umkehrbarkeit - ob das, was verborgen wurde, später wieder aufgedeckt werden muss
3. Leistung - wie viel Rechenaufwand ist mit dem Algorithmus verbunden?
4. Erscheinungsbild - ob die Daten nach dem Schutz ihr ursprüngliches Format behalten müssen
   IRI hilft Ihnen gerne bei der Beurteilung, welche Funktionen für Ihre Daten am besten geeignet sind.

Beachten Sie auch, dass Sie ein oder mehrere Felder mit denselben oder unterschiedlichen Funktionen schützen können oder einen oder mehrere Datensätze ganz schützen können („wholerec“). In jedem Fall können die Bedingungskriterien und die Ziel-/Layout-Parameter ebenfalls angepasst und mit der Datenumwandlung und der Berichterstellung im selben Auftrag kombiniert werden. Und in zweckmäßigen Assistenten für mehrere Tabellen oder durch globale Datenklassifizierung können DBAs und Datenverwalter diese Schutzmaßnahmen als Regeln anwenden, um Konsistenz und referenzielle Integrität datenbank- oder unternehmensweit zu wahren.

Für MongoDB bieten FieldShield und DarkShield verschiedene Möglichkeiten zur Identifikation und Maskierung sensibler Daten, je nach Anwendungsfall. DarkShield kann beide Szenarien abdecken.

Falls die Daten in den Collections vollständig strukturiert sind:

1. CSV-Export & Import mit FieldShield
2. Einsatz von CData O/JDBC-Treibern mit FieldShield
3. Verwendung des IRI BSON-Treibers mit FieldShield

Falls die Collections auch semi-strukturierte (JSON) oder unstrukturierte Daten (Dokumente, Bilder, Freitext usw.) enthalten:

4. Maskierung über die DarkShield-GUI
5. Nutzung der DarkShield-API

1️⃣ Breitere Verschlüsselungs- und Maskierungsoptionen
TDE bietet nur AES- und 3DES-Verschlüsselung für MS SQL-Datenbanken. IRI bietet zusätzliche Verschlüsselungs- und Maskierungsfunktionen für zahlreiche Quellen, darunter relationale und NoSQL-Datenbanken, Legacy-Dateien (z. B. COBOL), JSON, XML, Office-Dokumente, PDFs, Bilder und mehr – sowohl On-Premise als auch in der Cloud.

2️⃣ Flexiblere Verschlüsselungsstrategie
TDE verschlüsselt gesamte Datenbanken und ist nicht auf Spaltenebene anwendbar. IRI erlaubt feld-, zeilen- und wertbasierte Maskierung sowie spaltenübergreifende Regeln zur Wahrung der referenziellen Integrität, einschließlich formatbewahrender Verschlüsselung.

3️⃣ Bessere Sicherheit gegen SQL-Injection und Angriffe
Da TDE direkt mit SQL verknüpft ist, kann ein Angriff die gesamte Datenbank entschlüsseln. IRI maskiert spezifische Spalten statisch mit individuellen Maskierungsregeln, wodurch SQL-basierte Angriffe keine vollständige Rückentschlüsselung ermöglichen.

4️⃣ Effizientere Performance
TDE erfordert die Verschlüsselung jeder einzelnen Datenbankseite, was ressourcenintensiv ist. IRI-Verschlüsselung und Maskierung arbeiten auf Feldebene mit hoher I/O-Geschwindigkeit und minimalem Rechenaufwand, einschließlich inkrementeller Maskierung für geänderte Datensätze.

5️⃣ Flexible Schlüsselverwaltung
TDE benötigt Azure Key Vault (EKM) zur Verwaltung von Schlüsseln. IRI unterstützt dies ebenfalls, bietet aber zusätzlich lokale Speicherung oder die Nutzung von Townsend Alliance Key Manager als Alternative.

6️⃣ Interoperabilität mit anderen Systemen
TDE ist nicht direkt mit anderen Metadaten-Systemen verbunden. IRI FieldShield integriert sich in ETL, CDC, Datenbank-Subsetting, Datenmigration und mehr und unterstützt MIMB, erwin und BI-Tools für eine nahtlose Zusammenarbeit.

7️⃣ Erweiterte PII-Schutzmechanismen
TDE bietet keine integrierte PII-Klassifikation, Re-Identifizierungsrisiko-Scoring oder Audit-Trails. IRI FieldShield und DarkShield beinhalten diese Funktionen und bieten zudem Kompatibilität mit SIEM-Lösungen wie Splunk ES.

8️⃣ Optimiert für Testdatenmanagement
TDE ist nicht für DevOps-Testdatenbereitstellungssysteme optimiert. IRI FieldShield und RowGen integrieren sich nahtlos in Testdaten-Hubs, Webservices und containerisierte MS SQL-Umgebungen (z. B. Actifio, Commvault, Windocks).

IRI FieldShield und Voracity bieten umfassende Funktionen zur Erkennung, Maskierung und Teilung sensibler Daten, die über die Möglichkeiten des Oracle Data Masking & Subsetting Pack hinausgehen. Während Oracle auf vordefinierte Maskierungsmuster und integrierte Funktionen für relationale Datenbanken setzt, erweitert IRI seine Lösung durch eine Eclipse-basierte Benutzeroberfläche mit umfangreichen Profiling-, Such- und Klassifizierungsfunktionen für strukturierte und unstrukturierte Daten.

IRI FieldShield ermöglicht eine flexible Anpassung von Maskierungsregeln auf verschiedene Datenquellen, einschließlich NoSQL-, Cloud- und Big-Data-Umgebungen. Zudem bietet es eine größere Auswahl an statischen und dynamischen Maskierungsfunktionen sowie die Möglichkeit, eigene Funktionen zu definieren. Durch die Integration mit Voracity können Maskierungsaufgaben nahtlos mit Datenintegration, -migration und -transformation kombiniert werden.

Die Subsetting-Funktionen von IRI bieten eine automatische Erstellung referenziell korrekter Teilmengen, die individuell anpassbar sind. Zudem ist eine sichere Maskierung und Subsetting über mehrere Datenquellen hinweg möglich, ohne den Produktionsbetrieb zu beeinträchtigen.

IRI hebt sich insbesondere durch zusätzliche Funktionen hervor, darunter erweiterte PII-Suche in unstrukturierten Daten, automatisierte Klassifizierungs- und Maskierungsfunktionen, API-gestützte dynamische Maskierung sowie eine Vielzahl von Integrationen mit ETL-, BI- und Big-Data-Tools. Damit bietet IRI eine leistungsfähige, vielseitige und zukunftssichere Alternative zu Oracle.

Beides, wobei das Maskieren von Quelle zu Ziel häufiger genutzt wird. Für In-Place-Masking kann einfach die Quelle als Ziel angegeben werden.

Wir empfehlen, dies erst nach einer erfolgreichen Überprüfung des Outputs (z. B. anhand einer kleinen Testdatei oder stdout) durchzuführen, um sicherzustellen, dass das Ergebnis den gewünschten Anforderungen in Bezug auf Format, Darstellung und Funktionalität (z. B. Reversibilität durch Entschlüsselung) entspricht – insbesondere, wenn keine Sicherungskopie vorhanden ist.

In den IRI-Datenmaskierungsprodukten wie FieldShield, CellShield und DarkShield bedeutet Pseudonymisierung das Ersetzen (Substituieren) einer Identität durch eine andere. Je nach Anwendungsfall können diese Werte konsistent und reproduzierbar sein, einige davon reversibel oder wiederherstellbar, während andere zufällig bleiben.

Alle IRI-Pseudonymisierungstechniken basieren auf der Nutzung einer Ersatzwert-Datei. Falls die Ersatzwerte konsistent sein sollen, muss diese Datei zwei durch ein Tabulatorzeichen getrennte Spalten enthalten. Diese sogenannten Lookup-Set-Dateien (Crosswalks) gewährleisten eine eindeutige Zuordnung zwischen Original- und Ersatzwerten.

Die Anforderungen an eine Lookup-Set-Datei sind einfach:

• Jeder mögliche Wert aus dem ungeschützten Datensatz (Spalte) muss in der linken Spalte der Lookup-Datei enthalten sein.
• Jeder linke Wert muss durch ein Tab gefolgt sein von einem eindeutigen Ersatzwert.
• Die Lookup-Datei muss nach den Werten der linken Spalte sortiert sein.

In einigen Fällen kann die Anwendung die Set-Dateien basierend auf den vorhandenen Daten und einer optionalen Liste möglicher Ersatzwerte automatisch erstellen. Dies ist jedoch nicht möglich, wenn die Pseudonymisierung über eine generische Regel angewendet wird. Lookup-Sets für konsistente Ersetzungen können nur direkt über den Feldeinstellungen-Editor erstellt werden, wenn eine einzelne Maskierungsaufgabe erstellt oder bearbeitet wird.

Sind die eindeutigen Werte des Quelldatensatzes bekannt, gibt es zwei Möglichkeiten, die Ersatzwerte bereitzustellen:

1. Der Benutzer stellt eine Datei mit Ersatzwerten bereit.
2. Die Originalwerte aus der Quelle werden ausgelesen und dann gemischt (Shuffling), um sie als Ersatzwerte zu verwenden.

Bei kleinen Datensätzen ist es oft sinnvoller, eine separate Datei mit Ersatzwerten bereitzustellen. Für große Datensätze kann es hingegen ausreichend sein, eine zufällig gemischte Version der Originalwerte als Ersatz zu verwenden – besonders bei großen Mengen von Werten wie Namen, Straßen oder Städten.

Da die Anzahl möglicher Werte begrenzt ist, spielt es nicht zwingend eine Rolle, ob die Ersatznamen aus einer separaten Liste oder aus den Originaldaten durch Shuffling stammen. Beispielsweise werden in beiden Fällen gängige Vornamen wie „Peter“ oder „Paul“ in den Ersatzwerten enthalten sein.

Die Pseudonymisierung kann sowohl als Regel für eine gesamte Datenklasse als auch individuell pro Feld definiert werden. Die feldspezifischen Einstellungen lassen sich über den Feldeigenschaften-Editor oder das Kontextmenü eines Feldes im Skript-Editor anpassen.

Ja, gleichzeitig. Tatsächlich kann das IRI CoSort-Produkt (über das SortCL-Programm) oder die IRI Voracity (Big Data) Management-Plattform (über SortCL oder austauschbare Hadoop-Engines) auf Feldebene Sicherheit durchsetzen, während Datenintegrations-, Datenqualitäts- und Reporting-Aufgaben ausgeführt werden. Mit anderen Worten, Sie können im gleichen Produkt, Programm und I/O-Durchgang: maskieren/redigieren, verschlüsseln, pseudonymisieren oder anderweitig PII-Werte (personenbezogene Daten) anonymisieren, während Sie die Daten aus heterogenen Datenquellen transformieren, bereinigen und anderweitig neu zuordnen und umformatieren.

Legacy-ETL- und BI-Tools können dies nicht so effizient oder kostengünstig tun. Tatsächlich können Sie in Voracity – das Datenentdeckung, Integration, Migration, Governance und Analyse unterstützt und konsolidiert – Daten gleichzeitig verarbeiten (integrieren, bereinigen usw.), schützen (maskieren) und präsentieren (berichten/analyzieren) oder vorbereiten (mischen/umwandeln/verarbeiten).

Alternativ können Sie IRI-Datenmaskierungsprogramme auf statischen Datenquellen ausführen (oder unsere API-Funktionen dynamisch aufrufen), um nur bestimmte Felder zu schützen, die Ihre bestehende Plattform dann transformieren oder visualisieren wird. Auf diese Weise können Sie:

• Ihren bestehenden Code verwenden
• Nur die Felder schützen, die Sicherheit benötigen
• Sowohl geschützte als auch ungeschützte Daten den Routinen und Systemen zur Verfügung stellen, die darauf zugreifen müssen.

Es gibt mehrere Methoden, aber beginnen Sie mit der neuesten, die in diesem Artikel beschrieben wird: PII-Maskierung in MongoDB und Cassandra

FieldShield, CellShield und DarkShield (sowie CoSort) und damit Voracity werden mit mehreren 128- und 256-Bit-Verschlüsselungsbibliotheken ausgeliefert, die bewährte, konforme 3DES-, AES-, GPG- und OpenSSL-Algorithmen verwenden. Für jedes PII-Element oder jeden Teilstring können Sie die gleiche oder eine andere integrierte Verschlüsselungsroutine verwenden oder eine Verknüpfung zu Ihrer eigenen Verschlüsselungsbibliothek herstellen und diese als benutzerdefinierte Transformationsfunktion auf Feldebene in einem Jobskript angeben. Sie können auch denselben Algorithmus bzw. dieselben Algorithmen und einen anderen Verschlüsselungsschlüssel für jedes Feld verwenden.

Die Verwaltung von Verschlüsselungsschlüsseln wird durch Passphrasen in Jobskripten, sicheren Dateien und Umgebungsvariablen sowie in Drittanbieter-Tresoren wie Azure Key Vault und Townsend Alliance Key Manager unterstützt.