Locking down your production SQL database can be one of the more important things you do as a business to increase your security. Your database can hold valuable customer, company, or other high risk information. I recently attended a MySQL conference where Benjamin Wood, from Oracle, presented on database security. I’ll go over the five main security risks and how to prevent them.
1. Shared Service Accounts
Shared service accounts are commonly used with databases in development because members of development teams can easily remember the shared service account credentials. Shared service accounts also require very little oversight, but they are strongly discouraged in production, especially in a larger corporate environment. The biggest threats to your database due to shared service accounts are former employees. These employees may be less than happy with your company, and they could use a shared service account to log into your server. Once they’re in they may have the ability to drop your database, steal information, or give credentials away. If they can’t log in to the server from outside of the business, they can still contact somebody on the inside to perform actions on their behalf.
LDAP, Active Directory, and Kerberos are examples of authentication/authorization solutions that could eliminate shared service accounts. If an employee gets fired, these systems allow you to just remove their credentials from the directory and the problem is solved.
2. SQL Injection
A common and scary form of database hacking is with SQL injection. SQL injection allows a hacker to expose backend data through unexpected SQL. SQL injection leverages SQL commands on application forms in an unexpected way that exposes the backend database. Here’s an example of a form that asks for your email.
- The query on the backend looks like this:
‘select user from usertable where email = ’
- The hacker would input something like this:
‘firstname.lastname@example.org’ OR ‘x=x.’
- The x=x was unexpected and the query now says:
‘select user from usertable where email = email@example.com’ or ‘x = x’
- When the query executes it will return the entire user list because the query returns TRUE.
You can combat SQL injection by validating user input. The best kind of validation is known as “positive security,” a.k.a whitelist. Using positive security, you specify what can be entered into a field rather than just specifying what can’t be entered into that field. Email addresses follow a regex pattern: they can’t have the word OR, they can’t have an equal sign, and they have to be a string with no quotation marks. When you use positive security you can prevent most injection attacks.
Another way to combat SQL injection is to return quality error messages. When you have a descriptive error message when a hacker’s injection attack is disallowed they may be deterred and move on. For instance, if an email doesn’t pass validation your error should say, “invalid email format,” rather than “email not found.” Quality error messages will show the hacker that entries are being checked and validated.
3. Unsupervised Operations
Unsupervised operations is a threat that is very similar to that of shared service accounts. The threat is introduced when you have an employee who is upset with the company and have no way to monitor their access to important systems. This employee might be about to quit their job and in a fit of rage, they decide they’d like to trash the database.
Monitoring and alerting anomalous access and operations is really the only decent way to keep tabs on this type of malicious activity. If employees are aware that transactions they do on the database are being stored in a logging system, then they’ll be less likely to do anything malicious.
4. Compromised Root Privileges
If a hacker gains root privileges to your database server, your data will be vulnerable and they can do whatever they’d like with it. Root privileges are often compromised because of a phishing attack on an employee. If your database information is encrypted, and the key lives on the server, the hacker has access to the key as well and can easily read your data.
Transparent data encryption with a key held in a keystore, can dramatically help with this issue. Transparent data encryption (TDE) encrypts data as it goes over the wire in both directions, so the data “at rest” on the server is encrypted. Because the encryption keys are in a keystore, root access to the server doesn’t compromise security to your encrypted database.
5. Privileges and Passwords
A phishing attack can expose usernames and passwords to a database. Hopefully those exploited credentials don’t have root privileges. Also, a hacker could figure out a simple username/password combination such as “admin/password” quite easily.
A secure production database environment should have systems in place for password complexity, rolling updating passwords, and user privileges to the database. These methods can’t stop hackers from ever gaining access, but it can greatly deter them. When using these methods, hackers have to spend more time breaking in. Also, correct database privileges will prevent hackers from gaining access to everything at once from a single password hack. Provide developers with only the access they need to do their job. By allowing only necessary access it will make it extremely hard to for anybody attacking from the outside to gain root privileges to your data.
There are many solutions for each of these problems through third party software or internal solutions. I know that MySQL enterprise has built in tools for every single one of these if you choose to go that route. Of course, security is never guaranteed. If you take the proper precautions in a sensitive production environment, you can greatly reduce your risks.