Google, YouTube, Facebook (now Meta), Twitter, LinkedIn, WordPress, Discord, Slack… They all have a couple of things in common. One thing that they all share is databases – in some of these companies, databases are so unfathomably large that the company dedicates entire teams of dedicated seasoned database engineers to manage them – think about it. Working with the data of billions of users in hundreds of databases is never an easy task. You’re busy enough managing the performance and availability of all of the database instances – do you even have a second to think about security? Yeah… That’s important too – with all kinds of data breaches making headlines no one wants their company to be on the front page. No worries – with some right preparation, securing a database can be almost as easy as eating a cake. Ready? Let’s figure out how to do that together.
The Backbone Behind Your Data
Any kind of database you find yourself using is the backbone behind the most crucial data to your company. No matter what kind of database management system you find yourself using – whether you’re using SQL Server, PostgreSQL, MySQL, Oracle, or Sybase, the main point remains the same – the database management system is the backbone behind your data.
One of the most prevalent threats targeting all kinds of database management systems is SQL injection, or SQLi for short – SQL injection is almost always on the top of the OWASP Top 10 list of threats targeting web applications and part of it is because SQL injection is very easy to accomplish (there are even tools that help script kiddies and hackers dump data belonging to a certain website on the Internet), but another part of it has to do with harm that such attacks can do. SQL injection attacks target databases and the data within them – access to a single database on one website alone might not seem like a very big deal, but it can certainly become a trampoline towards other databases since the data contained within usually pertains to passwords that are frequently reused and frequently all that means that securing our data – and doing so in a proper fashion – is the only ticket out of this mess.
Securing Databases – General Aspects
There are a couple of aspects that are relevant to the security of every RDBMS and these are as follows:
- Access control mechanisms.
- User security.
- The components inside our database (think plugins, any used additions, etc.)
- Our actions related to the application and the database itself.
We will now briefly go through each of these aspects.
Database Security – Access Control
Ensuring proper access control is crucial because accounts that are overly privileged can be problematic on the security front – it’s a problem because should an attacker take control of such an account, he then would be able to do whatever he or she desires without privileges stopping any of his actions.
As an example, the MySQL ecosystem has privileges spanning a couple of different fronts:
- Administrative privileges that allow users to work with their databases themselves.
- Database privileges that are specific to a specific database.
- Database object privileges are specific to the modification and maintenance actions performed within a database e.g. tables, indexes, routines, also views.
When granting privileges, keep in mind that privileges can be related to specific queries (ALTER, ALTER ROUTINE, CREATE, DELETE, DROP), actions (e.g. specifying ALL would grant a user the ability to run all kinds of queries), or roles (roles are basically collections of privileges – they were introduced in MySQL 8 and the core purpose of them is to grant privileges to a role, then assign the role to a specific user – by doing so, that user will have all of the privileges specified to that role.)
Once we have taken care of user privileges, though, we should also look into the accounts themselves.
Database Security – User Accounts
User security mostly pertains to using stronger passwords – and if we think about it, everything is logical on that front too: a password like “Ud{jpLgudvfptXk#GdK3TibUS4au|g” will always be safer than “Password123.” Passwords like the one specified above, of course, are usually generated by password managers and not manually so for some, that might seem like a downside, but passwords stored in password managers are usually better secured than those stored in our heads due to the following factors:
- Everything stored in password managers is always end-to-end encrypted.
- Data stored in password managers is usually stored locally and only synced to the cloud, phones, and other computers belonging to the user if the user so chooses.
- Password managers don’t have a single point of failure: those passwords that require a secret key generate it locally during setup, etc.
- Password managers also don’t require us to share anything specific to our lives or our secrets to confirm our identity.
Password managers also have other factors that keep our data safe – we won’t get into all of the details here, but for those who are interested, a whitepaper detailing the security procedures in one of the most popular password managers is available here.
Aside from password managers, though, there also are other options: one of them is to enforce stronger passwords and a stronger security policy in general by using plugins.
Database Security – Plugins
Database management systems usually offer a couple of plugins to enforce a stronger security policy as well; as far as MySQL as concerned, the RDBMS offers plugins related to authentication, as well as to the control of the users who are already connected to MySQL. These kinds of plugins help secure one of the most important parts of our database: logging in via the CLI.
Some database management systems also offer password strength evaluation plugins that can be used to evaluate the strength of all used passwords and to implement a password security policy across the database. The list of security plugins specific to MySQL can be found in the MySQL documentation, other database management systems have similar approaches as well.
Database Security – Our Actions
Finally, to keep a database secure, we must consider the actions we perform as well – if our actions are not supportive of privacy or security, we will still be in trouble, no matter what we do. Don’t fret, though – taking care of your own actions is actually rather simple and only requires you to think about your database before or during a certain action you are performing. For example, think about the implications of SQL injection the next time you’re writing queries that are being run by your application, think about the least-knowledge principle next time you’re assigning privileges, and think about password security the next time you find yourself setting a password for a specific user.
That’s it, really – that’s no rocket science!
Conclusion
Database management systems are the backbones behind our data – unfortunately, databases are also a frequent target for attackers due to the volume of sensitive data they hold. However, not everything’s so bad – users can easily secure all kinds of database management systems by following the advice outlined in this article and the documentation relevant to their database management system of choice:
- The security documentation relevant to Oracle can be found here.
- Information about securing SQL Server can be found here.
- The security documentation relevant to PostgreSQL can be found here.
- The security documentation surrounding MySQL can be found here.
- The security documentation surrounding MongoDB can be found here.
We hope you’ve enjoyed reading this blog, come back to the BreachDirectory blog for more news in the database space, and we’ll see you in the next one!