Beskyttelse af data i hvile og i bevægelse
Databaseapplikationer, der opdaterer og forespørger om tabeller, skal muligvis sikre data, der går ind i eller hentes fra disse tabeller. Følsomme data skal beskyttes på vej ind i bordet, en gang i bordet eller på vej ud. I alle tilfælde er målet at forhindre uautoriserede personer i at få adgang til bestemte rækker eller kolonneværdier, der anses for at være følsomme.
For normal form (strukturerede) data i relationsdatabaser kan IRI FieldShields selvstændige datamaskeringsværktøj eller dets kompatible bibliotek af opkaldbare maskeringsfunktioner rumme ovenstående scenarier, hvilket giver mange muligheder for både statisk (vedvarende, ved hvile) og dynamisk (i -transit) datamaskeringsmuligheder. Hvis du også har PII/PHI-værdier, der flyder tilfældigt inden for semi- og ustrukturerede RDB-kolonner (som tekst, C/BLOB, XML/JSON), kan du se denne artikel om IRI DarkShield-tilgangen.
Denne artikel vil imidlertid tale om FieldShield-muligheder, da de fleste RDB-brugere er optaget af at finde og maskere faste kolonneværdier. FieldShield-brugere kan klassificere, lokalisere og maskere data i DB-tabeller, og for applikationsbrugere kan de køre via:
- en statisk datamaskering på produktionstabeller og dynamisk afmaskning af autoriserede appbrugere
- maskeringsfunktioner indlejret i metadata-kompatible transformations-, rense- eller rapporteringsjob
- et proxy-baseret dynamisk dataredigeringssystem
- via et SDK API eller system opkald fra et program
- in-situ, via SQL-procedurer ved hjælp af et brugerdefineret bibliotek
Hvis dine data er i NoSQL-databaser som MongoDB, Cassandra, Elasticsearch eller MarkLogic, ville FieldShield håndtere strukturerede samlinger, mens DarkShield ville håndtere både strukturerede og ustrukturerede samlinger.
Som standard — og den måde, IRI Workbench GUI præsenterer FieldShield for slutbrugere og DBA'er — er en eller flere komplette tabeller typisk sikret med statiske datamaskeringsfunktioner (som kryptering, redaktion, pseudonymisering) i henhold til forretningsreglerne. Valget af hvert 'felt (kolonne) skjold' bør være baseret på sikkerhed, realisme, reversibilitet og måske CPU- eller lagerovervejelser.
Den statiske tilgang fungerer fint, når data er i ro. Enten kan kildetabellen beskyttes, eller der kan oprettes en ny måltabel eller fil med anvendte beskyttelser. Programmer, der henter de beskyttede data, behøver ikke være bekymrede over sikkerheden, fordi deres datakilder var forhåndsbeskyttede. FieldShield-programmer, der er designet til at beskytte data i hvile, kan også planlægges eller kaldes ind i batchjobs til regelmæssige opdateringer.
Men i et realtidsmiljø, hvor opdaterede rækker har brug for dynamisk beskyttelse, skal FieldShield-funktioner integreres i applikationens dataflow. Der er flere tilgange at overveje:
1) Dit program kalder FieldShield
Database og andre programmer, der henter fra eller sender nye eller ændrede data til tabeller, kan overføre dem til en FieldShield-kryptering, hashing, kodning eller redaktions-API-funktion i C, Java eller .NET. Du kan også overføre data i bevægelse til et selvstændigt FieldShield-program gennem en pipe- eller inputprocedure. Enhver af disse metoder kan udfylde mål med beskyttende (eller afsløre) funktioner på kolonneniveau.
2) FieldShield beskytter kun opdateringer
FieldShield-programmer kan også tilpasses via funktionerne /QUERY og /UPDATE, eller til kun at filtrere nye poster betinget, hvor rækkerne, der skal beskyttes, opfylder specifikke kriterier, som f.eks. API-kald ville give mulighed for endnu mere detaljeret forretningslogik og lette flere data-"hastigheds"- (eller latens-) betingelser — for eksempel mere datamaskering i realtid – fordi disse behov kan udtrykkes gennem applikationen og defineres af dens logik. Se dette PL/SQL-eksempel på realtidsmaskering baseret på en trigger.
3) Fang og beskyt deltaer i CoSort (FieldShield Parent)
Change data capture (CDC) jobs kan også programmeres i CoSorts Sort Control Language (SortCL), hvorefter kun udvalgte indsættelser, opdateringer, sletninger eller uændrede rækker kan overføres til tabeller eller filer med kolonnebeskyttelse anvendt, når dette sker. CoSort-brugere har alle FieldShield-beskyttelsesfunktioner til deres rådighed, så det er muligt kun at maskere ændrede data i dette bulkrapporteringsparadigme.
4) Proxy-baserede forespørgselsafskæringer
IRI leverer nu en speciel "JDBC SQL Trail"-driver, som applikationer kan bruge, og som filtrerer DB-forespørgsler for autoriserede brugere og bestemte tabeller og kolonner. De, der ikke er undtaget fra DDM-politikdefinitionen, vil kun se helt eller delvist redigerede værdier under flugten til den specielt tilsluttede applikation fra databasen, som forbliver umaskeret i hvile.
5) Brugerdefinerede integrationer
IRI kan arbejde sammen med din DBA eller applikationsprogrammør for at designe en skræddersyet løsning, der involverer elementer af ovenstående, eller for at give FieldShield-biblioteker, som dine SQL-procedurer kan påkalde in-situ som disse for at beskytte eller afsløre (kryptere eller dekryptere) forespørgsler resultater, forespørgselstabeller, materialiserede visninger og så videre.
Kontakt for at få hjælp til at integrere en dynamisk datamaskeringsfunktion som redaktion eller formatbevarende kryptering i din applikation.