Your Personal Driving Instructions

This book is like any knowledge-based tool: there is a lot of material to sift through and not all of it is going to apply to you now. For some readers, the amount of material won't matter because you may have the time to read the book from cover to cover. For others, like me, computer books are for skimming and absorbing what is appropriate at the time and then, hopefully, for returning to later to read completely. For these types of readers, I have assembled a number of different sets of driving instructions to help you find what suits your situation most quickly.

No matter what happens, you are going to have to slice and dice the ideas, examples, and samples to fit your own situation, and I hope that the chapter introductions and book-driving instructions that follow help you to get the most out of the book.

Note  

Throughout this section, you may come across terminology that you may not be familiar with. I have deliberately not elaborated on the terminology at this stage, but I will do so at the appropriate times in the chapters referenced immediately following the terminology.

This book aims more at providing a comprehensive review of the protection and security topic than catering precisely to a particular reader skill level. As a result, the book has to cater to different audiences and cover a variety of topics. To help you digest the information relevant to you, I have prepared brief driving instructions for different topics or reader types, as follows .

Protecting Your Data Locally

First, you will need to turn off the all the startup options (Chapter 2), split your database (Chapter 4), protect your menus (Chapter 7), use workgroup security to protect startup options and your user interface (Chapter 8), and add workgroup security for your data (Chapter 10). To support your internal Access security, you can restrict the people who use your database by using operating system security (Chapter 12).

Securing Your Data Locally

Securing data is not easy and will require you first to follow the instructions in the previous "Protect Your Data Locally" section. Once you have all those elements working, you will need to implement the protected Access folder strategy (Chapter 12), look carefully at how you manage your workgroups (Chapter 10), and build a secure shortcut to open the database (Chapter 10).

Securing Software and Code

Making an MDE-format database will secure your forms, reports , and VBA code (Chapters 1 and 11). If you find that you have to stick with the MDB database format, you will need to read about developer workgroup security (Chapter 8) and securing your objects (Chapter 11). No matter what, you will need to split your database and add error handling to your database (Chapter 4).

Managers' Top Issues

Once a manager has identified his or her important databases (and for big companies, this process may involve sifting through a large number of them), there are some important issues to get on top of. Probably most important is ascertaining whether important data that may seriously damage your company if it is lost or ends up in the wrong hands is stored in the Access databases. To protect this data, you will need to verify that you are backing up and can recover the databases (Chapter 5), to protect your database properly by using internal security (Chapter 10), and to protect the databases by using the operating system (Chapter 12). On the software side, if you have any internally secured databases, you need to ensure that you have backups of the passwords and workgroup identifiers used to secure the databases (Chapter 8) and that you have access to the source code that is legally yours (Chapter 11). Finally, when your developers or DBA say that the Access database needs upgrading to another programming language or a server database, you can verify the value of that advice of that by collecting user statistics (Chapter 6).

Backing up Your Database

A very important part of protecting your database is having backups that you can recover (Chapter 5). To assist you with that process, you are going to need to find out who is using your database so that you can ask those users to log off (Chapter 6). Finally, if you are trying to secure your database, you will need to ensure that your users cannot prowl around the backup folders by using the Access protected folder strategy (Chapter 12).

Options for the Procrastinator

Procrastination is not an advised option when it comes to security, so let me suggest some easy habits. First, you should turn off the nonmenu startup options (Chapter 2). Next , you should identify the important objects in your database and hide them (Chapter 3). Now, turn off the nonmenu startup options (Chapter 7) and add some simpler menus and toolbars to make your database look more like a user interface than a developer interface. Put a note in your diary to review all the other options in two months.

Apologies to all Ye Hackers

In this book, I have been open about the issues caused by password-cracking software and quiet about some of the little issues that cause a threat. In some cases, I crafted the information to help you avoid a particular threat without actually discussing how you could take advantage of that threat to exploit a particular vulnerability of Access. So if you are thinking of using this book as a guide to help you pilfer someone's database asset, you will be a little disappointed.

Protecting and Building a Better Interface

One side benefit of introducing protection and security measures is that you can improve the interface. To do so, look at the startup options (Chapter 2), better error messages (Chapter 4), and protecting menus (Chapter 7). Sometimes when you're working on a software database that has many forms and reports, you just cannot decide what the best thing to improve next is. For those times, I recommend user object logging (Chapter 6), which will help you ascertain what objects are being used the most.

The Server Database Option

If you have determined that you want to transfer your database to SQL Server or some other server-based database (Appendix C) for performance, stability, or enterprise-level security, first ensure that you have split your database (Chapter 4) and then ascertain user levels and which objects are being used the most (Chapter 6). For the bigger conversion, it would be a good idea tto freeze the design of all the tables and objects by using workgroup security (Chapters 8 and 10) at the same time that you start setting up the test projects for migration.

The Author's Highlights From the Book

While I am protecting a database, I always like to set up the secure menus (Chapter 7). I really enjoyed when I found out that you can actually set up an Access group account in your default workgroup file. If you combine that with a secure Windows XP/2000 local directory, you can open a workgroup-secured database by using operating system security (Chapter 8). My favorite discovery came near the end when my good friend John Reidy and I worked out how to establish protected folders so that users could not copy the database (Chapter 12). At that stage, I realized that we now had a way to make Access databases pretty secure again.