The Access Protected Folder Strategy


I am now going to show you how you can set up folder permissions in the Windows operating system so that users will not be able to browse the folder and subfolders where the database is located. This strategy will make it very difficult for users to copy the database to their local folders, to a CD-ROM, or any other place. It will also stop them from importing objects from the database into another database. I call this the Access protected folder strategy.

The first part of the strategy involves setting up a new group of Windows users (called the Access DBA group in this chapter) that will be allowed to manage the files in a database folder. In essence, these permissions are exactly the same as those we set up for the Access Editors group before. The second and most important part of the strategy will be a revised permission scheme for the Access Editors group, discussed in the last section. This time though, we are going to deny the Access Editors group the ability to list the files in a folder.

Setting up a New Access DBA Group

Stage one of Access protected folder strategy involves setting up a new Windows permission group that will manage the database. We need this new Windows group because a number of Access administration functions require you to list the contents of a folder. To set up this group (which I am calling the Access DBA group), follow these instructions:

  1. Make sure that you have set up and tested the Access Editors group and the related folder permissions as detailed in the section "Proof-of-Concept Operating System Security" in this chapter.

  2. Log on as the Administrator on the peer-to-peer server.

  3. Set up a new group called the Access DBA group by using the same instructions as for the Access Editors group. See the section "Setting Up a New Access Editors Group" earlier in the chapter.

  4. Add the appropriate Windows account(s) to the Members Of list for the Access DBA group.

  5. Give the Access DBA group the same permissions to the protected database folder ( \\ComputerName\Databases\Protect\ ) that we gave to the Access Editors group.

  6. To test the new group folder permissions, log on as one of the members of the Access DBA group.

  7. Test that a member of the Access DBA group can browse the \Protect\ folder: open the database, compact the database, create a small text file, and delete that text file in the folder.

Note  

This group is not essential if the DBA of the Access database is also the administrator of the computer. This case is unlikely in larger organizations, and even for smaller organizations, it is probably best if the administrator's role and the DBA's role were kept separate because it is a good idea to limit the time that the administrator is using a server to server administrator tasks only. This practice is good because it reduces the chances of viruses and mistakes affecting the server.

Now we are going to modify the permission scheme for the Access Editors group so that members of that group will not be able to browse the protected folder.

Denying Users the Ability to List the Contents of a Folder

Stage two of the Access protected folder strategy requires that we make some modifications to the permissions that the Access Editors have on the protected database folder ( \\ComputerName\Database\Protect\ ). To make these modifications, we need to delve into the Windows advanced permissions for the Access Editors group:

  1. Make sure that you have set up and tested the Access Editors group and the related folder permissions as detailed in the section "Proof-of-Concept Operating System Security" in this chapter.

  2. In Windows Explorer, right-click the \Database\Protect\ folder to display the folder's Properties dialog.

  3. Select the Access Editors group in the group name list and make sure that the properties are set up like those shown in Figure 12-20.

    click to expand
    Figure 12-20: Modifying folder permissions for the Access Editors group.

    Note  

    At this stage, you may want to remove the Modify permission (shown in Figure 12-20) because this permission allows members of the Access Editors group to delete files in the folder. In some Access situations, this capability may be a good idea, and in some, it may not. The users in this group need this permission because Access automatically deletes the .LDB file when the last user closes the database. Naturally, this action won't happen if the permission to delete a file is removed. Deleting the .LDB file improves performance when determining which other users have locks. Personally , I would keep the Modify permission selected unless you can work out another way to delete the .LDB file when it is not being used. See more information on this topic in the "Further Reading" section.

  4. Click Advanced, as shown before in Figure 12-20, so that we can look at the advanced permissions.

  5. On the Access Control Settings dialog that appears (shown in Figure 12-21), we need to add a second permission for the Access Editors group. Make sure that you have selected the Allow Access Editors entry in the permissions entry list, and then click Add.

    click to expand
    Figure 12-21: The Access control settings for the folder.

  6. Once again, choose the Access Editors group in the Select User or Group dialog (shown in Figure 12-22) and click OK.

    click to expand
    Figure 12-22: Selecting a user or group.

    Note  

    In Windows XP, type the name of the user or group, then, optionally , click Check Names.

  7. The Permission Entry dialog appears; it has all the advanced permissions for the folder. Figure 12-23 shows this dialog and the appropriate permissions for the folder already selected. Nevertheless, I will detail them in steps 8 and 9.

    click to expand
    Figure 12-23: Selections required to stop a group from browsing the contents of a folder.

  8. From Apply Onto drop-down field, select This Folder and subfolders.

  9. Select the Deny check box for List Folder/Read Data.

  10. Click OK, and the list of permissions for the folder will appear in the Access Control Settings dialog as shown in Figure 12-24. Notice that the Deny permission is now at the top of the Permissions Entries list.

    click to expand
    Figure 12-24: The Access Editors now have a new deny permissions entry.

  11. When you click OK on the Access Control Settings dialog, a message box appears, telling you that deny permissions take priority over allow permissions, as shown in Figure 12-25. You will need to click Yes to confirm those changes.

    click to expand
    Figure 12-25: Confirming that the deny permission is going to take priority.

