Skydda data i vila och i rörelse
Databasapplikationer som uppdaterar och frågar efter tabeller kan behöva säkra data som går in i eller hämtas från dessa tabeller. Känsliga data måste skyddas på väg in i tabellen, en gång i tabellen eller på väg ut. I alla fall är målet att hindra obehöriga från att komma åt vissa rader eller kolumnvärden som anses vara känsliga.
För normal form (strukturerad) data i relationsdatabaser kan IRI FieldShields fristående datamaskeringsverktyg eller dess kompatibla bibliotek med anropsbara maskeringsfunktioner rymma scenarierna ovan, vilket ger många alternativ för både statisk (beständig, i vila) och dynamisk (i -transit) alternativ för datamaskering. Om du också har PII/PHI-värden flytande slumpmässigt inom semi- och ostrukturerade RDB-kolumner (som text, C/BLOB, XML/JSON), se den här artikeln om IRI DarkShield-metoden.
Den här artikeln kommer dock att diskutera FieldShield-alternativ, eftersom de flesta RDB-användare är angelägna om att hitta och maskera fasta kolumnvärden. FieldShield-användare kan klassificera, lokalisera och maskera data i DB-tabeller och för applikationsanvändare, köra via:
- en statisk datamaskering på produktionstabeller och dynamisk demaskering av auktoriserade appanvändare
- maskeringsfunktioner inbäddade i metadatakompatibla transformerings-, rensnings- eller rapporteringsjobb
- ett proxybaserat dynamiskt dataredigeringssystem
- genom ett SDK API, eller system, anrop från ett program
- på plats, via SQL-procedurer med hjälp av ett anpassat bibliotek
Om din data finns i NoSQL-databaser som MongoDB, Cassandra, Elasticsearch eller MarkLogic, skulle FieldShield hantera strukturerade samlingar, medan DarkShield skulle hantera både strukturerade och ostrukturerade samlingar.
Som standard — och hur IRI Workbench GUI presenterar FieldShield för slutanvändare och DBA:er — är en eller flera fullständiga tabeller vanligtvis säkrade med statiska datamaskeringsfunktioner (som kryptering, redaktion, pseudonymisering) enligt affärsreglerna. Valet av varje "fält (kolumn) sköld" bör baseras på säkerhet, realism, reversibilitet och kanske CPU eller lagringsöverväganden.
Den statiska metoden fungerar bra när data är i vila. Antingen kan källtabellen skyddas, eller så kan en ny måltabell eller fil med tillämpade skydd skapas. Applikationer som hämtar den skyddade informationen behöver inte bry sig om säkerheten eftersom deras datakällor var förskyddade. FieldShield-program utformade för att skydda data i vila kan också schemaläggas eller anropas till batchjobb för regelbundna uppdateringar.
Men i en realtidsmiljö där uppdaterade rader behöver dynamiskt skydd måste FieldShield-funktioner integreras i applikationens dataflöde. Det finns flera tillvägagångssätt att överväga:
1) Ditt program anropar FieldShield
Databas och andra program som hämtar från eller skickar ny eller ändrad data till tabeller kan skicka den till en FieldShield-kryptering, hashning, kodning eller redigerings-API-funktion i C, Java eller .NET. Du kan också skicka data i rörelse till ett fristående FieldShield-program genom ett rör eller inmatningsförfarande. Vilken som helst av dessa metoder kan fylla i mål med skyddade (eller avslöja) funktioner på kolumnnivå.
2) FieldShield skyddar endast uppdateringar
FieldShield-program kan också anpassas via funktionerna /QUERY och /UPDATE, eller för att villkorligt filtrera endast nya poster, där raderna som ska skyddas uppfyller specifika kriterier, som nyhet. API-anrop skulle möjliggöra en ännu mer detaljerad affärslogik och underlätta mer datahastighets (eller latens) villkor — till exempel mer datamaskering i realtid – eftersom dessa behov kan uttryckas genom applikationen och definieras av dess logik. Se detta PL/SQL-exempel på realtidsmaskering baserat på en trigger.
3) Fånga och skydda delta i CoSort (FieldShield Parent)
Change data capture (CDC)-jobb kan också programmeras i CoSorts Sort Control Language (SortCL), varpå endast utvalda infogningar, uppdateringar, raderingar eller oförändrade rader kan skickas till tabeller eller filer med kolumnskydd tillämpat när detta händer. CoSort-användare har alla FieldShield-skyddsfunktioner till sitt förfogande, så det är möjligt att endast maskera ändrade data i detta bulkrapporteringsparadigm.
4) Proxybaserade frågeavlyssningar
IRI tillhandahåller nu en speciell "JDBC SQL Trail"-drivrutin för applikationer att använda som filtrerar DB-frågor för auktoriserade användare och särskilda tabeller och kolumner. De som inte är undantagna från DDM-policydefinitionen kommer endast att se helt eller delvis redigerade värden under flygning till den speciellt anslutna applikationen från databasen, som förblir demaskerad i vila.
5) Anpassade integrationer
IRI kan arbeta med din DBA eller applikationsprogrammerare för att designa en skräddarsydd lösning som involverar delar av ovanstående, eller för att tillhandahålla FieldShield-bibliotek som dina SQL-procedurer kan anropa på plats som dessa för att skydda eller avslöja (kryptera eller dekryptera) fråga resultat, frågetabeller, materialiserade vyer och så vidare.
Kontakta för hjälp med att integrera en dynamisk datamaskeringsfunktion som redaktion eller formatbevarande kryptering i din applikation.