Den här artikeln beskriver en dynamisk datamaskeringsmetod (DDM) som är tillgänglig för IRI FieldShield premiumsajter som använder ett proxybaserat system för att fånga upp applikationsfrågor till JDBC-anslutna databaser. Det är en av flera metoder för att maskera data under flygning som FieldShield-användare kan överväga.
Andra IRI DDM-alternativ inkluderar:API-anropbara FieldShield-funktioner inbäddade i C/C++/C#-, Java- eller .NET-program; FieldShield-funktioner i realtid inbäddade i SQL-procedurer som skapar maskerade vyer; och dynamisk avmaskering av statiskt maskerade tabeller för auktoriserade användare.
Det proxybaserade systemet som introduceras här använder en lämplig, databasspecifik "JDBC SQL Trail"-drivrutin i kombination med en webbapplikation för konfiguration och hantering som heter SQL Sharp (SQL#). Detta diagram visar systemarkitekturen före och efter implementering:
Denna applikation stöder för närvarande följande relationsdatabasplattformar:
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
och kräver följande tredjepartskomponenter:
- MS Windows 7,10 eller Server 2012 och senare (testad).
- Java JDK och JRE 1.8 eller senare.
- Tomcat 8.5 eller senare för att köra SQL#-webbservern.
- En modern webbläsare, som:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle eller PostgreSQL som arkivdatabasen att lagra:
- SQL# användar- och gruppkonfiguration
- DB-åtkomst- och aktivitetskontroller
- Dynamiska datamaskeringspolicyer
- SQL-granskningsloggar
Hur fungerar det?
Inom webbapplikationen SQL# skapar du datamaskeringspolicyer för att redigera kolumnvärden under flygning för alla utom behöriga användare som ansluter till databasen via JDBC SQL Trail-drivrutinen. Du måste installera och konfigurera den drivrutinen för varje databasinstans du vill skydda.
DDM-principerna definierar vilka tabeller och kolumner som ska maskeras och hur de maskerade värdena kommer att visas. När systemet är korrekt konfigurerat kommer alla frågor som är anslutna via drivrutinen att omfattas av maskeringspolicyn.
Det är också möjligt att definiera policyer för att blockera användare från att logga in och vissa SQL-aktiviteter. En fullständig inloggnings- och granskningslogg för SQL-aktivitet skapas och kan visas i SQL#.
Drivrutinen skiljer inte mellan programanvändare för blockering, maskering eller granskning. Du kan dock tillåta specifikt namngivna användare – att göra alternativa applikationsserveranslutningar till DB via samma drivrutin – att se data demaskerade.
Skapa en maskeringspolicy
För att skapa en maskeringspolicy i SQL#, använd Maskningspolicyn fliken SQL# Execute Management skärm. Välj + (Lägg till)-ikonen till höger om Maskeringsregellistan etikett.
Ge maskeringsregeln ett namn och en valfri beskrivning. Du kan sedan välja vilken typ av mask som ska tillämpas från Masing Regex: rullgardinsmenyn i Lägg till maskeringsregel dialog.
De tre första alternativen är fördefinierade, medan Regex låter dig definiera ett anpassat maskeringsformat. Klicka på + (Lägg till)-ikonen till höger om TAB/COL etikett för att lägga till en eller flera tabell- och kolumnkombinationer, för att ange vilka datavärden som ska maskeras.
När varje kombination av tabell och kolumner har skapats klickar du på Lägg till knappen i mitten av dialogrutan för att placera dem i listan. När du är klar med att ange tabell- och kolumnplatser klickar du på Lägg till knappen längst ned för att lägga till platserna i Lägg till maskeringsregel dialog.
Klicka slutligen på Spara längst ned i Lägg till maskeringsregel dialogrutan när du är klar med maskeringsregeln. Vid denna tidpunkt kommer alla användare som är konfigurerade för åtkomst till data att se maskerade värden när de ansluter via JDBC SQL Trail-proxydrivrutinen.
För att tillåta en användare att se omaskerade data måste du lägga till dem i listan över omaskerade användare , som beskrivs nedan.
Ge auktorisering till användare
Inom samma maskeringspolicy fliken SQL# Execute Management skärm. Klicka på + (Lägg till)-ikonen till höger om Avmaskerade användarlista märka. Detta visar Sökanvändare dialogruta där du kan välja en eller flera användare för vilka frågor i de valda kolumnerna och tabellerna inte kommer att maskeras.
Klicka på Spara längst ner i dialogrutan när du är klar med att välja användare.
Använda SQL# och SQL Trail från DB Applications
I det här exemplet kommer vår databasapplikation att vara IRI Workbench, Eclipse front-end jobbdesignmiljö för Voracity, FieldShield och andra IRI-programvaruprodukter.
För att aktivera dina applikationer för SQL-kontroll och dynamisk datamaskering med SQL#-proxyservern och JDBC SQL Trail-drivrutinen, måste du aktivera SQL# via Tomcat och dess proxyserver. Du måste också konfigurera JDBC SQL Trail-drivrutinen i vyn IRI Workbench Data Source Explorer, såväl som DDM-policyerna i SQL# enligt beskrivningen ovan.
Här är en vy av Oracle-instansen ansluten via JDBC SQL Trail-drivrutinen.
Observera att alla normala databasoperationer och IRI-jobbguider kommer att fortsätta att fungera via denna anslutning. Det betyder också att all obehörig aktivitet från IRI Workbench kommer att blockeras, och alla SQL-kommandon som utfärdas härifrån till den anslutna databasen kommer att registreras i SQL#-granskningsloggen.
Detta är en Workbench-fråga i ORDERS-tabellen som var policykonfigurerad för DDM i SQL#:
jämfört med samma fråga som körs av en auktoriserad användare, som visar de ursprungliga omaskerade data:
Under tiden tillbaka i SQL#-applikationens loggningssektion kan du se vår frågepost:
från IRI Workbench IP-adressen.