Hacker News Reader

Comment by mmanfrin | Hacker News Reader

The screenshots from the leaker mention that they are using "redshift", which is the name of Amazon's RDB product. Which means this is about people who have access to the database. This is unsurprising that they could access customer data given access to their database. I'm not sure how you prevent this without preventing access to the db (and there are legitimate reasons people within the company would have access -- DBAs, Engineers who are writing direct queries, etc).

Not defending people accessing PII, but just saying there are legitimate reasons why someone could have access.

View on HN

Even if all their data is within Redshift, you can still control access in a way that is more fine grained than just "everyone has access to everything"

See the docs -> https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html

Perhaps some people have legitimate reasons to access some sensitive info, perhaps not. But not _everyone_ needs that access anyways.

Eh, I think the only thing that works is you kill your velocity and institute a bunch of processes, and bureaucracy or put up light gates and hire people that you trust to do the right thing. It sounds like they have some gating, but perhaps they need better auditing, and logging?

Anyone who can access that database can _probably_ deploy code too. If you can deploy code, you can sneak in whatever you want.

You can't prevent access but you can log all access and require a written reason for access. That, followed up by routine audits of access logs will reduce and discourage abuse as described in the article.

This is about Redshift, Amazon's cloud-based data warehousing tool. Auditing and logging every individual access made by data analysts, engineers, and others making use of Redshift would make their jobs impossible. One day of queries would take weeks to audit and validate a legitimate use case for all the individual data that got touched, and if you're just going to say "oh they needed everyone's PII because it was a big analytical query like they do all day", you're back at square one.

The reality is that some people are going to need wide-reaching access. You could monitor for certain problematic access patterns, like someone who is supposed to be doing primarily aggregate queries doing a lot of specific ones, and I'm sure that'd be a good thing to do, but to be honest there are probably much higher priorities since employees who need sensitive access are probably going to be able to avoid that type of detection.

Redshift doesn’t have column level access permissions but it does have schema/table level access permissions. That is more than sufficient to prevent this kind of issue.

You can do all development, testing and debugging on databases that have sensitive information removed. Just replacing names and email addresses goes a long way and shouldn't make a difference for the engineer. If there's a bug with a certain ride, the ID for that is enough to test.

Read access to production data is only necessary in very few cases and can be heavily audited.

Reply on news.ycombinator.com