Re: tough choices

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40dc9be3$0$18668$afc38c87_at_news.optusnet.com.au>...

> Right. Now, what about If the user is this sort of customer, he's allowed to
> look at those sorts of rows and columns, but if he's this other type of
> customer, he can see a different selection of rows and columns. And I want
> to test for his IP address as well as his username. And 12 other conditions
> as well. And I have other users of the table who aren't customers, but who
> access the same table, and should have a completely different sort of where
> clause applied. And I'm not entirely sure what the future may bring, but I
> suspect there will be even more, distinct, 'consumer groups' for this table
> in the future....

But how do you manage these security policies? By manage - I mean, how do you prove that they work correctly, that you haven't left any gaps, that the implemenation matches the requirements, etc, etc?

I've got an application that has implemented some very complex security policies like this in the application layer and it is a maintenance nightmare. They choose to do this in the application layer for a variety of reasons - including database portability (they support oracle, db2, sql server is coming). Anyhow, in my circumstance the vendor hasn't provided the maintenance tools to really manage this complexity. Being completely pragmatic here - does Oracle have a good grasp on this today? Can you easily determine in a proactive fashion:

• all the users & ip ranges that any given row can be accessed by?
• all the rows & columns that a given user can access? If not, are there tools coming out to help with this?

> Then there's the point I missed by I see others have made: If I can hack
> into your box, I can see all the rows of the table. If you can hack into
> mine, the FGAC policies still apply, and you can't see any more than you
> could by using the front-end application.

Well, only if you hack into the database with the right id. I haven't seen that happen personally, but yeah - it could happen. Tools like crystal reports aren't a hack of course, that's a deliberate part of the architecture. Of course, that brings up the other potential challenge with policies like these - can they be implemented as easily on the BI (data warehousing, data mart, olap) side as they are on the OLTP side? Or is the best practice implementation for those very high security apps that don't ever allow the data out of a single centralized repository?

buck Received on Fri Jun 25 2004 - 22:48:04 CDT