Question

This isn’t about a specific problem I’m having, but I have to clear something up as I have alot at stake with this project.

I’m creating a web application that will deployed to some BIG companies in the UK and if we get this wrong it could cost us hugely!

I need to keep each companies data VERY secure, so what I was wondering is would it be a good idea to create a new database for each organisation, this way their data is totally seperate and if one database is compromised the data for all the organisations wouldn’t be effected – this would give us time to react to the security problem before all the data is compromised. My Questions are:

1. What are the short term and long term benefits of this (if any)
2. What are the short term and long term drawbacks of this (if any)
3. Is this good practice?
4. Would it even solve a security issue in the way I anticipate?

Thanks in advance

Answer 1

I’m assuming this is a question about building a “multi-tenanted architecture” for a “software as a service” style application.

The first issue is that separating your databases may or may not be a good idea – but it’s not the first question to ask. Someone who can get access to your databases at the level where this matters has already penetrated your application in ways that are hugely damaging – they can almost certainly execute arbitrary commands on your database server. This means that you’re not just dealing with damage to one account, but to your entire infrastructure. It’s a “lights out” moment, and you have to shut down the whole system whilst you recover.

If they haven’t established a shell on your database server, it would mean there’s an application-layer security issue – SQL injection, or some way of escalating privileges in your authentication scheme. Again, both are “lights out” moments.

So, make sure all that stuff is totally covered. Include security testing in your development lifecycle; consider using automated penetration testing tools as part of your continuous integration system. Make sure the infrastructure guys harden the whole environment, and consider having a 3rd party security audit when you get close to a release candidate. Consider a code review process focussed on security issues, and agree coding standards with specific security considerations. Tell all your developers about cross site scripting, SQL injection and other application-level vulnerabilities.

Once you’ve done all that, you’ve locked the doors and bolted the windows; your database strategy is the equivalent of how you keep the jewelry safe.

Separate databases offer some additional security – but only if you have a corresponding strategy for user management. In most web applications, there are only 2 types of user: “admin” and “web app”. “Admin” can create/modify databases (creating databases, tables, views etc.), and can usually also modify data. “Web app” should have only data modification rights, but no rights to modify databases objects.

For splitting the databases to make sense, you must ensure that:

• an attacker who can get access to your web application’s file system cannot get access to valid user names and passwords, or if they can, only for one client.
• an attacker can never get access to the “admin” credentials

However, there are other reasons (beyond security) where it makes sense to split up your databases. It reduces the risk of human error, it allows you to scale your system at a more granular level, and it allows you to offer different levels of hosting (“gold” users get their own server, “silver” their own database, “bronze” take their chances).

The big issue you have to solve to make this happen is deployments – how will you deploy new versions of the code, with changes to the database? This in turn may complicate the testing process.