MySQL Security - Part 1

Security takes center stage in this episode as Lois Houston and Nikita Abraham are joined by MySQL Solution Engineer Ravish Patel. Together, they explore MySQL’s security features, addressing key topics like regulatory compliance.

 

Ravish also shares insights on protecting data through encryption, activity monitoring, and access control to guard against threats like SQL injection and malware.

 

MySQL 8.4 Essentials: https://mylearn.oracle.com/ou/course/mysql-84-essentials/141332/226362

Oracle University Learning Community: https://education.oracle.com/ou-community

LinkedIn: https://www.linkedin.com/showcase/oracle-university/

X: https://x.com/Oracle_Edu

 

Special thanks to Arijit Ghosh, David Wright, Kris-Ann Nansen, Radhika Banka, and the OU Studio Team for helping us create this episode.

 

---------------------------------------------------------

 

Episode Transcript:

 

00:00

Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative  podcasts, we’ll bring you foundational training on the most popular Oracle technologies. Let’s get started!

00:25

Lois: Welcome to the Oracle University Podcast! I’m Lois Houston, Director of Innovation Programs with Oracle University, and with me today is Nikita Abraham, Team Lead of Editorial Services.

Nikita: Hey everyone! In our last episode, we took a look at MySQL database design. Today is the first of a two-part episode on MySQL security. 

Lois: In Part 1, we’ll discuss how MySQL supports regulatory compliance and how to spot and handle common security risks. 

00:55

Nikita: Joining us today is Ravish Patel, a MySQL Solution Engineer at Oracle. Hi Ravish! Let’s start by talking about how MySQL supports regulatory compliance.

01:06

Ravish: Some of the most important international regulations that we have surrounding data and organizations include the GDPR, HIPAA, Sarbanes-Oxley, the UK Data Protection Act, and the NIS2.

Although each regulatory framework differs in the details, in general, you must be able to comply with certain key requirements and all of which are enabled by MySQL. First, you must be able to monitor user activity on the system, which includes keeping track of when new users are created, when the schema changes, and when backups are taken and used. You must protect data, for example, by ensuring that databases that are stored on disk are encrypted at REST and ensuring that only authorized users have privileges to access and modify the data.

You must have the appropriate retention policies in place for your data, ensuring that backups are held securely and used only for the purpose intended. You must be able to audit access to the data so that you can trace which users gained access to records or when they were modified. All of these facilities are available in MySQL, either as part of the core community edition features or made available through enterprise features.

02:21

Lois: What kind of risks might we encounter, Ravish, and how can we address them?

Ravish: As your system grows in complexity, you're likely going to have more risks associated with it. Some of those risks are associated with the human factors that come with any computer system. These might be errors that are introduced when people perform work on the system, either administrative work on the environment or database or work that developers and testers perform when working on a changing system. You might even have malicious users trying to exploit the system or good faith users or support staff who make changes without proper consideration or protection from knock-on effects.

At the foundation are the necessary components of the system, each of which might be vulnerable to human error or malicious actors. Every piece of the system exposes possible risks, whether that's the application presented to users, the underlying database, the operating system or network that it works on, or processes such as backups that place copies of your data in other locations.

More complex environments add more risks. High availability architectures multiply the number of active systems. Consolidating multiple application databases on a single server exposes every database to multiple vectors for bugs and human error. Older, less well supported applications might give more challenges for maintenance. Engaging external contractors might reduce your control over authorized users. And working in the cloud can increase your network footprint and your reliance on external vendors. 

03:53

Nikita: What are risks that specifically impact the database?

Ravish: The database server configuration might not be optimal. And this can be changed by users with proper access.

To mitigate this risk, you might enable version control of the configuration files and ensure that only certain users are authorized. Application and administrator accounts might have more data privileges than required, which adds risk of human error or malicious behavior. To mitigate this, you should ensure that users are only granted necessary permissions.

In particular, structural modifications and administrative tasks might be more widely accessible than desired. Not every developer needs full administrative rights on a database. And certainly, an application should not have such privileges. You should limit administrative privileges only to those users who need that authorization.

04:45

Nikita: Okay, quick question, Ravish. How do authentication and password security fit into this picture?

Ravish: Authentication is often a weak point. And password security is one of the most common issues in large applications. Ensure that you have strong password policies in place. And consider using authentication mechanisms that don't solely rely on passwords, such as pass-through authentication or multifactor authentication.

05:11

Lois: So, it sounds like auditing operations are a critical part of this process, right?

Ravish: When something bad happens, you can only repair it or learn from it if you know exactly what has happened and how. You should ensure that you audit key operations so you can recover from error or malicious actions. If a developer laptop is lost or stolen or someone gains access to an underlying operating system, then your data might become vulnerable. You can mitigate this by encrypting your data in place. 

This also applies to backups and, where possible, securing the connection between your application and the database to encrypt data in flight.

05:54

Did you know that Oracle University offers free courses on Oracle Cloud Infrastructure? You’ll find training on everything from multicloud, database, networking, and security to artificial intelligence and machine learning, all free for our subscribers. So, what are you waiting for? Pick a topic, head over to mylearn.oracle.com and get started.

06:18

