Access backend security

Had

New member
Local time
Today, 12:16
Joined
Nov 12, 2013
Messages
2
I have just been trying to see if its possible to secure the backend of my access database. I have searched the forums but couldn't quite see the answer.

The current setup is that the frontend is distributed as a runtime accde and run on the clients locally and the backend sits on a windows file server.

As far as I can see there is no way to set the ntfs/share permissions on the domain to restrict browsing to the unc path where the backend is located and either copying or deleting the backend. Is this correct?

My only thoughts are too obscure the files by using hidden shares and restricting access to the windows network explorer. Are there any other better ways to do this?
 
You can set a password to the back end using the encrypt with password feature on access.

This will require uses to input a password before being able to view and tables in the backend.

To ensure the front end works after applying the password you will need to relink and update locations for the tables on the front end using the linked table manager. You will be asked to enter the back end password only once on the connection update.
 
You can use Windows Security to "hide" the BE and to restrict access but once someone has access, you cannot prevent them from copying the file. That is why Jet/ACE are inherently unsecure. If you really need security for your data, then you need to use SQL Server or some other RDBMS.
 
If the BE file is public and exposed to the internet, Pat's idea is good.

If the BE file is private and not exposed to the internet, and if your staff is reasonably intelligent, tell them to not mess with something that isn't their responsibility to fix because if they do, they'll become part of the maintenance team.

If you have some thumb-fingered dolts on the team and they cannot be trusted to reliably change out a light-bulb, post a policy (which has to be approved by your management) that says "If you screw with our back end file, we'll screw with your job."
 
I think some types of data just shouldn't be stored in Jet/ACE. As long as anyone could walk away with the file (breaches are frequently caused by trusted personnel), HIPPA data, for example, shouldn't be stored in access.
 
Cheers guys you've confirmed what I thought. In the future I will look into migrating to sql server for security. The database was started in 97 so i'm sure it wont be a simple transition. There's still quite a lot of work to finish on the front end before we look at that.
 
If you are working on the FE, now would be the time to make it client/server "ready". Search for some articles on optimizing for client/server. Then when the time comes, you run the wizard and add the "dbSeeChanges" argument to your DAO code if you haven't added it already. No database I have ever made has taken more than a half day to convert to SQL Server and most take less than an hour. But, that's because I always assume that at some point it will need to be converted. Several of my apps are set up to use either BE depending on what the client wants so the relinker included in those apps, is capable of switching between SQL Server and ACE rather than simply relinking to a different copy of the same type of BE.
 

Users who are viewing this thread

Back
Top Bottom