One aspect of the implimentation of CloudSinc is the data vaults we built in order to provide secure storage for customer data. As security is job #1 for a SaaS firm, we put in a lot of effort to achieve isolation-by-default in our multi-tenant architecture. I’ll provide further details in future posts, but for now I wanted to cover the principles.

  • Reduce the amount of code high-sensitivity code
  • Leverage 3rd party for generic login*
  • Reduce capability of business logic to need tenant access explicitly

* Okta concerns notwithstanding

Here’s a picture of how the progression from standard monolith to secure zones looks.

In order to isolate the tenants we create a user & tenant-specific IAM role. All interaction from the web is then via this role, meaning even bugs in our business logic can’t affect multiple tenants. Moving the responsibility out of the business logic has a number of effects:

  • simplicity, as less logic is required
  • faster review of code in terms of any security impact
  • segregation of authorisation code allowing extra scrutiny when it does change (typically on a much reduced cycle compared to business logic)
  • exposing data access interaction to AWS audit tools - since every action is now per-tenant, audit tools can be used to examine historical access and even client reporting provided

Hopefully this is useful - do get in contact if interested in discussing in more depth.