User Security

The most common methods used to implement user security are passwords and roles . It is advised that each user be required to enter an ID and a password when accessing the database. This ID and password can and should be in addition to any network (for example, NT) ID and password. In addition, many shops have a change schedule for passwords, usually about 60 days. Regular changes of passwords are also thought to help reduce the risk of unauthorized access. Just be aware that both internal and external auditors are now taking a very close look at computer security, and this will be one of your major responsibilities for the foreseeable future.

Roles are a very common way of handling security. Think of a role as a cloak or special coat. Here's an example: To handle the payroll process at one particular company, 8 database programs are involved. There are 14 payroll staff. You can either take the time and give all 14 staff members the rights to each of the 8 programs, or you can create a role that has rights to the 8 programs and then assign the 14 payroll staff members that role.

Note

Let me push the analogy a bit and tell you that a user can have many roles, so you can think of a role as a hat, with users having many hats to go with their many cloaks. (I hear your groans...)

What's the advantage of using roles? Well, if you suddenly needed 9 programs for payroll, you would just change the role instead of each staff member's security. Conversely if your payroll system dropped to 6 programs, again you would just change the role instead of performing an emergency change to 14 accounts.

Special consideration must be given to the very sensitive administration accounts. These are accounts with the IDs SYS and SYSTEM , and their passwords should be changed as soon as the system is installed. In addition, roles are usually created for all DBAs. These roles contain the various administrative privileges that a DBA has. The same scheme that I described for the preceding payroll example is followed.

Then we have the programmers, or application developers. Perhaps the best way to protect the system is to allow the developers much freedom in a test environment, and then completely restrict them in the production environment. In many cases, there will be several test databases that various development groups will use, and within their own database the developers will have a fairly free hand.