Section 18.5. Securing Your Database


18.5. Securing Your Database

In most shared databases, different people perform different tasks . The easiest way to keep everyone on the right track is to create several distinct front ends, one for each group of people. This lets you gently guide people along in the tasks they perform.

However, customizing the front end doesn't restrict the abilities of a determined troublemaker. In a large company that relies on a multiuser database, you don't just think about guiding peopleyou also worry about restricting them.

Sadly, Access 2007 provides a limited security model. You have the ability to lock strangers out of a database with a password, but you don't have the more finegrained features you need to restrict a single user from using certain tables or performing certain actions. As you'll see in the following sections, there are possible workarounds, but none works as well as the security provided by a server-side database product like SQL Server.


Tip: Once again, Access gives you just enough to make shared databases work, but not much more. It's up to you to decide whether Access works for your organization. Small outfits are likely to find that it's perfectly fine, while large organizations may want a server product.

18.5.1. Password-Protecting Your Database

The password protection feature in Access offers simple, no-frills security. You choose a single password for your database, and from that point on it can't be opened without the password. Even better, the data in your database file is scrambled using a key that's generated from your password. This ensures that even if high-tech hackers peer directly into your database file with a specialized tool, they won't be able to retrieve any data.

NOSTALGIA CORNER
Workgroup Security Gets Locked Out

Old-hand Access experts may remember that previous versions of Access included a much more useful form of userlevel security called workgroup security. With workgroup security, Access keeps a separate file that identifies what each user and group is allowed to do with the database. Workgroup security is easier to implement than file-based security, and a lot more flexible. In fact, it seems like the perfect solution.

Unfortunately, workgroup security was never truly secure. Well-published workarounds could be used to circumvent it. Most of the time, this wasn't a problem because Access experts weren't really worried about stopping skilled hackers. Instead, they were more concerned with keeping ordinary people under control.

However, in recent years Microsoft has become increasingly obsessed with security. When Microsoft prepared Access 2007, it decided it could no longer support a security feature that wasn't truly secure, especially when better options are available in other products, like the free version of SQL Server (see Section 20.1.2). For that reason, Microsoft removed support for workgroup security in .accdb files. You can still use workgroup security if you use older .mdb files (see Section 1.2.2 to learn about the difference), but that's only a good idea if you need to keep supporting a database that you designed with an older version of Access. New databases should always be created as .accdb filesafter all, Access has earmarked it as the database format of the future.



Note: In Access 2007, password protection gets serious. Now, Access uses state-of-the-art encryption to ensure that skilled hackers can't crack open your files with specialized toolsat least not unless they're willing to devote a huge amount of time to the task.

It's ridiculously easy to apply a password. Here's how:

  1. Choose Office button Open .

    To apply a password, you need to open your database in Exclusive mode. This step is necessary because Access can't encrypt a database while it's in use.

  2. Select the file you want to open, click the drop-down arrow on the Open button, and then choose Open Exclusive .

    Access opens the database in Exclusive mode.

  3. Choose Database Tools Database Tools Encrypt with Password .

    Access asks you to supply a password (Figure 18-14).

  4. Enter your password, and then click OK .

    To ensure that your database is secure, you need to choose a strong password. Good passwords are long (ten letters or more), can't be found in the dictionary (because attackers use dictionaries to launch automated attacks), use mixed case, and include special characters (like numbers , punctuation, and other symbols). The password hellodata is a poor choice, while w0nDER_wh@t_32 is much more reliable.

    Figure 18-14. Just to be sure, Access asks you to enter the password twice.


    Access uses the password to encrypt your database, and then saves the modified database automatically. Now, the next time you open your database you'll be asked to supply the password first.

    If you decide that you don't need password protection later on, click Remove Database Password and Encryption.

18.5.2. Passwords and Split Databases

It's fairly obvious how passwords work with ordinary databases, but a few interesting quirks are at work with shared databases. First, you always use the password to protect the back-end databaseafter all, it's the data that you need to protect, not your forms and reports . But here's the interesting bit: When you create a front end that links to a password-protected back end, Access quietly stores the password in the front end. That means that as along as you use the right front end, you don't need to supply the password at all.


Note: In order to successfully use a password with a back-end database, you must apply the password before you split the database. Otherwise, Access won't store the password in the front end, and the linked tables won't work.

Technically speaking, this model doesn't provide industrial-strength security, because a crafty hacker could steal the password by digging through the front-end database file. However, as long as you make sure your front ends don't get into the wrong hands, you have some interesting possibilities:

  • You can keep the password secret, which prevents people from accessing the back end directly . Instead, they'll need to rely on the front end you distribute, which has the password embedded.

  • You can protect the front end with another password . That way, a sneaky hacker who steals your front end will still be locked out of the database.

  • You can split the back-end database into separate files (as described in Section 18.2.4) . That way, you can give each file a separate password and prevent people from accessing the wrong tables. Unless their front end has a link to the back-end database they need, they won't be able to use its tables.

18.5.3. Using Windows File Security

Password protection isn't your only security choice. You can also use Windows security to specifically set which users and groups can access a file.

In order to make this work, you need to split your back end into more than one file, as described in Section 18.2.4. Then, once the files are in the shared folder, you can configure exactly who is allowed to access each one. Hopefully, you have a network administrator to help you out. The basic process works like this:

  1. Using Windows Explorer, right-click the database file you want to protect, and then Choose properties .

    The Properties window appears, with several tabs of information about the file.

  2. Choose the Security tab (Figure 18-15) .

    Windows keeps track of people in two waysit identifies them uniquely by user name , and it categorizes entire groups of people by group name . For example, you can log in as MarkHamlon and be a member of several groups, including Users, Administrators, SalesDepartment, and so on. That gives an administrator the ability to change the security settings for a single individual or for a whole crowd of people with one rule.

    Figure 18-15. The Security tab lists all the people (and groups) who are allowed to use this file, and it indicates what they're allowed to do. In this example, every user and group name is preceded by the term FARIA\ because the name of the computer where the user accounts are defined is FARIA.


  3. To change what a person or group can do with the file, select them in the list, and then change the Allow or Deny options (Figure 18-16) .

    Say you don't want the people in the Users group to be able to use this file; select the Users group in the list, and then place a checkmark in the Deny column next to each permission.


    Note: The Deny options always take precedence. For example, if a person is a member of two groups, and one group is allowed to use a file but the other isn't, the Deny setting overrides everything else.

    Figure 18-16. If the checkbox is grayed out, that's because the setting is inheritedin other words, it's based on the folder that contains this file. For example, you can't change the Allow settings of the Users group, because they're inherited. However, you can add Deny settings (as shown here with the user named RemoteUser). The Deny settings always overpower the Allow settings.


  4. If you want to add a new group or person to the list, click the Add button, fill in the user or group name, and then click OK .

    You may decide you don't want to lock out an entire group but you want to single out a specific person.

Windows file security gives you a very basic level of security. It isn't really designed to work with Access databases. In order to use it at all, you need to split your database into smaller and smaller pieces, which can be difficult to manage. You also can't control what actions a person is allowed to performthe file security either locks people out entirely or gives them full control to add, delete, update, and redesign the information in your database.

If you need real user-level security, you're better off with a server product like SQL Server. However, if you just need the ability to keep some sensitive information out of reach, the file-based security features can help you out.



Access 2007[c] The Missing Manual
Access 2007[c] The Missing Manual
ISBN: 596527608
EAN: N/A
Year: 2007
Pages: 153

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net