Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Shifting blame doesn’t help much when you lose customers (or pay financial penalties) due to non—compliance.

You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.



It’s rare for things to go so disastrously wrong that legal sway is relevant. What’s much more common is an angry CTO looking for someone to be mad at, and Amazon doesn’t have any particular ability to deflect that.


If you're dealing with businesses where compliance is required, such as PCI, HIPPA, or FedRamp, legal sway is absolutely relevant. If you should have a breach and an associated fine, Amazon can easily push the blame (and the likely-company-breaking fines) back on you.


AWS' compliance model isn't a magic wand that makes your crappy app's XSS vulnerabilities go away. The real question: do you think AWS will try to push responsibility for a breach to their customers unjustly?

If you don't adhere to the shared responsibility model and a contractor checks long lived IAM credentials into Github, that breach is definitely attributable to you and you deserve all the "blame" you get.

But if someone figures out how to trick AWS' IAM into issuing credentials that allow PHI to be pulled out of S3, do you think that gets passed along to a customer?


Yup! If something goes wrong with compliance, who is going to win the finger pointing game? A smaller company that needs to outsource their compute, or Amazon?


If it was really Amazon's service that was at fault, then what are the chances that only one client is affected?




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

Search: