Hacker News new | past | comments | ask | show | jobs | submit login

On one hand, I see what you are saying. Other systems make it harder to make changes -- I get it. But is "harder" and "slower" better? Or it just gives humans more time to correct errors?

Many things can be misconfigured -- should we avoid those things and prefer things that are harder / slower/ more manual to configure?

It seems problematic to hear you someone moving away from a solid, tested, automated, fine-grained, multi-layer permission system (AWS with IAM) because it is "too easy to mess up". Let me ask this: what would it take to neutralize the "it is too easy to mess up" argument?

I'd summarize the overall problem this way. People make mistakes. Mistakes take time to surface. Certain kinds of mistakes are worth avoiding, even if it slows down a process.

What are the solutions to this problem? A: Use a slow, tool that does not allow quick, possibly dangerous changes. B: Continue using fast, easily configurable solutions but build technology and process around them to provide the guarantees your business needs.

The problem with the problem A, as described, is you lose the benefits of the fast, nimble system because you want to slow things down.

It seems to me that (B) is worth considering. Perhaps you could look into additional internal tooling and/or process to verify permissions.

(Keeping configuration carefully controlled is essential in any case.)




Well we use option C which is a layered architecture with default deny policies between each layer.

It's not about speed but about the consequences of making a bad change.

Adding tools never decreases risk. Adding process never decreases risk.

Start from impossible then make it possible. Dont start from possible and then make it less likely.


> But is "harder" and "slower" better? Or it just gives humans more time to correct errors?

For risk mitigation, these are somewhat equivalent. There's a reason critical switches get molly-guarded.


You are totally right but there are people for shom some kind of risks cannot (as in they deem it totally impossible) be outsourced: either total responsibility (and hence no delegation) or no business.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: