[michaelmrose]

Forget the analogies having to explicitly misuse the system to violate customers privacy creates a strong disincentive.

All accesses to customers data should require multiple people not by policy but by mandatory access controls.

The fact that employees could hack their employer is true and not meaningful.

The number willing to commit felonies is less than the number willing to risk termination.

[hinkley]

I feel like I asked this before and then didn't bookmark the answers.

What systems are out there for requiring consensus for access? I know about K of N protocols for hardware cryptography, but I'm fuzzy on such systems for, say, admin functionality or data retrieval. Are they all in-house at this point?

I've found over and over again in my work that it's much easier to spout rhetoric about process change when I have provided tools to facilitate those changes. Maybe it's time for us to collaborate on some tooling in this space.

[nicoburns]

I can't remember which company it was, but I once read an article about a company who implemented their own version of `sudo`. Their version required another developer to approve your session before granting root privileges, and then allowed them to watch everything you did.

[TeMPOraL]

I was addressing the lock analogy itself, but going back to the original topic, I believe this line of thinking still applies to an extent. Setting up hoops one has to jump through to do something nefarious is as much about the difficulty of jumping as it is about the very act of jumping. If you have to work around some security features to access customer data, you can't defend yourself by saying you've accessed it "somehow" or by accident.