Voracity

Voracity ist ein moderner One-Stop-Shop für die schnelle Verwaltung und Nutzung von Unternehmensdaten. Es ist auch eine eigenständige ETL- und Datenlebenszyklus-Management-Plattform, die auch alle Formen von „Big Data“ verpackt, schützt und bereitstellt.

Voracity spart Geld für Software, Hardware und Beratungsressourcen und erweitert gleichzeitig Ihre Enterprise Information Management (EIM)-Fähigkeiten zur Unterstützung digitaler Geschäftsinitiativen - alles aus einer einzigen Eclipse-Sicht.

IRI Voracity bietet Analysefunktionen auf fünf verschiedene Arten, mit zwei weiteren geplanten Erweiterungen im Jahr 2019:

1. Eingebettete Berichte und Analysen – CoSort SortCL-Programme ermöglichen die Erstellung individueller Detail-, Summar- und Trendberichte in 2D-Formaten. Diese enthalten Quersummenberechnungen sowie Funktionen für Datenumwandlung, Neuabbildung, Maskierung und Formatierung. Die Berichte können deskriptiv sein oder durch unscharfe Logik, Standardabweichungen sowie statistische Analysen und lineare Regressionsgrafiken (mit Boost und BIRT) auch prädiktive Analysen liefern.

2. Integration mit BIRT in Eclipse – Zur Berichtszeit werden mit BIRT entworfene Diagramme und Grafiken mit "IRI Data Sources" gefüllt. Diese In-Memory-Übertragung von SortCL-Daten und Metadaten spart Zeit und Ressourcen, da die Daten außerhalb der BI-Schicht mit CoSort oder Hadoop verarbeitet werden.

3. Beschleunigte Datenvorbereitung für Drittanbieter-BI-Plattformen – Voracity optimiert die Visualisierungszeit für zehn verschiedene BI- und Analyseplattformen wie BOBJ, Cognos, Microstrategy, QlikView, Splunk, Spotfire, R und Tableau. Benchmarks zeigen, dass SortCL in vielen Fällen eine schnellere Vorverarbeitung als diese BI-Tools bietet.

4. Direkte Integration mit Splunk – Voracity kann Daten direkt an Splunk weiterleiten, um Analysen innerhalb der Splunk-Plattform zu ermöglichen.

5. Cloud-Dashboard-Integration mit DWDigest – Voracity kann interaktive Business-Intelligence-Dashboards bereitstellen, die in jedem Browser oder innerhalb der IRI Workbench GUI auf Eclipse-Basis genutzt werden können.

6. (Geplant) Streaming-Analysen mit JupiterOne – Voracity wird in der Lage sein, als Quelle für Kafka-Datenströme zu dienen oder Echtzeit-Sentiment-Analysen weiterzuverarbeiten.

7. Integration mit KNIME in der IRI Workbench – Voracity unterstützt Analysen mit der KNIME-Plattform, wodurch Machine Learning, Künstliche Intelligenz, neuronale Netze und Data Mining für Citizen Data Scientists zugänglicher werden.

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.

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.

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.

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

Beides! FieldShield und das SortCL-Programm von CoSort ermöglichen es, sowohl Flat Files als auch Datenbankspalten gleichzeitig mit einer oder mehreren feldspezifischen Sicherheitsfunktionen zu schützen. Diese IRI-Produkte können entweder große Datenmengen (statische Datenmaskierung) oder gezielt einzelne Werte (dynamische Datenmaskierung) über Filterbefehle oder angepasste gespeicherte Prozeduren schützen.

Natürlich bieten einige Datenbanken eine integrierte Spaltenverschlüsselung an. Doch diese kann aus mehreren Gründen umständlich oder eingeschränkt sein, beispielsweise:

• Wenn Sie mehrere Datenbanken, andere Quellen oder Daten in Bewegung (z. B. Flat Files) schützen müssen, reicht eine einzelne Plattform oder Methode oft nicht aus.
• Integrierte Verschlüsselungsbibliotheken von Datenbanken können zu langsam, teuer oder zu komplex in der Implementierung sein.
• Sie bieten oft nur eine einzige Verschlüsselungsmethode, die möglicherweise nicht den Sicherheitsanforderungen oder gewünschten Darstellungsformaten entspricht.
• Manchmal müssen Daten in der Datenbank unverschlüsselt bleiben, aber beim Import oder Export geschützt werden – insbesondere bei der Verarbeitung von Flat Files, die häufig als Zwischenformat genutzt werden.

Andere Verschlüsselungslösungen schützen ganze Dateien, Datenbanken, Festplatten oder Netzwerke, um sensible Daten in Bewegung zu sichern. Allerdings kann eine solche Ganzverschlüsselung zeitaufwendig sein und den Zugriff auf nicht-sensitive Daten verhindern, die weiterhin genutzt und verarbeitet werden müssen.

FieldShield und CoSorts SortCL können gezielt nur die Felder oder Spalten verschlüsseln (oder anderweitig schützen), die es wirklich benötigen. Dies geschieht innerhalb derselben Job-Skripte und I/O-Durchläufe, parallel zu Big-Data-Transformationen, Migrationen und Berichterstellung.

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.

Nachdem Sie personenbezogene Daten (PII) in der kostenlosen IRI Workbench IDE (auf Eclipse basierend) für FieldShield, Voracity usw. gefunden und klassifiziert haben, können Sie mit FieldShield oder anderen SortCL-kompatiblen Jobs spezifische Schutzfunktionen auf Feldebene festlegen – entweder ad hoc oder regelbasiert.

Diese statischen Datenmaskierungsfunktionen ermöglichen geschützte Ansichten sensibler Daten (z. B. Sozialversicherungs- oder Telefonnummern, Gehälter, medizinische Codes) in ODBC-verbundenen Datenbanktabellen und sequenziellen Dateien. Dafür stehen 14 verschiedene Techniken zur Verfügung, darunter:

• Feldfilterung (Entfernung)
• Zeichenkettenmanipulation oder Maskierung (Schwärzung)
• Generalisierung von Quasi-Identifikatoren
• Sichere Verschlüsselung und Entschlüsselung
• Reversible und nicht reversible Pseudonymisierung
• ASCII-De/Re-Identifizierung, Kodierung und Big Shifting

Durch die konsistente Anwendung dieser Methoden (z. B. basierend auf Datenklassen oder musterbasierten Spaltenregeln) bleibt die referenzielle Integrität erhalten.

Weitere Möglichkeiten zur Datenmaskierung und Wahrung der referenziellen Integrität in Voracity sind:

• Der integrierte Database-Subsetting-Assistent, der auch Maskierungsfunktionen unterstützt
• Die Generierung synthetischer Testdaten mit dem IRI RowGen DB-Testdaten-Job-Assistenten

Weitere Informationen finden Sie unter den hier angegebenen Links.

Ja. Mit Voracity können Sie personenbezogene Daten (PII) nicht nur verschleiern (z. B. durch Verschlüsselung oder Maskierung), sondern auch gezielt entfernen (schwärzen, auslassen oder löschen) oder randomisieren (durch Zufallsgenerierung oder Ersetzung mit zufälligen Werten).

Das Ergebnis kann in neue Tabellen mit derselben Struktur geschrieben werden, die in einem separaten Schema erstellt, aufgebaut und geladen werden. Dies kann direkt in der IRI Workbench erfolgen, die sowohl als plattformübergreifende Datenbankverwaltungsumgebung als auch als zentrale Plattform für IRI-Tools dient.

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.

Ja, zum Beispiel an Splunk, und zwar auf verschiedene Weise. Siehe Artikel wie diesen:

• Enthüllung der Geheimnisse der Datenprofilierung in Splunk
• Automatische Weiterleitung von Ziel- oder Protokolldaten in Splunk
• Licht in Dark Data mit Splunk ES bringen

Ja, und zwar in mehrfacher Hinsicht, z. B. durch Zugriffsberechtigungen auf Auftragsmetadaten, Datenquellen (und -ziele) und Entschlüsselungsschlüssel sowie durch differenzierte Zuweisung von Funktionen/Regeln für Datenklassen.

