Securing a multi-tenant architecture

Question

I'm a computer science student looking to expand an already developed web application into using multi-tenant architecture. Considering I'm far from being a security expert, which precautions can I take to my application as secure as possible? Here's how I've been thinking to do it, most of it based on this article from msdn: http://msdn.microsoft.com/en-us/library/aa479086.aspx

Framework

Django

This is what I used to develop the software and as I exclusively use it's ORM, I should be well protected against SQL injections. Passwords are hashed and all forms are CSRF protected. I'm thinking of somehow prohibiting users from using weak passwords, ideas? Any other precautions I should take?

Database Layer

Shared Database, one Schema per Tenant

I've decided to go with this solution because this still grants me good security ("moderate degree of logical data isolation") and I don't have to change my code much. A tenant can be identified solely from the subdomain, for example tenant1.website.com. I can simply tell the database to use the schema tenant1. Here I don't know if I should create a database user for each of the tenants, the article calls this as: "a combination of the impersonation and trusted subsystem approaches". Basically it creates an user for each tenant that has permissions only on that schema. Does this make sense? Where would I store the password for each user?

Symmetric encryption for sensitive data

I actually don't store any super important info like credit cards numbers, but there are a couple of fields which would be nice if they were a bit safer. Tenants will be storing reports that should not be visible to their competitors. As these fields will be text-heavy (max 70000 chars) I was thinking of using symmetric encryption (AES-128) on these fields. Is it ok if all tenants share the same key? Can I store the key in the source code?

Miscellaneous

Wildcard SSL Certificate

As all tenants will be on the same "server" (cloud: amazon ec2), with each tenant in it's own subdomain, it should be ok to use wildcard certificates, right? I'm thinking RapidSSL as our budget is very lean (edit: at the beginning probably only one instance).

Is there any other thing I've been completely forgetting?

Answer 1

Database Layer

The multi-schema approach is OK but as always the devil is in the detail.

One major isolation technique that is underappreciated is separate schemas for the data owner and for the web-app to access.

• This reduces the impact of any compromise by using least privilege, taking away specific rights of the connecting database user to really destroy the database (cannot drop tables or view hidden data).
• Allows the application to hide data (behind packages or views).
• You can use synonyms to map between web-app user and table owner schemas.

An Example Setup to get you started.

Data Owner:   MYCLIENT_OWNER
Web User:     MYCLIENT_USER  <- Django points to this schema
Synonyms:     MYCLIENT_USER.TABLE1 -> MYCLIENT_OWNER.TABLE1 (for all required tables)
Grants:       MYCLIENT_USER Granted Select, Insert, Update Delete as appropriate.
Packages:     MYCLIENT_USER Synonyms/Grants for required Packages, Functions and Procedures.

Authentication Layer

The authentication of users can be isolated into a sso / ldap server.

• This reduces the impact of a compromise of your web-app.
• The surface area of the authentication service is much much smaller than the whole system.
• But as always this is more complicated and usually more expensive (even if only for setup time).

Symmetric Encryption

I have heard that wallet key storage outside the database is the best practice here, but an alternative is to hide the data behind functions as above.

I suspect that a encryption service on a different box might be a good alternative, but I have never seen this design used before.

Answer 2

While this is just a partial answer to your question, you can use selinux integration with postgresql and apache to run the service on different domain ( ie, the equivalent of user in selinux lingo, roughtly speaking ) and prevent access to data ( on postgresql level, per database ) from a instance of the service running on apache under a different domain.

Another simple step would be to run different processes, one for each tenant. You cna achieve this with wsgi, and make sure that each process is separate. This way, you can have 1 database per tenant and not share the password at all.

There is various isolation measures, such as lxc, vserver, vm that could be used to restrict everything and communication between tenant, but that may be overkill, so it is up to you.

Also, for wildcard certificate, that's IMHO to avoid since if someone steal the certificate, this person would be able to spy on other tenants traffic ( as they have the private key in the cert ). Without a wild card certificate, someone can only spy on 1 website.

Answer 3

For the SSL certificate(s): wildcard certificates have several issues, biggest of which being that they tend to be expensive. Indeed, the business model of most existing CA is to sell certificates. A wildcard certificate is a certificate which allows you to buy less certificates from the CA -- therefore the CA does not like it, and will try to recoup these losses by pricing the wildcard certificate accordingly. Also, really generic wildcard certificates are not allowed by browser (even if you find a CA who accepts to sell you an "*.com" certificate, Web browsers will not accept it).

Conversely, certificates meant for a single, non-wildcard host name can be cheap, even so cheap as to be considered as to be loss leaders by some CA. For instance, StartSSL provides basic SSL certificates for free.

A related point is about IP management. Sharing the same IP between two SSL servers, which are meant to use distinct names, is still difficult: the server must guess the name under which it is contacted, so as to send the right certificate. This can be done with SNI, which is unfortunately not supported by IE on WinXP (which is still a common configuration). Wildcard certificate may or may not help you, depending on the domain names you want to support (since browsers reject too generic wildcards). You will probably have to buy some extra IP, and the cost of these IP may exceed that of the certificates.