K
Kax
I’m trying to temporarily** secure a Microsoft Access 2000 database.
In particular about 4 tables. There are no queries, forms, reports,
etc. that need protection. We ONLY want to protect about 4 tables.The
bottom line to my case is that I NEVER need to have anyone access the
database using Microsoft Access at all. The way our process works, we
use a Master database and copy it for as many instances of the process
we want to run. Each process “fills” its own copy of the database
tables up with the data we wish and then the databases get shuffled
off to the next processing step. Then the Master copy procedure starts
all over again.
The database is not a compiled Access application but is simply a data
repository for a windows program which uses ODBC to get to it. My
problem is that there doesn’t seem to be a way to protect the tables
it if it isn’t a self-contained app. By this I mean that the
application is not part of the MDB file. If it were, then we could
split the database, compile it to an MDE and what not but since we
don't do this we have issues....
Security Issues…
If I password protect the MDB file, there are no end of hacker tools
available. If I use workgroup security, again, there are tools
available to hack this. In addition, the external application cannot
access the tables either directly to the MDB or via the security
shortcut of the same name using workgroup security. The ODBC driver is
looking for a database and ODBC doesn’t seem to be able to pass
credentials directly to a database secured this way????
If I try splitting the database, then may external application can
access the foreground password-protected MDB file and the linked
BackEnd database....but the process of splitting the database removes
the password from the back end (which contains the tables I want to
protect). If I then password protect the back end, then the foreground
MDB file can’t access the back end because the links by default, won’t
have the new password for the back end. If I could add the password to
the backend database into the links, the password is not encrypted
anyway and from what I’ve read, if security is an issue we shouldn’t
use this method for object protection…workgroup security is
recommended instead…which has the above problems
If I want to set/protect the startup options and run an AutoExec to
hide tables, disable the bypass keys, etc. I can write a Macro to call
a function to do this but if one opens it up, macros are disabled by
default and the user can simply opt to not run them. If one states
that to fix this problem all you have to do is compile the app into an
MDE, this requires splitting up the database which has the problems
stated above.
Bottom line: is there ANY way to secure a few tables in MsAccess (2000
version) so that no one can get to the tables but I can access them
via ODBC?
Thanks!
**PS: I say temporarily because the very next step for us is to
convert the data and application to run from SQL server. Then all of
these security issues go away. Should I punt attempting to secure
Access for my purposes?
In particular about 4 tables. There are no queries, forms, reports,
etc. that need protection. We ONLY want to protect about 4 tables.The
bottom line to my case is that I NEVER need to have anyone access the
database using Microsoft Access at all. The way our process works, we
use a Master database and copy it for as many instances of the process
we want to run. Each process “fills” its own copy of the database
tables up with the data we wish and then the databases get shuffled
off to the next processing step. Then the Master copy procedure starts
all over again.
The database is not a compiled Access application but is simply a data
repository for a windows program which uses ODBC to get to it. My
problem is that there doesn’t seem to be a way to protect the tables
it if it isn’t a self-contained app. By this I mean that the
application is not part of the MDB file. If it were, then we could
split the database, compile it to an MDE and what not but since we
don't do this we have issues....
Security Issues…
If I password protect the MDB file, there are no end of hacker tools
available. If I use workgroup security, again, there are tools
available to hack this. In addition, the external application cannot
access the tables either directly to the MDB or via the security
shortcut of the same name using workgroup security. The ODBC driver is
looking for a database and ODBC doesn’t seem to be able to pass
credentials directly to a database secured this way????
If I try splitting the database, then may external application can
access the foreground password-protected MDB file and the linked
BackEnd database....but the process of splitting the database removes
the password from the back end (which contains the tables I want to
protect). If I then password protect the back end, then the foreground
MDB file can’t access the back end because the links by default, won’t
have the new password for the back end. If I could add the password to
the backend database into the links, the password is not encrypted
anyway and from what I’ve read, if security is an issue we shouldn’t
use this method for object protection…workgroup security is
recommended instead…which has the above problems
If I want to set/protect the startup options and run an AutoExec to
hide tables, disable the bypass keys, etc. I can write a Macro to call
a function to do this but if one opens it up, macros are disabled by
default and the user can simply opt to not run them. If one states
that to fix this problem all you have to do is compile the app into an
MDE, this requires splitting up the database which has the problems
stated above.
Bottom line: is there ANY way to secure a few tables in MsAccess (2000
version) so that no one can get to the tables but I can access them
via ODBC?
Thanks!
**PS: I say temporarily because the very next step for us is to
convert the data and application to run from SQL server. Then all of
these security issues go away. Should I punt attempting to secure
Access for my purposes?
