Forum Stats

  • 3,770,713 Users
  • 2,253,156 Discussions


Redaction Policies on ODI Integration Tables

Christyxo Member Posts: 146 Silver Badge
edited Jul 21, 2020 5:13AM in Data Integrator

Hi all,

I have data being loaded to a staging table where the staging table has a number of redacted fields. The ODI user is exempt from this policy so it can see the data.

The data is being transformed and loading into a dimension table which is redacted on the same fields, and the ODI user is exempt from this policy as well.

Moving data from staging to dimension works without any issue.

My concern is that the integration tables are not redacted. The integration tables are isolated in a schema that others don't have access to, the integration tables are dropped on completion and on error, but I am dealing with a large volume of identifiable information, but I at least need to make sure that I have explored all options before I rule out any possibilities.

The options I have considered:

  • Avoid integration tables - easy enough to address, but performance is impacted when attempting to carry out the transformations in memory;
  • Use static integration tables with a redaction policy on these - achievable, but does limit the executions to serial over parallel since I'm loading from multiple sources;
  • Modify the knowledge module to add a redaction policy on table creation - Would require the ODI user having permissions to modify policies, and may be complex to incorporate in a knowledge module - also KM won't be supported which is a business concern.

I'm curious to know what your thoughts on the options above, or if you have an alternative approach.



Best Answer


  • XavierGrosfils
    XavierGrosfils Member Posts: 155 Blue Ribbon
    edited Jul 20, 2020 10:42AM

    If schema is well isolated, I don't see why adding complexity. As Oracle will state, Redaction is not intended to protect against attacks by privileged database users.

    Not sure the added security is worth the performance degradation.

    Mostly dependent of your organization standards and processes...

    Probably not usefull comment, but at least it's a comment

  • Christyxo
    Christyxo Member Posts: 146 Silver Badge
    edited Jul 20, 2020 4:18PM

    I agree with you, although I think holding customer data makes some overly cautious and this was my requirement.

    I do still need an answer to the question, but your input is definitely appreciated.