Bescherming van gegevens in rust en in beweging
Databasetoepassingen die tabellen bijwerken en opvragen, moeten mogelijk gegevens beveiligen die naar deze tabellen gaan of worden opgehaald. Gevoelige gegevens moeten worden beschermd op weg naar de tafel, eenmaal in de tafel of op weg naar buiten. In elk geval is het doel om te voorkomen dat onbevoegden toegang krijgen tot bepaalde rijen of kolomwaarden die als gevoelig worden beschouwd.
Voor normale (gestructureerde) gegevens in relationele databases kan het zelfstandige IRI FieldShield-hulpprogramma voor gegevensmaskering, of de compatibele bibliotheek met aanroepbare maskeringsfuncties, de bovenstaande scenario's accommoderen, met veel opties voor zowel statisch (persistent, in rust) als dynamisch (in -transit) opties voor gegevensmaskering. Als je ook PII/PHI-waarden hebt die willekeurig zweven binnen semi- en ongestructureerde RDB-kolommen (zoals tekst, C/BLOB, XML/JSON), bekijk dan dit artikel over de IRI DarkShield-aanpak.
Dit artikel gaat echter over FieldShield-opties, aangezien de meeste RDB-gebruikers zich bezighouden met het vinden en maskeren van vaste kolomwaarden. FieldShield-gebruikers kunnen gegevens classificeren, lokaliseren en maskeren in DB-tabellen, en voor toepassingsgebruikers uitvoeren via:
- een statische gegevensmaskering op productietabellen en dynamische ontmaskering door geautoriseerde app-gebruikers
- maskeringsfuncties ingebed in metadata-compatibele transformatie-, opschonings- of rapportagetaken
- een op proxy gebaseerd dynamisch gegevensredactiesysteem
- via een SDK API, of systeem, aanroep vanuit een programma
- in-situ, via SQL-procedures met behulp van een aangepaste bibliotheek
Als uw gegevens zich in NoSQL-databases zoals MongoDB, Cassandra, Elasticsearch of MarkLogic bevinden, zou FieldShield gestructureerde verzamelingen verwerken, terwijl DarkShield zowel gestructureerde als ongestructureerde verzamelingen zou verwerken.
Standaard - en de manier waarop de IRI Workbench GUI FieldShield presenteert aan eindgebruikers en DBA's - zijn een of meer volledige tabellen doorgaans beveiligd met statische gegevensmaskeringsfuncties (zoals codering, redactie, pseudonimisering) volgens de bedrijfsregels. De keuze van elk 'veld (kolom) schild' moet gebaseerd zijn op beveiliging, realisme, omkeerbaarheid en misschien CPU- of opslagoverwegingen.
De statische benadering werkt prima wanneer gegevens in rust zijn. Ofwel de brontabel kan worden beveiligd, of er kan een nieuwe doeltabel of bestand met toegepaste beveiligingen worden gemaakt. Toepassingen die de beschermde gegevens ophalen, hoeven zich geen zorgen te maken over de beveiliging, omdat hun gegevensbronnen vooraf waren beveiligd. FieldShield-programma's die zijn ontworpen om gegevens in rust te beschermen, kunnen ook worden gepland of in batchtaken worden aangeroepen voor regelmatige updates.
In een realtime omgeving waar bijgewerkte rijen dynamische bescherming nodig hebben, moeten FieldShield-functies echter worden geïntegreerd in de gegevensstroom van de toepassing. Er zijn verschillende benaderingen om te overwegen:
1) Uw programma roept FieldShield op
Database en andere programma's die gegevens ophalen uit of nieuwe of gewijzigde gegevens verzenden naar tabellen, kunnen deze doorgeven aan een FieldShield-coderings-, hash-, coderings- of redactie-API-functie in C, Java of .NET. U kunt de gegevens in beweging ook doorgeven aan een stand-alone FieldShield-programma via een pijp- of invoerprocedure. Elk van deze methoden kan doelen vullen met beveiligingsfuncties op kolomniveau (of onthullen).
2) FieldShield beschermt alleen updates
FieldShield-programma's kunnen ook worden aangepast via /QUERY- en /UPDATE-functies, of om voorwaardelijk alleen nieuwe records te filteren, waarbij de te beschermen rijen voldoen aan specifieke criteria, zoals nieuwheid. API-aanroepen zouden een nog gedetailleerdere bedrijfslogica mogelijk maken en meer gegevens 'snelheid' (of latentie) voorwaarden mogelijk maken - bijvoorbeeld meer realtime gegevensmaskering - omdat die behoeften via de applicatie kunnen worden uitgedrukt en door de logica ervan kunnen worden gedefinieerd. Bekijk dit PL/SQL-voorbeeld van realtime maskering op basis van een trigger.
3) Vang en bescherm Delta's in CoSort (FieldShield Parent)
CDC-taken (Change Data Capture) kunnen ook worden geprogrammeerd in CoSort's Sort Control Language (SortCL), waarna alleen geselecteerde invoegingen, updates, verwijderingen of ongewijzigde rijen kunnen worden doorgegeven aan tabellen of bestanden waarop kolombeveiliging is toegepast. CoSort-gebruikers hebben alle FieldShield-beveiligingsfuncties tot hun beschikking, dus het is mogelijk dat alleen gewijzigde gegevens worden gemaskeerd in dit paradigma voor bulkrapportage.
4) Op proxy gebaseerde query-onderscheppingen
IRI biedt nu een speciaal "JDBC SQL Trail"-stuurprogramma voor toepassingen dat DB-query's voor geautoriseerde gebruikers en bepaalde tabellen en kolommen filtert. Degenen die niet zijn vrijgesteld van de DDM-beleidsdefinitie, zien alleen volledig of gedeeltelijk geredigeerde waarden tijdens de vlucht naar die speciaal verbonden applicatie uit de database, die in rust ontmaskerd blijft.
5) Aangepaste integraties
IRI kan samenwerken met uw DBA of applicatieprogrammeur om een op maat gemaakte oplossing te ontwerpen die elementen van het bovenstaande omvat, of om FieldShield-bibliotheken te bieden die uw SQL-procedures in-situ kunnen aanroepen zoals deze om query's te beschermen of te onthullen (versleutelen of ontsleutelen) resultaten, querytabellen, gerealiseerde weergaven, enzovoort.
Neem contact op voor hulp bij het integreren van een functie voor dynamische gegevensmaskering, zoals redactie of formaatbehoud, encryptie in uw toepassing.