Subject Re: Database Protection
Author sc_odo
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:
> At 10:09 PM 15/02/2005 +0000, you wrote:
>
>
>
> >My application is distributed among thousands of people, I want to
> >protect the access to the database against third tools.
> >I know that Firebird gives the protection system to the operating
> >system. In my case this is a problem because the customer is the
owner
> >of the operating system and then he can do anything.
> >I can change the password, etc... but this protection is not
efective
> >if you have administrator rights in your operating system because
you
> >can manipulate the FB.
> >
> >I do not want that the user see the data or stored procedures.
> >Is there a way or trick to protect the database against these
access?
>
> Yes and no. :-)
>
>
http://firebird.sourceforge.net/index.php?op=doc&s
ub=contrib&id=fb_meta_security
>
> ./hb
Hello,
at this very moment I'm facing the same problem, not only with
firebird but also with other dbms. Main problem, I think, ist that
user rights are managed outside of the database structure, metadata or
publically accessed tables with user names and passwords.
The article is nice to read, has just stolen a friendly smile out of
my face. "The solution: host all the databases yourself", my comment:
and get a good insurance that covers data losses and hacker intrusions
, but before earn a few million to buy the security equipment you need
in order to even get an insurance company to insure you.
OK, this sounds a little extreme, I know, but describes the problem
pretty well.
In my concern, there are two main points why I want to get database
structure and data unaccessable for the admins and anybody else. First
and most important is to prevent the data to be manipulated from
anywhere else but from my application. Users today are not to be
trusted. They manipulate data without knowing what they are doing, and
afterwords they make you responsible for damages without even telling
you that they manipulated the data.
OK, to prevent this, the article is right, one could encrypt the data
in such a way that the user can't identify the content of a record.
For the second problem, the protection of the database, I didn't find
any answer yet.
I have some ideas, but don't know yet if they would work.
One is to create two additional tables within the database, one
containing usernames and passwords, the other one containing some
functions that would be triggered as soon as any object of the
database is called. This way it would have to pass the function before
beeing able to view the structure and content.

I haven't tried any of this yet, but maybe some of you got any further
with this problem.

Best regards

Ralf