Re: "Write once-Read many" table ?
From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 05 Mar 2008 04:59:54 -0800
Message-ID: <1204721992.477069@bubbleator.drizzle.com>
>
> But isn't that the problem: isn't it trivial to reverse the process,
> given DBA SYS and root SA access and another machine. You can wind up
> with two cd's - which one is lying? For that matter, how do you know
> the original data file is really gone? Aren't there going to be pre-
> RO backups? And what about all these newfangled flashback and replay
> features?
>
> I think Niall and Dan are both right, the important points are
> auditing and legal proof. Somewhere a long time ago I saw a
> presentation that stated you have to have a remote secure worm to
> really get trustable auditing.
>
> jg
> --
> @home.com is bogus.
> http://books.google.com/books?id=wuNImmQufGsC
Date: Wed, 05 Mar 2008 04:59:54 -0800
Message-ID: <1204721992.477069@bubbleator.drizzle.com>
joel garry wrote:
> On Mar 4, 11:36 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
> wrote:
>> jm.scheiwi..._at_gmail.com wrote: >>> On Feb 28, 2:46 pm, Mladen Gogala <mgog..._at_yahoo.com> wrote: >>>> On Thu, 28 Feb 2008 03:17:19 -0800, jm.scheiwiler wrote: >>>>>> You have to trust your DBA. That's the bottom line. >>>>>> --http://mgogala.freehostia.com >>>>> The thing is, I am the dba. >>>>> I trust myself but that's not enough >>>> So, who else, besides you, can do grants & revokes? >>>> -- >>>> Mladen Gogalahttp://mgogala.freehostia.com >>> In fact, business management want to be sure that a line inserted will >>> never be changed, by anyone. >>> They would like a feature to ensure that. >>> Something that would be guaranteed by construction in the database, >>> guaranteed by oracle ... >>> I ask the question on their behalf. >>> Thanks >> Create a tablespace (e.g. "jms") with an associated (new!) datafile. >> Create your table (e.g. "ro_table") in tablespace "jms". >> Put tablespace "jms" in read-only mode. >> Burn a copy of the datafile onto a good-quality >> read-only media (e.g. WORM). >> Mount the read-only (WORM?) device >> Tell Oracle the datafile has been moved. >> Drop the original datafile. >> >> Unless you reverse the process, and mount a new copy, >> changes are impossible. Costs a whole lot less than >> Data Vault :) >>
>
> But isn't that the problem: isn't it trivial to reverse the process,
> given DBA SYS and root SA access and another machine. You can wind up
> with two cd's - which one is lying? For that matter, how do you know
> the original data file is really gone? Aren't there going to be pre-
> RO backups? And what about all these newfangled flashback and replay
> features?
>
> I think Niall and Dan are both right, the important points are
> auditing and legal proof. Somewhere a long time ago I saw a
> presentation that stated you have to have a remote secure worm to
> really get trustable auditing.
>
> jg
> --
> @home.com is bogus.
> http://books.google.com/books?id=wuNImmQufGsC
You are correct on all points: Especially about the remote secure worm: Preferably one at a location not under your control such as in your auditor's offices/data center.
Audit Vault isn't foolproof. But it would take a remarkably clever fool to beat it given it can simultaneously collect the data from AUD$, FGA, and REDO.
-- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan_at_x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.orgReceived on Wed Mar 05 2008 - 06:59:54 CST