Oracle 12c Security Transparent Sensitive Data Protection Tutorial

What is Oracle 12c Transparent Sensitive Data Protection?

Transparent Sensitive Data Protection (a 12c new feature) leverages the Virtual Private Database facility (available since release 8i) and the the Data Redaction facility (introduced in release 12.1.)  TSPD eases the process of implementing and managing either VPD or Redaction.

This tutorial will go through the old way of doing things with VPD: it was always a mission to set up, and because it operates at the row selection stage, sometimes hard to tune. Then we’ll look at Data Redaction: in some ways simpler than VPD, and because it operates at column projection stage, possibly better performing.

Everything discussed is Enterprise Edition, but no need to licence any additional options.

Presented by Oracle Certified Master John Watson, SkillBuilders’ Director of Oracle Database Services.

Limited Time Complimentary eBook, Securing Oracle Database 12c

Are you an Oracle DBA who wants to protect your databases? Register now for the complimentary eBook and learn about Oracle Database Security from the experts who brought you the #1 database in the world.

This free training is segmented into several separate lessons:

  1. Oracle 12c Security Tutorial Introduction (1:58)
  2. Oracle 12c Security Tutorial-Agenda (4:38)
  3. Review Oracle Virtual Private Database (12:29)
  4. Oracle Virtual Private Database FAQ (4:48) (click on video below)
  5. Oracle12c Data Redaction (6:52)
  6. Oracle12c Data Redaction FAQ (1:11)
  7. Oracle 12c Transparent Sensitive Data Protection TSDP (9:51)
  8. Oracle 12c Security Tutorial Summary (1:41)

Date: Sep 18, 2013

NOTE: Some corporate firewalls will not allow videos hosted by YouTube.


Oracle Virtual Private Database FAQ

Oracle Database 12c Security 


Session 4 – Oracle Virtual Private Database FAQ




>> Dave:  What about parsing – is SQL with the predicate reusable?




>> John:  It is. This was a major problem with the earlier releases. Back with 8i the workload of parsing and not merely the parsing workload, also the workload of evaluating the function was appalling. But with the current release, if the policy is defined correctly, we can eliminate any workload. 


It’s really defining policies as static or defining the policy type as being sensitive to variations in context, variations in session. So, yes, there can be dreadful performance issues parsing and false evaluation, but there are ways around them if it’s done correctly.




>> Dave:  Great. Thank you. How about connection pooling? How does it work with connection pooling?




>> John:  You need to use global context. The context I’m going to is just a local context. My predicate, as we see up here, is going to use RAM and that is variable stored in the PGA. That’s useless for connection pooling because then you might have hundreds in application server-users sharing one session and, of course, all the same session user. 


I don’t have time to demonstrate it now but the keyword is “global context” – a global context that you set up variables in the SGA typically maintained by the application server. Then we can apply different predicates to different users as they come in through the application server on the sequel by sequel basis. In effect, the one persistent database session will generate different predicates for every sequel it hits it.




>> Dave:  John, there’s a great contribution in the chat. I’ll read it to you. You’ve mentioned that you’ve seen CBO performance issues, but perhaps you can speak to one comment about it’s not always transparent. Let me read. 


“Our experience with VPD isn’t the dynamically added predicates could cause CBO performance issues and it is not always transparent what is happening. Have you experienced this?”




>> John:  Yes, I have. When it first came in with 8i, I had dreadful performance issues as did virtually everybody. With the later releases, major upgrade from 10g, I believe there will probably workarounds for most of the performance issues. One should be able to design the functions in such a way that it will be if not deterministic at least deterministic within the confines of one application server session. And if one can do that, then one can solve the performance issues. 


To go back to the questioner, yes, I have seen those issues. I’m not surprised you’ve seen those issues. I do believe they can usually be fixed, but that comes on something I was going to say later on that I’ll mention now. Setting up VPD it can be a mission to set up. It is not easy and that I believe is one reason why data redaction may well become very popular.




>> Dave:  You might have shown it John in your demo – I was doing some chatting. Is it possible to see the altered query, the underlying query? Is there a technique for that?




>> John:  There is no technique to see the actual underlying query but what you can do is go to the view. 




If you look at all the VPD policy 




then to join column. Joining that column to the statement to the row of [4:18 inaudible] sequel will let you identify the predicate that was appended. You have to write code to do that to identify your sequel joined there that’s the predicate. There’s no view that’s going to show you the modified code.


>> Dave:  But there’s the knowledge that the students need in order to find the appended predicate.




>> John:  Yes. Good question.


>> Dave:  Very good. Thank you very much.


Copyright 2017

Free Online Registration Required

The tutorial session you want to view requires your registering with us.

It’s fast and easy, and totally FREE.

And best of all, once you are registered, you’ll also have access to all the other 100’s of FREE Video Tutorials we offer!