One Secure Object Marks a Developer s Territory


One Secure Object Marks a Developer's Territory

To change permissions for just one object (form or report) in your database, you first need a user account with administer permission over that object (and hopefully all others as well). The steps to achieve this protection follow:

  1. Join the developer workgroup file (called Developer.mdw ) as described in the "Preparing Your Developer Workgroup File" section earlier in the chapter.

  2. Select the database that you are going to secure (I use a copy of Northwind in these examples).

  3. Log on to the developer's account (which we earlier named Developer). If you are already using Access, double check that you are using the correct workgroup file and user account.

  4. Open the database container and select a form or report to protect. In this case, I will select the first form in the Northwind database, called Categories .

  5. Choose Tools ˜ Security ˜ User and Group Permissions.

  6. Select Admin in the User/Groups Name list. Clear the Read Design check box in the Permissions area. This action also clears the Modify Design and Administer check boxes. Now click Apply.

  7. Choose the Groups option. A dialog appears, asking if you want to assign the permissions now. Click Yes.

  8. Select Users in the User/Groups Name list.

  9. Clear the Read Design check box in the Permissions area, as shown in Figure 8-11. Now click Apply.

    click to expand
    Figure 8-11: Clearing the Read Design check box in the Permissions area.

  10. Finally, change the ownership of the object to the Developer account to make sure that the anonymous Admin user cannot modify this object. To do this, select the Change Owner tab. Now choose the correct object type (form or report) and choose the object. Then select your secure user (Developer) from the New Owner drop-down list, as shown in Figure 8-12.

    click to expand
    Figure 8-12: Changing the ownership of the form to the Developer.

Tip  

You can always check your user account in the Current User field at the bottom of the User and Group Permissions dialog.

That concludes the process of securing an object. To describe this important process in a different way, here is a summary of what we have done. We have minimized the necessary permissions on an object for the Admin user and the Users group and changed the ownership of the object to your Developer user account. Now, unless the user can log on to or re-create the same developer workgroup file, you will achieve the following worthwhile security and protection outcomes .

Stopping Anyone From Reading the Design of Your Object and Changing its Permissions

The obvious benefit of these changes is that the anonymous Admin account cannot open the object in design mode.

Stopping Anyone From Importing the Object into Another Database

Removing read design permissions from an object prevents someone from importing the object into another database. To try out this deterrence, open another database and import (the already secured) Categories form from the Northwind database with which we have been experimenting. When you do, you will receive the error message shown in Figure 8-13.

click to expand
Figure 8-13: The error message issued when an object cannot be imported into another database.

Stopping Anyone From Upgrading the Database to a Later Version of Access

Whenever you open an Access database in a later version of Access, Access will assess the permissions of all the objects in the database. If Access finds that the current user has read design permissions for all the objects in the database (and passes other requirements as well), the user can upgrade the database to a later version of the database. If Access doesn't find that the user is able to convert the database, a warning message appears, as shown in Figure 8-14.

click to expand
Figure 8-14: A warning message that appears when the user account cannot convert a database.
User Story  

This particular result of securing an object has proved profitable to me over the years when the occasional user has wandered off to another employer with the database. When that user arrives, they find that the new employer has a later version of Access, making it impossible to run the database the user depended on. One such user relocated from central Australia to West Africa and, after opening the software, found that he was blocked. If he had looked hard enough, he would have found that he could have imported all the important objects into another database because in this case, I had not protected any object of importance.

The other way in which this result proves useful is when clients themselves upgrade Access. At this stage, I receive a call and a little bit of work to upgrade and test the software, and I have a chance to reestablish contact after long periods of maintenance-free running. A good analogy is that securing just one object is a bit like designing a refrigerator so that it starts to break down after seven years.

Stopping Users From Opening Access 97 Databases in Access 2000 or Later

One feature of multiversion compatibility with Access is the Open Database option (shown in Figure 8-15) that allows Access 2000 or later to open Access 97 databases without converting the database. This seemingly useful option is not without its pitfalls, however, because the first time that someone opens the database this way, the database expands without warning because Access adds extra compatibility information to the database. As an example, the Access 97 Northwind database expands from 1.5MB to 2.2MB. Not even the unsupported \decompile shortcut switch will retrieve the space. But because you're interested in protecting your database, not having the appropriate permissions will stop the anonymous Admin account from opening the database by using a later version of Access.

click to expand
Figure 8-15: The Convert/Open Database message, which appears when you open a database with a later version of Access.

That concludes the descriptions of the considerable benefits that result from removing the object permissions from the anonymous Admin account and Users group. In the next section of this chapter, I describe how to transfer the ownership of all the objects in the database to the new Developer account.




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