• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 259
  • Last Modified:

(Fun, interesting topic) How secure would it be to. . .

Never mind the absurdity of it:

But how *secure* would it be to use and develop a split Access 2007 database by having 100% of the database components on a local computer and installing a virtual machine using the Windows Vista OS that is essentially crippled with security features (no context menus, no execution of applications, no registry access, Access runtime-only installed, the list goes on. . .), with a remote connection between the client virtual machine to a file share managed by advanced Windows file permissions on the local machine negotiated by a virtual private networking utility called "Hamachi" wherein the users may be granted access to the network, blocked, or banned, and must always be approved before being added to the VPN, and having a further split back-end database that runs perhaps once daily based off of append and update queries so as to manage having multiple clients' tables with permissions set on a per-client basis (CLIENT A + CLIENT B = MASTER)?  

Each virtual machine would be associated with negotiating a connection to a separate front-end Access database application on the VPN Local Machine and this front-end database would be password encrypted, compiled in the .accde format, and have internal script-based security for authenticating users periodically ("Are you still there?  Please enter your pin.").

One obvious advantage of this is the ability to update the client application as needed and monitor client access to the application in real-time.  Just like the internets!!

So. . .

How secure is this implementation?  Any other considerations?

Thanks!!
0
drtrmiller
Asked:
drtrmiller
1 Solution
 
Kelvin SparksCommented:
Access 2007 is not a secure environment.

You can manage it to a degree by controll access to a folder - you're either in or out - which is much what your suggesting but using a machine for that.

Once in, you have virtually no control over who does what.

If you're that concerned, use SQL server (correctly setup) to manage the backend with an Access front end.

SQL Server 2005/2008 Express (free) would do better than what you're suggesting.


Kelvin
0
 
thenelsonCommented:
>Access 2007 is not a secure environment.<
Not true. I have encrypted Access databases to a very high level of security.

Here is a short discussion of MS Access security.

To secure the frontend (the db with the forms, reports, code, etc.), you have eight levels of security, lowest to highest in security level also easiest to hardest (you can use any combination of them):

1: Create a macro in the frontend with the name of autoexec.  A macro with that name will run whenever someone tries to open the backend directly.  Have the macro create a msgbox with something like "You bad, bad boy!" and quit.  Create another macro with an obscure name that does nothing or opens your main form.  To open the database, you use the command: FullPath\msaccess DBPathName /x MacroName.  You can use a shortcut to start your database.  Downside: a: The user name and password is easy to read from the shortcut. b: The shift bypass can be used to open the db

2: Goto tools, startup.  Uncheck all the check boxes including the one after clicking advanced in W2k.  Downside: Same as 1b

3: Disable the shift bypass.  The easiest way to do this is with a utility such as: Access Property Editor at: http://www.jamiessoftware.tk  Downside: Can be easily enabled. However if you add the following code to a module which deletes the database if the shift bypass is disabled  and call the sub from every on open event of every form and report, you can make life a little more complicated for someone trying to bypass the shift bypass.  This is explained in http://www.thenelson.name, Shift Bypass Functions.

4: Convert the Front End to a mde file (tools, database utilities, make mde file). Be sure you keep a copy of the mde file.  Downside: There are programs available that can back engineer the missing design info and code.
 
5: Build your own login/security system.  Here is a sample database to show you how (or just cut and paste): http://www.thenelson.name/,  Simplified Login.  Downside: Easily circumvented by shift bypass, opening with another database or just looking at the security tables if they are not encrypted.

6: Set passwords for the front end (the part with forms, etc) and backend with tools>security>set passwords.  If you don't want your users to have to put in the user name and password, you would then put the following in the shortcut to start your database:
msaccess <database name> /User <user name> /Pwd <password>
Downside: a: the user name and password is easy to read from the shortcut. b: there are programs readily available starting at about $20 which will parse out the user name and password.

7: Use msaccess user level security (ULS).  A great reference: http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fsecfaq.asp
Downside: a: same as 6a,  b: a huge jump in complexity,  c: there are programs readily available starting at about $100 which will parse out the user names and passwords.

8: Write the Front End in a compiled language and compile an exe file. Downside: same as 7b


To secure the backend (the db with the data), you have five levels of security, lowest to highest in security level also easiest to hardest (you can use any combination of them):
1: Create an macro in the backend with the name of autoexec.  A macro with that name will run whenever someone tries to open the backend directly.  Have the macro create a msgbox with something like "You bad, bad boy!" and quit.  Downside: someone can easily access the data from another db.

2: Set passwords for the front end (the part with forms, etc) and backend with tools>security>set passwords.  If you don't want your users to have to put in the user name and password, you would then put the following in the shortcut to start your database:
msaccess <database name> /User <user name> /Pwd <password>
Downside: there are programs readily available starting at about $20 which will parse out the user name and password.

3: Encrypt the backend with tools > security > encrypt.  Downside: Since Access encryption does not use a key, anyone with Access and the user name/password from 2 above can decrypt it.

4: Use msaccess user level security (ULS).  Downside: a: a huge jump in complexity,  b: there are programs readily available starting at about $100 which will parse out the user names and passwords.  

5: Create your own BE encryption scheme or use an encryption addin.  Downside: a: same as 4a, b: if you lose your encryption key or the backend gets corrupted and you don't have backups, you are screwed big time.
http://support.microsoft.com/default.aspx?scid=KB;en-us;q165009
http://www.netlib.com/encryption-software.shtml
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now