Subject | Database Security questions |
---|---|
Author | mspencewasunavailable |
Post date | 2006-09-17T00:08:38Z |
Our application is being converted from a stand-alone, desktop
database to Firebird. Our users (mostly small businesses) will be
running the application and FB together on their Windows system; in
some cases, even on their laptop.
We'd like to arrange things so that they can't easily see or modify
our database directly, including the metadata. We understand that
since they'll have physical access to database, that with enough
knowledge they can pretty much do anything they want, but we'd like
to keep the casual user, or competitor, from poking around in
things, connecting our data to other applications without our
approval or running reports directly out of the database.
I've changed the SYSDBA password to something obscure in the copy of
FB that we're going to distribute (so they'd have to download a
fresh copy to replace the security database).
Currently, our application is using SYSDBA as the username to
connect. Since our app. will be the only user, ever, is there
anything to be gained by adding another user and using *that* to do
the connection?
Is there anything else we can do in this regard besides changing the
SYSDBA password, like add a table to the security DB so that if they
replace it, we'll know? There are some things like this in the
Firebird book, but they were more about keeping legitimate users out
of trouble in a multi-user situation than keeping anyone from ever
adding another user or getting at the database in any way beside
through our app.
Michael D. Spence
Mockingbird Data Systems, Inc.
database to Firebird. Our users (mostly small businesses) will be
running the application and FB together on their Windows system; in
some cases, even on their laptop.
We'd like to arrange things so that they can't easily see or modify
our database directly, including the metadata. We understand that
since they'll have physical access to database, that with enough
knowledge they can pretty much do anything they want, but we'd like
to keep the casual user, or competitor, from poking around in
things, connecting our data to other applications without our
approval or running reports directly out of the database.
I've changed the SYSDBA password to something obscure in the copy of
FB that we're going to distribute (so they'd have to download a
fresh copy to replace the security database).
Currently, our application is using SYSDBA as the username to
connect. Since our app. will be the only user, ever, is there
anything to be gained by adding another user and using *that* to do
the connection?
Is there anything else we can do in this regard besides changing the
SYSDBA password, like add a table to the security DB so that if they
replace it, we'll know? There are some things like this in the
Firebird book, but they were more about keeping legitimate users out
of trouble in a multi-user situation than keeping anyone from ever
adding another user or getting at the database in any way beside
through our app.
Michael D. Spence
Mockingbird Data Systems, Inc.