Feed your Appetite for Reduction. Meet us at booth #605 at AWS re:Invent.
Say what you will, relational databases are still the backbone of the Internet. Even in the face of recent threats from cybercriminals, these databases remain secure and unshaken.
Over the last 10 years there has been an explosion of new ways to store and access data. Each brings its own benefits and interesting applications. With each new data store inevitably comes a wave of claims that “this is the future” and “relational databases are the past.” A quick Google of Graph, Web3, NoSQL and “replace relational database” will render plenty of results. I’m sure we will see some claims soon that vector databases can replace relational databases too.
However, the ground reality is that for most projects, an RDBMS is the right architectural choice. Even when you’re working with other components of the infrastructure such as cloud databases, chances are that at least one element of the application will benefit from a relational database. Given this, it’s safe to say that relational databases will continue to play an integral role in applications for a considerable time to come.
Given the lasting importance of RDBMS, it’s crucial to secure the data within them effectively, especially from the ever-evolving threats posed by cybercriminals and potential data breaches.
This security guide covers techniques primarily for relational databases. To make this guide easy to digest, I’ll focus on web interface-based applications built in AWS. However, the principles could apply to any web-based application or data storage structure.
Let’s think about the architecture as so: A request is made to a web server / application, a workload component (Kerbnetes, EC2, Lamda) handles the request, processes it, then, as needed, writes and reads to a relational database (MS SQL, MYSQL, Aurora, etc.). The database may be managed or self-hosted on EC2.
To determine how we should protect the data hosted on the database server, particularly cloud databases, let’s adopt an attacker’s mindset before thinking like a defender.
From an attacker’s point of view, databases are a prime target for either stealing data or disrupting services. A truly vindictive hacktivist may just mangle records in subtle ways.
There are many approaches that an attacker could take to get to their ultimate objective.
I’ll glaze over the discovery phase of an attack (i.e. how an attacker figures out where a database may exist) as security through obscurity is not an approach I support. Nonetheless, an attacker will do some reconnaissance to figure out the method of attack that is likely to succeed. This can be network scanning, probing an application’s inputs to see how it responds, or open intelligence gathering (for example, a job posting about a new DBA role for your primary customer application likely tells a malicious party more than enough to come up with some ideas on where to start).
Once the attacker knows data is likely stored in a relational database, here are the methods they may employ to get access to or disrupt availability. (List is in order from lowest to highest tech.)
An attacker needs to weigh the likelihood of success, ease of execution, and likelihood of being discovered to determine which approach to try. Typically, the most common approach is to try the lowest likelihood of being discovered and the easiest to execute first, then if that fails, try the next until all options have been exhausted.
As a colleague who has an interesting history used to say: “It’s not whether we could succeed, it was a matter of how much time and money we wanted to spend to succeed.”
Let’s switch to a defense perspective. We need to raise the bar for attacks high enough so that the time, money, and knowledge required is higher than what can be obtained without intensive efforts.
Reviewing the above, we can think of the controls relevant to protecting data in a RDBMS into seven categories: Physical security, access control, policies and procedures, application security, network security, resilience and backup, and workload / cloud security.
Let’s look at these more closely.
In this example, we are focusing on AWS / Cloud deployed RDMS. Physical security is maintained by AWS as part of the shared responsibility model. Of course, if your organization is one that is targeted by the brightest and best nation-sponsored hackers, auditing and working with AWS to ensure physical security meets your standards should be considered. Most organizations can point to the AWS public documentation on physical security.
If you’re still self-hosting, make sure your servers are in a well-secured location.
Implement the principle of least privilege and use the following technologies in AWS:
Defining clear and comprehensive policies and procedures is an essential step in database security. This encompasses guidelines for data access, breach response, regular audits, and more, providing a framework for secure operations.
No matter how exciting the latest data storage methods are, RDBMS is here to stay. The resurgence of technologies like Fortran is testament enough that time-tested methods continue to maintain relevance in our evolving technological ecosystem.
Given that data stored in RDBMS is frequently critical, and subject to various privacy laws, it’s paramount that we prioritize resilient and secure applications built on relational databases. Here are some guiding principles to ensure success in your RDBMS security:
If you want more information, or need to backup your AWS RDBMS, give me a shout. I’m happy to chat or connect you with the right experts, regardless of where you need to enhance your security posture.