Da es keinen „Voracity“-, „FieldShield“- oder „CoSort“-Server an sich gibt, gibt es derzeit keine Möglichkeit, Benutzer zu konfigurieren. Benutzer werden durch ihre Anmeldung entweder an dem PC identifiziert, auf dem sie IRI Workbench ausführen, oder an dem Remote-Server, der den Auftrag ausführt (d.h. auf dem SortCL installiert ist). In beiden Fällen kontrolliert das Betriebssystem (OS) den Benutzer, nicht die IRI-Software.

Wenn es um das Lesen und Schreiben von Dateien geht, bestimmt das Betriebssystem, wer auf der Grundlage des Benutzers, unter dem die Auftragsskripte ausgeführt werden, Zugriff auf Dateien hat. Bei Datenbanken werden die Benutzerkennung und die Kennwörter oder andere Anmeldeinformationen in die JDBC- und ODBC-Verbindungszeichenfolgen eingegeben, die für die Verbindung mit der Datenbank verwendet werden.

Die Workbench-Artefakte im Arbeitsbereich können auch geschützt werden, wenn sie über ein Git- oder ein anderes Quellkontroll-Repository freigegeben werden. Auf diese Weise kann mit Passwörtern oder Verschlüsselungsschlüsseln kontrolliert werden, wer die Job-Skripte, Metadaten-Dateien, Set-Dateien und andere Assets im Workspace lesen und schreiben darf.

Dies ist ein anderes Paradigma als bei den meisten anderen ETL- und Maskierungsprodukten, bei denen alle Datenbankverbindungen auf einem zentralen Server verwaltet werden. Unsere Architektur ist zwar etwas gewöhnungsbedürftig, vor allem, wenn man von einer anderen Art von Tool kommt, aber wir sind der Meinung, dass sie viel mehr Flexibilität im Betrieb bietet.

Unser zukünftiges Plattform-Release sieht ein noch granulareres System der Benutzer- und Daten-Governance vor, das RBAC für bestimmte IRI-Jobs, Funktionen und Datenklassen unterstützt. IAM- und Protokollierungsrichtlinien werden in IRI Workbench konfiguriert und von der ausführbaren Laufzeitanwendung durchgesetzt, um sicherzustellen, dass die Berechtigung zur Ausführung des Auftrags wie angegeben mit den Governance-Richtlinien und den angegebenen Benutzergruppen übereinstimmt und/oder mit ActiveDirectory oder LDAP integriert ist.

Wie sieht es mit dem Zugriff auf Aktivitätsprotokolldaten für Audits und Berichte aus?

Ja. Im Kontext von IRI Voracity, CoSort, FACT, NextForm oder IRI FieldShield und RowGen können Daten und Metadaten über Rollen getrennt werden:

1. DBA-definierte Quell-/Zieldatenzugriffe (Konfigurationsdetails für die in verwaltbaren DSN-Dateien oder Workbench Data Connection Registry-Einstellungen gespeichert werden, die den auf Dateiebene (oder O/S-Login-Ebene) kontrollierten Zugriffsrechten für den Arbeitsbereich unterliegen)
2. Active Directory oder LDAP (O/S)- und/oder Repository (z.B. Git)-gesteuerter Zugriff auf Datendateien, Arbeitsbereiche, Projekte, Daten und Job-Metadaten, ausführbare Dateien, Protokolle usw. oder auf FieldShield- oder DarkShield-Verschlüsselungsschlüssel, die über einen Schlüsselmanager wie Azure Key Vault verwaltet werden.
3. Skript-integrierte IAM- (und letztendlich AD-kompatible) Richtlinien in IRI Workbench-Datenklassen für den Zugriff auf Skript-, Quell- und Feldebene und/oder ausführungs-/änderungsspezifische Berechtigungen (in Vorbereitung)
4. Kontrollen auf Projektebene für IRI-Assets in der Metadaten-integrierten DataSwitch-Plattform oder der API-integrierten Erwin Data Governance oder Plattform (Premium-Optionen).
5. Die neue operative IRI-Governance-Infrastruktur wird 2024 eingeführt und konzentriert sich zunächst auf das IRI-Backend-Datenverarbeitungsprogramm SortCL, das eine zentrale Kontrolldatei verwendet, um Benutzer, Gruppen und Rollen für den Zugriff auf auftragsspezifische Attribute wie Datenquellen, Skripte und Protokolle zu definieren.