That's what it takes to stop someone from listing the contents of a folder. Now I will describe what we have done here.

How Does this Access Protected Folder Strategy Work?

It's a good time to think about what has happened here. Because we need permission to read and write to files in a folder, the folder permissions that we initially set up (shown earlier in Figure 12-20) act as a simple view to a more advanced set of permissions. In most cases, you or your system administrator will never have to work with these advanced permissions (shown earlier in Figure 12-23). The reason that we need advanced permissions is that you can apply the permissions individually to the files, the folder, the subfolders, and any combination. We take advantage of this capability by setting up a deny permission that applies only to the folder and subfolder and not to the files themselves . Because the deny permission takes priority over the already-established folder permissions, this then removes a specific permission for the folder but does not affect the files in that folder. The result, all that most of us really care about, is that it is now impossible for a person to browse that folder if that person happens to be a member of the Access Editors group.

Note  

Importing and linking is substantially more difficult to do for people who do not have list file permissions.

Testing the Permissions

After working your way through all these steps, you will be eager to test that your database user will be unable to browse your protected folder. Following are a number of different tests that you can undertake to ensure that users cannot browse the protected folder. Before you start, log off the Administrator account on the peer-to-peer server and log on with an account (like Editor2000) that is a member of the Access Editors group. Here are the different tests:

  • Open Access and choose File ˜ Open. Now browse to the \\ComputerName\ Database\Protect\ folder and try to open either of the databases. When you get to the folder, you will encounter the error message shown in Figure 12-26.

    click to expand
    Figure 12-26: The error received when browsing to a folder that has no listing permission.

  • Open another Access database and then try to import tables from the back-end database into it. You will find that you cannot locate the database in the folder.

  • Open Windows Explorer and try to look at the files in the folder. When you do, you will get the error message shown in Figure 12-27. Naturally, this stumbling block makes it very hard to copy a database.

    click to expand
    Figure 12-27: You cannot browse the folder.

That, in a nutshell , is how and why you should consider the Access protected folders strategy. Before you start discussing these new processes with the system administrator, I will explain why you need a shortcut file to open the database and how to set it up.

You Will Need a Shortcut File

Now that you have a secure folder, your users will not be able to open the database by browsing to the file itself. This means that you will need a shortcut file that opens the database, and you are going to have to put that shortcut in a folder where the user can find it. I suggest that you place it in the folder directly above the protected folder ( \\ComputerName\Database\ ). You will find comprehensive instructions for Access shortcut files in Chapter 10.

When you are setting up a shortcut, you have to be careful about what goes into the Target line (shown in Figure 12-28). Following is an example of a shortcut that works on the network share that I set up on our network:

 C:\MSOfficeXP\Office10\MSACCESS.EXE "\cow-fx\Databases\Protect\Northwind.mdb" 
