Part one.
Let’s be clear from the start, this isn’t going to be a suitable alternative if you have a compliance standard which you are required to comply with such as PCI DSS, or anything else that specifically calls for “tokenization”.
That being said, I have worked with more than a few organizations that are trying to expand the use of such solutions to protect PII across their enterprise and they are struggling to do so. The most common issues being complexity, performance impact in their application and the need to modify their applications to accommodate them.
I get it. Tokenization provides a very high level of protection for your data but if you can’t get it deployed for the reasons mentioned above, or some other reasons then how useful is it to you? Is there an alternative that doesn’t require changes to your applications, is designed to be used at scale, is a feature or option in the Oracle database and fully supported by Oracle?
Such an alternative is possible by combining Oracle’s Advanced Security Option (Transparent Data Encryption & Data Redaction) and Database Vault. Below is a RASCI matrix which will help understand the rest of this post.
| SELECT DATA | INSERT, UPDATE, DELETE DATA | MANAGE REDACTION POLICIES | MANAGE DATABASE VAULT REALMS | GRANT DATA ROLES | |
| DATA_FULL_READ | YES | NO | NO | NO | NO |
| DATA_READ_MASKED | YES | NO | NO | NO | NO |
| DATA_PARTIAL_READ | YES | NO | NO | NO | NO |
| DATA_FULL_WRITE | YES | YES | NO | NO | NO |
| DATA_WRITE_MASKED | YES | YES | NO | NO | NO |
| SECOPS | NO | NO | YES | YES | YES |
As can be seen, a solution is needed which can accommodate different levels of READ access and this access should be managed by a team – SECOPS – who can’t READ or WRITE data. As well as this, SYS and anyone with the DBA role should be prevented from managing this access in the database and should also be prevented from READ and WRITE access to the data.
To summarize how this will work, you have to start by using TDE to encrypt data at rest and preventing any out-of-band access to data from the OS layer or through backups/exports. When data is encrypted with TDE, anyone wishing to access data needs to be authenticated and should also have the right privileges to do so. Next you layer on Data Redaction with different roles to determine who can see data in clear text and how much of that data should be presented. Lastly, you use Database Vault to prevent SYS and DBA from accessing the data and also circumventing our desired access controls which were implemented by SECOPS team.
In part two of this post, I will provide sample code and configuration steps so you can see all of this working together.

Leave a comment