6 ms·

I’m pretty sure buckets are private by default.

shepardrtc 8y ago
They are private by default. This is just making public/private settings very explicit, and also helping to ensure that anything that was public before the default setting was changed to private is known. This is really just extra CYA because people who really don't know what they are doing are apparently still being put in charge of buckets by companies.
- privateSFacct 8y ago
  Totally true! Some folks use S3 kind of a like a quick dropbox to share big files even internally in an org. Bob in accounting to Sue in finance. One solution I've found if folks INSIST they do not want any login / security. Expose the bucket contents using time expiring shared links (presigned links). This has worked great in one use case I had where users INSISTED on no security with sensitive data. Users can then cut / paste / download / share links for a few hours (all they really want - send it to a few folks on a project). Even if their email is hacked you are OK. Not ideal, but better than nothing. If you look inside orgs, the desire for no security is sometimes surprisingly high!
  - isostatic 8y ago
    > the desire for no security is sometimes surprisingly high! The desire for security to not get in the way is high.
  - closeparen 8y ago
    Those folks are wrong, and the correct answer here is for AWS to stop them. Google Drive and Box are appropriate solutions for that use case. Maybe AWS should launch one too.
    - scarface74 8y ago
      The simplest way is to use CloudBerry. It maps an S3 bucket to a Windows drive.
  - shepardrtc 8y ago
    You could also set up a lifecycle policy to delete anything in the bucket after a day to add even more security.
cjcampbell 8y ago
They are private by default, but it was far too easy for a to enable public access through a bucket policy that seemed sane to the untrained eye. In the systems I've designed, I've built multiple layers of protection around sensitive buckets. I figure it's safest to assume that someone will eventually screw up the policy. When possible, I deny access to the bucket except for explicit whitelisted approvals (alternatively, requests coming from IAM roles or users in the current account). I also encrypt buckets by default and often deny unencrypted uploads. The concept of public access doesn't map in quite the same way to customer-managed KMS keys, so you have good odds that S3 requests would fail on decryption even when a bucket becomes public. Next layer of protection is monitoring via Config rules and Trusted Advisor checks, combined with alarms to ensure that these alerts are actually brought to someone's attention. Finally, except for development accounts, I insist on automating configuration of the environment (and aim to use IAM to prevent manual changes). This is great if you can pull it off, but you don't get there overnight. And you certainly don't get here by relying only on the basic documentation. I would say you don't even necessarily get there by relying on AWS partners. I've seen more than a couple disappoint. All of this to say that I'm happy to add one more guardrail (with much lower overhead).
- scarface74 8y ago
  This is exactly the right approach. AWS hammers people about the “shared security model”, being in the cloud doesn’t stop you from doing stupid stuff. You have all kinds of tools to help you do the right thing.

They are private by default. This is just making public/private settings very explicit, and also helping to ensure that anything that was public before the default setting was changed to private is known. This is really just extra CYA because people who really don't know what they are doing are apparently still being put in charge of buckets by companies.

privateSFacct 8y ago
Totally true! Some folks use S3 kind of a like a quick dropbox to share big files even internally in an org. Bob in accounting to Sue in finance. One solution I've found if folks INSIST they do not want any login / security. Expose the bucket contents using time expiring shared links (presigned links). This has worked great in one use case I had where users INSISTED on no security with sensitive data. Users can then cut / paste / download / share links for a few hours (all they really want - send it to a few folks on a project). Even if their email is hacked you are OK. Not ideal, but better than nothing. If you look inside orgs, the desire for no security is sometimes surprisingly high!
- isostatic 8y ago
  > the desire for no security is sometimes surprisingly high! The desire for security to not get in the way is high.
- closeparen 8y ago
  Those folks are wrong, and the correct answer here is for AWS to stop them. Google Drive and Box are appropriate solutions for that use case. Maybe AWS should launch one too.
  - scarface74 8y ago
    The simplest way is to use CloudBerry. It maps an S3 bucket to a Windows drive.
- shepardrtc 8y ago
  You could also set up a lifecycle policy to delete anything in the bucket after a day to add even more security.

cjcampbell 8y ago

They are private by default, but it was far too easy for a to enable public access through a bucket policy that seemed sane to the untrained eye. In the systems I've designed, I've built multiple layers of protection around sensitive buckets. I figure it's safest to assume that someone will eventually screw up the policy. When possible, I deny access to the bucket except for explicit whitelisted approvals (alternatively, requests coming from IAM roles or users in the current account). I also encrypt buckets by default and often deny unencrypted uploads. The concept of public access doesn't map in quite the same way to customer-managed KMS keys, so you have good odds that S3 requests would fail on decryption even when a bucket becomes public. Next layer of protection is monitoring via Config rules and Trusted Advisor checks, combined with alarms to ensure that these alerts are actually brought to someone's attention. Finally, except for development accounts, I insist on automating configuration of the environment (and aim to use IAM to prevent manual changes). This is great if you can pull it off, but you don't get there overnight. And you certainly don't get here by relying only on the basic documentation. I would say you don't even necessarily get there by relying on AWS partners. I've seen more than a couple disappoint. All of this to say that I'm happy to add one more guardrail (with much lower overhead).

scarface74 8y ago
This is exactly the right approach. AWS hammers people about the “shared security model”, being in the cloud doesn’t stop you from doing stupid stuff. You have all kinds of tools to help you do the right thing.