|
The need for database security is an unfortunate fact of life. As with your house, car, office, or briefcase, the level of security required for your database depends on the value of what you have and whether you are trying to protect it from curious eyes, accidental damage, malicious destruction, or theft.
The security of a company’s business information can be critical to its survival. For example, The Garden Company’s owners might not be too concerned if a person gained unauthorized access to their products list, but they would be very concerned if a competitor managed to see—or worse, steal—their customer list. And it would be a disaster if someone destroyed their critical order information.
Your goal as a database developer is to provide adequate protection without imposing unnecessary restrictions on the people who should have access to your database. The type of security required to protect a database depends to a large extent on how many people are using it and where it is stored. If your database is never opened by more than one person at a time, you don’t have to worry about the potential for corruption caused by several people trying to update the same information at the same time. If many people access the database to work with different types of information, you will want to consider setting up workgroups and assigning permissions to restrict the information each group can see and the actions they can perform. If your database is sold as part of an application, you will want to take steps to prevent it from being misused in any way.
In this chapter, you will explore various ways to protect data from accidental or intentional corruption and to make it difficult for curious eyes to see private information.
See Also
Do you need only a quick refresher on the topics in this chapter? See the Quick Reference entries in Chapter 9 Keeping Your Information Secure.
Important
Before you can use the practice files in this chapter, you need to install them from the book’s companion CD to their default location. See "Using the Book’s CD-ROM" for more information.
A database created with Microsoft Office Access 2003 is a binary file, meaning that it is composed of mostly unreadable characters. If you open it in a word processor or a text editor, at first glance it looks like gibberish. However, if you poke around in the file long enough, you will discover quite a bit of information. Most likely, not enough information is exposed to allow someone to steal anything valuable. But if you are concerned that someone might scan your database file with a utility that looks for key words, you can encrypt the file to make it really unreadable.
Encrypting a file doesn’t prevent it from being opened and viewed in Access. It does not add password protection or any other kind of security. But it does keep people who don’t have a copy of Access from being able to read and perhaps make sense of the data in your file. The only difference you might notice when opening an encrypted database in Access is that some tasks might take slightly longer. If this is an issue, you will want to decrypt it before you work with it.
In this exercise, you will encrypt and decrypt the GardenCo database.
BE SURE TO start Access before beginning this exercise.
USE the GardenCo database in the practice file folder for this topic. This practice file is located in the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder and can also be accessed by clicking Start/All Programs/Microsoft Press/Access 2003 Step by Step.
OPEN the GardenCo database and acknowledge the safety warning, if necessary.
On the Tools menu, point to Security, and then click Encode/Decode Database.
The Encode Database As dialog box appears.
Navigate to the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder, type
GardenCo_Encodeas the name of the encrypted file you want to create, click Save, and acknowledge the safety warning.An encrypted version of the database is created, but you continue to work in the original GardenCo database. You could have saved the encrypted database with the same name (you would be warned that you were overwriting an existing file), but this way you can compare the two versions.
Close the database, and start a text editor, such as Microsoft Notepad. On the File menu, click Open. In the Files of type box, click All Files, navigate to the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder, and then click GardenCo.
Close the GardenCo database, and open GardenCo_Encode in the same text editor.
It would be difficult to make much sense of the original file, and the same section of the encrypted version is even less meaningful.
Close the text editor.
Start Access, and navigate to the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder. Double-click GardenCo_Encode, and acknowledge the safety warning, if necessary.
The encrypted file looks identical to the original.
Tip
Encrypting a database compresses it, but the amount of compression is minimal. Using the Compact and Repair utility provides more compression. Using a third-party compression program such as WinZip provides far more compression than either of the other methods and has the added benefit of effectively encrypting the database.
Close the GardenCo_Encrypt database.
To decrypt the encrypted database, on the Tools menu, point to Security, and click Encode/Decode Database.
In the Encode/Decode Database dialog box, navigate to the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder, click GardenCo_Encode, and then click OK.
The Decode Database As dialog box appears.
In the File name box, type
GardenCo_Decode, and click Save.Quit Access.
Click the Windows Start button, navigate to the My DocumentsMicrosoft PressAccess 2003 SBSSecureEncrypt folder, and then compare the size of the three databases.
Decrypting a database doesn’t uncompress it, so usually the difference in size between the encrypted file and the decrypted file, if any, is minimal.
