* Dearman, Rick <[EMAIL PROTECTED]> [1245 05:45]:
> I have a requirement from my security manager but I can't seem to find a good
> solution.
> So I wondered if someone had done something similar.
>
> We have a web portal and a DB in PostgreSQL (obviously) which contains user
> data.
> The portal is accessed by account managers who have access to only specific
> user accounts.
> This all works fine however the concern is that if you ever got access more
> directly
> into the DB through a hack, or poorly designed site code,
> you could potentially access information that you shouldn't.
>
> So the idea is that he is floating is we create a cache DB between the portal
> and the
> main DB which will only keep the information currently being worked on by the
> person logged in,
If I was you, I'd have major concerns and have a chat with the manager in
question.
How is that going to help anything - surely the cache DB would have to do a
query to populate itself anyway, which you have to check to gain any security
benefit?
You're in a similar boat for updates.
If you're going to check the queries it makes somehow, just do those checks on
the queries
you get in the first place.
This sounds like a pain in the arse to implement, maintain and debug with no
benefits.
Far better to spend that time cleaning up your application code and
implementing a decent backup
policy.
--
'A little rudeness and disrespect can elevate a meaningless interaction
into a battle of wills and add drama to an otherwise dull day.'
-- Calvin discovers Usenet
Rasputin :: Jack of All Trades - Master of Nuns
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
