Re: tough choices

> Did I miss anything?
> Cheers
> Serge

First and foremost - a security policy cannot be bypassed - its attached to the table. Think about is a constraint - not a lot of sense using views to define the constraint, at some stage somebody is going to update the table directly.

Then there is some refinement (this has been out in the market since Oracle8i, so it's had at least 3 major release revisions, and plenty of minor ones)

Secure Application Contexts - what the policy uses to make decisions (User name, time of day, IP address etc). Basically what the database understands to be significant about you. There is a series of defaults scraped from the client environment, and additional ones can be user defined, and there is no way to spoof them.

Multi Tier Proxies - a secure way to pass a user's identity etc through a middle tier without having to re-authenticate the user. So I don't need to give you my password - the database trusts you, you trust me, therefore the database trusts you telling it that its me.

Relevant Column Enforcement - I don't care if you select Larry's name, email, telephone number etc from the employee table , but if you do select salary, then I want to apply a policy that makes sure you are worthy to see it. Similarly - lets say you can see details about departments, but only total salary cost for your own department - you can still select salary, but it get masked for the departments you aren't allowed to see.

Then there is the whole audit side of the business. Audit policies based on who the user is, and what data they want to see etc. For instance, unlisted numbers aren't really unlisted. Operators have access to them, they are just not allowed to give them out. You simply cannot audit all operator access to all numbers - too may audit transactions. Instead you can say "Only audit access to Cameron Diaz's unlisted number". Then, if she has a stalker, the telephone company can prove that they didn't provide the number. This area is growing fast with HIPA, Sarbox etc. Received on Sat Jun 26 2004 - 19:40:27 CDT