AWS strains to make Simple Storage Service not so simple to screw up Amazon wants you to know that it's not to blame for the data you've exposed though its cloud storage service. AWS Simple Storage Service (S3) is, after all, simple. No doubt you tried to keep your data secure. But let's face it, in the sixteen years S3 has been available, the cloud-based data storage service hasn't been simple …
I agree that S3's control interface is a huge wreck. (15 months here) What I DON'T agree with is at someone can make the access public "by accident". You have to either be a ******* yourself & either not read or not bother to understand what you are doing, or you do it intentionally.
It's almost a shame that when these things blow up, it's not literally in the face of the culprits.
Making a bucket private is really simple, it's default.
Adding more complexity and additional controls doesn't actually make it easier, though it can help with compliance tasks like verifying that buckets are still private.
The problem is that connecting to a public bucket is far easier. When security is hard, people work around it.
It's not an easy fix but it's not wildly difficult either, it's just that AWS aren't on the hook for your mistakes (when implementing their broken process) and customers have low standards.
It's true: with all their (tech) power and resources, AWS UI's are simply an absolute mess. AWS shows to me, IMHO, what programmers will create when they have little concern for end user experience; all the power and ability is there, if you can understand the disaster that passes for "concept in design" and can then comprehend exactly what they are trying to communicate to you within said structural disaster.
It is a design failure and rather than admit that, and create a web UI that makes sense, they either come up with excuses or apply simple overlay patches in hopes of mitigating the UIX failures.
Some programmers will create bad UIs, and bad program concepts/organization, just as some programmers create terrible variable- and function- names; their brains just aren't wired for doing it in a sensible, meaningful-to-others fashion.
This is not a new phenomonon. One of DEC's early OSes for the PDP-8 had an account admin program which used the [Escape] / [Alt Mode] key to delete an account! Quite counter-intuitive.
You had an extra word when. "Security is hard, people work around it." Otherwise, your post neatly summarized my thinking as well.
It's not *setting* the security that needs to be made simpler. It's *debugging* which security setting is causing the application to halt (or return no records) that needs to be made simpler. `grep -Fi "auth" security.log` isn't going to cut it for the low code folks. They would rather search for "how do I allow all on amazon s3". It's the "I just need this working now, I'll figure out the security later" mentality that needs to go, but boss is tapping his toes.
Bidirectional grants in IAM, assumed roles, inherited roles, instance roles, deployment/tools roles, global bucket rules, and temporary access tokens. Multiply that by a ton of internal operation codes that no longer match APIs. You can see why an outsourcing company with a tight deadline is simply going to flip the switch to make it public.
Between that and needing to use a multi-part API for streaming uploads, I think the word "simple" might be misused.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
