3 ms·
I've really only seen 2 core approaches to this: 1.) Free Access to everything. You trust everyone and hope it works out right. This is the simplest solution,
by jlawer 12y ago
I've really only seen 2 core approaches to this:
1.) Free Access to everything. You trust everyone and hope it works out right. This is the simplest solution, but offers nothing to prevent someone violating that trust.
2.) Lock production down to a trusted team. Typically this is done with a full dev / ops separation. Dev build the site and test, Ops run it live and have access to the live database. You trust 3 people in ops fully and no one else. Locking down production often entrenches rivalries between dev and ops, and makes debugging performance issues a PITA as dev typically don't have access to the dataset that is exhibiting the problem.
I've seen both work and both fail, and neither protects you from a trusted employee screwing you over.
What I have seen work rather well though is audit logging. Logging all access to the key systems and periodically (and randomly) auditing access. I've seen this done at the db level, system level and app level before. Basically the story is not that you will be prevented from doing something you shouldn't, but if you are that you will be held accountable for it (typically on the spot termination). However to be effective the company needs to be able to take the high ground and be consistent. This won't work if someone (co-founder, manager) is doing a similar thing and getting away with it.
As long as the data isn't high value (Credit Cards, etc) enough to make the opportunity cost worth it, knowing you will loose your job provides enough to make most hesitant to break the rules.