Protecting Production Passwords and Sensitive Data via Oracle VPD and Blitz Report
A significant internal security policy violation is posed by developers requiring access to production data for report debugging, forcing us to grant them high-privilege credentials or access to data using methods that expose sensitive information. Specifically, since many reporting tools inherently run using the APPS database user context, how can we enforce a security layer that strictly prevents unauthorized developers from viewing sensitive columns like salary data, even when debugging reports, thereby ensuring we are truly Protecting Production Passwords and Securing Sensitive Data during development phases?
7 replies
The most robust method for isolating data visibility is implementing Oracle VPD (Virtual Private Database). This database feature attaches security policies directly to tables, allowing the server to dynamically modify any incoming SQL query, restricting the rows or columns returned based on defined conditions.
The key is using Application Context within the VPD policy function. The policy function is modified to check `sys_context(‘userenv’,’module’)`. When Blitz Report runs, it sets a unique module name (e.g., ‘XXEN_REPORT – %’), allowing the policy to detect the report session and dynamically enforce restrictions, such as returning NULL for sensitive columns, regardless of the APPS user executing the query.
For a restricted user running a report against a column secured by VPD, the system will dynamically render the data in that column as NULL or mask it, even if the underlying query selected it. All other non-restricted columns remain visible, satisfying debugging needs while achieving granular security.
- You must be logged in to reply to this post.
Sign in with LinkedIn or Google to take part.