Database Hardening Best Practices

This checklist was developed by IST system administrators to provide guidance for securing databases storing sensitive or protected data. Implementing these security controls will help to prevent data loss, leakage, or unauthorized access to your databases.

Physical Database Server Security

  • The physical machine hosting a database is housed in a secured, locked and monitored environment to prevent unauthorized entry, access or theft.
  • Application and web servers are not hosted on the same machine as the database server.

Firewalls for Database Servers

  • The database server is located behind a firewall with default rules to deny all traffic.
  • The database server firewall is opened only to specific application or web servers, and firewall rules do not allow direct client access.   If the development environment cannot meet this requirement, then protected data is not stored in the development database server and mock data is made up for development.  Data obfuscation of production data is not sufficient.
  • Firewall rule change control procedures are in place and notification of rule changes are distributed to System Administrators (SAs) and Database Administrators (DBAs).
  • Firewall rules for database servers are maintained and reviewed on a regular basis by SAs and DBAs. If using the IST provided firewall service, the rules are also regularly reviewed by the Information Security Office (ISO).
  • Regularly test machine hardening and firewall rules via network scans, or by allowing ISO scans through the firewall.

Database Software

  • The database software version is currently supported by the vendor or open source project, as required by the campus minimum security standards.
  • All unused or unnecessary services or functions of the database are removed or turned off.
  • Unneeded default accounts are removed, or else passwords are changed from defaults.
  • Null passwords are not used, and temporary files from the install process that may contain passwords are removed.
  • Database software is patched to include all current security patches. Provisions are made to maintain security patch levels in a timely fashion.

Application / Web Servers / Application Code

  • Destination systems (application/web servers) receiving protected data are secured in a manner commensurate with the security measures on the originating system. All servers and clients meet minimum security standards.
  • All servers, applications and tools that access the database are documented.
  • Configuration files and source code are locked down and only accessible to required OS accounts.
  • Application code is reviewed for SQL injection vulnerabilities.
  • No "Spyware" is allowed on the application, web or database servers.

User/Client Workstations

  • If users are allowed protected data on their workstations, then client workstations meet the minimum security standards.
  • If users are allowed protected data on their workstations, then the workstation is protected against unauthorized access to a session by deploying screen savers. Users understand the requirement to lock their workstations when leaving the station.
  • If users are allowed protected data on their workstations, then the workstation should require an individual login and password.
  • If users are allowed protected data on their workstations, then protected data on the client workstation is encrypted by the workstation’s operating system.
  • Protected data is not stored on transportable devices.
  • Protected data is never sent via email, either in the body or as an attachment, by either users or as an automated part of the system.
  • Protected data that is no longer needed is routinely deleted.
  • If users are allowed protected data on their workstations, then no "Spyware" is allowed on the client workstations.

Administrator Accounts / Permissions / Passwords

  • DBAs understand their responsibility for reviewing all requested script and database changes to ensure the security of the system is not compromised.
  • Accounts with system administration capabilities are provided to as few individuals as is practical, and only as needed to support the application.
  • All Developers, Vendors, SAs, DBAs & Contractors have signed a non-disclosure agreement.
  • All developers, SAs, DBAs and contractors have passed a criminal background check if required by the background check policy. The background check policy may be found athttp://campuspol.chance.berkeley.edu/Policies/BackgroundChecks.htm
  • Operating system accounts used by DBA staff to login to dataserver machines for administrative duties are individual accounts, and not a shared group account.
    • When possible, the daemon OS account that is required to run the dataserver process does not allow a direct login.
    • Instead, individual OS accounts are used to login, then sudo or su to the daemon account (for UNIX) or disallow desktop login (Windows).
  • Database accounts used by DBA staff for administrative duties are individual accounts, and not a shared group account.
    • A group account is permitted for running automated DBA maintenance and monitoring jobs, such as backups.
    • This group account is not used for daily interactive tasks by the DBA group, except when required to troubleshoot maintenance and monitoring jobs.
  • Passwords for all DBA operating system accounts and database accounts are strong passwords, and are changed when administrators/contractors leave positions. See: Password complexity guidelines
  • If the DBA and developer roles are being filled by a single person, changes are approved by the Data Proprietor.

User Database Roles / Permissions / Passwords / Management & Reporting

  • Secure authentication to the database is used.           
  • The procedure for provisioning and reviewing access to the database is documented. The data proprietor has signed the procedures document.
  • Only authorized users have access to the database.           
  • Users are granted the minimal permissions necessary for their job function in the database. Permissions are managed through roles or groups, and not by direct grants to user IDs where possible.           
  • Strong passwords in the database are enforced when technically possible, and database passwords are encrypted when stored in the database or transmitted over the network.           
  • Applications require individual database login/password and roles/grants when possible. When not possible, application accounts may be utilized. However, the login ID and password must be secured in this case, and this information does not exist on the client workstation.
  • Applications should manage user permissions and auditing to meet the Data Proprietors requirements.           
  • User database objects with protected data do not have public grants when possible. Document any public grants if needed in databases with protected data.           
  • Non-DBA accounts do not allow the granting of roles or permissions in any environment with protected data (QA, Production, Dev).
  • Database accounts are locked after at most six failed logins.           
  • Procedure to address inactive users are documented and approved by the Data Proprietor.           
  • A report of elevated database permissions is provided to the data proprietor by the DBAs on a quarterly basis.
  • A report of all access rights for users is provided to the data proprietor by the DBAs on a regular basis. Twice a year is the recommended interval.

Protected Data

  • Only the protected data required for the business function is kept within the database. When possible, historical information is purged when no longer required.
  • Redundancy of protected data is eliminated throughout the system, and shadowing of protected data outside the system of record is avoided wherever possible. Hashing functions are applied to protected data elements before storing if the data is only required for matching purposes. If possible, disassociate protected data from personally identifiable information and keep offline until needed. If data transfers are required for other applications, notify them of protected data and its security requirements.
  • Protected data in non-production environments is held to the same security standards as production systems. In cases where non-production environments are not held to the same security standard as required in production, data in these non-production environments must either be encrypted using industry-standard algorithms, or else test data must be made up for these systems. Data obfuscation is not sufficient.
  • The protected data elements within the database are documented.
  • Protected data is never used as a key in a table.

Change Management

  • Change management procedures are documented and meet the data proprietor’s requirements.           
  • Change management controls are in place to log all changes to the production database.           
  • All programs scheduled to run against the database which read or modify production data are documented.           

Database Auditing

  • All logins to operating system and database servers, successful or unsuccessful, are logged. These logs are retained for at least one year.
  • Database objects with protected data have auditing turned on where technically possible.           
  • Audit logs are regularly reviewed by knowledgeable and independent individuals appointed by the data proprietor to meet the data proprietor’s requirements. These requirements and the review process are documented.           
  • Accounts that are locked due to maximum database login failures trigger an automatic notification of the security administrator(s) responsible for this system.

Database Backup & Recovery

  • The backup and recovery procedures are documented and meet data proprietor’s requirements.           
  • Backup and recovery procedures are periodically tested.           
  • Backup retention intervals are documented and sufficient to meet the business resumption requirements and expectations of the data proprietor.           

Database Encryption & Key Management

  • Protected data is encrypted during transmission over the network using encryption measures strong enough to minimize the risk of the data’s exposure if intercepted or misrouted from database to client workstation.
  • If database-level encryption for protected data is implemented, procedures for secure key management are documented. (Check National Institute of Standards and Technology (NIST) for current recommendations.) Note: It is recommended that all application layers (network, application, client workstation) are already encrypted before encrypting the database. Database encryption is not a substitute for any of the above requirements. Database encryption of protected data is not mandatory to meet this standards document.
  • For data subject to disclosure that is encrypted at storage, the means to decrypt must be available to more than one person and approved by the data proprietor.
  • Backup tapes store backups of the database in an encrypted format, and the tapes do not store the plain text encryption keys necessary to decrypt the backups.           
  • Key management procedures for decrypting backups are documented, available to more than one person and approved by the data proprietor.

Topics