In this post I’d like to discuss what steps you can take to try and secure, as best you can, your MS Access Front-End application.
Password Protect your FE
As I pointed out in my post entitled Why Ms Access Isn’t A Secure Database – Part 2, a MS Access Front-End is not secure and leaves sensitive information completely open to hacking. As such, like your back-end (BE), you should always Encrypt with Password your front-end (FE). This will, in the very least, stop prying eyes from being able to harvest BE passwords allowing anyone to have complete reign on your raw data.
Also, be sure to use a different password for the FE than used with the BE.
Distribute a Compiled FE to your End-Users
Another critical step is to always distribute a compiled version (mde/accde) of your FE to your end-users. By converting your mdb/accdb into an mde/accde, you lock down certain type of objects within your database. Users can not open Forms or Reports in design view, nor can the view any of the VBA code. So in essence by distributing a compile version you minimize any opportunity to mess around with the database itself.
Now an mde/accde surprisingly does not lock down tables, queries or macros.
Also note that since all VBA code is locked down and unviewable, any unhandled errors will cause a fatal application crash, hence the crucial importance of bulletproof error handling throughout all of your VBA code.
Hide the Navigation Pane
As noted in the previous section, an mde/accde surprisingly does not lock down tables, queries or macros so it becomes critical to take the necessary steps to do as much as you can to limit users abilities to get into aspects of the databases they shouldn’t be in. As such, by simply hiding the Navigation Pane, you eliminate your user’s ability to access these database objects.
Hide individual Database Objects
Of lesser importance, if you’ve taken the necessary steps to hide the Nav Pane altogether, changing the individual object Hidden attribute to True (so as to make it a hidden object) can keep most users from viewing objects in the first place unless they purposely go and changes their Navigation Display Options to Show Hidden Objects.
Use a Custom Ribbon
By completely hiding the standard Ribbon and using your own Ribbon, you can control which commands your users have access to and thus minimize any trouble they can get into.
Disable the Shift Bypass
Even if you prepare your database and hide this and that, you must disable the Shift Bypass property so as to close the back door which enables people to get around all of the above steps you’ve taken to harden your application.
Disable Special Keys
Change your database Use Access Special Keys property.
Create an AutoKeys Macro
By creating an AutoKeys macro, you can disable certain built-in key sequences, such as:
Ctrl+G -> Opens VBE
Ctrl+Break
F11 -> Shows/Hides Navigation Pane
In an ideal world we’d also include the following key combinations, but for whatever reason Microsoft does not allow the use of Alt in AutoKeys, go figure?!
Atl+F11 -> Opens VBE
Alt+F1
This step is somewhat redundant since we disabled Access’ Special Keys in the previous step, but I prefer to do both. It provides an extra layer of security in case someone manages to change the database property itself.
Create an AutoExec Macro
I personally like to use an AutoExec macro which calls my startup procedure. Typically, as part of my startup procedure I call a procedure that simply sets/resets the various properties we’ve been discussing (Shift Bypass, Hide Nav Pane, Check that we’re running an compiled copy, …)
Lockdown Where Your Database Can Run
If you are lucky enough that you are running your db on say a CITRIX server, you can easily add code, as part of your startup mechanism, that verifies which computer is running the current application. If it doesn’t match up with the computer/server name it should be running on, simply close the application.
Note: I actually send an e-mail to the db admin when this occurs with certain information (PC name, Username, IP address, Date/Time, …).
Lockdown Which User Can Run Your Database
Another easy process to implement is to have a table in your database that lists all the windows usernames that are allowed running the database. At startup, retrieve the current user’s network username and then see if it is in your user table. If it isn’t close the application.
Note: I actually send an e-mail to the db admin when this occurs with certain information (PC name, Username, IP address, Date/Time, …).
Lockdown Folder Permissions
Yes, simple folder permissions are still one of your best friends when trying to harden any application, not just MS Access databases! By controlling who can access what, you minimize any potentials for disaster.
When it comes to Access, setting up the BE folder to have Travers permission thus allowing user access to the data but not to the folder itself stops people from nosing around and being able to copy everything and walking away with it. Then you distribute the FE as you always do (one copy per user locally installed on their PC).
Implement Virtual Password Protected Connection (vPPC)
If you truly want to take things to the next level, you may wish to examine and implement Virtual Password Protected Connection (vPPC). Alan Cossey was kind enough to provide me with a copy to the initial concept which you can download below since all the other download links are no longer valid. Do note this is offered with no support whatsoever.
Download “Access - vPPC Security Toolkit” vPPCSecurityToolkit.zip – Downloaded 45009 times – 1.24 MB
As always, if you have any tips to share please feel free to leave a comment.