Protecting Data at Rest and in Motion
Database applications that update and query tables may need to secure data going into, or being retrieved from, those tables. Sensitive data must be protected on the way into the table, once in the table, or on the way out. In every case, the goal is to keep unauthorized people from accessing certain rows or column values.
IRI FieldShield users can deploy the product or its library functions in several ways to accommodate the scenarios above. FieldShield protections can be applied:
- in a job script run from the command line or Eclipse GUI
- within reporting or batch operations
- through a SDK API, or system, call from a program
- in-situ, via SQL procedures using a custom library
By default — and the way the IRI Workbench GUI presents FieldShield to end-users and DBAs — one or more full tables are typically secured with static data masking functions (like encryption, redaction, pseudonymization) according to the business rules. The choice of each ‘field shield’ should be based on security, realism, reversibility, and perhaps CPU or storage considerations.
The static approach works fine when data are at rest. Either the source table can be protected, or a new target table or file with protections applied can be created. Applications which fetch the protected data need not be concerned about security because their data sources were pre-protected. FieldShield programs designed to protect data at rest can also be scheduled or called into batch jobs for regular updates.
However, in a real-time environment where updated rows need dynamic protection, FieldShield functions must be integrated into the application’s data flow. There are several approaches to consider:
1) Your Program Calls FieldShield
Database and other programs which fetch from, or send new or changed data into, tables can pass it into a FieldShield encryption, hashing, encoding, or redaction API function in C, Java, or .NET. Or, it can pass the data in motion into a standalone FieldShield program through a pipe or input procedure. Either way can populate targets with column-level protect (or reveal) functions applied.
2) FieldShield Protects Only Updates
FieldShield programs can also be customized via /QUERY and /UPDATE functions, or to conditionally filter only new records, where the rows to be protected meet specific criteria, like newness. API calls would allows for even more granular business logic and facilitate more more data ‘velocity’ (or latency) conditions — for example, more real-time data masking — because those needs can be expressed through the application and defined by its logic.
3) Capture and Protect Deltas in CoSort (FieldShield Parent)
Change data capture (CDC) jobs can also be programmed in CoSort’s Sort Control Language (SortCL), whereupon only selected inserts, updates, deletes or unchanged rows can be passed to tables or files with column protections applied as this happens. CoSort users have all FieldShield protection functions at their disposal, so it is possible mask only changed data in this bulk reporting paradigm.
4) Custom Integrations
IRI can work with your DBA or application programmer to design a bespoke solution that involves elements of the above, or to provide FieldShield libraries your SQL procedures can invoke in-situ to protect or reveal (encrypt or decrypt) query results, query tables, materialized views, and so on.
Contact firstname.lastname@example.org for help integrating a dynamic data masking function like redaction or format preserving encryption into your application.