A Rule can match SQL based on a number of options, not the least of which is SQL text, but also the UserID, Program, Time of Day, IP Address of the origination.

If the criteria of the rule is matched, we apply an appropriate action. Action include rewrite, block, redirect to mention a few.

One of the simplest illustrations of this is an application sends in SELECT NAME, we rewrite the statement to SELECT SUBSTR(NAME,1,2)||’***’ which will take the name ‘Tiger’ and display it as “Ti***”. There are a variety of truncation, masking and scrambling algorithms available.

This has proven to work with any application, including in DWH environments that use a variety of tools, BO, OBIEE, Cognos, etc.
It also works with Dev Tools such as Toad, DBArtisan, PL/SQL, SQL*Plus and others.

Also we have implemented this in ERP/CRM applications where we do not have access to the source code.

The beauty of this solution is that the underlying data is not masked, but it is returned masked at the presentation layer. What this allow us to do is to use this in PRODUCTION as well.

We have different groups of Production DBA’s. Some are local employees and others are cross-border
contractors. Both groups use Toad and have SYSDBA. The local employees are permitted to see the real data, but rule identifies requests from the cross-border contractors and they do not get to see the real data when they are browsing. But if we do need to give access, then we can temporarily disable the rule for an hour and then turn the rule back on.