Durch Zugriffskontrollen auf Client-Computern oder ActiveDirectory/LDAP und Berechtigungen auf Dateiebene. Darüber hinaus kann entweder die erwin (AnalytiX DS)-Governance-Plattform oder ein beliebiges Eclipse-kompatibles SCCS wie Git für Metadaten-Assets - bei dem Berechtigungen nach Rollen konfigurierbar sind - bestimmte Projekte, Jobs und andere Metadaten-Assets sperren.

Ja, mehrere Rollen/Berechtigungen für IRI FieldShield oder Voracity (usw.) Metadaten-Assets (ddf, Job-Skripte, Flows) usw. können durch Systemadministratoren zugewiesen werden, die diesen Assets richtliniengesteuerte ActiveDirectory- oder LDAP-Objekte zuweisen. Weitere Optionen sind die erwin Data Governance Platform (Premium-Option) oder Eclipse Code Control Hubs wie Git; ein Beispiel finden Sie hier.

Der IRI Test Data Hub innerhalb des ValueLabs TDM-Portals unterstützt auch die Zuweisung und Löschung von Administrator- und Testerrollen. Der Administrator der höchsten Ebene kann auch Genehmigungsrechte für Sicherheitsrichtlinien an andere Administratoren delegieren. Solche Rollenberechtigungen werden auf sehr detaillierten Einzel- oder Gruppenebenen festgelegt, die die DB-Anmeldung, die Ausführungsberechtigung, den Datenzugriff und die Berechtigungen zur Abfrage/Berichterstattung/Wiederherstellung des Audit-Protokolls steuern.

Ja, im Kontext von IRI Voracity (für Profiling, ETL, DQ, MDM, BI, etc. ), CoSort (für Datentransformation), FieldShield (für PII-Erkennung und -Maskierung), NextForm (für Datenmigration, Remapping und Replikation) und RowGen (für TDM und Subsetting) kann der Zugriff auf bestimmte Datenquellen (und Ziele, bis hinunter zur Spaltenebene) durch vom DBA erteilte Berechtigungen oder Berechtigungen auf Dateiebene (verwaltet in DSN-Dateien und der IRI Workbench-Datenverbindungsregistrierung) sowie durch Offenbarungsberechtigungen auf Feldebene, die in (sicherbaren) Jobskripten und Entschlüsselungsschlüsseln gesteuert werden, kontrolliert werden.

Im Zusammenhang mit der optionalen proxy-basierten DDM SQL#-Anwendung für FieldShield können Einzel- und Gruppenrollen mit granular definierten Sicherheitsrichtlinien abgeglichen werden, die das Recht bestimmen, sich mit bestimmten DB-Instanzen zu verbinden, bestimmte SQL-Anweisungen auszuführen, Spalten dynamisch zu maskieren (oder nicht), usw.

Beides, da der Zugriff auf Daten, Metadaten und/oder Jobskripte - sowie die Ausführungserlaubnis - mit objektdefinierten ActiveDirectory-, DBA-Login- und/oder Dateisystem-Kontrollen verbunden ist, die auf einer Richtlinienbasis zu Authentifizierungszwecken auferlegt werden.

IRI bietet auch eine optionale proxy-basierte dynamische Datenmaskierung, die abgefragte Spaltenwerte gemäß spezifischer Richtlinien, die einzelne Benutzer, Benutzerrollen oder Benutzergruppen betreffen, unkenntlich machen kann.

Die aufrufenden Anwendungen können auch zusätzliche Ebenen der Benutzerauthentifizierung einführen, um optional eine Lücke zu schließen oder zusätzliche Datenkontaktpunkte zu schützen.