Ask HN: How do you keep employee eyes off production data in new startup? | Hacker News Reader

Ask HN: How do you keep employee eyes off production data in new startup?

3 pointsneilv3 comments

Let's say you're early in startup (not enough resources, have to move fast before runway ends, have to fix problems rapidly)... and prod has sensitive user data.

I just had a thought about my tentative next project, that I'd have to be very careful typing `npx prisma studio` (or run any other generic database browser), such as when debugging or doing database surgery, because it would be too easy to accidentally glimpse information that should be private to the users. And I couldn't look at some tables at all this way.

What are some low-cost, viable ways for an early startup to isolate this private data from founders&employees even accidentally seeing it?

An obvious measure you'd do in any case is to have a separate "prod" database, which is harder to access, and by fewer people. (You can usually work with dummy data instead.) But even then you'll need to go in there sometimes. And also there's debugging logs that more people are likely to see, more often, which can leak information.

So more than that is needed.

Also, especially if you're dogfooding something like social media, there's the possibility that some employee might be very motivated to access user data intentionally (e.g., the "LOVEINT" problem, or when a Reddit exec showed off their power inappropriately). Access logging can help with this, but can be circumvented, and is also runway-expensive to implement.

Late to this, but this usually looks like:

1. Vet people in sensitive positions with things like background checks. This isn't very effective, but gosh will you feel silly if you hire an actual criminal or spy from a country that isn't very good at it.

2. Use access controls so people can only access what they need to for their role. Logged and audited "break glass" functions to access additional data in emergencies can let you set more restrictive permissions for day-to-day use.

3. Be extremely clear to people about privacy expectations, and that bad-faith access of private data is possibly a crime and certainly subject to termination. This is where you can make a strong distinction between not stressing about accidents and volunteering if you do something by mistake vs intentional access and covering it up.

4. Keep access logs and audit them. We randomly audit data access events, as well as randomly selecting customers and auditing all accesses to their data. If we ever had suspicions about an employee we would audit everything they did in a particular time.

5. Use "trip-wires" on particularly sensitive accounts or that people might have incentive to look at, such as celebrities or coworkers.

As an example, there's a lot of potential liability for healthcare providers if their employees violate customer privacy. So generally they do employee background checks to try to make sure they don't hire known criminals, they put them through a privacy law compliance training, and an alert gets fired off to security if someone tries to look up Britney Spears' patient records or accesses records with their same last name (family members).

At a government job, new contractors had to watch a video of a serious man telling us the jailtime and monetary penalties for accessing Personally Identifiable Information (PII) inappropriately. I never even tried to get the PROD credentials.

Thank you. As an early-startup variation on that, I think the solution for intentional snooping might be (assuming you you did a good job picking and incentivizing people) to impress upon everyone that snooping is NOT OK, and is a potentially company-ending scandal, that threatens the mission and the personal futures that the entire team are working towards.

That, and don't let anyone get stressed (for whatever reason) to the point that their judgment goes bad.

I'm still wondering about low-hanging fruit tactics to avoid unintentional exposure to user data in the course of moving fast with too little resources.

(Say, prod is down, and normally debugging would include looking at tables, but you haven't built a fleet of privacy-protecting ways to rapidly get the same diagnostic information and intuition about the database that you can just by looking at it.)

Reply on news.ycombinator.com