A lot of time I get asked by customers, contractors, and even co-workers about our multi-tenancy architecture. Here at Wing Security we have a unique architecture, and when I present it I usually get raised eyebrows and the question of “Why did you do that”?
From the get-go it was very important for us to be a secure vendor. It was very obvious to us that the trust of our customers is the biggest asset we must protect, especially as there are some cases when we request customers to give us offline permissions in order to perform automatic remediation of issues. Also, as cyber-security professionals we knew all too well the ease to get it wrong and somehow enable an attacker (or a bug) to allow one tenant access to other tenants, and the reputation cost and loss-of-trust associated with it.
“From the get-go it was very important for us to be a secure vendor.”
So we researched for the best solution and asked for advice from several experts and this is what we got:
- We use infrastructure-as-code to create parallel and separated stacks of resources per tenant: Compute, Storage, configuration, secrets etc.
- We use separate cloud accounts (we use AWS) in order to make it very difficult for one tenant to access the resources of another tenant.
- Resources that have to be available for all tenants are in another separate account ( “Production Account”).
- All tenants have access to the generic resources in the Production Account, but the Production Account has no access to the customer tenant accounts.
The rationale, except for the emphasis on security, was that with modern infrastructure-as-code and devops tools it is quite easy to maintain, deploy, update and manage multiple accounts for multiple tenants, and this simplifies the IAM policies and configuration mess that often arises from after-the-thought tenancy solutions. As we work almost solely with serverless computing, it is also cost-effective: We pay for the workloads we need and have minimal costs for inactive accounts.
Another advantage is that we get a development and testing environment that is similar to the production environment: Each developer has their own tenant and they can run end-to-end tests by deploying to their own tenant with no impact whatsoever to other tenants. We can even create several environments for different types of tests, or for demo purposes. If we want to do canary deployment for example, no problem as well.
But the main value wasn’t technical: This really helped us to onboard customers quickly since almost all customers always asked “How do you secure my data and how can I be sure that no one can access my data?” The ability to answer this question in an easy-to-understand and persuasive manner was priceless and enabled us to begin trials and convert to paying customers very early which helped us better understand the value that our customers need and want from us.
Customers always asked, “How do you secure my data and how can I be sure that no one can access my data?”
The ability to answer this question in an easy-to-understand and persuasive manner was priceless.”
Of course this comes with costs: Deployment could be a bit quicker , and this approach pretty much mandates us to use serverless so as to not need to maintain and pay for separate compute solutions for every customer. The choice of serverless brings its own difficulties, especially when testing and debugging, and this does require our developers to think in a cloud-native fashion on everything which means a smaller pool of potential employees.
We solved this by investing in an automatic deployment script that hides the complexity and runs in the cloud to reduce deployment time and we developed a way for developers to easily test and debug everything locally and in integration tests that allow us to easily find problems. Doing this helps us overcome the issue of scale – we can scale as fast and as much as we need.
All in all, I believe the investment proved to be fruitful. We continuously think about how to improve and what we should change to be faster and better, but at least for the time I am writing this, the separation between tenants and the thought about multi-tenancy from the beginning seems to be one of the strengths we have as a platform. Besides, from my experience, to build multi-tenancy into an existing single-tenant solution when you already have customers and legacy constraints is an expensive and long nightmare that I am relieved to not have to experience again.
Every system is different and while your system may have other characteristics, and this solution may not fit your constraints and needs, I urge you to plan multi-tenancy from the beginning and to analyze how best to implement multi-tenancy with the workloads profile you assume. Even if you don’t implement this from the start, it will undoubtedly make your design better and make your product more secure.
