Guardrails - Keeping Customer Data Separate in a Multi Tenant System
Many companies are built upon a multitenant architecture. This means that all customers share the same storage and computing resources: databases, caches, search engines, etc. An individual workspace’s data is isolated and made invisible to others at runtime. This is achieved by using logical safeguards, the most common being: query time filtering using a customers’s unique ID.
Engineers are human, and most engineers are not security experts. This means that sometimes these logical safeguards are implemented incorrectly or they become incorrect after a large architectural change.
We have solved this problem by weaving the customer id into all inline and async work and introducing a middleware that raises an exception of work is attempted outside of that customers workspace. I will talk about how we achieved this and the lessons learned, as well as touching on additional benefits we unlocked along the way.
- 14:15 - 14:45
- 5th October 2023
- Track 2
Staff Engineer, Intercom
I’m a Staff Engineer on Intercom’s Datastores team (which owns all core technologies, including Rails) and have worked here for 6 years as of June 2023. In that time I’ve seen a lot of big and exciting changes, and long the way I’ve become Intercom’s expert on ActiveRecord. In recent times I lead a project to ensure the long term scalability of our MySQL databases with horizontal sharding with lots of low level work at the application layer to make it as seamless as possible for engineers.