I am planning an architecture of a web application for my company which is launching a financial service for its partners, and my main question is - does it make sense to put each partner on a different server (or even server groups web/db)?
The application is in some sense similar to https://www.wealthfront.com/ - partners trust us with their assets and provide us with data, which we use to automate investments. Each partner has an account with us, login/password pair and a url where he can log in. After login he gains access to a dashboard which contains all his data presented in charts in tables.
Partners and their data is completely independent from each other. We also have some admin interface to preprocess their data and manage their accounts, but there is a separate web/db/workers adm server and partners feed their data to main db via write-only services (they cannot query any arbitrary information).
Partners data is very sensitive, if any of it falls in wrong hands - the impact could be very serious up to us going out of business.
I have two ways in mind on how to organize an architecture of such service:
Grouped, in which we have one server for each role, all partners are sitting all together on each server
Isolated, in which we also have one server for each role, but each partners gets a set of servers for each role
I see two types of scenarios in which unauthorized access to data could happen:
- Attackers: somebody hacks some server and gains some kind of access to it. Could be anything from simple misconfiguration (ssh access left from public network without password, heartbleed-like vulnerability, ...). This is too vague and isolation surely cannot save from all scenarios, but I still have a feeling that with all other things being equal isolated architecture is more secure, because it creates more barriers.
- Human error: an engineer forgets to add some security checks or inadvertently removes some or gives everyone superadmin powers to see everything, it gets into production and everybody is unhappy. This surely should be prevented by all kinds of rules, reviews, constraints and processes but errors always find their to production. I have a feeling that physical isolation also helps mitigating if something likes happens (even when a junior partner employee gains access to partners senior-only information, it is much better if he gains access to senior-only information of other partner!)
Grouped pros/cons which I see:
- [+] more easily scaled
- [+] less expensive (less servers, can spread load more effectively)
- [+] less to configure (though we are using configuration management tools and host in cloud environment, so it is not a big problem anyway)
- [-] every access checks failure will result in exposure of all data data to user
- [-] hacking into web/db server gives you access to everything (e.g. if some partner decides to explore and somehow successfully finds his way inside our system)
- [-] if one partner creates a lot of load, it hurts everyone (though mitigated by somewhat easy scaling)
- [-] cannot effectively use ip-based restrictions (I think)
Isolation pros/cons which I see:
- [+] every access checks failure will result in exposure of user's own data to himself
- [+] hacking into web/db server gives you only this server data (e.g. if some partner decides to explore and somehow successfully finds his way inside our system)
- [+] separates one partner's load on system from other
- [+] can tune firewall rules more granularly (we can limit access from only partner ip which is not the case for grouped architecture)
- [-] less easily scaled (though this is definitely not a high-load project, so it's not that much of concern)
- [-] more expensive
- [-] more to configure (though we are using configuration management tools and host in cloud environment, so it is not a big problem)
So far I can see a lot of pros for isolation and some little cons, but there is a huge question: since we use configuration management tools, each server will have the same OS, same software and configuration, same codebase and everything. This way if we have any vulnerability, nothing can stop attacker to use them on all servers, isolated or not. Maybe there are also other pitfalls that I cannot see right now that undermine the whole idea.
So, given all that information:
- Do you think that isolated architecture provides more security than grouped?
- Are there any serious tradeoffs/showstoppers to isolated architecture that I haven't thought of?
- Do you think there's some common alternative solution to this problem (not grouping or isolating, but something else)?
- If isolated architecture is good, is there any sense splitting web and db servers (security-wise), since they are already isolated from everything else and splitting them doesn't add more security?