Database Reference
In-Depth Information
• 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
• Planning
• Develop a security plan for preventing and detecting security problems
• Create procedures for security emergencies and practice them
Figure 9-16
Summary of DBMS Security
Guidelines
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 un-
printable 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, are authorized, and have the correct per-
missions. Further, the DBA should audit accounts with null passwords. The users of such ac-
counts should be required to protect those accounts with strong passwords. Also, as a general
rule, accounts should be granted the lowest privileges possible.
As stated, the privileges for the DBA should normally not include the right to process the
users' data. If the DBA grants himself or herself that privilege, the unauthorized grant opera-
tion 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 prevent-
ing 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
 
Search WWH ::




Custom Search