In dit artikel wordt een dynamische datamaskeringsmethode (DDM) beschreven die beschikbaar is voor premium IRI FieldShield-sites en die een op proxy gebaseerd systeem gebruikt voor het onderscheppen van applicatiequery's naar JDBC-gekoppelde databases. Het is een van de vele benaderingen voor het maskeren van gegevens tijdens de vlucht die FieldShield-gebruikers kunnen overwegen.
Andere IRI DDM-opties omvatten:API-aanroepbare FieldShield-functies ingebed in C/C++/C#-, Java- of .NET-programma's; realtime FieldShield-functies ingebed in SQL-procedures die gemaskeerde weergaven creëren; en, dynamisch ontmaskeren van statisch gemaskeerde tabellen voor geautoriseerde gebruikers.
Het op proxy gebaseerde systeem dat hier wordt geïntroduceerd, maakt gebruik van een voor dit doel geschikte, databasespecifieke "JDBC SQL Trail"-driver in combinatie met een configuratie- en beheerwebtoepassing genaamd SQL Sharp (SQL#). Dit diagram toont de systeemarchitectuur voor en na implementatie:
Deze applicatie ondersteunt momenteel de volgende relationele databaseplatforms:
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
en vereist de volgende componenten van derden:
- MS Windows 7,10 of Server 2012 en later (getest).
- Java JDK en JRE 1.8 of hoger.
- Tomcat 8.5 of hoger om de SQL#-webserver uit te voeren.
- Een moderne webbrowser, zoals:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle of PostgreSQL als de repository-database om op te slaan:
- SQL# gebruikers- en groepsconfiguratie
- DB-toegang en activiteitenbeheer
- Beleid voor dynamische gegevensmaskering
- SQL-controlelogboeken
Hoe werkt het?
Binnen de SQL#-webtoepassing maakt u beleid voor gegevensmaskering om kolomwaarden tijdens de vlucht te redigeren voor alle behalve geautoriseerde gebruikers die verbinding maken met de database via het JDBC SQL Trail-stuurprogramma. U moet dat stuurprogramma installeren en configureren voor elke database-instantie die u wilt beschermen.
Het DDM-beleid bepaalt welke tabellen en kolommen moeten worden gemaskeerd en hoe de gemaskeerde waarden worden weergegeven. Zodra het systeem correct is geconfigureerd, vallen alle query's die via het stuurprogramma zijn aangesloten, onder het maskeringsbeleid.
Het is ook mogelijk om beleid te definiëren om te voorkomen dat gebruikers inloggen en bepaalde SQL-activiteiten. Er wordt een volledige login en een auditlogboek voor SQL-activiteiten gemaakt, dat kan worden bekeken in SQL#.
Het stuurprogramma maakt geen onderscheid tussen toepassingsgebruikers voor blokkerings-, maskerings- of controledoeleinden. U kunt echter specifiek benoemde gebruikers - die alternatieve verbindingen met de applicatieserver maken met de DB via hetzelfde stuurprogramma - autoriseren om de ontmaskerde gegevens te zien.
Een maskerbeleid maken
Om een maskerbeleid in SQL# te maken, gebruikt u het Maskerbeleid tabblad van de SQL# Beheer uitvoeren scherm. Selecteer de + (Toevoegen) pictogram rechts van de Lijst met maskeringsregels label.
Geef de maskeerregel een naam en een optionele beschrijving. U kunt vervolgens het type masker kiezen dat van toepassing is uit de Masing Regex: vervolgkeuzelijst in de Makkingsregel toevoegen dialoog.
De eerste drie opties zijn vooraf gedefinieerd, terwijl u met de Regex een aangepast maskeringsformaat kunt definiëren. Klik op de + (Toevoegen) pictogram rechts van de TAB/COL label om een of meer tabel- en kolomcombinaties toe te voegen, om aan te geven welke gegevenswaarden worden gemaskeerd.
Nadat elke combinatie van tabel en kolommen is gemaakt, klikt u op de knop Toevoegen knop in het midden van het dialoogvenster om ze in de lijst te plaatsen. Wanneer u klaar bent met het specificeren van tabel- en kolomlocaties, klikt u op de knop Toevoegen knop onderaan om de locaties toe te voegen aan de Maskerregel toevoegen dialoog.
Klik ten slotte op Opslaan onderaan de Maskerregel toevoegen dialoogvenster wanneer u klaar bent met de maskeerregel. Op dit punt zullen alle gebruikers die zijn geconfigureerd voor toegang tot de gegevens gemaskeerde waarden zien wanneer ze verbinding maken via het JDBC SQL Trail-proxystuurprogramma.
Om een gebruiker toe te staan om niet-gemaskeerde gegevens te bekijken, moet u deze toevoegen aan de Lijst van niet-gemaskeerde gebruikers , zoals hieronder beschreven.
Autorisatie verlenen aan gebruikers
Binnen hetzelfde maskeringsbeleid tabblad van de SQL# Beheer uitvoeren scherm. Klik op de + (Toevoegen) pictogram rechts van de Lijst met ontmaskerde gebruikers label. Hierdoor wordt de Gebruiker zoeken . weergegeven dialoogvenster waarin u een of meer gebruikers kunt selecteren voor wie zoekopdrachten in de geselecteerde kolommen en tabellen niet worden gemaskeerd.
Klik op Opslaan onderaan het dialoogvenster wanneer u klaar bent met het selecteren van gebruikers.
SQL# en SQL Trail gebruiken vanuit DB Applications
In dit voorbeeld is onze databasetoepassing IRI Workbench, de Eclipse front-end jobontwerpomgeving voor Voracity, FieldShield en andere IRI-softwareproducten.
Om uw toepassingen SQL-controle en dynamische gegevensmaskering in te schakelen met behulp van de SQL#-proxyserver en het JDBC SQL Trail-stuurprogramma, moet u SQL# activeren via Tomcat en zijn proxyserver. U moet ook het JDBC SQL Trail-stuurprogramma configureren in de IRI Workbench Data Source Explorer-weergave, evenals het DDM-beleid in SQL# zoals hierboven beschreven.
Hier is een weergave van de Oracle-instantie die is verbonden via het JDBC SQL Trail-stuurprogramma.
Houd er rekening mee dat alle normale databasebewerkingen en IRI-taakwizards via deze verbinding blijven werken. Dat betekent ook dat alle ongeautoriseerde activiteiten van IRI Workbench worden geblokkeerd en dat alle SQL-opdrachten die van hieruit naar de verbonden database worden verzonden, worden vastgelegd in het SQL#-auditlogboek.
Dit is een Workbench-query op de ORDERS-tabel die door het beleid is geconfigureerd voor DDM in SQL#:
vs. dezelfde zoekopdracht uitgevoerd door een geautoriseerde gebruiker, die de originele ontmaskerde gegevens weergeeft:
Ondertussen, terug in de logboeksectie van de SQL#-toepassing, kunt u onze queryrecord zien:
van het IRI Workbench IP-adres.