Securing a database on a shared hosting account

I've searched for documents on securing a database to prevent cyber threats and also comply to new regulations.  I found an interesting one by IBM.
https://www.ibm.com/topics/database-security

Berkley's one is particularly interesting as a checklist on what to do, or not.
https://security.berkeley.edu/education-awareness/database-hardening-best-practices

Actually, all cloud providers have similar documents (Google, Microsoft, Amazon, ...)  This is all good theories, but on a smaller scale and on a smaller budget, using web hosting kind of forces the developer to do things that are not supposed to be done, ever.  For example:

• Isolate the database from the website (front end), not the same server.
• Do not hardcode the database access into the website source code.
• Log database actions, but not in the database's own space.

These are all things that need to be done when you purchase a website hosting account.  Perhaps that this is a non-issue if 49% of breaches are because of a human error (stats mentioned in the IBM document), and the rest is perhaps because of zero-day exploits and corrupt employees.

To complexify things, another web hosting account can be purchased from another company so the database is really on a different server, and an HTTPS interface can then be designed as a proxy and a firewall to protect the database.  A bad actor might crack the website (front end) account, find out that the database account is on a different account, then try to crack it too.  So, only a matter of time for someone with motivation (and money rewards).

So, what do you think?  What should be done to protect a database on a shared hosting account?

Hi, you do not name your host.  Need to follow the rules of your host and the plan.

Question is also generalized so : https://www.google.com/search?client=firefox-b-d&q=What+should+be+done+to+protect+a+database+on+a+shared+hosting+account%3F

I have not selected a host yet.  The reason to direct the question to hosting solutions is that these resources are easier to access for me.  Any ideas and concepts provided here will help my system development.  Imo, it's better to plan the development ahead instead of a hacker (good or bad) pointing out vulnerabilities of the system.  At that point, to me, it's already too late and damage may have been done.

Question is also generalized so : https://www.google.com/search?client=firefox-b-d&q=What+should+be+done+to+protect+a+database+on+a+shared+hosting+account%3F

The first Google result for this search is actually my BC post#1.   I guess people replying here will also help other fellow developers.   

Not many tip or hint flowing here from security researchers or forensic analysts.    Would it be because Google search results are complete enough? or there are trade secrets not to be disclosed to keep the edge over treat actors?

I also searched for cyber attack statistics just to have a better idea of today's reality (that may not be the same for tomorrow, of course).  Results seem buried in tons of disappointing search results so I compiled this year's first 20 days of cyber attacks mentioned in BC stories.  Here's what I came up with:

 BC-Security-20DaysOf2024.gif   14.36KB   0 downloads

tbd is mostly ransomware attacks where the initial point of entry is not disclosed.  It could be stolen credentials through phishing, brute force, a software vulnerability, etc...  What caught my attention is credential stuffing attacks where credential stolen from elsewhere are tested on a new website just to see if it works.  It's not the company's fault per say, but it makes them look bad, for example Jason's Deli.  And not knowing how many users have been affected doesn't help their image either.  Adding code to notify users faster would be a step in the right direction, for example if their login are from a different and unexpected ISP.  I'm going to add that consideration into my system.  You've also got to protect the users from themselves too.

General tips?

1. Only expose your database server to your web application server and configure your firewall correctly
2. Ensure all your SQL queries are parameterised if you're using a SQL-based database
3. Do not store any credentials in your source code, at least read from a configuration file or a key vault
4. Ensure that the database user which the web application is using has least privilege i.e. don't give write permissions if it isn't needed
5. Ideally, have the database server and web application server as separate instances and place them behind some kind of reverse proxy 

Thanks!

Some further guidelines for inspiration:

https://www.bleepingcomputer.com/news/security/us-govt-shares-cyberattack-defense-tips-for-water-utilities/

Edited by Dominique1, 23 February 2024 - 08:17 PM.