2 ms·

> The likes of AWS already make it a bit harder to expose an insecure server Has this changed recently? S3 was a huge part of data leaks a few years ago, and t

> The likes of AWS already make it a bit harder to expose an insecure server Has this changed recently? S3 was a huge part of data leaks a few years ago, and that's basically a managed server.

jffry 5y ago
Indeed, AWS has both made it more difficult to create a world-readable S3 bucket, and made it much more obvious in the UI. Some things I've noticed just clicking around the S3 console right now: - There is an account-level S3 setting to instruct S3 to ignore public access grants in all buckets in that account (i.e. no matter how bucket is configured, public access is impossible). - The list of S3 buckets in the S3 console homepage includes a prominent column saying if a bucket is private or not. Buckets that allow public access have a warning icon and red color in this column to make them stand out. - When creating a new bucket, the default is "Block Public Access settings for this bucket". If you change this, it gives you a warning and asks you to check a box saying "I acknowledge that the current settings might result in this bucket and the objects within becoming public" - When editing a bucket's access control list, if you grant public access, it asks you to acknowledge "When you grant access to the Everyone or Authenticated users group grantees, anyone in the world can access the objects in this bucket." - Whenever you are looking at file listings or settings of a bucket with a public access rule in its ACL, the S3 console includes a prominent red "Publicly accessible" next to the bucket name in the top nav on every page IMO, this is significantly better than how it used to be, and helps reduce or, with the account-level setting on, fully-eliminate accidentally public buckets. The reality is that proper cross-account IAM role based access is still a little tricky to set up and difficult to test without coordinating with the other party, which means that this won't stop people looking to transfer data to some other account from making a bucket public and assuming it's OK as long as there is an obscure name for the bucket.
- jacquesm 5y ago
  And yet, I still came across one of these recently with vast amounts of absolutely radio active data in it.

> The likes of AWS already make it a bit harder to expose an insecure server Has this changed recently? S3 was a huge part of data leaks a few years ago, and that's basically a managed server.

jffry 5y ago

Indeed, AWS has both made it more difficult to create a world-readable S3 bucket, and made it much more obvious in the UI. Some things I've noticed just clicking around the S3 console right now: - There is an account-level S3 setting to instruct S3 to ignore public access grants in all buckets in that account (i.e. no matter how bucket is configured, public access is impossible). - The list of S3 buckets in the S3 console homepage includes a prominent column saying if a bucket is private or not. Buckets that allow public access have a warning icon and red color in this column to make them stand out. - When creating a new bucket, the default is "Block Public Access settings for this bucket". If you change this, it gives you a warning and asks you to check a box saying "I acknowledge that the current settings might result in this bucket and the objects within becoming public" - When editing a bucket's access control list, if you grant public access, it asks you to acknowledge "When you grant access to the Everyone or Authenticated users group grantees, anyone in the world can access the objects in this bucket." - Whenever you are looking at file listings or settings of a bucket with a public access rule in its ACL, the S3 console includes a prominent red "Publicly accessible" next to the bucket name in the top nav on every page IMO, this is significantly better than how it used to be, and helps reduce or, with the account-level setting on, fully-eliminate accidentally public buckets. The reality is that proper cross-account IAM role based access is still a little tricky to set up and difficult to test without coordinating with the other party, which means that this won't stop people looking to transfer data to some other account from making a bucket public and assuming it's OK as long as there is an obscure name for the bucket.

jacquesm 5y ago
And yet, I still came across one of these recently with vast amounts of absolutely radio active data in it.