Subject Re: [firebird-support] Protecting data from end users
Author Alexey Kovyazin
Hello Richard,

>We have figured out to how protect sales data from being altered. The
problem I am left with is how to protect a row from being deleted.
> (firstly, have come to the conclusion that it impossible to fully
protect data, however the idea here is just make it a bit harder and
scare people off)

Actually you need audit solution. Both SYSDBA role and trigger to outer
database are "kids tricks" which can be easily cracked and bypassed by
experienced user who has access to the database file (and reads
firebird-support :)).

If you need reliable audit solution you should consider integration with
some external tool like our FBScanner, which works as a proxy and can
store all data and events like unsuccessful login attempts to the
external Firebird [or other database engines] or text files, with
necessary data encryption.
It's possible to built-in additional plugin for FBScanner to encrypt
data exchange or perform additional secure "handshake" with client
application in order to prevent "bypass" attempts, and with ISV
subscription licensing even deployment at hundred of terminals will have
the flat price.
Feel free to contact me directly and ask any questions.

Regards,
Alexey Kovyazin
IBSurgeon (www.ib-aid.com)

> Hi, I need a way of logging or protecting data from being deleted by a
> user.
>
> I work for a POS (point of sale) company, each user "shop" would have
> a local firebird db running. We are entering into a new market where
> regulation states we have to protect our system from tax evasion
> (where possible)
>
> We have figured out to how protect sales data from being altered. The
> problem I am left with is how to protect a row from being deleted.
> (firstly, have come to the conclusion that it impossible to fully
> protect data, however the idea here is just make it a bit harder and
> scare people off)
>
> The two method I have thought of is
> a) Using roles and remove the delete privilege (we currently just
> using SYSDBA, which is probably a bit bad anyway)
> or
> b) Add some kind of trigger logging to keep this deleted data and copy
> to another db.
>
> Just wanted to know if anyone else had any other ideas or been in a
> similar situation.
>
> PS at the moment using FB 2.0, however planning on upgrading our
> clients to FB 2.5. I have been looking at the trace logging in FB2.5
> but don't see that usefull for this problem
>
> Thanks in advance
> Richard
>
>



[Non-text portions of this message have been removed]