security of MDB file...

[poolban]

Hi,

We are using MS-Access for some critical applications. The MDB file is kept in a fileserver and users access it thru icon defined to point to the applicationn.

We have problem in one database which is very critical and having highly sensitive bank data. For that one, we want to stop the copy operation of the MDB file.

People can use the application (for read/write/query/print) but copying to local machine - this is what we want to prevent.

This is a running application - that is why I am looking for an easy and quickly implementable solution. Audit is on the way, I need help to circumvent this situation.

Hope to hear your comments,

Best regards,

pb

 

[The_Doc_Man]

You are stuck with Microsoft security on this, I'm afraid.

If the user can read the file (which is mandatory, since they can query the file), they can copy the file. If they can copy the file, they can open it locally.

The only things I can think of can be circumvented to some degree by a clever user.

First, make sure that the Admin user isn't a member of the Admins group. Make sure that the User group doesn't have any rights at all and that the Admin user doesn't have OpenExclusive.

Second, put in a startup screen (if you haven't done so already) that, on Form_Load, checks the location of the database file. Hard-code the sucker so that if it isn't running under a legit Admins group account AND isn't on the shared drive, it starts deleting all tables. (Write hidden queries owned by an Admins group user to do this, then run them WITH OWNER ACCESS.) Look up how to disable the various methods used to bypass that startup form. Several threads in the forum have discussed this issue. Make sure that no one can escape the form.

Third, make sure that all objects have individually asserted security related to your groups such that your average user cannot read the definition of anything. Make sure that NO object is wide-open to members of the Admin account or the Users group.

Fourth, if you have the right kind of setup, create an e-mail from your startup screen so that if it ever detects that it has been run improperly from a local copy, it quietly sends e-mail to your security manager and/or yourself. Turn off all confirmations when you do this. Make it as silent as possible.

Fifth, notify all users that you have taken steps to make it unwise to copy this information. Warn them ahead of time that if anyone is caught with a local copy, you WILL press charges. Don't tell them what the steps are. Let 'em guess.

Sixth, don't hesitate to back up your words with actions. Then, if it ever happens that someone makes a copy, go physically grab the person who did it. Threaten them with criminal charges. Heck, PRESS criminal charges.

Now, here is why I'm suggesting what I just suggested. For something that is shared and readable, it is just about impossible to prevent someone from making a copy. Even if you revoke the right to do an OpenExclusive, it might happen that the person making the attempt is the only person in the DB at the moment. So you probably cannot stop the copy operation. The only things you can hope to do are

(1) Make it harder for them to use the copy

(2) Notify you that a copy has been made and someone tried to open it.

(3) Set Draconian examples to violators.

 

[ElsVanMiert]

Since your problem is the security of the tables in the BE, here the corresponding article from the ACCESS ONLINE ENCYCLOPEDIA at www.unsoftwareag.com
Article Code: S4

Security of the backend tables ?
PROBLEM


If you activate the security system on the frontend all database objects are securized.
In a split application all tables from the backend file are linked into the frontend file. It is not possible to link tables from a securized backend file even if you use the same MDW file for backend and frontend.


SOLUTION

You have three possibilities to solve this problem:
Integration with DAO (Opendatabase) (A97 and A2K)
Integration with ADOX (Setpermissions)(only A2K)
Utilization of queries with "OwnerAccess" option

The first two solutions require that you transmit both username and password, therefore the third solution is the most secure.


Creation of a query with "OwnerAccess"

Log in with write rights on the securized table
Create a new query
Activate the query property "OwnerAccess" in the query window
Save the query
This query can be used by all logged-in users.
If you use SQL strings in your VBA code then use the following structure:


SELECT Field1,Field2 FROM tableName WITH OWNERACCESS OPTION

SELECT Field1,Field2 FROM tableName WITH OWNERACCESS OPTION