3 ms·

> so that people in companies can operate with access to "the information you need but no more." I think SELinux addresses this problem pretty well, but there

> so that people in companies can operate with access to "the information you need but no more." I think SELinux addresses this problem pretty well, but there is no real requirement to give access to developers for a production database when a development database could be setup with test data. I'm not arguing that this is a great idea for IT, but trust has been an issue from the beginning and there are more than a couple of solutions with varying degrees of quality.

munchbunny 8y ago
> there are more than a couple of solutions with varying degrees of quality I think you raise a good point. If I were to phrase my wish better, I think it comes down to your implication that "varying degrees of quality" means some solutions do the job better (like SELinux) and some that do it worse. The more work it takes, the more you end up with startups where everyone has the passwords to the production database because it's just easier operationally. But when you do that, then you start to get into institutionalized risks like Uber employees stalking exes. I'm well aware that this is a case of engineering a solution to cover the 0.01% case, but when it comes to sensitive data, you're usually guarding against a tiny number of bad actors who could do a lot of damage. As an example, let's say you want certain developers to have access to non-sensitive parts of a Postgres database, and you want to be able to temporarily authorize developers with worthy exceptions to touch sensitive data, and you want to leave an audit trail. Let's say you're doing it this way because of HIPAA. It's currently a pain to do, and you'll have to write a bunch of automation to make it work. Now let's say you also have some S3 stores or ETL pipelines using Kinesis, and you have potentially sensitive data in there too. In the ideal case, you could manage the roles and groups and elevations in a more central place, federate those identities over to the Postgres cluster, SSH permissions, etc. That way data and privacy controls could actually be lightweight, which I think would be an overall win for the industry.
- ilovetux 8y ago
  I understand your argument and have heard it first-hand, but from my standpoint (a felon working in IT) I usually push for a workable and sensible security posture because I do not want any more access than I need. A non-felon might not share my (perhaps) paranoid view, but I have a family now and need to pointedly avoid any possible controversy or scandal especially related to security and access. To that end, I feel the need to push for sensible and workable solutions.

munchbunny 8y ago

> there are more than a couple of solutions with varying degrees of quality I think you raise a good point. If I were to phrase my wish better, I think it comes down to your implication that "varying degrees of quality" means some solutions do the job better (like SELinux) and some that do it worse. The more work it takes, the more you end up with startups where everyone has the passwords to the production database because it's just easier operationally. But when you do that, then you start to get into institutionalized risks like Uber employees stalking exes. I'm well aware that this is a case of engineering a solution to cover the 0.01% case, but when it comes to sensitive data, you're usually guarding against a tiny number of bad actors who could do a lot of damage. As an example, let's say you want certain developers to have access to non-sensitive parts of a Postgres database, and you want to be able to temporarily authorize developers with worthy exceptions to touch sensitive data, and you want to leave an audit trail. Let's say you're doing it this way because of HIPAA. It's currently a pain to do, and you'll have to write a bunch of automation to make it work. Now let's say you also have some S3 stores or ETL pipelines using Kinesis, and you have potentially sensitive data in there too. In the ideal case, you could manage the roles and groups and elevations in a more central place, federate those identities over to the Postgres cluster, SSH permissions, etc. That way data and privacy controls could actually be lightweight, which I think would be an overall win for the industry.

ilovetux 8y ago
I understand your argument and have heard it first-hand, but from my standpoint (a felon working in IT) I usually push for a workable and sensible security posture because I do not want any more access than I need. A non-felon might not share my (perhaps) paranoid view, but I have a family now and need to pointedly avoid any possible controversy or scandal especially related to security and access. To that end, I feel the need to push for sensible and workable solutions.