DBMS Security Guidelines

DBMS Security Guidelines

Guidelines for improving security in database systems are listed in Figure 9-15. First, the DBMS must always be run behind a firewall. However, the DBA should plan security with the assumption that the firewall has been breached. The DBMS, the database, and all applications should be secure even if the firewall fails.

DBMS vendors, including IBM, Oracle, and Microsoft, are constantly adding product features to improve security and reduce vulnerability. Consequently, organizations using DBMS products should continually check the vendors’ Web sites for service packs and fixes; any service packs or fixes that involve security features, functions, and processing should be installed as soon as possible.

The installation of new service packs and fixes is not quite as simple as described here. The installation of a service pack or fix can break some applications, particularly some licensed software that requires specific service packs and fixes to be installed (or not installed). It may be necessary to delay installation of DBMS service packs until vendors of licensed software have

Chapter 9 Managing Multiuser Databases

• Run DBMS behind a firewall, but plan as though the firewall has been breached • Apply the latest operating system and DBMS service packs and fixes • Use the least functionality possible

• Support the fewest network protocols possible • Delete unnecessary or unused system stored procedures • Disable default logins and guest users, if possible • Unless required, never allow users to log on to the DBMS interactively

• Protect the computer that runs the DBMS

• No user allowed to work at the computer that runs the DBMS • DBMS computer physically secured behind locked doors • Visits to the room containing the DBMS computer should be

recorded in a log • Manage accounts and passwords

• Use a low privilege user account for the DBMS service • Protect database accounts with strong passwords • Monitor failed login attempts • Frequently check group and role memberships • Audit accounts with null passwords • Assign accounts the lowest privileges possible • Limit DBA account privileges

Figure 9-15

• Planning

• Develop a security plan for preventing and detecting security problems Summary of DBMS Security

• Create procedures for security emergencies and practice them Guidelines

upgraded their products to work with the new versions. Sometimes just the possibility that a licensed application might fail after a DBMS service pack or fix is applied is sufficient reason to delay the fix. But, the DBMS is still vulnerable during this period. Pick your regret!

Additionally, database features and functions that are not required by the applications should be removed or disabled from the DBMS. For example, if TCP/IP is used to connect to the DBMS, other communications protocols should be removed. This action reduces the pathways by which unauthorized activity can reach the DBMS. Further, all DBMS products are installed with system-stored procedures that provide services such as starting a command file, modifying the system registry, initiating e-mail, and the like. Any of these stored procedures that are not needed should be removed. If all users are known to the DBMS, default logins and guest user accounts should be removed as well. Finally, unless otherwise required, users should never be allowed to log on to the DBMS in interactive mode. They should always access the database via an application.

In addition, the computer(s) that runs the DBMS must be protected. No one other than authorized DBA personnel should be allowed to work at the keyboard of the computer that runs the DBMS. The computer running the DBMS should be physically secured behind locked doors, and access to the facility housing the computer should be controlled. Visits to the DBMS computer room should be recorded in a log.

Accounts and passwords should be assigned carefully and continually managed. The DBMS itself should run on an account that has the lowest possible operating system privileges. In that way, if an intruder were to gain control of the DBMS, the intruder would have limited authority on that local computer or network. Additionally, all accounts within the DBMS should be protected by strong passwords. Such passwords have at least 15 characters and contain upper- and lowercase letters; numbers; special characters, such as +, @, #, ***; and unprintable key combinations (certain Alt + key combinations).

The DBA should frequently check the accounts that have been assigned to groups and roles to ensure that all accounts and roles are known, authorized, and have the correct permis- sions. Further, the DBA should audit accounts with null passwords. The users of such accounts should be required to protect those accounts with strong passwords. Also, as a general rule, accounts should be granted the lowest privileges possible.

Part 4 Multiuser Database Processing

As stated, the privileges for the DBA should normally not include the right to process the users’ data. If the DBA grants him- or herself that privilege, the unauthorized grant operation will be visible in the database log.

In the spring of 2003, the Slammer worm invaded thousands of sites running SQL Server. Microsoft had previously released a patch to SQL Server that prevented this attack. Sites that had installed the patch had no problems. The moral: Install security patches to your DBMS as promptly as possible. Create a procedure for regularly checking for such patches.

Finally, the DBA should participate in security planning. Procedures both for preventing and detecting security problems should be developed. Furthermore, procedures should be developed for actions to be taken in case of a security breach. Such procedures should be practiced. The importance of security in information systems has increased dramatically in recent years. DBA personnel should regularly search for security information on the Web in general and at the DBMS vendor’s Web site.