Chapter 8: Developer Workgroup Security


Overview

This chapter will show you how to use the Access workgroup (user-level) security system to secure your user interface and most of the objects in your database. To achieve these worthwhile goals, you need to follow some fundamental steps, such as creating a secure workgroup file, changing object ownership in the your database, and setting permissions on all or some of these objects. Just undertaking these tasks can all get a little complex, especially if you are unsure of what you are doing or what you are testing for. Another issue with workgroup security is that it can add the burden of yet another password for a user and additional responsibilities to the DBA in sorting them out. Therefore, I have structured this chapter to

  • Provide you with driving instructions for the different things you need to do (can do) to implement workgroup security.

  • Provide a system in which users (and the developer) never have to enter passwords.

  • Produce a database in which the user cannot change the design of any object and cannot view the design of forms, reports , macros, and, to a lesser extent, modules.

  • Achieve a lot of security and protection without producing a too-complex security design.

  • Create a database that is not susceptible to password-cracking software (discussed in Chapter 9).

  • Allow you to protect your startup options and, therefore, protect toolbars and menus , the Database window, and other startup options that you don't want your users to tamper with.

  • Set up a framework for other security measures, such as Access data and query security (discussed in Chapter 10) and operating system security (discussed in Chapter 12).

While we are pursuing these goals, I will introduce the different facets of workgroup security that you have to master to secure your database. I have deliberately structured the information on the end goals of security rather than diverging into fuller descriptions of the technology itself because at the end of the day, once you know that an end goal is worth pursuing, the technology becomes all the much easier to research and understand.

To achieve these security goals, we depend on one overriding principle: "The developer must not provide any of the users with the workgroup security file that is used to secure the database." Once you have set up your own developer workgroup file, you will find that you can reuse it when securing your databases from then on.

The demonstration material for this chapter includes forms and Visual Basic for Applications (VBA) examples, as follows :

  • A form to build a secure workgroup file from scratch.

  • A form to check and change object ownerships.

  • A form to remove a module's permissions that supposedly couldn't be turned off in Access 2000 or later.

Note  

To find the demonstration material, open the download database for your version of Access ”for example, grMAP97.mdb -and select Chapter 8.

To work through the exercises in this chapter, I suggest that you make a copy of the Northwind database for your experimentation. Do not use your own database or workgroup file until you are certain about what you want to do. Naturally, back up your database by using a .ZIP file or the instructions in Chapter 5 before implementing it. Finally, remember to rejoin your original workgroup when you finish experimenting.




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