Secure Your Database Server

If you are permitted to access or maintain sensitive institutional data in a database housed on a securely managed server, follow these instructions to further protect the database.

Information Assurance (IA) recommends that you begin the process of hardening university servers, workstations, or databases by running the Center for Internet Security's Configuration Assessment Tool—CIS-CAT. The tool will scan your system, compare it to a preset benchmark, and then generate a report to help guide further hardening efforts. See CIS-CAT for U-M Systems for information about the UM-specific version of the tool.

These guidelines were developed for MySQL and MSSQL databases, but can be applied more universally.

  1. Do not use the root, default, or sa account to connect the web server to the back end database.
  2. Manage accounts by limiting account privileges to only the necessary database instances and ensure that there is a unique administrator password for each database instance in the case of distributed database administration. If local account authentication is being used, ensure that administrative accounts in each database are given unique passwords.
  3. Use secure passwords if local accounts must be used. See guidelines for creating a secure password.
  4. Schedule periodic disconnections (timeouts) for accounts idle more than two hours.
  5. Limit access to the database listener port(s) to U-M campus networks using firewall rules.
  6. Remove demo or example databases or database users if created by an application installation.
  7. Consider database-level encryption if the database stores sensitive data.
  8. Enable logging of all database logon authentication attempts (failed and successful).
  9. Configure secure transaction log backups to allow database restores for disaster recovery. Be aware that transaction log backups for some database systems are stored in clear text by default and may contain sensitive data. To be consistent, database backup files should be encrypted if database-level encryption is not used. Encrypt those logs when in transit and where stored.
  10. Update promptly. Update the service or application within 30 days of an official security patch release by a vendor.
Note: If your database is hosted on a system separate from your web server, but on the U-M campus network, best practice is to ensure that the connection between the server and the database is encrypted. You may need to request an additional SSL server certificate and enable its use by the database web server.