Importing Objects From Other Databases

The number-one security concern for an Access database is the Import menu command. Importing is a double-edged sword when it comes to security. When securing your database, you need to import all the objects into a new database to change ownership. Conversely, any database that you have protected with measures such as startup options and menus is completely vulnerable if someone imports all the objects into a blank database.

So, what are the main problems exposed with importing?

• The startup options, such as Show Database Window, Allow Bypass Key, and Menus Protection, are not transferred.

• Ownership of all objects will change to the current workgroup user .

• If objects are hidden, they may not be transferred unless you choose the Show Hidden Objects option (Tools ˜ Options ˜ View). This issue can cause problems if the imports are used for legitimate purposes.

• Database options (discussed in Chapter 3) are not transferred, so some of the protection measures will be lost.

Now that we have established that importing is a problem, you may want to use some of the following measures to protect against it:

• Operating system permissions will stop people from using the importing option on a database where a Windows user account cannot read the contents of the folder (see Chapter 12).

• Hiding objects in the Database window is one way to fool the importer. If you want to use this approach, it is better to hide a small number of important objects so that the protection measure is less noticeable. Hiding all the tables, for instance, will be obvious. You may want to turn tables into system tables, as discussed in Chapter 3.

• Workgroup security is the secure way of protecting forms, reports , and macros from importing. To set this security, you should either use the developer workgroup strategy discussed in Chapter 8 or the Access user-level security wizard discussed in Chapter 10.

• Review the module protection measures described in Chapter 8.

• Compiling the database into MDE format will completely secure forms, reports, and modules from being imported. See Chapter 11 for more details.

• To secure tables, you need to implement the workgroup security discussed in Chapter 10. If you need to deny access to the table or query design, use the developer strategy described in Chapter 8. Then implement the Read with Owner Access permission queries, described in Chapter 11.

• If you have permission from the IT manager or DBA, you can disable built-in menu items by using the strategy outlined in Chapter 7. This action can include turning off the Import menu command.

• Install a runtime version of Access on computers where there is little need for Access's development features. This action will hide the Import menu command (discussed in Chapter 7).

• You can move queries to SQL strings and store them in Form and Report properties and VBA code to make them more secure. If you use the same SQL string more than once, be careful how you do it.

When you have digested that long list of protection measures, the next topic that you need to contemplate is that of database encryption.