Schutz von Daten im Ruhezustand und in Bewegung
Datenbankanwendungen, die Tabellen aktualisieren und abfragen, müssen möglicherweise Daten sichern, die in diese Tabellen eingehen oder aus diesen abgerufen werden. Sensible Daten müssen auf dem Weg in die Tabelle, einmal in der Tabelle oder auf dem Weg nach draußen geschützt werden. In jedem Fall besteht das Ziel darin, unbefugte Personen vom Zugriff auf bestimmte Zeilen- oder Spaltenwerte abzuhalten, die als vertraulich gelten.
Für (strukturierte) Normalformdaten in relationalen Datenbanken kann das eigenständige Datenmaskierungsdienstprogramm IRI FieldShield oder seine kompatible Bibliothek aufrufbarer Maskierungsfunktionen die oben genannten Szenarien berücksichtigen und bietet viele Optionen sowohl für statische (persistent, in Ruhe) als auch dynamische (in -transit) Datenmaskierungsoptionen. Wenn Sie auch PII/PHI-Werte haben, die zufällig in halb- und unstrukturierten RDB-Spalten (wie Text, C/BLOB, XML/JSON) schweben, lesen Sie diesen Artikel über den IRI DarkShield-Ansatz.
Dieser Artikel wird jedoch über FieldShield-Optionen sprechen, da die meisten RDB-Benutzer damit beschäftigt sind, feste Spaltenwerte zu finden und zu maskieren. FieldShield-Benutzer können Daten in DB-Tabellen klassifizieren, lokalisieren und maskieren und für Anwendungsbenutzer über:
ausführen- eine statische Datenmaskierung in Produktionstabellen und eine dynamische Demaskierung durch autorisierte App-Benutzer
- Maskierungsfunktionen, die in metadatenkompatible Transformations-, Bereinigungs- oder Berichtsjobs eingebettet sind
- ein Proxy-basiertes dynamisches Datenschwärzungssystem
- über eine SDK-API oder einen Systemaufruf von einem Programm
- in-situ, über SQL-Prozeduren unter Verwendung einer benutzerdefinierten Bibliothek
Wenn sich Ihre Daten in NoSQL-Datenbanken wie MongoDB, Cassandra, Elasticsearch oder MarkLogic befinden, würde FieldShield strukturierte Sammlungen verarbeiten, während DarkShield sowohl strukturierte als auch unstrukturierte Sammlungen verarbeiten würde.
Standardmäßig – und die Art und Weise, wie die IRI Workbench-GUI Endbenutzern und DBAs FieldShield präsentiert – werden eine oder mehrere vollständige Tabellen normalerweise mit statischen Datenmaskierungsfunktionen (wie Verschlüsselung, Schwärzung, Pseudonymisierung) gemäß den Geschäftsregeln gesichert. Die Wahl jedes „Feld-(Spalten-)Schildes“ sollte auf Sicherheit, Realitätsnähe, Umkehrbarkeit und möglicherweise CPU- oder Speicheraspekten basieren.
Der statische Ansatz funktioniert gut, wenn Daten ruhen. Entweder kann die Quelltabelle geschützt werden, oder es kann eine neue Zieltabelle oder -datei mit angewendeten Schutzmaßnahmen erstellt werden. Anwendungen, die die geschützten Daten abrufen, müssen sich keine Sorgen um die Sicherheit machen, da ihre Datenquellen vorab geschützt wurden. FieldShield-Programme, die zum Schutz ruhender Daten entwickelt wurden, können für regelmäßige Aktualisierungen auch geplant oder in Batch-Jobs aufgerufen werden.
In einer Echtzeitumgebung, in der aktualisierte Zeilen dynamischen Schutz benötigen, müssen FieldShield-Funktionen jedoch in den Datenfluss der Anwendung integriert werden. Es gibt mehrere zu berücksichtigende Ansätze:
1) Ihr Programm ruft FieldShield auf
Datenbanken und andere Programme, die neue oder geänderte Daten aus Tabellen abrufen oder an diese senden, können diese an eine FieldShield-API-Funktion für Verschlüsselung, Hashing, Codierung oder Schwärzung in C, Java oder .NET übergeben. Sie könnten die Daten in Bewegung auch über eine Pipe oder eine Eingabeprozedur an ein eigenständiges FieldShield-Programm übergeben. Jede dieser Methoden kann Ziele mit angewendeten Schutz- (oder Offenlegungs-)Funktionen auf Spaltenebene füllen.
2) FieldShield schützt nur Updates
FieldShield-Programme können auch über /QUERY- und /UPDATE-Funktionen angepasst werden oder nur neue Datensätze bedingt filtern, wenn die zu schützenden Zeilen bestimmte Kriterien wie Neuheit erfüllen. API-Aufrufe würden eine noch granularere Geschäftslogik ermöglichen und mehr Bedingungen für die „Geschwindigkeit“ (oder Latenz) von Daten ermöglichen – zum Beispiel mehr Echtzeit-Datenmaskierung – da diese Anforderungen durch die Anwendung ausgedrückt und durch ihre Logik definiert werden können. Sehen Sie sich dieses PL/SQL-Beispiel für Echtzeit-Maskierung basierend auf einem Trigger an.
3) Deltas in CoSort (übergeordnetes FieldShield) erfassen und schützen
Change Data Capture (CDC)-Jobs können auch in der Sort Control Language (SortCL) von CoSort programmiert werden, woraufhin nur ausgewählte Einfügungen, Aktualisierungen, Löschungen oder unveränderte Zeilen an Tabellen oder Dateien mit angewendetem Spaltenschutz übergeben werden können, wenn dies geschieht. CoSort-Benutzern stehen alle FieldShield-Schutzfunktionen zur Verfügung, sodass es möglich ist, nur geänderte Daten in diesem Massenberichtsparadigma zu maskieren.
4) Proxy-basierte Abfrage-Intercepts
IRI stellt jetzt einen speziellen „JDBC SQL Trail“-Treiber für Anwendungen zur Verfügung, der DB-Abfragen für autorisierte Benutzer und bestimmte Tabellen und Spalten filtert. Diejenigen, die nicht von der DDM-Richtliniendefinition ausgenommen sind, sehen nur vollständig oder teilweise unkenntlich gemachte Werte während der Übertragung zu dieser speziell verbundenen Anwendung aus der Datenbank, die im Ruhezustand unmaskiert bleibt.
5) Benutzerdefinierte Integrationen
IRI kann mit Ihrem DBA oder Anwendungsprogrammierer zusammenarbeiten, um eine maßgeschneiderte Lösung zu entwerfen, die Elemente der oben genannten enthält, oder um FieldShield-Bibliotheken bereitzustellen, die Ihre SQL-Prozeduren wie diese in-situ aufrufen können, um Abfragen zu schützen oder offenzulegen (zu verschlüsseln oder zu entschlüsseln). Ergebnisse, Abfragetabellen, materialisierte Ansichten usw.
Wenden Sie sich an uns, um Hilfe bei der Integration einer dynamischen Datenmaskierungsfunktion wie Schwärzung oder formaterhaltender Verschlüsselung in Ihre Anwendung zu erhalten.