Nikita: Welcome back! Before the break, we touched on the importance of auditing. Now, Ravish, what role does encryption play in securing these operations?

Ravish: Encryption is only useful if the keys are secure. Make sure to keep your encryption assets secure, perhaps by using a key vault. Every backup that you take contains a copy of your data. If these backups are not kept securely, then you are at risk, just as if your database wasn't secure. So keep your backups encrypted.

06:47

Lois: From what we’ve covered so far, it’s clear that monitoring is essential for database security. Is that right?

Ravish: Without monitoring, you can’t track what happens on an ongoing basis. For example, you will not be aware of a denial-of-service attack until the application slows down or becomes unavailable. If you implement monitoring, you can identify a compromised user account or unusual query traffic as it happens. A poorly coded application might enable queries that do more than they should. A database firewall can be configured to permit only queries that conform to a specific pattern.

07:24

Nikita: There are so many potential types of attacks out there, right? Could you tell us about some specific ones, like SQL injection and buffer overflow attacks?

Ravish: A SQL injection attack is a particular form of attack that modifies a SQL command to inject a different command to the one that was intended by the developer. You can configure an allow list in a database firewall to block such queries and perform a comprehensive input validation inside the application so that such queries cannot be inserted. A buffer overflow attack attempts to input more data than can fit in the appropriate memory location. These are usually possible when there is an unpatched bug in the application or even in the database or operating system software.

Validation and the database firewall can catch this sort of attack before it even hits the database. And frequent patching of the platforms can mitigate risks that come from unpatched bugs. Malicious acts from inside the organization might also be possible. So good access control and authorization can prevent this. And monitoring and auditing can detect it if it occurs.

08:33

Lois: What about brute force attacks? How do they work?

Ravish: A brute force attack is when someone tries passwords repeatedly until they find the correct one. MySQL can lock out an account if there have been too many incorrect attempts. Someone who has access to the physical network on which the application and database communicate can monitor or eavesdrop that network. However, if you encrypt the communications in flight, perhaps by using TLS or SSL connections, then that communication cannot be monitored.

09:04

Nikita: How do the more common threats like malware, Trojan horses, and ransomware impact database security?

Ravish: Malware, ransomware, and Trojan horses can be a problem if they get to the server platforms or if client systems are compromised and have too much permissions. If the account that is compromised has only limited access and if the database is encrypted in place, then you can minimize the risks associated even if such an event occurs.

There are also several risks directly associated with people who want to do the harm. So it's vital to protect personal information from any kind of disclosure, particularly sensitive information, such as credit card numbers. Encryption and access control can protect against this.

09:49

Lois: And then there are denial-of-service and spoofing attacks as well, right? How can we prevent those?

Ravish: A denial-of-service attack prevents users from accessing the system. You can prevent any single user from performing too many queries by setting resource users limits. And you can limit the total number of connections as well.

Sometimes, a user might gain access to a privileged level that is not appropriate. Password protection, multifactor authentication, and proper access control will protect against this. And auditing will help you discover if it has occurred.

A spoofing attack is when an attacker intercepts and uses information to authenticate a user. This can be mitigated with strong access control and password policies. An attacker might attempt to modify or delete data or even auditing information. Again, this can be mitigated with tighter access controls and caught with monitoring and auditing. If the attack is successful, you can recover from it easily if you have a strong backup strategy in place.

10:50

Nikita: Ravish, are there any overarching best practices for keeping a database secure?

Ravish: The MySQL installation itself should be kept up-to-date. This is the easiest if you install from a package manager on Windows or Linux. Your authentication systems should be kept strong with password policies or additional authentication systems that supplement or replace passwords entirely. Authorization should be kept tightly controlled by minimizing the number of active accounts and ensuring that those accounts have only the minimal privileges.

You should control and monitor changes on the system. You can limit such changes with the database firewall and with tight access controls and observe changes with monitoring, auditing, and logging. Data encryption is also necessary to protect data from disclosure. MySQL supports encryption in place with Transparent Data Encryption, also known as TDE, and a variety of encryption functions and features. And you can encrypt data in flight with SSL or TLS.

And of course, it's not just about the database itself but how it's used in the wider enterprise. You should ensure that replicas are secure and that your disaster recovery procedures do not open up to additional risks. And keep your backups encrypted.

12:06

Lois: Is there anything else we should keep in mind as part of these best practices?

Ravish: The database environment is also worth paying attention to. The operating system and network should be as secure as you can keep them. 

You should keep your platform software patched so that you are protected from known exploits caused by bugs. If your operating system has hardening guidelines, you should always follow those. And the Center of Internet Security maintains a set of benchmarks with configuration recommendations for many products designed to protect against threats.

12:38

Nikita: And that’s a wrap on Part 1! Thank you, Ravish, for guiding us through MySQL’s role in ensuring compliance and telling us about the various types of attacks. If you want to dive deeper into these topics, head over to mylearn.oracle.com to explore the MySQL 8.4 Essentials course.

Lois: In our next episode, we’ll continue to explore how user authentication works in MySQL and look at a few interesting MySQL Enterprise security tools that are available. Until then, this is Lois Houston… 

Nikita: And Nikita Abraham, signing off!

13:12

That’s all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We’d also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.