We wrote earlier about the differences between Deveo, GitHub, GitLab and Bitbucket. One of the differences covered in the post was the fact that Deveo offers strict multi-tenancy both in the cloud and on-premises installations. In this blog post, I'm going to explain the difference between the user management and permission scheme between Deveo and the three aforementioned cloud services. In addition, I will cover how strict multi-tenancy, will prevent you from making mistakes that might cost you your source code IPRs going public or to people no longer working in your company.
Multi-tenancy in Deveo
Let's start off by describing the differences between multi-tenancy and single tenancy. Multi-tenancy is described quite well in a blog post by Manish Mundra, that "Multi-tenant Software as a Service (SaaS) is an architecture where multiple companies share the same instance to store their data. This instance is typically divided (or partitioned) to prevent the companies from accessing each other’s information. This is like high-rise building where the floor plans are generally set but minor cosmetic changes can be made to the individual units.
Single-tenant (or hosted) Software as a Service (SaaS) is an architecture where each company has their own instance of the software application and supporting infrastructure. Think of it like a neighborhood community developed by the same architect and engineer where each household has the ability to change and customize their property as desired. By having a single hosted instance the purchaser can tweak and customize the software to meet their needs."
How Deveo approaches multi-tenancy is by isolating the data at the company level. This means that the data inside a specific company can never leave or be exposed to other companies inside Deveo. The same applies to user accounts. Each user account is tied to a specific company. This is a very strict form of multi-tenancy and provides an additional layer of security and control on top of the Git, Subversion and Mercurial repositories that can be hosted in Deveo. The picture below represents the differences between the multi-tenancy in Deveo compared to a shared system where no clear isolation between the tenants is in place.
The difference between a shared system model that is in use at Github, Bitbucket and Gitlab cloud services, in comparison to a more strict multi-tenancy that is used in Deveo, is that the potential reachability of the data is much greater in the shared model than it is in the strict model. This will expose systems using the shared model to the two aforementioned two problems:
- Exposing data, and
- forgetting to remove people
Problem 1: Exposing data
The reachability of the data can be defined as the number of potential users having access to the data. In the case of version control system repositories, having access means the ability to read or check out the source code in a given repository.
Products that require no login to see the data are exposing the data to everyone who can access the product. This is not a problem in on-premise installations, where the data is protected either via the firewall or even by a separate network. It is, however, a problem in shared cloud services, where in the worst case scenario you may expose your source code related IPRs to the whole world.
What is required for this to happen is simply that someone by mistake toggles a repository from being private to being public. Suddenly your precious code is available for anyone to download. Given the current number of internet users is over three billion, the potential number of users who might access your code is this exact same number.
In the strict multi-tenancy, the problem is mitigated because users need to login to access any data. In addition to the need to log in, users always log in to a specific company. These two simple sounding facts make your data an order of magnitude safer as the reachability of the data is the number of people who have the ability to log in to the same company scope.
Problem 2: Forget to remove access from people who should not have access
The second problem is not as common but can still happen. When an employee or a collaborator working on your projects leaves, it's common to remove that person from all of the projects he has access to. If you do not remember to remove that person from all of the projects, in a shared system the person is still able to access those repositories and that data you forgot to remove his access from. This is due to the fact that the user account is tied to the service, and not one part of it.
In strict multi-tenancy, that user is removed once from the whole company scope, which revokes the from all of the data since the user is no longer able to login to the scope of the company.
In this post, I presented the differences between a shared system and strict multi-tenancy. I consider strict multi-tenancy a necessity for hosting professional code in a cloud service. Strict multi-tenancy brings an extra layer of security and provides an order of magnitude smaller potential exposure of your data.
Have you had problems with data being exposed in one way or another? Or what do you think about strict multi-tenancy vs. a shared system? Let us know in the comments. And if you liked this post, do share it forward.