Idea ID 2802336
Add a configurable method to flag attributes as 'is-sensitive' at the driver/shim level before they enter the input or output flow. Currently this can be managed in policy by adding the setting to a given attribute at any point in the channel processing. The initial input of these attributes will still be visible in a level 3 trace before a policy can be applied. It also does not cover attributes that may be returned in response to out of band queries. This can result in sensitive information being made visible in the driver traces at any point. With the growing number of items that are considered sensitive for personal information (Social Insurance Number, Birth Date, etc.) there can be a need to add additional protection to data included in traces, besides the defaults of passwords and encrypted attributes. Having this type of configurable ability would also allow the option to flag octet type attributes, with long values variables, as sensitive to hide them from traces. This can clean up traces that currently have long strings of base-64 encoded data which usually is just a waste of file space.
Wondering if this could be implemented as an extension to the Driver Filter, by adding an option to identify attributes that are to be treated as sensitive, or maybe by adding a new resource object that lists the attributes to be flagged as sensitive. The driver would consume the configuration on startup and pass the information, after translation through the schema map, to a remote loader/driver shim to the connected system so that attributes from the connected application are also returned with the sensitive flag set as well. Maybe just an extension to the Schema Map to flag the selected mapped attributes as sensitive, could cover both vault and application.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.