Home Discussions Questions & Answers Advanced VPD Implementation for Column-Level Restrictions

Advanced VPD Implementation for Column-Level Restrictions

Avatar photoCustomer November 19, 2019 at 11:03 am

Row-level security via VPD is clear, but we need to prevent unauthorized users (even developers running custom SQL via Blitz Report) from viewing specific columns containing Personally Identifiable Information (PII), while still allowing them access to other columns in the same table. How is column-level VPD technically implemented and enforced via Blitz Report?

Viewing 8 reply threads
  • Author
    Replies
    • Support November 19, 2019 at 3:42 pm  

      Blitz Report fully supports the use of standard Oracle Virtual Private Database (VPD) policies at both the row and column level. Column-level security is often implemented using a masking function or a mechanism that ensures the sensitive column returns a null or masked value for unauthorized users, even when queried via SQL.

    • Avatar photoCustomer November 20, 2019 at 3:10 am  

      If a developer constructs a complex SQL query joining multiple EBS tables in a Blitz Report, how does the database guarantee that the column-level policy is applied correctly without impacting the joins?

    • Support November 21, 2019 at 2:42 am  

      The application of the security policy occurs at the database dictionary level. When a user executes the Blitz Report query, the database dynamically rewrites the query or applies a function to the sensitive column. Because this security is enforced at the earliest stage of data retrieval, the policy is respected automatically, ensuring the unauthorized user receives masked data.

    • Avatar photoCustomer November 21, 2019 at 11:14 am  

      Does Blitz Report require any specific flags or security setup within its definition form to recognize and apply column-level VPD policies?

    • Support November 23, 2019 at 5:16 am  

      Blitz Report acts as the execution layer, passing the standard EBS user context to the database. Since the VPD policy is linked directly to the underlying table and the database user context, Blitz Report configuration simply needs to ensure the custom SQL targets the correct table. The security is then transparently enforced by Oracle itself.

    • Avatar photoCustomer November 25, 2019 at 7:44 am  

      We need to document this security capability as part of our data governance framework.

    • Support November 27, 2019 at 9:40 am  

      This capability is a core feature of the Blitz Report toolkit , allowing you to manage and protect sensitive data effectively. You can confidently state that access control at the data layer is achieved through standard Oracle VPD policies, compatible with Blitz Report’s flexible SQL execution model.

    • Avatar photoCustomer November 29, 2019 at 12:01 pm  

      If we decide to change the masking logic, will the change be instantly reflected in all Blitz Reports accessing that column?

    • Support November 29, 2019 at 3:14 pm  

      Yes, because the policy function is centralized in the database, changing the masking logic updates the restriction universally and immediately for every subsequent query accessing that secured column, regardless of whether it’s run via a form, a concurrent request, or a Blitz Report.

Viewing 8 reply threads
  • You must be logged in to reply to this post.

Login with: