Flylib.com

Books Software

 
 
 

Further Reading


Further Reading

As you might expect, there is never enough information when it comes to powerful products like Access. To assist you with further investigations, I have put together a Web page with links to Web sites and articles on the issues relating to the material in this chapter. The first three of these links discuss issues relating to the developer workgroup strategy.

  • A paper by Microsoft on securing your database without asking the user to log on.

  • The highly referenced Access security FAQ paper.

  • Mary Chipman's article in Access/VB SQL Advisor, "Is Database Security an Oxymoron?"

The remainder of the reading is related Microsoft documentation.

  • A useful paper on many aspects of Access security by Frank Rice, this book's technical editor.

  • How to use ADO with Visual Basic or VBA code with databases that are protected by Access passwords and workgroups.

  • Find all the specifics about owners , groups, SIDs, and the Admins group .

  • A short but definitive article by Microsoft on how to secure a database, including permissions for newly created objects.

  • Workgroup security explained in detail by Microsoft.

  • How to upgrade DAO to ADO, containing a lot of detail about what library to use for what security aspect.

  • Programming user security with VBA code.

  • A Microsoft article on the "No permission to convert database" message, which contains insight into some upgrade protection ideas I detailed in this chapter.

  • Database security and replicated databases.

  • More details on the Admin account, the Admins group, and the Users group.

You can find the further reading Web page for this chapter in the Downloads section of the Apress Web site ( http://www.apress.com ) or at http://www.vb123.com/ map/adm.htm .

Apart from those online links, you can review the Access security in the Contents section of the Access help file. In Access 97, look for "Securing a Database," and in Access 2000 or later, look for "Administering and Securing an Access File," as shown in Figure 8-25.

click to expand
Figure 8-25: Help in Access 2002.

Finally, to find out about the different types of permissions for the different types of objects, search on "permissions" in Access help.



Reflecting on this Chapter

The strategy for this chapter was to adopt a simple model for using Access workgroup security and then to explain how to implement it. The developer workgroup strategy that I settled on is significant in that it doesn't require passwords to use it, it is relatively easy to understand, and it achieves a number of significant security results, including the following:

  • Stopping users from viewing forms, reports , and macros in design mode. The open exclusive database permission further assists in this regard.

  • Stopping users from changing the design of queries and tables.

  • Stopping users from changing the startup options.

  • Removing the ability for users to upgrade and view databases in later versions of Access.

  • Stopping users from importing secured objects into another database.

All these outcomes are significant for developers who want their Access databases to behave like software produced from compiled languages, such as Visual Basic, within a security framework that you can trust.

Once you manage to work this model into your database, it is important to take a break and let the database settle down. There are many directions to take from here, and it is best to wait for the user pressures to dictate what the next best thing is to invest your software dollars in. As I have said, this model is flawed in that anyone who can find the database will be able to see the data through the user interface. They will not be able to change the interface, however, and there are many ways for you to protect your data, including the following:

  • Implementing your own internal security system to stop users from viewing particular data.

  • Setting up a front-end database in separate location from a hard-to-find back-end database.

  • Using the operating system to restrict usage based on operating system names and groups.

The other flaw is that the VBA code is quite vulnerable if you don't protect your startup options; verify that your menus and toolbars don't provide entry to the VBA environment through buttons, such as the form and report design mode buttons ; or use the special module permissions code that I have provided.

Finally, remember when working with workgroup file security that you must know which workgroup you joined and what user you logged on as before you do anything. The number of times that this author has made that mistake seems like a good enough reason to warn the readers.