The document discusses the development of a multi-tenant serverless architecture by Orchestrated.io, emphasizing the importance of data security, automation, and cloud-first principles. It explores the pros and cons of single-tenant versus multi-tenant infrastructures, ultimately advocating for a single tenancy model due to its enhanced security. Various security practices and challenges encountered during the SaaS tool's development are also outlined, along with references for further reading.

1. Multi-tenant Architecture
at Scale with Serverless
July 2018

2. About Us
Emmanuel Kong
Engineering Lead
Pim Ampompun
Senior Devops Engineer
Sumesh Suvarna
Senior Consultant

3. We @ orchestrated.io
We're a boutique consultancy that's been helping
large organisations transform their culture,
using a sensible mix of modern business &
engineering practices.

4. Our Products
people
1000s of them
dependencies
100s of concurrent projects
budgets*
substantial ones
1. Distributed, detached data drives critical decisions. Over-reliance on Excel & PowerPoint!
2. Too much data for humans to reason about. Insights module focuses attention on key
parts.
3. We built an internal tool to support our consultancy first. Now polishing for general
release.
Observations:

5. Our Principles
Customer
focus
Automation
Of
everything
SecurityIs a first-class citizen
Cloud 1st
That’s what you're here for

6. SaaS (Software as a Service)
Just a few of the concerns in making a SaaS tool acceptable to
the Enterprise's data crown jewels:

7. SaaS Infra: Single-tenant or Multi-tenant?
• More client flexibility
• Faster and simpler
backups and restorations
• Enhanced security
• Blast Radius is minimized
• Expensive per tenant
• Simple rollout process
• Zero tenant provisioning
time
• Better scalability?
• Blast Radius is large
• Cheaper per tenant
Single-tenant Multi-tenant

8. Single-Tenant or Multi-Tenant: What did we choose?

9. Tenant Isolations layers on AWS?
Account Layer All the tenants will have their individual AWS accounts
Company XYZCompany PQR Company ABC

10. Tenant Isolation layers on AWS?
VPC Layer Same AWS account, but tenant deployed to a separate VPC

11. Tenant Isolation layers on AWS?
Subnet Layer Same AWS account, but tenant deployed to a separate Subnet protected by Access rules

12. Tenant Isolation layers on AWS?
Container Layer Same AWS account, but tenant deployed to a separate Container cluster protected by Access rules

13. The Answer: single tenancy + serverless

15. Our prototype

16. Overall architecture

17. Graphql service and query resolver

18. Mutation resolver ( Event sourcing)

19. Authentication and Authorization

20. Authentication and Authorization

21. Client App

22. Automation and new tenant onboarding

23. Tighten up the screws

24. Element of Security - CIA triad
Ref: Unix and Linux System Administrator Handbook

25. Basic Security Measures - Rules of thumb
Ref: Unix and Linux System Administrator Handbook

26. #Rule1: Apply principle of least privilege - IAM Role

27. #Rule1: Apply principle of least privilege - IAM Role
Policy
serverless.yml
?

28. #Rule1: Apply principle of least privilege - Lambda roles
-Multi-tenants

29. #Rule1: Apply principle of least privilege - Lambda roles
- Multi-tenants

30. Basic Security Measures - Rules of thumb
Ref: Unix and Linux System Administrator Handbook

31. #Rule2: Layer security measures to achieve defense in
depth

32. #Rule 2: Layer security measures to achieve defense in
depth - Multi-tetants

33. Basic Security Measures - Rules of thumb
Ref: Unix and Linux System Administrator Handbook

34. #Rule 3: Minimise the attack surface - Scenario

35. #Rule 3: Minimise the attack surface - Lambda VPC

36. #Rule 3: Minimise the attack surface - Lambda VPC -
Multi-tenants

37. #Rule 3:Minimise the attack surface -
Scenario 2

38. #Rule 3: Minimise the attack surface - VPC endpoint

39. #Rule 3: Minimise the attack surface - VPC endpoint for
S3, DynamoDB & Kinesis

40. Basic Security Measures - Rules of thumb
Ref: Unix and Linux System Administrator Handbook

41. #Rule 4:Encryption at Rest

42. #Rule 4:Encryption at Rest - Multi-tenants

43. #Rule 4: Encryption in Transit

44. Basic Security Measures - Rules of thumb
Ref: Unix and Linux System Administrator Handbook

45. What we’ve learned in building a SaaS tool
Single Tenant is beautiful in terms of Data Security and Isolation
Not everything is as scalable as marketed (test & observe!)
When possible, use Serverless else Containers
Tag/Label everything, We thank ourselves for this every day
The hard part is not building the App, securing it is. Invest in security early
When using an AWS provided service, understand how traffic flows in and out
Testing locally is a challenge, use docker & create plugins for others to use
Automation is the key, helps you to be bold in integrating new tech faster

46. References:
https://hackernoon.com/exploring-single-tenant-architectures-57c64e99eece
https://www.slideshare.net/developerforce/salesforce-multitenant-architecture-how-we-do-the-magic-we-do
https://www.atlassian.com/blog/archives/when_it_comes_t
https://en.wikipedia.org/wiki/Multitenancy
https://medium.com/@tarekbecker/serverless-enterprise-grade-multi-tenancy-using-aws-76ff5f4d0a23
https://orchestrated.io
check us out @
https://orchestrated.io/tech/
our thoughts on tech:
https://orchestrated.io/dependencies/
tackling the org change challenges @
https://orchestrated.io/people/
https://aws.amazon.com/blogs/networking-and-content-delivery/dynamically-route-viewer-requests-to-any-origin-using-lambdaedge/
Building on the great works of others @
Helping you test AWS services locally @
https://github.com/orchestrated-io/serverless-plugin-offline-dynamodb-stream
https://github.com/orchestrated-io/serverless-plugin-offline-kinesis-stream

47. Thanks!

48. Bonus content: AWS KMS and CMK