Re: tough choices

From: Serge Rielau <srielau_at_ca.eye-be-em.com>
Date: Fri, 25 Jun 2004 04:48:51 -0400
Message-ID: <cbgou8$dmp$1@hanover.torolab.ibm.com>

Mark Townsend wrote:
> Ian wrote:
>

>>
>> Can you list the specific security features that are provided with the
>> base Oracle product that are missing from DB2 UDB for LUW?
>>

>
> I'm presuming DB2 has column encryption, roles, system and object
> privileges, GRANT/DENY privileges, basic auditing etc. So I think that
> leaves
>
> * Enterprise Users (password authenticated, requires an LDAP directory)
Don't know, can't comment, there's some stuff in Stinger. DB2 in general operates via user-exits in this space. Blair may know.

> * Schema Independent Users

Is that just what it says? DB2 UDB for LUW has only one connection between Schema and User: The default setting of the CURRENT SCHEMA register upon login. Users may not have the right to create schemata (including one with their own name) depending on the CREATE SCHEMA privilege.

> * Security Policies (policies attached to tables and views that
> determine what rows can be accessed based on information known about the
> user)

Can be handled with views. Let the DBMS do what the DBMS does best.
> * Secure Application Contexts (the afore mentioned user information,
> which cannot be spoofed)
> * Global Application Contexts (same again, this time shared across
> multiple connections)

Can't comment, don't know.
> * Relevant Column Enforcement (applies security policy only when query
> accesses named columns)

I get less rows if I refer to a protected column? Never heard of that requirement before...
> * Relevant Column Masking (all rows are returned, but relevant columns
> are masked (hidden) according to security policy)
Views, relying on join-elimination, unused column drop.
> * Partitioned Fine Grained Access Control (allows multiple security
> policies to be applied to the same table, information about the user
> determines which policy is applied)

Like security clearances? Views again...
> * Proxy Authentication - allows a user identity on a client to be
> securely proxied through a middle tier, without the need for the middle
> tier to know the users security credentials (password etc).
> * Audit Policies (similar to security polcies, in that they are specific
> to what the user trys to access, and that they fire an audit event)
Can't comment, don't know
> * Audit trails that include what data the user saw at the time they
> performed the operation (uses Flashback if the row has since been
> changed, deleted, etc)

Uhm... but flashback is only good for a short time, right? There is no guarantee the flashback is still available (?)
> * Administrator Audit Trails - an audit trail of what the DBA did that
> the DBA etc cannot see.
> * Proxied User Audit Trails - an audit trail that shows what a client
> did via a middle tier proxy.
>
> Last but not least, 10 independent security certifications (over
> multiple releases).

I'm not going to get into that one....
>
> Note that this is just the base EE product - the Advanced Security
> Option, and Label Security, extends this list of features (and
> certifications) even further.

IMHO a lot of the finegrained access control part tastes like syntacic sugar.
Complexity gets shifted from a view definition to the table DDL (it's got to be modeled somewhere).
How does Oracle enforce? Hooks in runtime (like procedure calls) or "implicit views"? The first would be unfortunate since it would takes the optimizer out of the picture, cardinalities get messed up, join choices taken away.

See "Group- and row-level security" example below: http://www-106.ibm.com/developerworks/db2/library/techarticle/0210rielau/0210rielau.html#section4

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

Received on Fri Jun 25 2004 - 03:48:51 CDT