click to expand
Figure 12-28: A shortcut file that points to a database in a protected folder.

There are a couple of things to understand about the Target line in the shortcut file that are particular to protected folders:

  • You must put the full path to the Access executable at the start of the line. If you don't, then the shortcut will try to look at the contents of the protected folder and the shortcut will not work. If your computers have different locations for the Access executables, then you will need to place the shortcuts on the users' desktops.

  • You need to enter the path to the database that includes the network share, rather than a local path. You only need to use inverted commas if there are spaces in the path to the database location.

If you want to add another layer of security, you can also hide the location of the front-end database by concealing the path to the database in an .MDE file, as discussed in the section "Creating a Secure Shortcut File" the Chapter 10.

As you probably already know, anyone who can read the shortcut file will be able to find the location of the front-end database. Of course, that person will need to be a member of the Access Editors group to copy the database, but a protected folder makes getting access a difficult task. More importantly, we can make sure that users will have a devil of a time opening the back-end database by setting up the following protection measures on the front-end database:

  • Turn off the startup options (Chapter 2).

  • Protect the menus (Chapter 7).

  • Set up and secure a database by using a developer workgroup file (Chapter 8).

Note  

It is possible to apply read-only permissions to shortcut files, but as a rule, most systems administrators would not apply permissions at the file level because of the maintenance required.

Another useful benefit of the Access protected folder strategy is that you can save your backups (described in Chapter 5) to a subfolder protected by the Access protected folder strategy. Because the Access Editor group cannot list the contents of subfolders, it is unlikely that a user from that group will be able to find out what backup files (tables or data) are in those folders.

Other Permission-Related Topics

I will briefly explain a number of other issues to complete the discussions of the Access protected folder strategy.

Setting up a Read-Only Group

I investigated the possibility of also including a demonstration of using the operating system for read-only Access database permissions. This option worked out to be far more difficult than it needed to be, due to complications with the deny permissions and the need for yet another Windows permission group. If you want to offer this protection, it is probably better to switch completely to a read-only folder rather than try to combine it with the Access protected folder strategy that I outlined in this chapter. Otherwise, you can approach read-only security by using alternative shortcut files that include a read-only command line option. It is also possible to set up simpler read-only folder permissions, but this method would allow that group to copy the database. I would rather that people can't copy the database than have read-only permissions on the files. Anyway, you can always use Access workgroup security to manage the read-only permissions for the database (Chapter 10).

Bundling all Related Databases in the Same Folder

If one group of users uses the same network share, then you can place a number of Access databases in the same folder that the same Access Editors group uses. That way you will save a lot of time as compared to setting up and managing the permissions for different folders for different databases. The downside of this method is that granting permission for a user to use one database is actually granting permission for the user to use all the databases in the folder.

Client-Based Access Front Ends

A popular method of distributing Access databases is to install the front-end databases on the client computer. If you are intending to use operating system security on your database, you should be careful with this approach because you will significantly reduce the quality of the operating system security. If you still want to go ahead and install the front-end database on the client, be aware that you are going to make it harder to protect the location of the back-end database. Also, because you will have databases scattered across a number of machines, any changes to the front-end security will rely on all the databases being updated. I personally am not in favor of this approach, because networks and file servers have improved a lot in the last few years , negating the performance reason for using this approach.

Why You Can't Set Permissions on Individual Files

When you compact an Access file that's located on a volume that uses the NTFS file system, Access removes the existing file and replaces it with the compacted file. It then applies the default file permissions to the new file, which may not be the original permission that you established for the database file. On a more general note, if a file is copied between a single NTFS volume or copied and moved between NTFS volumes , NTFS treats it as a new file. As a new file, it takes on permissions of the parent folder, and any existing permissions will be lost.

In the next section, I will discuss the importance of using NTFS for your hard drives .




Real World Microsoft Access Database Protection and Security
Real World Microsoft Access Database Protection and Security
ISBN: 1590591267
EAN: 2147483647
Year: 2003
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net