3 ms·
I do sometimes wonder about giving every customer separate databases and putting in firewalls (of varying kinds) between each piece of infrastructure, using vau
by andy_ppp 9y ago
I do sometimes wonder about giving every customer separate databases and putting in firewalls (of varying kinds) between each piece of infrastructure, using vault to manage and grant access, check summing changes to peoples accounts (and possibly requiring some obscure system for reading info in each database), and in the end making everything very difficult even if a hacker gets root access to one machine, say, inside your application. Ideally they wouldn't have access to everything.
I'm terrified for example of taking in copies of peoples Passports or Social Security Numbers as part of creating Stripe managed accounts; I'm responsible for confirming they are who they say they are, fine, however I don't want to keep copies of passports lying around on my servers forever. Is it sensible to delete them after they have been reviewed by two people? Should we encrypt them after use and store that encryption key lookup in a separate instance of vault on a different network/AWS account?
Firstly, startups don't have the resources usually to dedicate to these things and secondarily there seems to be a need for a standard set of principles in building less hackable applications. Getting behind the giant metal door should not be enough to become completely compromised, but is there a solution, guide or standard or once I launch am I constantly going to be looking over my shoulder wondering when the breach will happen at Stripe or Google or my own company? It's only a matter of time right?