Want to Strengthen Database Security? Automate.

Database automation is not the first line of defense for your databases. The first line of defense should be network security. The second, third, and fourth lines of defense should be database patching, encryption, and strong password use. But there is a last line of defense: access to the database.

At Liquibase, we have seen cases where the number of users with schema owner permissions to a database (and thus the ability to change schema) was greater than 250. In and of itself, this may seem fine since a large organization will have a large number of users with elevated access. However, it absolutely does not make sense in a world that has automation.

Automation controls database access

As a best practice, we recommend that you not include credential information in your Liquibase properties files or enter them via the command line. (For unsecured databases that your team uses for development purposes, doing so is acceptable.) As you continue to make improvements to how you make changes to your secured databases, consider another mechanism for managing secrets.

A superior solution is storing secrets in a central, secure location such as HashCorp Vault. In turn, automation will gather secrets from Vault and pass them onto Liquibase. In this scenario, your existing Application CD solution probably already uses Vault, or some other repository, for secret management. Leveraging this best practice with Liquibase decreases the surface area for database attacks.

The alternative is to have a large number of users with access to secured databases manually making database changes. By leveraging Liquibase, Vault (or similar), and your existing application CD solution, you eliminate the need for humans to have direct access to databases to make schema changes.

Other benefits of database automation

For companies that do not automate database schema updates, the workflow goes something like this:

1. A developer submits a ticket for schema change (likely attaching a SQL script to a ticket).
2. A DBA reviews the ticket and the SQL script. (The DBA may send the SQL script back to development for improvements.)
3. DBA executes the SQL script on the target database. (The DBA may spend hours resolving any errors.)
4. DBA closes the ticket.

In our new high-speed, low-drag continuous delivery cycles using application deployment automation, this causes unnecessary strain on the DBAs available to perform these four steps. 

Here we have a video of DBA team that has been taxed due to the development team adopting processes to speed delivery:

https://youtu.be/7DilsrxNJyY

Choices have consequences. To attain the same rate of delivery for a manual process that the automated process provides, companies must increase the number of people that have access to the secured databases. After all, a herd is only as fast as its slowest member.

Wrapping it up

There are certainly more benefits to automating database change such as lower lead time, higher change success, lower mean-time-to-recovery, and increased change success rate. (A great resource on why those metrics are key is Dr. Nicole Forsgren’s book Accelerate.) Every decision that your organization makes regarding application delivery must be viewed from a perspective of speed and security. We can no longer do one without the other.

Interested in automating your database process? We’re here to help guide you. Contact us and we’ll help you get started.