Time for Reflection

We are now at a stage where you have a way to make your database protected in either read-only mode or totally secured from the anonymous Admin user and the ubiquitous Users group . You also know how to allow another person to manage data in your databases without being able to change objects, if that's how you want to play the game.

At this stage in the development lifecycle of an Access database, I like to recommend to the client that we watch to see how the application develops before proceeding with any more security enhancements. I have been involved in many Access development exercises, and I have found that unless you start adding the security late in the project, you tend to waste both the developer's and the DBA's time by repeating work. By holding out on security, testing will not take as long and you will be far wiser as to how people will use your application. Probably the best approach is to implement other, simpler protection systems like startup options, menu control, and operating system security before embarking on a full implementation of workgroup security. By introducing security later in the development cycle, users will be more comfortable with the application. At that time, your database and user base will have grown to the extent that you will be ready to invest more time in data security. In the meantime, here are some background issues to reflect on.

Organize Your Users in Groups

Ever since the early days of computing, the model of organizing users into groups and then assigning permissions to the groups has been prominent. Access work-group security has been built to use this approach, and I highly recommend that you use groups for managing permissions for data and objects because it is far easier to manage than assigning permissions for individual users. The processes that you would use to add a new person to a workgroup-protected database sums up why this method works well.

• Establish object permissions for the Group accounts. This information is stored in the database and is completely independent of the workgroup file itself.

• If a person needs access to a database, you can add that user's account to the workgroup and then add that account to a user group.

• If that person needs different permissions, you will remove the account from the first user group and assign the account to another user group.

• When that person leaves the company or the department, you will remove their account from the workgroup file, which automatically deletes the user account from any group that he or she belongs to.

• Meanwhile, the object permissions that you have set up for those user groups in the database remain the same.

This is a good management model for Access databases, irrespective of whether they are developed on-site or off-site. It works well because you can manage the accounts in the workgroup file on-site and set up the group permissions on objects in front-end databases anywhere .

The only time that I advocate adding permissions for a single user is for the Developer account. In this case, adding permissions for a single account makes reconciliation between ownership and developer permissions a little easier to conceptualize, as ownership is assigned by the user account rather than by a user group. Of course, if more than one person is developing the database, granting permissions to the Admins group is a good idea.

Employee Security Considerations

Another important security consideration are the employees of your company and how they handle issues that can directly or indirectly affect your database. I have been at a number of client sites where all the good intentions of security seem to come to naught because of the way people use the systems. First, remember that good old genie in the bottle , the password. Access passwords, because they are specific to a computer system and aren't tied to more personal material such as email or documents, seem to be treated with too little respect.

Another prevalent Access- related security issue that I have noticed seems to be when people hand over a password to another person so that person can get on with a job that isn't officially their responsibility. For example, some data is missing on the daily report. The data-entry person is working on some other urgent task when someone enquires about the missing data entry. In this case, the data-entry person passes on his password to the enquirer so that she can complete the data entry. At this stage, the integrity of the system is compromised, and the person who passed on his password should actually change his password. But he doesn't!

How can this sort of issue be addressed? First of all, the users of important parts of the system need to be informed of their obligations to protect user names and passwords. Second, a system of regularly changing passwords needs to be enforced. Another approach that I advocate is that the developer and the DBA need to make time to observe how users are interacting with the database because such observation may lead to insights as to how better to design and protect the user interface and data.

Note  

If you think that you have a problem with users trading passwords and workgroup accounts, have a look at the user logging software in Chapter 6.

So, if you are thinking of heading down the path of passwords and secure users, please make sure that the software users understand their security obligations. You should also regularly review security issues that occur because managing security is yet another adventure in the process of maintaining ever-changing databases.

Investigate Operating System Security as an Alternative

You may now be at a point where you are sharing the developer workgroup file with users, so you might consider it more appropriate to work on operating system security as the next step that you take to protect your database. Operating system security is discussed at length in Chapter 12. Anyone who already has a workgroup-secured database or is considering using the User-Level Security wizard (discussed in the next section) is at the stage where you need to decide which direction to head next .

Beware of Falling Through the Cracks

If you remember from the last chapter on security concerns, allowing more than one person to use your workgroup file exposes your database to password-cracking software. Therefore, as we move further into workgroup security, it is important to reflect that it is not difficult for anyone who has access to a workgroup file to find out a password to an account that has more permissions. So, as we move on to allocating permissions to different groups of users, please temper your enthusiasm for workgroup security with the knowledge of the relative ease that password-cracking software can be obtained. To counter this issue, once you have completed the section on security wizards, I will describe a system, which I have labeled PID authentication, that will make it a lot harder for users to break into other work-group accounts with different permissions.