5 ms·

Logging doesn't help you when you business has to shut down because someone took over you account and deleted everything. Separation of access is important and

by ntnn 8y ago

Logging doesn't help you when you business has to shut down because someone took over you account and deleted everything. Separation of access is important and _required_. Developers don't need access to prod, admins maintaining the infrastructure don't need access to the directory, IDM doesn't need access to either QA or prod. Developers do need full access in an environment to properly test - but that environment should be basically hermetically sealed from the rest of the companies infrastructure. So even if they do screw up the whole business won't be affected.

andrewstuart2 8y ago
If someone took over your account and deleted everything, and you couldn't get any of it back, you weren't taking care of the "availability" third of security. I agree that developers don't need access to everything, but I completely disagree that they should have no access to prod. The games of phone tag and "try typing this" that happens during prod issues is a waste of everybody's time, and I fully believe that the people who write the code should be the ones with both the responsibility of the pagers and the ability to fix the code they've deployed. Everybody is happier, and the job gets done more quickly, when the job gets done by the people most qualified to do it (because they wrote it), and when they bear the consequences of writing bad code. The environment needs to be set up to be forgiving of mistakes, yes, but that's easily done these days and should never result in loss of data if the infrastructure is properly automated. If giving production access means your developers can screw something up, then your admins can just as easily screw something up. Create environments that forgive these failures because they'll happen one way or another.
- georgebarnett 8y ago
  There are already examples companies which have folded overnight after losing creds and having everything deleted. Removing root is not a trust issue - it’s a security surface area issue. You increase the number of audit points and attack options by at least an order of magnitude (1 admin : 10 devs). In a small shop this might be acceptable, however in a large org it’s plain old insane. If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly.
  - voidr 8y ago
    If all I need to do is gain admin to my dev machine and then I'm free to nuke your production database, your company is doomed. > If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly. Or it might be an indicator that you are not relying on archaic and ineffective methods to protect your system.
    - georgebarnett 8y ago
      Who said anything about admin on a dev machine? I don’t give a flying shit about dev environments - they’re polluted with chaos. We are talking about root in prod being granted and yet you seem to be intentionally misrepresenting this.
      - voidr 8y ago
        > you seem to be intentionally misrepresenting this. Top level comment in this thread: > Not getting root on your own machine as a developer? Maybe I missed the part where this thread transitioned from dev to prod. I have no reason to misrepresent a stranger on the internet.
      - yebyen 8y ago
        Seconded that: > Not getting root on your own machine as a developer? was the origin of this thread, and there are tons of places where developers are not permitted root access to their own dev machines. We are not all talking about prod instances. I have this conversation with my own counterparts in network / platform / infosec / application teams (I am an app dev), and in some cases the issue is conflated because dev environments are based on a copy of prod, and the compromise of such prod-esque data sources would be almost equally as catastrophic as an actual prod compromise. If this is your environment, then don't be that guy and make it worse by changing the subject from dev to prod. Don't conflate the issue. Dev is not prod and it should not have a copy of sensitive prod data in it. If your environment won't permit you to have a (structural-only) copy of prod that you can use to do your development work unfettered, with full access, then you should complain about it, or tell your devs to complain if it affects them in their work and not such a big deal for yours. Developers write factories, mocks, and stubs all the time to isolate tests from confounding variables such as a shared dev instance that is temporarily out of commission for some reason, and so they don't have to put prod data samples into their test cases, and in general for portability of the build. Then someone comes along and says "it would be too expensive to make a proper dev environment with realistic fake data in it, just give them a copy of Prod" and they're all stuck with it forever henceforth. It's absolute madness, sure, but it's not misrepresented. This is a real problem for plenty of folks.
IanCal 8y ago
As a dev, I love it when I'm not able to access production systems and poke them.

by ntnn 8y ago

andrewstuart2 8y ago

If someone took over your account and deleted everything, and you couldn't get any of it back, you weren't taking care of the "availability" third of security. I agree that developers don't need access to everything, but I completely disagree that they should have no access to prod. The games of phone tag and "try typing this" that happens during prod issues is a waste of everybody's time, and I fully believe that the people who write the code should be the ones with both the responsibility of the pagers and the ability to fix the code they've deployed. Everybody is happier, and the job gets done more quickly, when the job gets done by the people most qualified to do it (because they wrote it), and when they bear the consequences of writing bad code. The environment needs to be set up to be forgiving of mistakes, yes, but that's easily done these days and should never result in loss of data if the infrastructure is properly automated. If giving production access means your developers can screw something up, then your admins can just as easily screw something up. Create environments that forgive these failures because they'll happen one way or another.

georgebarnett 8y ago
There are already examples companies which have folded overnight after losing creds and having everything deleted. Removing root is not a trust issue - it’s a security surface area issue. You increase the number of audit points and attack options by at least an order of magnitude (1 admin : 10 devs). In a small shop this might be acceptable, however in a large org it’s plain old insane. If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly.
- voidr 8y ago
  If all I need to do is gain admin to my dev machine and then I'm free to nuke your production database, your company is doomed. > If you believe that devs require root then that’s an indicator that your build/test/deploy/monitor pipeline is not operating correctly. Or it might be an indicator that you are not relying on archaic and ineffective methods to protect your system.
  - georgebarnett 8y ago
    Who said anything about admin on a dev machine? I don’t give a flying shit about dev environments - they’re polluted with chaos. We are talking about root in prod being granted and yet you seem to be intentionally misrepresenting this.
    - voidr 8y ago
      > you seem to be intentionally misrepresenting this. Top level comment in this thread: > Not getting root on your own machine as a developer? Maybe I missed the part where this thread transitioned from dev to prod. I have no reason to misrepresent a stranger on the internet.
    - yebyen 8y ago
      Seconded that: > Not getting root on your own machine as a developer? was the origin of this thread, and there are tons of places where developers are not permitted root access to their own dev machines. We are not all talking about prod instances. I have this conversation with my own counterparts in network / platform / infosec / application teams (I am an app dev), and in some cases the issue is conflated because dev environments are based on a copy of prod, and the compromise of such prod-esque data sources would be almost equally as catastrophic as an actual prod compromise. If this is your environment, then don't be that guy and make it worse by changing the subject from dev to prod. Don't conflate the issue. Dev is not prod and it should not have a copy of sensitive prod data in it. If your environment won't permit you to have a (structural-only) copy of prod that you can use to do your development work unfettered, with full access, then you should complain about it, or tell your devs to complain if it affects them in their work and not such a big deal for yours. Developers write factories, mocks, and stubs all the time to isolate tests from confounding variables such as a shared dev instance that is temporarily out of commission for some reason, and so they don't have to put prod data samples into their test cases, and in general for portability of the build. Then someone comes along and says "it would be too expensive to make a proper dev environment with realistic fake data in it, just give them a copy of Prod" and they're all stuck with it forever henceforth. It's absolute madness, sure, but it's not misrepresented. This is a real problem for plenty of folks.

IanCal 8y ago

As a dev, I love it when I'm not able to access production systems and poke them.