3 ms·

This is one reason we're moving off AWS and Azure at the moment. Not because of them but because it's so damn easy to accidentally fuck something up on this sca

by buffoon 11y ago

This is one reason we're moving off AWS and Azure at the moment. Not because of them but because it's so damn easy to accidentally fuck something up on this scale and that would be endgame for us. There is not much between deploying a correct and a faulty bucket policy that instantly exposes your entire archive over the internet. If it is a CIFS / NFS mount on your own infrastructure, then not so easy.

dj-wonk 11y ago
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.)
- fixermark 11y ago
  > 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.
- pfortuny 11y ago
  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.
- buffoon 11y ago
  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.
MichaelGG 11y ago
They really should offer ways to disable public access by default. Same as having ways to disable deletes without some kind of secondary confirmation.

by buffoon 11y ago

dj-wonk 11y ago

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.)

fixermark 11y ago
> 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.
pfortuny 11y ago
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.
buffoon 11y ago
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.

MichaelGG 11y ago

They really should offer ways to disable public access by default. Same as having ways to disable deletes without some kind of secondary confirmation.