| Subject | Re: [IB-Architect] Journaling support? |
|---|---|
| Author | Jason Wharton |
| Post date | 2000-03-24T06:07:57Z |
Markus,
Keep in mind that this is in the context of quite large databases so keeping
numerous compressed copies of the GBK's around isn't even feasible...
updates, inserts, whatever to accomplish some malicious task. Thus, it
definitely is the DBA's job to sort out the mess and restore the data back
to the pre-attack state.
This becomes much easier if there is a way to have some granularity of
restoring to previous states and even being able to administratively
rollback to those previous states.
If the hacker did their thing at 10:00 AM and there was a backup of the
database at 12:00AM then 10 hours of data would need to be re-processed. If
the DBA had the ability to generate a freezepoint every hour then they could
administratively rollback through the freeze points until the hacker;s dirty
work was flushed out. Thus, at most 1 hour of work rather than 10 would be
lost. Plus, it would make it easier to determine when the hacker did their
thing. You wouldn't have to do full restores for one thing...
See previous posting for the ideas I have that would make InterBase able to
handle these situations.
Oh, and another thing, it would be totally cool if you could start up a
client transaction (read-only of course) that would allow you to query the
database as-of a previous freeze point. Then, it would be a piece of cake to
dig in and figure out where Mr. Hacker did their thing... At least to the
hour anyway...
FWIW,
Jason Wharton
InterBase Developer Initiative
jwharton@...
InterBase will be the database of the new millennium.
Keep in mind that this is in the context of quite large databases so keeping
numerous compressed copies of the GBK's around isn't even feasible...
>> 2. It doesn't help for situations where human errors or actsHuman error as in hacker gets access to the database and performs a bunch of
>> of malice force you to restore the database
>
>Human errors as in, whoops .. didn't mean to kick that power
>cord - yes. Malice force?? Not sure I'd agree that is the
>the responsibility of a database server. I believe that
>InterBase still has the ability to take advantage of UNIX
>user security. If I recall correctly, it bypasses the need
>to have an entry in the security database isc4.gdb.
updates, inserts, whatever to accomplish some malicious task. Thus, it
definitely is the DBA's job to sort out the mess and restore the data back
to the pre-attack state.
This becomes much easier if there is a way to have some granularity of
restoring to previous states and even being able to administratively
rollback to those previous states.
If the hacker did their thing at 10:00 AM and there was a backup of the
database at 12:00AM then 10 hours of data would need to be re-processed. If
the DBA had the ability to generate a freezepoint every hour then they could
administratively rollback through the freeze points until the hacker;s dirty
work was flushed out. Thus, at most 1 hour of work rather than 10 would be
lost. Plus, it would make it easier to determine when the hacker did their
thing. You wouldn't have to do full restores for one thing...
See previous posting for the ideas I have that would make InterBase able to
handle these situations.
Oh, and another thing, it would be totally cool if you could start up a
client transaction (read-only of course) that would allow you to query the
database as-of a previous freeze point. Then, it would be a piece of cake to
dig in and figure out where Mr. Hacker did their thing... At least to the
hour anyway...
FWIW,
Jason Wharton
InterBase Developer Initiative
jwharton@...
InterBase will be the database of the new millennium.