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



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?


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?

  • 4
    What are you doing to prevent XSS? May 26, 2012 at 4:14
  • @MikeSamuel, I think I should be ok. Django escapes dangerous characters and I use a WYSIWYG editor for the only field they can write HTML. They can share links, but only within the same tenant.
    – Clash
    May 26, 2012 at 8:05
  • @MikeSamuel, thanks for the tip! I was in fact storing HTML at the database and was in fact not protected! Now I run a html whitelist scrubber when saving this field at the database.
    – Clash
    May 26, 2012 at 10:18
  • 1
    sharing links can be dangerous. javascript: URLs allow XSS and aren't stopped by Django's auto-escaping. May 26, 2012 at 12:35
  • django's URLField doesn't accept URLS starting with javascript, but thanks for the tip!
    – Clash
    May 26, 2012 at 12:41

3 Answers 3


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.

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.

  • Andrew, thanks for the great answer! Could you please elaborate on the database layer? I didn't understand what you mean for separate schemas for the table owner and for the web-app.
    – Clash
    May 26, 2012 at 8:06

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.

  • well, I can't afford one certificate per tenant. I think my question is if there's any difference if I only buy one certificate and put all of them using the same domain (each tenant on a /directory/) or a wild card and each tenant on a subdomain. PS: How could someone steal the certificate?
    – Clash
    May 28, 2012 at 11:59
  • Stealing the certificate is nothing magic. If the webserver need to be able to read it ( for https ), then code executing in the webserver ( like, let's say, mod_php ) can also read the certificate. There can be various restrictions however, but that's something to keep in mind. And indeed, there isn't much difference with the 2 approaches. I would say that if you later have enough money for 1 cert per domain, the first approach would permit a easier migration.
    – Misc
    May 28, 2012 at 12:55
  • Note the following points, 1) the https certificates need an ip address per domain to be supported, 2) If you use a multi-tier architecture you can have the https decryption on web tier, the django on the app server tier, the db on the db tier and so the cert is on a different tier than the likely injection, so potential compromise is limited somewhat (separation of duties mantra). Jun 7, 2012 at 21:56
  • No, you can use more than 1 https certificate per ip address with newer ssl library ( ie, using SNI serverfault.com/questions/109800/… )
    – Misc
    Jun 8, 2012 at 4:56
  • Hi @misc, I love the idea, but it needs browser support and if you are going to support older browsers (at all) then you need to use multiple ip addresses. Apr 10, 2013 at 21:41

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.

  • Yes @Thomas, cost of IP addresses might be expensive for a load of subdomains. An alternative could be to have a dual hosted configuration having most sub-sites hosted on your domain, www.example.com/<subsite>/ and your high value paid subsites hosted on <subsite>.example.com/. Apr 10, 2013 at 21:47
  • Note that Google Apps for your domain uses Google domains and certs even for Paid Company email/docs/calendar etc. It is the easiest way and removes a lot of additional complexity and failure modes. Apr 10, 2013 at 21:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .