Database Administrators Checklist for Database Hardening Best Practices

Introduction to Database Administrators Checklist

Database Hardening is an expert measure in ensuring the database security of relational and non-relational databases of various kinds. The steps involved in hardening the database system may vary according to the database system and platform.

The concept of hardening in the Oracle database may widely differ from that of SQL Server, for example. So, DBA’s primary advice is to refer to the vendor’s manual to identify database hardening best practices for the respective DB.

Thus, the first step in any database hardening process is to start with the vendor documentation. You can also wade through the public material available on the internet, but all of those may not be trustable sources.

This checklist we enlisted below is prepared by the expert administrators of RemoteDBA, which is aimed to provide proper guidance to the administrators to secure the sensitive databases they are managing. Implementing monitoring using these checklist points will help prevent any data loss, data leakage, or unauthorized database access.

Even though the vendors manual is an apt place to start learning the database scheduling best practices, sometimes it may not be much more than the REVOKE and GRANT syntaxes. That is the reason why we put forth this standard practices to be tried across the database platforms. We have categorized into various sections with a unique checklist for each.

Physical DB server security checklist

  • Ensure that the physical machine which hosts is housed in a well-monitored and secured environment by taking care of the risk of any unauthorized access or theft.
  • Keep web servers and application servers separately at different hosts.
  • Ensure adequate firewall security for the database servers.
  • Ensure that the firewall of the database server is only opened to specific web servers or application servers, and the firewall rules deny any direct client access.
  • If the application development environment is not competent to meet the above requirements, then protected data may not be stored in the development server. Instead, mock data will be made for development. However, data obfuscation of the production data may not be sufficient.
  • Ensure that a procedure is in place for firewall rule changes and that the rule change notification is distributed across the system admins and database admins.
  • Also, ensure the firewall database server rules are reviewed and updated regularly by the database admins and server admins. If it is an IST provided firewall, then the rules may also be reviewed and updated by the ISOs (Information Security Office)
  • Also, check and test the firewall and machine hardening rules regularly through network scans and also let the ISOs scan through your firewall.

Database software checklist

  • Check whether the vendor or another open-source project supports the version of database software.
  • Also, ensure that all the unnecessary and unused services on the database are turned off or removed.
  • Check and ensure all the unwanted default accounts added by the provider are removed before implementing the database.
  • Ensure all the passwords and changed from the given defaults. Don’t use any null passwords and ensure that the temporary files from the install process containing any passwords are removed.
  • Patch the database software to include all the latest security patches. Provisions also should be made to maintain the level of security patches promptly.

Web Servers, Application, and Application Code

In the case of web server administration, it is ideal to seek an expert provider’s assistance. For getting a customized quote for your remote server administration service, explore the options available at RemoteDBA. Essentials to note are:

  • Ensure that the destination systems as web servers and application servers receive protected data, secured in a manner commensurate with the security measures on the originating system.
  • Ensure that all clients and servers meet the minimum standards of security.
  • Check all the servers, tools, and applications which access the database are adequately documented.
  • Lockdown source codes and configuration files by making those only accessible to the required accounts.
  • Ensure the application code gets reviewed for the vulnerabilities in SQL injection.
  • Ensure there is no “Spyware” allowed on the web server, application, or database servers.

Client/User Workstations

  • Ensure the client workstations to meet the desired security standards if the users are allowed to access the protected data from their workstation.
  • Ensure that the user workstations are protected against any unauthorized access by deploying password security and screen savers etc.
  • Encrypt user workstation operating system data if the users are allowed to access protected data at their workstations.
  • Ensure that the users/clients don’t save the protected data into any storage devices or on local devices.
  • Ensure that the protected data is not sent through email or other modes of sharing, either the user or any automated system implemented on the user machines.
  • Ensure that the not needed protected data available on the user/client systems are frequently deleted.
  • If the users are allowed to access protected data at their workstation, check if any “Spyware” is installed at their systems.

Permission and Password for Administrator Accounts

  • DBAs must understand their role in terms of reviewing all the requested scripts and changes in the database to ensure that the overall system security is not getting compromised.
  • The admin privilege needs to be provided only to a few experts in monitoring and supporting the applications.
  • Non-disclosure agreements (NDA) need to be signed by all DB users like Developers, SAs, DBAs, Vendors, and Third-party Contractors who have access.
  • The background check of all DBAs, SAs, and contractors also need to be conducted before providing them access to the database.
  • The database accounts for DBA for administrative tasks shouldn’t be shared as a group account for other categories of users.
  • A separate group account can be permitted for running some automated DBA maintenance, monitoring, and backup.
  • Don’t use the group account for any interactive daily tasks by the DBA, except for monitoring or maintenance.

Above mentioned checklist points are, to begin with, the database hardening process. The primary measures will ensure that you are on the right track in terms of advanced data security and protection. Once you become compliant with these necessary measures, it is time to go ahead with advanced data security practices, which we will discuss in further articles.

See also  What is SQL Injection in Testing: Complete Guide in Just 5 Minutes

Share and Enjoy !

Leave a Reply

Your email address will not be published. Required fields are marked *