0587-0590

Previous Table of Contents Next

Page 587

CHAPTER 24

Database Security

IN THIS CHAPTER

  • Authentication
  • Why Protect Passwords?
  • Privileged Accounts
  • Remote Passwords
  • Object Versus System Security
  • Object Security Model
  • Defining Database Roles
  • Database Auditing

Page 588

"Good morning, Jim. Your mission, should you choose to accept it." So began the television series Mission: Impossible . This chapter begins with that sound bite in a sense of homage. Like the title theme of that show, database security is a mission that ultimately the DBA must accept. There are some sites where database security is simply not done; virtually everyone has access to virtually everything. The assumption is that everyone knows what he is doing, so nothing should be restricted. Other sites put a premium on security and regularly use exotic designations, such as B1 and C2. It takes what seems like an act of Congress for anyone to accomplish anything. Most Oracle sites, though, fall comfortably in the middle.

As the industryOracle in particularmoves toward open systems such as UNIX, there is a greater need to configure and monitor an adequate database security plan. Many users do not care a great deal about how the security for the database is configured. Their burning desire is to be able to do their jobs. Power users, however, want to push the envelope to see exactly what they can do. They might be motivated by their technical knowledge or even by sheer ego; they think they should have more power than other users.

Most of the conflict comes from software developers, analysts, and management. In an age when MIS departments are constantly trying to justify their existence against the threat of out-sourcing, it is far simpler for managers to authorize everyone in the organization to have privileged access than to invest the time in a proper setup. Developers and analysts vocally proclaim that they are being handcuffed and cannot do their jobs unless they are given access. In many cases, they simply need information contained in a table or a view owned by SYS or SYSTEMthe DBA-level views, for examplethat makes them need DBA access.

Implementing a security plan, therefore, involves theory more than many other topics do, including the backup and recovery plan or user management. If a DBA undertakes a security plan, he accepts responsibility for enforcing the plan and determining the level of security that best suits the needs of his organization. Some organizations have groups of security administrators dedicated to this task. In practice, this becomes yet another task appended to the great "DBA job description in the sky."

This chapter focuses on the core ideas associated with implementing a security plan. It offers suggestions for a common security methodology.

Authentication

As discussed in Chapter 21, "Managing Users," there are two distinct methods of database authentication: password authentication and operating system authentication. With password authentication, the user must enter a unique word or character sequence to gain access. With operating system authentication, the Oracle database permits access to the database based on whether a corresponding user account exists for the current operating system account. When implementing either method, the DBA needs to be aware of various security concerns and constraints.

Page 589

Password Authentication

Password authentication is the more traditional method of user authentication. Although passwords are relatively secure, they have shortcomings that can make them more vulnerable to breach or attack.

In most cases, each user creates his own password. People usually like to keep things simple, which can make password authentication vulnerable to attack. Users who have access to multiple databases often use the same password repeatedly. This creates a massive security breach if a user's password is compromised, enabling the offending party to access all the databases that share the password. Oracle has no mechanism that forces a password change.

Passwords should conform to the following general standards:

  • They should be at least six characters in length.
  • They should contain a combination of characters and numbers or special characters that represent the actual spelling of words (such as S1ckle for sickle). Oracle database passwords, however, cannot contain spaces.
  • They should not contain obvious passwords.
  • They should be changed frequently.

There are only two ways to enforce this level of database password security: user education and third-party products. Neither is an easy solution. A few products on the market, such as SQL<>Secure by BrainTree Technology, give the DBA the latitude to set rules for passwords. Most sites, though, must simply try to educate users about how to set passwords properly. Unless a custom interface is used, it is impossible to prevent users from selecting simple passwords.

A number of public domain programs available on the Internet attempt to break into databases that use common types of passwords. Using the password standards helps minimize the chance that these programs will break inalthough it cannot eliminate the possibility. Some of the more common passwords that programs of this nature scan for are

  • Name of userfirst, middle, last, or account name
  • Name of spouse, children, or pets (more often tried by co-workers or hackers than security programs)
  • Colors
  • Simple words that many password-cracking programs contain in their data dictionaries

This list is by no means exhaustive, but it should provide a basis for judging the effectiveness of a given password. The bottom line on password authentication, however, is training users to use good passwords. Some DBAs use a program that attempts to crack a user's passwords and sends an e-mail to the user indicating that his password has been cracked. This should either induce a sense of paranoia among users or cause them to think seriously about password security.

Page 590

Operating System Authentication

Operating system authentication methods require an underlying password at the operating system level, so it is important to keep in mind the security ramifications of the use of accounts that are authenticated at the operating system level. This means that the Oracle database confirms whether an accountusually prefixed by OPS$exists within the database that corresponds to an operating system account. In this way, the operating system vouches for the user to the database. If the match is successful, the user is allowed access.

If used properly, operating system authentication is reasonably secure. No passwords need to be changed under this method. Connecting to the database is as simple as issuing a null user name and password. For example:

 sqlplus / 

There is a price, however. Anyone with access to the operating system account also has access to the database account. This can take a variety of forms. Aside from someone guessing or learning a user's password, there are other considerations. The system administrator, who has the root password (on a UNIX system), can switch between user accounts without the password. This is generally not a security issue because the system administrator is considered privileged. Even so, the DBA should be aware of this capability and that the system administrator can switch to other non-root privileged accounts, such as oracle.

Under UNIX, it is possible that a user might access another user's account by means of rlogin. Essentially, a file called .rhosts is optionally located in the user's home directory. This file contains the host machine and the username, thereby enabling a specified user on a specified machine to perform rlogin without needing the password. For example:

 % hostname sandbox % whoami natashia % cd /users/boris % ls .rhosts .rhosts % cat .rhosts sandbox natashia % rlogin sandbox -l boris % whoami boris 

An account that is authenticated by the operating system is only as secure as the password that protects the operating system account. If proper precautions are taken, though, this method is highly reliable and often more secure than password authentication.

Why Protect Passwords?

With all the discussion about authentication methods and protecting accounts, it is common to wonder why it is necessary. Depending on the environment in which the database operates,

Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

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