Access Security

djpearce

Bamedele
Local time
Today, 02:41
Joined
May 12, 2004
Messages
27
I plan to implement some form of security to prevent potential vandals or enthusiasts from gaining access to backoffice objects in Access 2000. So far, I am thinking of group/user level security, and/or create a .mde. If any one of these methods would accomplish the task without the other, I would rather use the one.

Do I need both? What do you recommend?
 
Think Shrek. Ogres (and Windows security) are like onions - they have layers. (No, you CANNOT have a parfait!)

First and foremost, setting Windows security regardless of the application can be something that even a seasoned professional will try to hand off to someone else. Then, adding some degree of security through workgroups and such just makes it that much harder. So the BEST method of doing this is to not rely on just one type of security.

Workgroup security is "native" to Access so is the ONLY choice at that level. Yes, I would implement a workgroup and make my security start with that layer. This forum must have a bazillion threads on the topic of security or workgroup security. Search for them. Pat Harman and I have posted on this more than once. Vassago and Neileg have also contributed several posts on the general topic. Many others have also tossed in some good hints. There is NO substitute at this level for Workgroup security.

But that's not enough. Creating an .mde might or might not be a good idea. Not all .MDB files can be converted. So you cannot rely on that ability. I would talk to my file server's system administrator and my network security officer (if they aren't the same person) and explain my concerns.

One thing I would STRONGLY suggest is that you find a place to put your app in a folder by itself. (Not the .MDB by itself, but all the files that make up the app.) NEVER EVER share a folder with a distinct and different app. Why? 'cause if the two apps have different security requirements, the folders cannot be set to two different filtration rules at once. If this goes on a file server, the system disk should not also be the place where the app resides. If at all possible, make the folder a top-level folder. I.e. when you type a path as \\server\dev\path1\path2\...\pathn\file.type, you want your private folder to take the place of path1 if possible, but never lower than path2 under any circumstances.

Now you can set up Windows file-system permissions on the folder, assuming it to be an NTFS-formatted volume. (PLEASE tell me you are not planning on using a FAT32 - or worse, a FAT16 - volume for this. If you are then give up now. You can't get where you want to go from that starting point.) OK, get your sys admin to set up the protections on the highest level of folder assigned to your project. If there is a reference to the EVERYONE group, consider removing it from the parent and all other files. (NOT setting it to DENY - but rather just say nothing at all about that group's permissions.)

I would be extremely careful to assign proper permissions to a GROUP of users (including yourself). Never put individual account names in a device permissions list. Also look for articles where the Admin account gets protected from user depredation by changing its properites.

Finally, if there is a firewall between you and the rest of the world, I would darn sure have the network security guys work on setting up the allow/deny list. Also look at the network permissions on the implied shared folder.
 

Users who are viewing this thread

Back
Top Bottom