FieldShield
Leistungsstarke und kostengünstige Software zur Datenerkennung und -maskierung .Version: 6
Version: 6
In einer Zeit, in der Datenschutz und Compliance von höchster Bedeutung sind, bietet IRI FieldShield® eine umfassende Lösung für Unternehmen, die personenbezogene Daten (PII) in strukturierten und semi-strukturierten Quellen schützen müssen. Diese innovative Softwarelösung adressiert die wachsende Herausforderung, sensible Informationen zu erkennen, zu maskieren und zu sichern, unabhängig von der Datenmenge oder dem Format.
FieldShield zeichnet sich durch seine Vielseitigkeit und Effizienz aus. Es kann große Datenmengen auf bestehenden Systemen maskieren, ohne auf teure Infrastruktur wie Hadoop oder In-Memory-Datenbanken angewiesen zu sein. Zudem bietet es die Möglichkeit, das Risiko einer erneuten Identifizierung zu bewerten und Daten entsprechend zu verallgemeinern.
Ein Krankenversicherungsunternehmen verwendet FieldShield, um eine Tabelle mit Versicherungsansprüchen zu schützen, die 19 Spalten enthält, von denen 3 geschützte Gesundheitsinformationen (PHI) beinhalten. Mit FieldShield kann das Unternehmen den Namen pseudonymisieren, die Sozialversicherungsnummer maskieren und den medizinischen Abrechnungscode verschlüsseln, während die übrigen Daten unverändert bleiben. Dies ermöglicht eine gezielte Datensicherung bei gleichzeitiger Beibehaltung der Datennutzbarkeit für Analysen und Berichterstattung.
FieldShield, entwickelt aus dem bewährten Datenverarbeitungspaket IRI CoSort, bietet eine robuste und präzise Lösung für moderne Datenschutzanforderungen und unterstützt Unternehmen dabei, ihre sensiblen Daten effektiv zu schützen und gleichzeitig compliant zu bleiben.
Seit 1978 weltweit im B2B-Sektor anerkannt: Bei Großunternehmen, Banken, Versicherungen sowie Behörden im Einsatz!
Schnelle, sichere und kosteneffiziente Datenverarbeitung: Für IT-Experten, die große und sensible Datenmengen effizient verarbeiten wollen!
Seit über 40 Jahren nutzen unsere Kunden weltweit aktiv unsere Software für Big Data Wrangling und Schutz! Dazu gehören NASA, American Airlines, Walt Disney, Comcast, Universal Music, Reuters, das Kraftfahrtbundesamt, das Bundeskriminalamt, die Bundesagentur für Arbeit, Rolex, Commerzbank, Lufthansa, Mercedes Benz, Osram,..
Sie finden eine Auswahl weltweiter Referenzen hier und eine Auswahl deutscher Referenzen hier:
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.
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:
Die Entscheidungskriterien dafür, welche Schutzfunktion für die einzelnen Daten zu verwenden ist, 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.
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:
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.
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.
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:
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:
Weitere Informationen finden Sie unter den hier angegebenen Links.
Ja. Mit FieldShield 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:
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:
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:
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.
Alle FieldShield- und CoSort/SortCL-Jobskripte und Funktionen auf Feldebene können in XML-Auditprotokollen aufgezeichnet werden, die Sie sichern und mit Ihrem bevorzugten XML-Berichtstool abfragen können. Sie können auch SortCL-Skripte (es werden Beispiele zur Verfügung gestellt, bei denen /INFILE=$path/auditlog.xml /PROCESS=XML usw.) gegen diese Audit-Protokolle für die Berichterstattung verwenden.
Kann ich neben den Such- und Audit-Berichten des IRI-Maskierungstools diese Informationen auch in ein SIEM exportieren?
Ja, zum Beispiel an Splunk, und zwar auf verschiedene Weise. Siehe Artikel wie diesen:
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:
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.
