Denne artikel beskriver en dynamisk datamaskeringsmetode (DDM) tilgængelig for IRI FieldShield premium-websteder, der bruger et proxybaseret system til at opsnappe applikationsforespørgsler til JDBC-forbundne databaser. Det er en af flere tilgange til maskering af data under flyvning, som FieldShield-brugere kan overveje.
Andre IRI DDM-muligheder omfatter:API-kaldbare FieldShield-funktioner indlejret i C/C++/C#-, Java- eller .NET-programmer; Real-time FieldShield-funktioner indlejret i SQL-procedurer, der skaber maskerede visninger; og dynamisk afmaskering af statisk maskerede tabeller for autoriserede brugere.
Det proxy-baserede system, der introduceres her, bruger en databasespecifik "JDBC SQL Trail"-driver, der passer til formålet, i forbindelse med en konfigurations- og administrationswebapplikation kaldet SQL Sharp (SQL#). Dette diagram viser systemarkitekturen før og efter implementering:
Denne applikation understøtter i øjeblikket følgende relationelle databaseplatforme:
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
og kræver følgende tredjepartskomponenter:
- MS Windows 7,10 eller Server 2012 og nyere (testet).
- Java JDK og JRE 1.8 eller nyere.
- Tomcat 8.5 eller nyere for at køre SQL#-webserveren.
- En moderne webbrowser, såsom:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle eller PostgreSQL som lagerdatabasen, der skal lagres:
- SQL#-bruger- og gruppekonfiguration
- DB-adgang og aktivitetskontrol
- Dynamiske datamaskeringspolitikker
- SQL revisionslogfiler
Hvordan virker det?
I SQL#-webapplikationen opretter du datamaskeringspolitikker for at redigere kolonneværdier under flyvning for alle undtagen autoriserede brugere, der forbinder til databasen via JDBC SQL Trail-driveren. Du skal installere og konfigurere den driver for hver databaseinstans, du vil beskytte.
DDM-politikkerne definerer, hvilke tabeller og kolonner der skal maskeres, og hvordan de maskerede værdier vises. Når først systemet er korrekt konfigureret, vil alle forespørgsler forbundet via driveren være underlagt maskeringspolitikken.
Det er også muligt at definere politikker for at blokere brugere fra at logge på og visse SQL-aktiviteter. En komplet login- og SQL-aktivitetsrevisionslog er produceret og kan ses i SQL#.
Driveren skelner ikke mellem applikationsbrugere til blokering, maskering eller revisionsformål. Du kan dog autorisere specifikt navngivne brugere - at lave alternative applikationsserverforbindelser til DB'en gennem den samme driver - til at se data afsløret.
Oprettelse af en maskeringspolitik
For at oprette en maskeringspolitik i SQL# skal du bruge Masking Policy fanebladet SQL# Execute Management skærmen. Vælg + (Tilføj) ikonet til højre for Masking Rule List etiket.
Giv maskeringsreglen et navn og en valgfri beskrivelse. Du kan derefter vælge den type maske, der skal gælde fra Masing Regex: rullemenuen i Tilføj maskeringsregel dialog.
De første tre muligheder er foruddefinerede, mens Regex giver dig mulighed for at definere et brugerdefineret maskeringsformat. Klik på + (Tilføj) ikonet til højre for TABEN/COL etiket for at tilføje en eller flere tabel- og kolonnekombinationer for at angive, hvilke dataværdier der skal maskeres.
Når hver kombination af tabel og kolonner er blevet lavet, skal du klikke på Tilføj knappen i midten af dialogen for at placere dem på listen. Når du er færdig med at angive tabel- og kolonneplaceringer, skal du klikke på Tilføj knappen nederst for at tilføje placeringerne til Tilføj maskeringsregel dialog.
Klik til sidst på Gem nederst i Tilføj maskeringsregel dialog, når du er færdig med maskeringsreglen. På dette tidspunkt vil alle brugere, der er konfigureret til adgang til dataene, se maskerede værdier, når de opretter forbindelse via JDBC SQL Trail-proxydriveren.
For at tillade en bruger at se demaskerede data skal du tilføje dem til Umasked User List , som beskrevet nedenfor.
Tildeling af autorisation til brugere
Inden for den samme Masking Policy fanebladet SQL# Execute Management skærmen. Klik på + (Tilføj) ikonet til højre for Umasked User List etiket. Dette vil vise Søg bruger dialog, hvor du kan vælge en eller flere brugere, for hvem forespørgsler i de valgte kolonner og tabeller ikke vil blive maskeret.
Klik på Gem nederst i dialogen, når du er færdig med at vælge brugere.
Brug af SQL# og SQL Trail fra DB-applikationer
I dette eksempel vil vores databaseapplikation være IRI Workbench, Eclipse front-end jobdesignmiljøet til Voracity, FieldShield og andre IRI-softwareprodukter.
For at aktivere dine applikationer til SQL-kontrol og dynamisk datamaskering ved hjælp af SQL# proxy-serveren og JDBC SQL Trail-driveren, skal du aktivere SQL# gennem Tomcat og dens proxyserver. Du skal også konfigurere JDBC SQL Trail-driveren i IRI Workbench Data Source Explorer-visningen samt DDM-politikkerne i SQL# som beskrevet ovenfor.
Her er en visning af Oracle-forekomsten forbundet via JDBC SQL Trail-driveren.
Bemærk, at alle normale databaseoperationer og IRI-jobguider vil fortsætte med at arbejde via denne forbindelse. Det betyder også, at enhver uautoriseret aktivitet fra IRI Workbench vil blive blokeret, og alle SQL-kommandoer, der udstedes herfra til den tilsluttede database, vil blive registreret i SQL#-revisionsloggen.
Dette er en Workbench-forespørgsel på ORDERS-tabellen, der var policy-konfigureret til DDM i SQL#:
vs. den samme forespørgsel kørt af en autoriseret bruger, som viser de originale afmaskede data:
I mellemtiden tilbage i SQL#-applikationens logningssektion kan du se vores forespørgselspost:
fra IRI Workbench IP-adressen.